Sborník databázové konference. Editoři. Luboš Popelínský Ondřej Výborný. Fakulta informatiky Masarykova univerzita Brno

Transkript

1 DATAKON 2007 Sborník databázové konference Editoři Luboš Popelínský Ondřej Výborný Fakulta informatiky Masarykova univerzita Brno Brno, Hotel SANTON Česká republika října

2 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. Masarykova univerzita, 2007 ISBN Autoři jsou uvedeni v obsahu. Příspěvky jsou publikovány ve tvaru, v jakém je dodali autoři, bez podstatných změn.

3 DATAKON 2007 Proceedings of the Annual Database Conference Edited by Luboš Popelínský Ondřej Výborný Faculty of Informatics Masaryk University Brno Brno, Hotel SANTON Czech Republic October 20-23,

4 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. Main topics are, among others, basic principles of database management, analysis and design of large information systems, development tools, application configuration and management tools, theoretical and technical aspects of data manipulation. 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. Masaryk University, 2007 ISBN The authors are mentioned in the table of contents. Contributions are printed as delivered by the authors without substantial modification.

5 Předmluva Je mi potěšením uvést několika slovy sborník dalšího ročníku jedné z nejstarších tuzemských, tj. českých a slovenských, informatických konferencí. Hlavními tématy tohoto významného setkání odborníků z praxe s odbornou veřejností akademickou byly tentokrát Architektury sítí Časová, časově prostorová a geografická data Dobývání znalostí z dat a z textu Informační bezpečnost, důvěra a zachování soukromí Kvalita dat Metody konceptuálního modelování Moderní databázové technologie Multimediální data Sémantický web Technologie pro počítačem podporovanou výuku Vyhledávání na webu XML technologie Letos jsme se nově zaměřili na dvě oblasti použití informačních technologií, a to na oblast krizového řízení a s ním související informační bezpečnosti a na technologie pro e-learning. Potěšitelný je nárůst počtu zaslaných příspěvků. V recenzním řízení, kdy každý příspěvek recenzovali tři recenzenti, bylo z 33 zaslaných vybráno 11 příspěvků, 5 krátkých sdělení a 3 případové studie. Dovolte mi na závěr poděkovat všem, kteří umožnili vznik tohoto sborníku, především autorům tutoriálů, zvaných přednášek a zaslaných příspěvků. Téměř všem členům programového výboru děkuji za odpovědné recenzování. Hlavní tíha při přípravě sborníku spočívala na Ondřeji Výborném, kterému patří můj velký dík. V neposlední řadě pak patří poděkování také sponzorům konference a organizačnímu výboru v čele s Janem Staudkem. Brno, 9. září 2007 Luboš Popelínský Fakulta informatiky Masarykova univerzita Brno předseda programového výboru

6 Preface It is a pleasure to introduce new proceedings of DATAKON, one of the oldest computer science conferences in Czech lands and Slovakia. Main topics of this meeting of experts both from enterprises and academy are Network architectures Temporal, spatiotemporal and geographic data Data and text mining Privacy and security Data quality Conceptual Modeling Modern database technology Multimedia Semantic web Technology enhanced learnig Web search XML This year the program focuses on two information technology areas, crisis management with related information security and technology enhanced learning. A number of submitted papers significantly increased if compared to the last year. From 33 submissions 11 has been chosen as a long contribution, 5 as a short contribution and 3 as a case study. All papers have been reviewed by three members of the program committee. I would like to thank to everybody who participates on preparation of this volume, namely to authors of tutorials, invited lectures as well as contributed talks. I also thank to almost all members of the Program Committee for their work during the reviewing process. My special thanks are due to Ondřej Výborný for editing and completing this volume, to sponsors and to organizing committee and its chair Jan Staudek. Brno, September 9 th, 2007 Luboš Popelínský Faculty of Informatics Masaryk University Brno Program Chair

7 Organizace konference Conference Organization Řídící výbor (Steering Committee) Předseda (Chair): Jaroslav Pokorný, MFF UK Praha Členové (Members): Miroslav Benešovský, NESS Czech s.r.o. Mária Bieliková, FIIT STU Bratislava Jiří Gregor, Progress Software, Praha Petr Hujňák, Per Partes Consulting, Praha Karel Richta, FEL ČVUT Praha Zdenko Staníček, FI MU Brno Programový výbor (Program Committee) Předseda (Chair): Luboš Popelínský, FI MU Brno Členové (Members): Pavol Bartoš, Softec s.r.o.,bratislava Miroslav Benešovský, NESS Czech s.r.o. Mária Bieliková, FIIT STU Bratislava Jiří Gregor, Progress Software, Praha Leo Galamboš, MFF UK Praha Petr Hanáček, FIT VUT Brno Tomáš Hruška, FIT VUT Brno Petr Hujňák, Per Partes Consulting, Praha Dušan Chlapek, VŠE Praha Jan Janeček, ČVUT Praha Karel Ježek, ZČU Plzeň Petr Kroha, TU Chemnitz Štefan Kovalík, Žilinská univerzita, Žilina Sekretář (Secretary): Jan Lužný, DCIT Praha Karol Matiaško, Žilinská univerzita, Žilina Ján Paralič, TU Košice Jiří Peterka, MFF UK Praha Jaroslav Pokorný, MFF UK Praha Karel Richta, FEL ČVUT Praha Jan Rychlík, ZČ Plzeň Václav Řepa, VŠE Praha Tomáš Skopal, MFF UK Praha Václav Snášel, VŠB-TU Ostrava Zdenko Staníček, FI MU Brno Jan Staudek, FI MU Brno Petr Tůma, MFF UK Praha Tomáš Vlk, TRIL s.r.o., Kladno Peter Vojtáš, MFF UK Praha Jaroslav Zelený, IBM ČR Praha Jaroslav Zendulka, FIT VUT Brno Ondřej Výborný, FI MU Brno

8 Organizační výbor (Organization Committee) Předseda (Chair): Jan Staudek, FI MU Brno Členové (Members): Petr Hanáček, FEI VUT Brno Renata Havelková, FI MU Brno Petra Kohoutková, FI MU Brno Dana Komárková, FI MU Brno Lukáš Patka, FI MU Brno Vladimír Pečený, FI MU Brno Šimon Suchomel, FI MU Brno Tomáš Staudek, OPTIMUS, s.r.o. Ondřej Výborný, FI MU Brno DATAKON 2007 organizují (DATAKON 2007 is organized by) Česká informatická společnost, pobočka Brno Česká společnost pro systémovou integraci Fakulta elektrotechnická, ČVUT Praha Fakulta informatiky, MU Brno Matematicko-fyzikální fakulta, UK Praha Slovenská informatická spoločnosť Sponzoři konference DATAKON 2007 (DATAKON 2007 Sponsors) Mediální partneři (PR partners) BERIT, a.s. IBM Česká republika, s.r.o. ICZ a.s. InterSystems B.V. Progress Software, s.r.o. Qbizm Technologies, Inc. SOFTEC, s.r.o. TATRA Banka, a.s. TurboConsult, s.r.o. Vema a.s. Business World ComputerWorld IDG Softwarové noviny

9 Obsah (Contents) Zvané přednášky (Invited Lectures) Informační systém MU: architektura a implementace v rozsáhlém prostředí velké organizace 1 Michal Brandejs, Miroslav Křipač Flexibilný IS riadený metadátami 7 Juraj Červeň Vyhledávání na Webu 17 Leo Galamboš Data mining v praxi 25 Miloslav Nepil Krizové řízení 39 Jaroslav Pejčoch Tutoriály (Tutorials) Bezpečnost IT podle standardu řady ISO2700x 43 Jan Mikulecký, Libor Široký Velké textové korpusy v praxi 58 Karel Pala, Pavel Rychlý Vizualizace geografických dat 59 Karel Staněk Ontologické inženýrství 60 Vojtěch Svátek, Miroslav Vacura Vybrané příspěvky (Contributed Talks) Chování uživatelů elektronické pošty 92 Dan Cvrček, Kamil Malinka Formálny model pre dolovanie synsetov a jeho využitie 102 Ján Genči

10 Web Search with Variable User Model 111 P. Gurský, T. Horváth, J. Jirásek, S. Krajči, R. Novotný, V. Vaneková, P. Vojtáš Vyhledávání a porovnávání znaků českého znakového jazyka 122 Michal Kopecký Nasazení federací ve velkém distribuovaném prostředí: systém pro správu interakcí léků 132 Daniel Kouřil, Martin Kuba, Michal Procházka Úložiště dat v servisně orientovaných systémech 142 Jaroslav Král, Michal Žemlička Data Preparation for User Profiling 152 Marek Kumpošt Testování kvality snímků otisků prstů 161 Filip Orság, Martin Drahanský Bezpečnost čipových karet a detekce vykonávaných operací pomocí genetického programování 169 Peter Pecho, Jiří Schäfer Sémantický web: vize globálního úložiště dat? 176 Martin Řimnáč, Roman Špánek, Zdeňka Linková Multidimensional algebra and its graphical representation 187 Lukáš Stryka, Tomáš Hruška, Michal Máčel Krátké příspěvky (Short Talks) Podpora procesov tvorby nových znalostí 198 František Babič, Karol Furdík, Ján Paralič, Jozef Wagner Diagram nebo text? 202 Miroslav Benešovský Využití databázového mirroru SQL Serveru 2005 pro řešení odolnosti informačního systému úpravny uhlí proti výpadkům 206 Roman Danel

11 MBA v Marketingu prostredníctvom virtuálnej univerzity 211 Jozef Hvorecký, Vladimír Burčík, Ivan Žáry GPGPU triedenie praktické skúsenosti 215 Martin Jurko, Ján Genči Případové studie (Case Studies) Praktické zkušenosti s testováním webových aplikací v heterogenním prostředí 219 Dušan Juhás, Miroslav Kroc Využitie firemného frameworku (JavaTEC) v projektoch Sociálnej poisťovne 227 Stanislav Straka Rozširovateľný model bankovníctva 241 Ľubor Šešera Industriální sekce (Industrial Section) Podpora aktualizace základní báze geografických dat (ZABAGED) 251 Rudolf Richter Zpracování komplexních událostí a architektury řízené událostmi 256 Mark Palmer, Michal Džmuráň Softec Invenio 267 Peter Franz Rejstřík autorů (Author Index) 271

12

13 Informační systém MU: architektura a implementace v rozsáhlém prostředí velké organizace Michal BRANDEJS 1, Miroslav KŘIPAČ 2 1 Vývojový tým IS MU, Masarykova univerzita Botanická 68a, , Brno brandejs@fi.muni.cz 2 Vývojový tým IS MU, Masarykova univerzita Botanická 68a, , Brno kripac@fi.muni.cz Abstrakt. Masarykova univerzita již devátým rokem provozuje vlastní jednotný systém na evidenci a celkovou elektronickou podporu studia. Jedná se o striktně webový on-line informační systém s přímým přístupem přibližně aktivních uživatelů a bezprostřední propagací změn v datech na všech úrovních. Cílem této přednášky je seznámit posluchače s hlavními principy architektury systému. Během prezentace budou rovněž diskutovány výhody, úskalí a získané praktické zkušenosti s principem distribuovaného ukládání dat, které se stává v poslední době populárním. Představeno tak bude několik produkčně používaných metod ukládání dat včetně využití databázových clusterů, plně distribuovaných datových úložišť a technologií z oblasti tzv. High-Performance Databases. Klíčová slova: Informační systém Masarykovy univerzity, databázové systémy, databázove clustery, webové systémy. 1 Úvod a motivace Informační technologie podporující základní chod velkých organizací nebo podniků se postupem času staly běžnou a zejména nezbytnou součástí našeho života. Bez snadno dostupných elektronicky evidovaných údajů se neobejdeme. Ne vždy je však implementace složitých procesů tak úspěšně použitelná v malém prostředí snadno rozšiřitelná do heterogenních prostředí rozsáhlých organizací. Jeden z prvních přirozených požadavků na takový systém je přístupnost údajů pro kohokoliv. Počítačový systém, který eviduje důležité údaje není již v praxi dostačující ve chvíli, kdy tyto údaje jsou přístupné (byť plně elektronicky) pouze jednomu nebo několika málo vybraným pracovníkům, kteří se pak stávají nutnými prostředníky pro ostatní uživatele, kteří data skutečně využívají. Například finanční účtárna se může stát úzkým místem pro efektivní správu finančních toků ve chvíli, kdy bude jako jediná schopna zadávat do elektronického systému data a číst z něj výstupy. Ve L. Popelínský, O. Výborný (eds.), DATAKON 2007, Brno, , str. 1-6.

14 2 M. Brandejs, M. Křipač: IS MU: architektura a implementace v rozsáhlém prostředí velké organizace skutečnosti je potřeba, aby každý člen organizace mohl zadávat finanční operace na které má právo a číst výstupy, které z nich plynou. Tento přirozený a snad dnes již úsměvný požadavek však není jednoduché ve skutečnosti implementovat takto doslova. Jak navrhnout systém, který bude umožňovat plný přístup k úplně všem kritickým údajům nejen pro deset ale i pro tisíc nebo deset tisíc lidí? Jak takový systém nasadit a jak jej udržet v chodu? Jak pružně a nejlépe obratem reagovat na závažné softwarové chyby? Druhým kritickým požadavkem je rychlost zpracování dat. Jaký čas je ještě akceptovatelný pro zpracování transakce nad daty, které potřebujeme evidovat, abychom se dozvěděli výsledek? Stačí pro naše interní procesy tři dny, které stačí bankám pro plně elektronicky zadaný přenos peněz z jednoho běžného účtu na druhý? V případě velkých organizací se pak setkáváme s dalšími problémy, které musí informační technologie podchytit a podporovat. Tím je například organizační struktura, řízení a vůbec celková vnitřní provázanost. Stačí zmínit přínos, který přináší jednotné informační prostředí bez ohledu na to, ve které části (oddělení, pobočce, závodu) k údajům přistupujeme. Propojování dat (a s nimi souvisejících znalostí) napříč různými (a v principu dost odlišnými) částmi rozsáhlé heterogenní organizace vede k usnadnění nejen vnitřních procesů, ale zejména k jednotnému a transparentnímu fungování navenek a tím i k výraznému zkvalitnění poskytovaných služeb pro koncové zákazníky nebo uživatele. Toto jsou jen některé z problémů, které stojí také za motivacemi pro zavedení plně elektronizované podpory výuky na Masarykově univerzitě. Ta je v současné době realizovaná pomocí tzv. Informačního systému Masarykovy univerzity (IS MU) [1]. Konkrétně tedy každý uchazeč, student, absolvent, učitel či zaměstnanec administrativy (studijní referent, ekonom ale i vedoucí na všech úrovních) má přímý přístup do systému s možností plného ovlivnění (ale také plné zodpovědnosti) všech dat, které souvisí s jeho posláním na univerzitě. Samozřejmostí tak jsou nejen plně elektronizované výkazy známek (dříve známé jako indexy) a další evidence (seznamy studentů v daném kurzu, přihlášených ke zkoušce), které jsou už dávno evidovány výhradně elektronicky, ale i jejich naprostá vzájemná provázanost. Evidence těchto dat je pak prováděna striktně on-line. To znamená, že pokud například student v určenou dobu projeví zájem o studium konkrétního předmětu, systém sám vyhodnotí celou řadu obecně složitých předpokladů a v případě úspěchu zaeviduje studenta jako řádně zapsaného k danému předmětu. Student se tak ihned dozví případné důvody, proč si daný předmět právě on zapsat nemůže, neboť důvody jsou zcela individuální. Vzniká tak rychlá a přesná evidence, která navíc podporuje zmiňovanou integraci napříč velmi různorodých součástí. Není administrativně složité, aby si například student specializující se na mezinárodní obchod navštěvoval oficiálně v rámci svého studia kurz japonštiny, který je vyučován v jiné části města apod. Toto jsou pouze některé základní principy, na kterých IS MU dnes funguje. Samozřejmostí jsou i další služby jako je elektronická podpora samotné výuky (online testování na počítači přímo v IS MU včetně udělení známky, scanování a rozpoznání písemných testů, systém pro odhalování plagiátů ve studentských pracích, multimediální výukové materiály), bezpečná správa a vyhledávání v dokumentech, správa identifikačních karet a přístupů, komunikace ( , akademické i volné diskuse, elektronické nástěnky) a v poslední době také podpora pro on-line prodej

15 Zvaná přednáška 3 vzdělávacích aktivit široké veřejnosti. Všechny tyto a mnohé další služby těží z jednotného plně sdíleného prostředí, které přináší zmiňované vlastnosti včetně široké dostupnosti a rychlé propagace změn. Na druhé straně však implementace takového systému včetně dosažení vysoké stability systému a nezbytné reakce na různé formy přetížení vyžaduje řadu různých implementačních rozhodnutí, které budou diskutovány v následujících kapitolách. 2 Architektura systému Základem architektury systému je plně webové prostředí pro všechny uživatele bez rozdílu. Pokud odhlédneme od komunikace s ostatními systémy univerzity, není do systémy možný jiný přístup, než pomocí webového prohlížeče. Bez ohledu, zda se připojuje student z mobilního telefonu na prázdninovém pobytu, nebo referentka provádějící různorodé datové operace po celou pracovní dobu z vlastní kanceláře, vždy je přistupováno pomocí webového prohlížeče. Základní výhoda tohoto přístupu spočívá ve velmi snadné správě a údržbě aplikací. Na straně koncového klienta je nutná pouze běžná podpora pro standardní prohlížeč, která často nepřináší další náklady oproti běžné správě výpočetní techniky. V prostředí, kdy i zmíněných referentů jsou řádově stovky nebo tisíce, Jakákoliv změna v aplikaci je pak propagována všem a ihned, což přináší v podstatě největší možnou flexibilitu vůči reakcím na chyby všeho druhu a tím i požadovanou stabilitu. Druhou výhodou je samozřejmě přístup z libovolného místa připojeného do Internetu, kterou stále častěji využívají nejen uživatelé pro prezentační část, ale i ti, kteří se systémem pracují velmi intenzivně (například práce z domova apod. ). Naopak tento přístup přináší také řadu úskalí. Ve chvíli, kdy podnikový informační systém stavíme primárně na klasických aplikacích a webové rozhraní použijeme pouze pro prezentaci nebo sběr základních údajů nezpracovaných on-line, je možné mnohem přesněji určovat požadovaný výkon a optimalizovat chování aplikací při zátěži. Obecně otevřený webový systém jakým je IS MU se tak mnohem snadněji stane terčem problémů souvisejících s přetížením a nebo naopak většinu doby jeho hardwarové kapacity nejsou využity. V takovém případě je nutné využít další sofistikovaná řešení pro řízení přetížení, která jsou nad rámec této přednášky. Nespornou nevýhodou webových řešení je pak složitější přizpůsobení uživatelských rozhraní pro snadné zadávání velkého množství údajů a podpora dalších periferií (jako například kvalitní grafické výstupy a tisk obecně), které jsou v tomto případě složitější, než s využitím standardizovaných rozhraní operačních systémů. Jiný je rovněž náhled na zajištění bezpečnosti systému, se kterou je také nutné počítat. 3 Základní komponenty systému Kromě běžných webových prohlížečů, které se také nemalou měrou podílejí na chodu systému a zpracování aplikací jsou všechny součásti systému plně pod kontrolou Vývojového týmu IS MU, který zajišťuje také samotný provoz systému. Ten je pak

16 4 M. Brandejs, M. Křipač: IS MU: architektura a implementace v rozsáhlém prostředí velké organizace umístěn na několika základních místech v budovách univerzity po městě Brně. Základní jádro systému je pak připojeno do sítě CESNET a tím i do Internetu dvěma obecně nezávislými linkami. Ty jsou obsluhovány nezávislými routery, které se starají také o primární ochranu vnitřní sítě IS MU například na paketové úrovni. Další sada strojů, tzv. brány, slouží při vzájemné zástupnosti pro distribuci požadavků klasického HTTPS spojení na aplikační servery. Cluster aplikačních serverů pak provádí jak zpracování HTTPS komunikace (včetně šifrování a reakcí na nestandardní stavy), tak běh aplikací, které jsou přímo navázány na jednotlivé fáze zpracování HTTPS požadavků. Kromě mechanismu lokálních vyrovnávacích pamětí jsou data, se kterými aplikace pracují, přístupná na další vrstvě, databázovém serveru. Ten je realizován jako jeden systém se sdílenou pamětí a jeho princip je popsán dále. Kromě těchto základních součástí jsou v rámci provozu IS MU k dispozici další servery například pro automatický převod různých formátů dokumentů (formáty Microsoft Office, OpenOffice, PDF, běžný text), fulltextové vyhledávání, generování sestav, přesné a bezpečné vyhledávání podobností v dokumentech, zálohování a zabezpečení včetně automatické antivirové ochrany nad uloženými dokumenty. Základním a v současné době téměř jediným využitým operačním systémem na všech serverech je Linux ve dvou různých distribucích. Jako webový server je použit Apache HTTP Server a aplikace využívají vlastní aplikační prostředí v jazyce Perl. Databáze je spravována pomocí produktu Oracle Database ve verzi Enterprise Edition. 4 Distribuce dat Základním předpokladem pro zpracování dat uvnitř IS MU je sdílení všech potřebných údajů napříč všemi součástmi. Tím dochází k bezprostřední propagaci změn a jednodušší správě jednotlivých údajů. Na druhou stranu sdílení údajů může vést ke snížení spolehlivosti v případě chyby (výpadku) v některé z kritických částí sdíleného systému a zároveň ne vždy lze snadno navýšit potřebné zdroje (ať už disky pro samotné uložení dat nebo výpočetní součásti jako procesory a paměti pro jejich zpracování). Z pohledu zpracování dat využívá IS MU dvou základních přístupů. První z nich slouží pro zpracování velice strukturovaných dat s velmi častou frekvencí změn. Tato data jsou všechna plně spravována pomocí databázového systému Oracle Database s využitím vlastního mechanismu vyrovnávací paměti na straně aplikačních serverů pro data, která jsou velmi často čtena, ale málo měněna. Příkladem takových dat je seznam studentů navštěvujících daný kurz nebo samotné údaje o kurzu. Druhý typ údajů představují rozsáhlé dokumenty a jiná objemná data, které je potřeba ukládat jako celek (nejsou vnitřně strukturovaná z pohledu systému), neprovádí se v nich změny přímo, ale systém slouží pouze jako prostředník pro jejich uchování a sdílení. Pro tento typ údajů slouží v IS MU speciální distribuované úložiště, které pomocí vlastní infrastruktury ukládá tyto dokumenty na disky jednotlivých aplikačních serverů, které by jinak zůstaly téměř nevyužity. Tímto způsobem dochází jednak k velmi efektivnímu využití (a případnému nárůstu) diskové kapacity a jednak k optimální distribuci zátěže při masivní práci s těmito

17 Zvaná přednáška 5 dokumenty. Každý dokument pro případ výpadku je pak uložen na nejméně dvou uzlech. Příkladem dat v distribuovaném úložišti jsou studentské práce (obecně textové, tabulkové a další dokumenty), multimediální výukové materiály či celé obrazy kompaktních disků používaných ve výuce. Výhody, které skýtá interní distribuce dat uvnitř navenek integrovaného systému se sdílením všech dat, je možné využít také pro data relačního typu. Zejména v poslední době k tomuto účelu vznikají různá řešení databázových systémů obecně označované jako databázové clustery [2]. Nabízí se tedy otázka, proč IS MU v současné době nevyužívá toto řešení také pro ostatní typy dat. Prvním cílem pro nasazení databázového clusteru pro zpracování dat je zvýšení dostupnosti v případě chyby uvnitř datového systému. Tato myšlenka předpokládá, že v případě chyby například v hardware databázového serveru je k dispozici druhý server, který je okamžitě schopen převzít provoz a obsluhu aplikačních serverů. Za tímto účelem je však nutné použít tzv. databázové clustery se sdíleným diskem, který předpokládá, že data z chybného uzlu budou dostupná i z dalších uzlů. Omezení, které toto řešení ale nabízí, je v případě rozsáhlých systémů dáno celkovým objemem zpracovaných dat, které je nutné při překlopení načíst na náhradní uzel. V případě systémů typu IS MU, a tyto zkušenosti potvrzuje i řada autorů dalších rozsáhlých databázových řešení, je celková doba na načtení všech potřebných dat natolik velká, že systém fakticky během této doby není schopen zajistit rozumné fungování stejně, jako je tomu v případě hardwarové rekonfigurace (restartu) vadného uzlu. Při zvažování zvýšení dostupnosti je také nutné brát v úvahu velké navýšení složitosti databázového clusteru oproti systému s jednou instancí a dále pak celkové vysoké vnitřní propojení všech uzlů v clusteru, které může vést k propagaci naopak softwarové chyby na všechny uzly clusteru. Teoretická výhoda nezávislosti clusterů se tak v praktickém provozu stává naopak zdrojem dalších chyb a výpadků. V neposlední řadě pak do uvažování o skutečném nasazení databázových clusterů pro zvýšení dostupnosti vstupuje celková cena za takové řešení daná nejen cenou za databázové licence. V případě clusterů s vysokým výkonem je totiž nezřídká výhodnější použít nekomoditní hardwarové řešení, které obsahuje řadu vlastností pro zvýšení výkonu včetně on-line výměny vadných komponent bez nutnosti výpadku celého systému, fyzického oddělení základních částí apod. Druhou výhodou pro obecné použití databázových clusterů je navýšení výkonu. V případě, že výkon stávajícího počtu uzlů nedostačuje, je velmi jednoduché přidat další uzel do clusteru. Toto řešení, které úspěšně funguje na aplikační úrovni (a zde to i IS MU hojně využívá), je však velmi závislé na nutnosti zajištění konzistence mezi masivně paralelním čtením a zápisem dat na různých uzlech současně. Toto softwarové zajištění konzistence, které musí nutně provádět databázový server, výrazně zvyšuje režii potřebnou pro běžný chod aplikace. U on-line přepočítávaných dat je pak tento způsob zpracování při masivním přístupu uživatelů přirozeně výrazně méně výkonný, než přístup do sdílené paměti realizovatelný hardwarově. Z tohoto důvodu IS MU opustil v minulém roce koncepci databázových clusterů a soustředí se plně na tzv. vertikální distribuci dat v rámci jednoho single system image řešení [3]. Za tímto účelem byla využita technologie SGI Altix z oblasti tzv. High Performance Databases, která umožňuje, podobně jako databázové clusteru, jednoduchým přidáním uzlu do systémové infrastruktury navyšovat a případně přesouvat výkon mezi různými částmi systému a to transparentně vůči databázovému

18 6 M. Brandejs, M. Křipač: IS MU: architektura a implementace v rozsáhlém prostředí velké organizace software. Zároveň umožňuje vícenásobné zařazení všech komponent nutných pro běh systému tak, aby i v případě výpadku jakékoliv komponenty byl zajištěn provoz poskytovaných služeb pouze s minimálním omezením výkonu. 5 Závěr V tomto příspěvku jsme se pokusili ilustrovat aktuální praktické zkušenosti s provozem velkého systému pro desítky tisíc uživatelů. Jistě není možné obsáhnout všechny aspekty celého řešení. Vedle principů zvolené architektury a jejich motivací jsme se proto zaměřili na klíčovou oblast z hlediska správného a efektivního fungování, čímž je správa dat. Podle našich aktuálních znalostí se ukazuje, že oproti všeobecně prosazovanému trendu zavádění databázových clusterů a podnikových gridů, není v řadě zejména rozsáhlých integrovaných systémů distribuce dat tímto horizontálním způsobem přínosná. Naopak existují alternativy, které přináší pro praktický provoz více možností. Literatura 1. Informační systém Masarykovy univerzity: 2. Tushar Mahapatra and Sanjay Mishra. Oracle parallel processing. O Reilly & Associates, Inc., Sebastopol, CA, USA, Michael Woodacre. Sgi global shared-memory architecture: Enabling systemwide shared memory. Embedded Computing Design, 6/2003 Annotation: Masaryk University Information System: architecture and implementation within large organization. Masaryk University has been using its own integral study evidence and management system for nine years. It is a strictly web-based on-line information system with direct access of 40,000 active users and immediate data change propagation. The goal of this presentation is to introduce main architecture fundamentals. Advantages, problems and acquired practical experiences with popular data distribution will be discussed during the talk. Also several methods of data storage including database clusters, fully distributed data storage and High Performance Databases will be provided.

19 Flexibilný IS riadený metadátami Juraj ČERVEŇ Softec s. r. o. Kutuzovova 23, Bratislava Abstrakt. Príspevok je venovaný informačnému systému ISZI (Informačný systém zdravotníckych indikátorov), ktorý vznikol v rámci riešenia Phare projektu pre Národné centrum zdravotníckych informácií Slovenskej republiky (NCZI). Systém podporuje procesy prípravy, zberu a spracovania štatistických údajov o zdravotníctve. Pre systém bola v zadaní stanovená špecifická požiadavka, aby bolo možné pridávanie nových štatistických zisťovaní a ich spracovanie bez nutnosti zásahov do programového kódu systému. Systém bol preto navrhnutý, ako automatizovaná výrobná linka riadená metadátami. Používatelia (správcovia jednotlivých zisťovaní) definujú typy jednotlivých zisťovaných údajov, výzor formulárov, potrebné kontroly vstupných dát i spôsob ich spracovania bez nutnosti programovania. Takéto riešenie zabezpečuje vysokú flexibilitu systému. Systém využíva na rôznych úrovniach princíp oddelenia formy a obsahu, čím je umožnené aj oddelenie časovo stabilnejších aspektov štruktúry sledovaných údajov od časovo premenlivejšej formy zberu i prezentácie údajov. Systém ISZI rieši aj správu registra poskytovateľov zdravotnej starostlivosti (RPZS)a umožňuje aj správu zdravotných registrov a registra zdravotníckych pracovníkov. Aj štruktúra údajov v registroch je definovaná metadátami, čo umožňuje rovnakú flexibilitu aj v tejto časti systému. Klíčová slova: zber dát, metadáta, štatistické zisťovanie, automatizácia procesov. 1 Informačný systém riadený metadátami Cieľom vývoja informačného systému bolo automatizovať procesy prípravy, zberu a spracovania štatistických údajov. S ohľadom na požiadavku vysokej flexibility systému, ktorý má umožňovať pridávanie nových zisťovaní, či modifikáciu existujúcich, bolo zvolené riešenie založené na systéme riadenom metadátami. V tomto príspevku používame termíny operatívne dáta a metadáta v nasledovnom význame: - operatívne dáta vlastné údaje, ktoré sú predmetom zberu a spracovania, - metadáta dáta o dátach - opisujú štruktúru a sémantiku operatívnych dát. Použitie systému riadeného metadátami odstraňuje potrebu programovať každý zber dát individuálne a používatelia systému tak získavajú nezávislosť od programátorov. Využitie tohto princípu zabezpečuje tiež jednotnosť ovládania a správania celého systému. L. Popelínský, O. Výborný (eds.), DATAKON 2007, Brno, , str

20 8 J. Červeň: Informačný systém riadený metadátami 1.1 Východiskové predpoklady. Operatívne dáta sa vyznačujú pomerne veľkým objemom (rádovo tisíce až milióny databázových záznamov), ale majú relatívne jednoduchá štruktúru. Na spracovaní operatívnych dát sa zúčastňuje pomerne veľký počet používateľov (rádovo tisíce spravodajských jednotiek a desiatky referentov, ktorí dáta spracovávajú). S ohľadom na uvedené vlastnosti bola na spracovanie operatívnych dát zvolená web aplikácia, ktorá pri svojej práci interpretuje metadáta. Web aplikácia nevyžaduje inštaláciu na počítači používateľa a preto je prístupná širokému okruhu používateľov, ktorí majú prístup na Internet. Relatívne jednoduchšia funkčnosť web aplikácie je s ohľadom na jednoduchú štruktúru operatívnych dát postačujúca. Metadáta sú charakterizované relatívne malým objemom (desiatky až stovky záznamov), majú ale pomerne zložitú štruktúru, preto je na ich správu vhodnejšia viacoknová aplikácia s bohatým klientom. Na správe metadát sa zúčastňuje pomerne malý počet používateľov (rádovo jednotky - správcovia metadát, ktorí konfigurujú funkčnosť web aplikácie). S ohľadom na malý počet používateľov nie je problémom nutnosť inštalácie aplikácie na klientsky počítač používateľov. V celom systéme sa prihliada na oddelenie obsahu (ktorý by mal byť časovo stabilnejší) a formy, v akej je obsah prezentovaný. Ak nemá byť definovanie metadát len programovaním v osobitnom programovacom jazyku, musí byť štruktúra metadát prispôsobená procesom, ktoré má systém podporovať. V nasledujúcej kapitole preto stručne opíšeme procesy, ktoré systém podporuje. 2 Podporované procesy Základné procesy, ktoré systém podporuje, sú znázornené na obr. 1. Obr. 1. Základné procesy podporované systémom V príspevku sa nebudeme zaoberať administráciou systému, ktorá zahŕňa štandardné činnosti, nezávislé od vecnej domény, ako je správa používateľov a prístupových práv, archivácia, zálohovanie a pod.

21 Zvaná přednáška Správa registra respondentov V registri sú evidovaní respondenti, ktorí majú spravodajskú povinnosť. Údaje registra sú tiež opísané metadátami, ako bude opísané podrobnejšie neskôr. Každý respondent má povinnosť poskytovať štatistické údaje rôzneho charakteru. Na základe informácií v registri systém generuje pre všetkých respondentov spravodajskú povinnosť pre dané obdobie (rok, kvartál alebo mesiac) a zoznam očakávaných výkazov, ktoré má daný respondent dodať. 2.2 Návrh zberu údajov V rámci návrhu zberu sa pre konkrétny typ štatistického výkazu definuje typ záznamu, ktorý opisuje položky výkazu (ich dátový typ i sémantiku). Typ záznamu by mal byť relatívne časovo stabilný, aby bolo možné tvoriť časové rady zisťovaných údajov. Usporiadanie formulára, ktorým sa údaje výkazu zberajú, sa môže meniť z roka na rok, a preto je opísané oddelene od typu záznamu, ale každá položka formulára referencuje zodpovedajúcu položku záznamu. S formulárom je spojená aj množina kontrol, ktoré systém pri vstupe dát vykonáva. Oddelenie typu záznamu od formulára je jedným z príkladov využitia princípu oddelenia obsahu a formy. V rámci návrhu zberu sa definujú aj formy vstupných rozhraní, cez ktoré je možné prijať dáta (napr. web formulár, XML súbor, XLS súbor a pod.). 2.3 Zber údajov V rámci zberu údajov sa plánuje zber, generujú sa oslovenia respondentov a potom prebieha samotný zber dát a priebežné sledovanie jeho stavu. Vstup dát do systému je možný v zásade tromi cestami: - ak má spravodajská jednotka prístup na Internet, môže údaje vyplniť priamo cez webový formulár, - spravodajská jednotka môže údaje dodať elektronicky vo forme súboru s dohodnutou štruktúrou, - ak spravodajská jednotka nemá možnosť dodať dáta v elektronickej forme, môže vyplniť papierový formulár, ktorý potom musia manuálne zadať do systému referenti inštitúcie, ktorá zber dát realizuje. Výkazy prijaté ktorýmkoľvek spôsobom sú na základe identifikačných údajov (napr. IČO a pod.) automaticky napárované na očakávané výkazy. Správca zberu má preto v každom okamihu prehľad o počte očakávaných výkazov i počte dodaných výkazov, vrátane ich stavu (rozpracovaný, s chybami, s varovaniami, bez chýb a pod.). Správca zberu môže daný zber ukončiť, čím sa zamedzí ďalšie pridávanie a modifikácia výkazov daného typu. 2.4 Spracovanie a výstup údajov Správca výstupov definuje štruktúru výstupných údajov (detailných i agregovaných), pričom aj samotné mapovanie vstupných dát na výstupné je definované metadátami. Štruktúra metadát výstupných tabuliek umožňuje definovať väčšinu typických algoritmov spracovania dát, ale pokiaľ by bolo potrebné vykonať zložitý neštandardný výpočet, je ho možné definovať uloženou procedúrou.

22 10 J. Červeň: Informačný systém riadený metadátami Aj v tejto oblasti je zohľadnený princíp oddelenia obsahu od formy. Funkčnosť systému je zameraná na definovanie obsahu (čo považujeme za zložitejšiu úlohu) a forma prezentácie výstupných dát je ponechaná na externé aplikácie. Napr. štandardné tlačové výstupy je možné vytvárať pomocou bežných reportovacích nástrojov (Crystal Reports, Microsoft Access a pod.), ktoré definujú usporiadanie obsahu výstupných tabuliek na papier a ich formátovanie. Na analýzy možno využiť vhodné analytické nástroje tretích strán (OLAP klient). Často postačuje aj Microsoft Excel s jeho OLAP funkcionalitou. 3 Architektúra systému Systém je vytvorený ako skupina niekoľkých softvérových aplikácií, ktoré sú navzájom integrované spoločnou dátovou základňou, ako je znázornené na obr. 2. Obr. 2. Architektúra systému Systém opisovaný v príspevku bol nasadený v Národnom centre zdravotníckych informácií Slovenskej republiky (NCZI) na automatizáciu procesov prípravy, zberu a spracovania štatistických údajov z odboru zdravotníckej štatistiky. Informačný systém zdravotníckych identifikátorov (ISZI) zabezpečuje poskytovanie zdravotníckych indikátorov a iných údajov o zdravotníctve v SR pre Eurostat, WHO a iné medzinárodné i domáce inštitúcie. 4 Vrstvy metadát Ako sme už uviedli, štruktúra metadát je pomerne zložitá, preto sú metadáta rozdelené do viacerých vrstiev, pričom vyššie vrstvy využívajú metadáta nižších vrstiev.

23 Zvaná přednáška 11 Obr. 3. Vrstvy metadát Pri spracovaní štatistických dát je veľmi dôležitá ich klasifikácia podľa rôznych kritérií. Preto základnou vrstvou metadát sú rôzne číselníky. Systém umožňuje rôzne číselníky zaraďovať do hierarchií, ktoré tvoria dimenzie (napr. okresy z číselníka okresov sú zaradené do krajov, kódy z číselníka OKEČ sú zaraďované do skupín a kapitol a pod.). Toto umožňuje tvorbu multidimenziálnych pohľadov na výstupné dáta. Nad vrstvou číselníkov a dimenzií je katalóg dátových prvkov, ktorý definuje sémantiku údajov uložených v systéme. Systém rozlišuje dátové prvky: - číselné (zvyčajne ide o rôzne sledované ukazovatele), - triediace (zvyčajne kódy číselníkov, ktoré charakterizujú číselné údaje, ale aj IČO, rodné číslo a pod) - popisné (zvyčajne textové popisy prislúchajúce ku číselníkovým kódom). Textové popisy môžu byť v slovenčine a v angličtine, takže možno vytvárať výstupy v týchto jazykoch. Ďalšou vrstvou sú typy záznamov, ktoré definujú (zjednodušene povedané) štruktúru vety, v ktorej sú uchované údaje určitého typu výkazu. Pojem veta je v úvodzovkách, pretože môže obsahovať aj tzv. otvorené moduly, t. j. časti, ktoré sa môžu opakovať pre daný výkaz viackrát (t. j. ide o asociáciu 1:N). Takýchto otvorených modulov môže byť v jednom type záznamu aj viac. Nad vrstvou typov záznamov je vrstva formulárov, ktoré sú zložené z modulov. Moduly sú jedno až dvojrozmerné tabuľky, do ktorých sa zapisujú vstupné dáta. 5 Metadáta vstupov Okrem uvedených štyroch vrstiev sa pre vstupné dáta v systéme definujú aj ďalšie typy metadát. Toky dát definujú od koho a ako často údaje očakávame. Formy dát definujú akceptovanú formu vstupu dát (WEB, XLS, XML, CSV).

24 12 J. Červeň: Informačný systém riadený metadátami Pre import vo formáte XML je predpísaná konkrétna štruktúra vo forme DTD. Ak sú údaje dostupné v inej XML štruktúre a je ich možné previesť do predpísanej formy pomocou vhodnej XSLT transformácie, možno cestu ku transformačnému XSLT súboru uviesť do metadát danej formy dát a systém automaticky aplikuje danú transformáciu pri importe dát. Pre vstupné formuláre sa definujú kontroly, ktoré popisujú obmedzenia kladené na vstupné dáta. Kontroly používajú špeciálny jazyk kontrol, ktorým možno definovať kontroly typu chyba (údaje identifikované kontrolou nie sú správne a až do opravenia chyby nie sú systémom akceptované) alebo varovanie (zadané dáta identifikované kontrolou sú nepravdepodobné napr. hmotnosť dieťaťa pri narodení > 10 kg, ale v prípade, že sa potvrdí správnosť zadaných dát, je možné aj dáta s varovaniami akceptovať). O akceptovaní dát s varovaniami rozhoduje príslušný referent po preverení ich správnosti. Pri vstupe dát cez web aplikáciu systém lokalizuje položky formulára, ktoré nevyhovujú definovaným kontrolám, ako je znázornené na obr. 4 (ide o testovacie dáta s úmyselnými chybami). Obr. 4. Príklad časti vstupného web formulára s lokalizovanými chybam.

25 Zvaná přednáška 13 6 Metadáta výstupov Podobne ako pre vstupné dáta, sa definujú aj pre výstupy toky dát určenie komu a ako často dané údaje poskytujeme. Výstupné tabuľky (nazývané tiež výstupné pohľady, pretože predstavujú určitý pohľad na vstupné dáta) sú tiež charakterizované typom záznamu a možno ich zobraziť aj pomocou web formulára, ktorý ale neumožňuje modifikáciu zobrazených dát a neobsahuje ani kontroly. Výstupné údaje sú zvyčajne agregované, ale je možné vytvoriť aj výstupné tabuľky s detailnými dátami. Definícia obsahu výstupnej tabuľky je realizovaná pomocou tzv. Záložky definície výpočtu je to meta popis spôsobu výpočtu výstupu zo vstupu, ktorý nevyžaduje programovanie. Napriek deklaratívnemu charakteru záložky, môže byť jej manuálne vytvorenie pomerne náročné, preto bol do aplikácie na správu metadát implementovaný sprievodca (wizard) ktorý automaticky generuje záložku definície výpočtu. Sprievodca zohľadňuje všetky dostupné metadáta (vrátane začlenenia číselníkových triediacich položiek do hierarchie dimenzií). Ak sú údaje správne napárované na plánované výkazy, je možné do výstupu zahrnúť aj korešpondujúce údaje z registra respondentov. Na obrázku č. 5 je príklad obrazovky sprievodcu, pomocou ktorej môže správca výstupných pohľadov jednoduchým spôsobom vytvoriť záložku definície výpočtu. Obr. 5. Príklad sprievodcu na vytvorenie výstupnej tabuľky Vygenerovanú záložku možno ďalej manuálne upravovať, prípadne doplniť ďalšie záložky, ak je výstup zložitejší a obsahuje údaje z viacerých vstupných zdrojov.

26 14 J. Červeň: Informačný systém riadený metadátami 7 Registre Pre implementáciu registrov bola zvolená fixná fyzická reprezentácia údajov (Dátový analytický vzor Responsibility od Martina Fowlera [1] upravený a zovšeobecnený Ľ. Šešerom [2]). V tomto vzore vystupujú len tri druhy entít: Účastník reprezentuje účastníka v nejakom vzťahu. Rola účastníka rola daného účastníka v danom vzťahu (ten istý účastník môže pritom vystupovať vo viacerých vzťahoch v rôznych rolách). Vzťah spája účastníkov s danými rolami v danom vzťahu. Nad touto fixnou fyzickou reprezentáciou údajov je vytvorená flexibilná logická štruktúra. Pre všetky entity Fowlerovho vzoru možno definovať typy záznamov, ktoré popisujú štruktúru atribútov danej entity aj prípustné vzájomné vzťahy. Registrom respondentov je v prípade implementácie na NCZI register poskytovateľov zdravotnej starostlivosti (PZS), ktorí majú spravodajskú povinnosť voči NCZI. Každý PZS má v závislosti od odborného zamerania svojich odborných útvarov povinnosť poskytovať štatistické údaje rôzneho charakteru. V registri PZS sú definovaní účastníci ako fyzická osoba, právnická osoba, zariadenie (zdravotnícke). odborný útvar (ambulancia, pracovisko a pod.). Vzťahom je doklad, na základe ktorého daný účastník pôsobí ako PZS (napr. povolenie, licencia a pod.). Fyzické a právnické osoby môžu mať rolu PZS prípadne rolu inej organizácie zdravotníckej štatistiky (ide o organizácie, ktoré nie sú PZS, ale majú povinnosť predkladať isté druhy výkazov) a pod. Na obr. 6 vidieť časť obrazovky web aplikácie, ktorá zobrazuje príklad obrazovky právnickej osoby s rolou PZS.

27 Zvaná přednáška 15 Obr. 6. Príklad obrazovky právnickej osoby s rolou PZS Na obrázku vidieť tiež spravodajské povinnosti danej právnickej osoby (aj tu ide o ilustratívne testovacie dáta nezodpovedajúce skutočnosti). Metapopis umožňuje prispôsobovanie štruktúry registrov zmenám podmienok (napr. zmeny legislatívy) bez nutnosti programovať. Navrhnuté riešenie má potenciál dopĺňať do systému podľa potreby postupne i ďalšie registre (bez nutnosti meniť programový kód). Napríklad systém je v súčasnosti dopĺnený o register zdravotníckych pracovníkov, kde sú doplnené len nové typy vzťahov a rolí pre existujúcich účastníkov. Napr. pracovnoprávny vzťah, v ktorom vystupuje fyzická osoba v roli zamestnaného a iná fyzická, prípadne právnická osoba v roli zamestnávateľa. 8 Záver Zavedenie systému, opísaného v príspevku, výrazným spôsobom zmenilo a zjednodušilo procesy prípravy, zberu a spracovania dát v NCZI. Popisovaný systém nie je viazaný na zdravotnícku problematiku a dokonca ani na oblasť štatistiky. Realizované riešenie umožňuje (práve vďaka využitiu metadát) podporiť procesy hromadného zberu a spracovania dát s rôznou a pritom dopredu nedefinovanou štruktúrou od pomerne veľkého počtu respondentov.

28 16 J. Červeň: Informačný systém riadený metadátami Literatúra 1. Fowler M.: Analysis Patterns: Reusable Object Models, Addison Wesley, Šešera Ľ., Mičovský A., Červeň J.: Datové modelování v příkladech, Grada, 2001 Annotation: Information system controlled by metadata The paper deals with automated support of statistical surveys. Covered processes start from survey design, through data collection to data processing. One of the problems in statistical surveys is the need of dynamical change of investigated content and the way of data processing. The system described in this paper is designed to allow addition of new surveys and their processing without need of programming. The system was developed as an automated production line which is controlled by metadata. Survey administrators define the type and structure of collected data, entry form layout, necessary input checks and the way of data processing by defining appropriate metadata. The system covers also management of the register of respondents. Data from statistical surveys are integrated with this register data.

29 Vyhledávání na Webu Leo GALAMBOŠ Katedra softwarového inženýrství, MFF UK Praha Malostranské nám. 25, Praha Abstrakt. Tento příspěvek se zabývá metodami, které se používají v technologiích webového vyhledávání. Jsou ukázány základní architektury příslušných vyhledávacích systémů, včetně architektury webového robota. Klíčová slova: vyhledávací stroj, index, robot, crawler, web. 1 Úvod Elektronicky uložená data rostou neuvěřitelnou rychlostí až 5EB ročně [24], přičemž jejich nemalé množství je přístupné právě prostřednictvím webu. Proto je jen logickým cílem využít tento obrovský informační potenciál, a v neposlední řadě i vazby mezi samotnými informacemi, k vyhledávání anebo zodpovídání nejrozmanitějších otázek. To následně evokuje celou řadu problémů od způsobu zpracování obrovského množství dat [8] a konče technikami, které ze syrových dat tvoří odpovědi na uživatelské dotazy v přirozeném jazyce [20]. Postupně se hledaly různé cesty jak webový prostor zvládnout. První generace vyhledávačů byla založena na osvědčených knihovních fulltextových systémech. Záhy se ale zjistilo, že web obsahuje takové množství obsahově podobných stránek s malou informační hodnotou, že do té doby známé postupy nemohou dlouhodobě zvládat nápor zvětšujícího se objemu webu. Průlomovým řešením bylo zapojení ohodnocovací funkce (OF), která jednotlivým stránkám přiřazovala jejich důležitost. To přineslo možnost odlišit kvalitní výsledky od těch zbývajících. Základní varianta OF přiřazuje stránkám takovou důležitost, která odpovídá pravděpodobnosti návštěvy čtenáře bloudícího náhodně po webu. Dnes je tato funkce základem mnohých webových vyhledávacích systémů (WVS) v bezpočtu variant. Zanedlouho poté se začaly objevovat i sofistikovanější systémy, které jsou schopny využít klasický fulltextový vyhledávač pro zodpovídání uživatelských dotazů v přirozeném jazyce (QA systémy). Většinou reformulují uživatelskou otázku na fragmenty s tokeny, které vyhledává WVS, a poté vytvoří souhrnnou odpověď [17,20]. Strukturu obou typů systémů popisuje Obr. 1. L.Popelínský, O.Výborný(eds.),DATAKON 2007,Brno, , str

30 18 L.Galamboš: Vyhledávání na Webu Obr. 1: Architektura QA systému (vlevo) a fulltextového systému (vpravo) Hlavní částí tohoto příspěvku bude první linie softwarových komponent WVS: crawler (kapitola 2) a indexátor (kapitola 3). Ty ve fulltextovém systému tvoří a zpracovávají vstupní n-tice dokument-term (d,t), respektive dokument-term-signal (d,t,s). V kapitole 4 pak budou zmíněny kešovací techniky používané při řešení uživatelských dotazů. Ukážeme alespoň některé problémy a zejména řešení, která napomáhají zvládat obrovský datový nápor webu, a které jsou tak nedílným základem efektivního webového vyhledávání. 2 Robot (crawler) Jednou z nejzatíženějších komponent WVS je robot, který stahuje z webu veškerá dostupná a zajímavá data. Výzvou v této oblasti je konstrukce robota, který dokáže s minimálními HW nároky stahovat co možná nejrychleji nejzajímavější data [4,27,3]. Pochopitelně, při zachování vlídného přístupu k poskytovatelům obsahu [23]. První implementace robotů nabízely z dnešního pohledu zanedbatelný výkon. Například pilotní implementace Google dokázala v roce 1998 stahovat na 4 strojích průměrnou rychlostí jen 100 stránek za sekundu. Mercator stahoval na každém ze zapojených Alpha strojů str/sec [15,27], zatímco Xyro dosahoval v téže době na čtyřech klasických PC hranice 184 str/sec [26]. Další přehled známých či publikovaných výsledků podává Tab. 1. Jedná se o ryze informační hodnoty, protože testy běžely v rozdílných časech, konfiguraci i prostředí. Hodnoty jsou normalizovány na jeden CPU. Není-li počet CPU znám, pak jsou normalizovány na počet strojů zapojených v robotu. Zvýšení přenosové kapacity linek s sebou přineslo i zvýšení výkonu robotů. Proto již není neobvyklé, když distribuovaný robot WVS dokáže během týdne stáhnout až 3 miliardy stránek (jako become.com) s minimálními náklady nad 1,5 miliónu USD [5]. Právě relativně vysoké náklady přispívají k tomu, že WVS indexují jen menší části webového prostoru. V roce 2000 to bylo dle některých odhadů jen 16% stránek

31 Zvaná přednáška 19 [21] a s ohledem na růst webu se budou roboti orientovat spíše na cílené stahování obsahu. Robot #strojů/cpu str/sec tok (MB/s) rok Googlebot 4/? , Mercator 1/2 55 0, Mercator 4/8 72 1, Xyro 4/? 12? 2001 Nutch 1/?? 0, Become 50/? 100 0,3? 2004 Egothor 1 1/2 40 0, Dominos 5/? 154 0, Egothor 2 1/ ,5-5,0 2005,2007 Larbin 1/2 80 2, VN 9/14 2? 0, Tab. 1: Výkonové charakteristiky webových robotů Základní strukturu robota popisuje Obr. 2, kde T * reprezentují výpočetní vlákna. Obr. 2: Vnitřní struktura robota. Vlákno T 0 je zodpovědné za správu báze všech známých URL, ze které vybírá kandidáty ke stahování. Ty umisťuje do své fronty aktivních URL a v plánovaném čase je posílá dále do systému. URL postupně prochází různými stavy stahovacího procesu (DNS resolve, HTTP stahování, analýza HTML, ), o které se většinou starají specializovaná vlákna. Komunikace mezi vlákny je nejčastěji asynchronní, prostřednictvím cyklických front. Tuto architekturu je možné provozovat v centralizované anebo distribuované variantě (většinou stačí zvládnout distribuci T 0 monitoru). S nárůstem zapojených výpočetních uzlů roste i náchylnost k chybám, a proto moderní robot umožňuje migraci libovolného T procesu mezi uzly [14]. V některých implementacích je navíc umožněno klonování T vláken s cílem zvládat okamžitý nápor dat [12]. V prvotních implementacích bývala úzkým hrdlem síť, ať již na straně DNS anebo HTTP přenosů. V současnosti je hlavním problémem dostatečně efektivní

32 20 L.Galamboš: Vyhledávání na Webu zodpovídání otázky jaké číslo má ve WVS přidělena stránka X, máme ji již v systému?. Zmíněná otázka se zdá být jednoduchou, ale systém si ji musí klást u každého URL, které objeví. Pokud je uplatněn i vlídný přístup robota k serverům se stránkami, nelze počítat s přílišnou lokalitou a z toho vzešlým kešováním odpovědi. Při frekvenci 1000 stránek za sekundu je tak otázka pokládána až 40000x a volba vhodných datových struktur se stává kritickou [13,14]. Existuje i celá řada dílčích problémů, například způsob procházení webu [2], znovunavštěvování stránek, atp. Tyto problémy kladou vysoké nároky na správu fronty požadavků ke stahování, což následně implikuje zvýšené nároky na přeskupování datových struktur fronty. Fronta sama bývá tak veliká, že ji nelze spravovat ve vnitřní paměti a do hry se tak významně zapojuje disk. Pokud robot pracuje s více takovými externími strukturami (pro tvorbu indexu, ukládání nezpracovaných fragmentů datového toku, ), pak se může projevovat negativní působení libovolného elevator plánovače I/O. V případě našeho robota docházelo na Linuxu 2.6 až k pětinásobnému snížení průtoku při použití CFQ, deadline nebo AS. Zatímco tedy konstrukce pomalého robota nevyžaduje velké úsilí, konstrukce robota schopného trvale stahovat miliardy stránek během několika málo týdnů obnáší mnoho problémů v jeho architektuře, efektivitě práce se sítí i disky, a též stabilitě a ochraně proti výpadkům [29]. Reálný provoz navíc vede i k častým obměnám robota s dobou životnosti kolem měsíců [18]. Mezi dlouhodobě otevřené problémy patří odhalování struktury webu a jeho využití v plánování stahování stránek (ve spolupráci s historickými údaji). Dalším důležitým problémem, jehož řešení není zcela uzavřeno, je detekce všude přítomného SPAMu, ideálně před samotným stažením většího počtu webových stránek. 3 Indexátor a úložiště stránek Další úskalí je hned v následujícím článku WVS v indexátoru a úložišti dokumentů. Z robota přichází řádově 100 až 1000 nových či aktualizovaných stránek za sekundu, což klade jednak nároky na úložiště ale i samotný index. V úložišti stránek se často využívá zlib [1], protože jiné kompresní techniky nedosahují dostatečné rychlosti [10]. Bohužel, náhodná I/O nejsou schopna zvládnout velký průtok (nad 100 stránek/sec), a proto se využívá například log-soubor s periodickým garbage-collection [16]. V indexu se v hojné míře [1,6,12] využívají invertované seznamy [30]. Na index v tomto formátu můžeme nahlížet jako na soubor dvojic (t;d), kde d identifikuje dokument a t slovo/term. Celý soubor je navíc uspořádán vzestupně, a to dle první a následně dle druhé složky. Implementačně tedy stačí nasadit algoritmus třídění sléváním na vstupní dvojice (d,t) přicházející z robota. Invertovaný soubor je vhodný pro vyhledávání [25], ale již méně pro aktualizaci [7]. Změna dvojic příslušných k modifikovanému dokumentu s sebou potencionálně přináší neefektivní skokové operace nad indexem. Proto se někdy výsledný invertovaný soubor ponechává rozložený do několika segmentů. To jsou vlastně dílčí běhy, které máme při třídění sléváním před tvorbou finálního výsledku. Každá taková část obsahuje ještě bitové pole (BTP), které udává, zda jsou dvojice příslušné k dokumentu d neplatné [6].

33 Zvaná přednáška 21 Odstranění (hodnot) dokumentu z indexu provedeme pouhým označením v BTP. Aktualizaci hodnot jejich odstraněním (označením v BTP) a znovuvložením, což implikuje vznik dalšího segmentu. Těchto segmentů nevzniká neomezené množství, protože při vzniku k segmentů podobné velikosti dojde k jejich slití. Tak jeden větší segment nahradí k menších, přičemž se zároveň do většího segmentu nepřenášejí hodnoty zneplatněných dokumentů. Konstanta k, označovaná jako merge factor, limituje celkový počet segmentů, které by WVS musel spravovat. Pokud se v systému vyskytuje N dokumentů, pak je počet segmentů omezen vztahem k ( 1+ log N). Popsaný postup je implementačně nenáročný a zachovává segmenty v maximální míře nefragmentované. Tato vlastnost napomáhá rychlému dotazování nad invertovanými seznamy. Bohužel, mezi negativní vlastnosti patří potencionálně velký počet segmentů a možnost vzniku dutých segmentů (obsahují mnoho zneplatněných hodnot). První negativní vlastnost snižuje výkon jen při paralelním dotazování více uživatelů, zatímco druhá jej degraduje vždy. Určitým řešením je spouštění servisních slévání, například rutinou optimize v [6], ale to má za následek velkou I/O zátěž. Proto byla v [11] navržena technika, která dozoruje zaplnění BTP polí a optimalizační slévání provádí jen na omezené podmnožině kritických segmentů. Tím je dosaženo plně automatické údržby, a to navíc s menším počtem spravovaných segmentů. Při provedených testech se ukázalo, že celý index obsahuje nejméně 65% platných záznamů (většinou ale 75-80%) a skládá se přibližně z 10 segmentů. Výhodou je i to, že největší segment bývá zaplněn obdobně jako samotný index. Vraťme se nyní k nasazení v rámci WVS. V praxi se využívá toho, že zásah bude tvořen spíše dokumentem s vysokou hodnotou danou ohodnocovací funkcí OF. Uspořádáme-li tedy druhou složku položek invertovaného indexu podle OF(d), pak budou invertované seznamy začínat položkami důležitějších dokumentů. Ve skutečnosti nám tak na sestavení výsledku postačí číst a zpracovat jen začátky invertovaných seznamů. Pracuje-li WVS se svým indexem v diskových blocích velikosti 4kB, tak jeden takový blok obsahuje přibližně 820 položek (toto již jsou položky opatřené kromě nezbytných hodnot t a d i váhou a seznamem pozic výskytu). Je patrné, že z disku čteme více, než bývá nezbytně nutné na sestavení výsledku top-10. Dynamizace [11] má v tomto směru další výhodu umožňuje schovat zneplatněné položky v rámci bloků tak, že neznamenají významný počet čtecích operací navíc. Mezi další výhody patří nulová fragmentace na disku a čistě sekvenční zpracování dat jak při vyhledávání, tak i aktualizaci. Rychlost aktualizace navíc odpovídá velikosti aktualizované části indexu, což napomáhá škálovatelnosti. Naproti tomu technika značek [23] přináší zvýšenou režii při samotných aktualizacích a může v některých případech vést i k fragmentovanému invertovanému souboru (s následným zpomalením při řešení dotazů). k 4 Webové vyhledávací systémy Kvalitu do celého procesu vyhledávání přinášejí až další komponenty, které data dále zpracovávají a čistí [8]. S ohledem na zaměření tohoto příspěvku se nebudeme zabývat jejich detailním popisem. Místo toho se zaměříme na další místo, kde lze proces vyhledávání ve webových datech zefektivnit.

34 22 L.Galamboš: Vyhledávání na Webu Obr. 3: Vnitřní struktura webového vyhledávacího systému. Obr. 3 popisuje strukturu fulltextového WVS. Ten se ve větších instalacích typicky skládá z několika serverů s částmi invertovaného indexu (SII), ze serverů s dokumenty (SD), a stroji s rozhraním WVS. Role mediátora (brokeru) spočívá v příjmu uživatelského dotazu, naplánování a spuštění jeho řešení na SII, seřazení výsledného vektoru identifikátorů dokumentů a následně i dodání výstřižků ve spolupráci se SD. Analýzou logů mnoha WVS bylo zjištěno, že vhodné kešování může zvýšit propustnost systému v mezích 20-30% [9,22], což přináší odlehčení zejména SII. Na druhou stranu se nejedná o výrazné zlepšení, a proto je efektivní správa invertovaných seznamů stále velmi důležitá oblast. WVS může odpovědi (na základě studia chování uživatelů) dokonce předkešovávat. Bohužel, zatím není znám žádný úspěšný pokus v tomto směru, a tak tato oblast zůstává i nadále otevřenou. 5 Závěr Při stavbě webového vyhledávacího systému je nutné stáhnout, zpracovat a udržovat obrovský objem dat. Tento příspěvek ukázal používané architektury jak stahovací komponenty (robota), tak i fulltextového a QA systému. Ilustrovali jsme problematiku v prvních dvou oblastech, které s webovými daty přímo pracují (robot a indexátor). Byla prezentována skutečná rychlost některých robotů a vymezili jsme i jejich problematické oblasti implementace. V neposlední řadě byly představeny i další místa v rámci WVS, která mohou být pro zvládnutí objemu webu kritická.

35 Zvaná přednáška 23 Poděkování Práce byla podpořena projektem 1ET programu Informační společnost (Tématického programu II Národního programu výzkumu v ČR: Inteligentní modely, algoritmy, metody a nástroje pro vytváření sémantického webu). Literatura 1. Brin, S., Page, L.: The anatomy of a large-scale hypertextual web search engine. Computer Networks ISDN Systems, 30(1-7): , Castillo, C.: Effective web crawling. SIGIR Forum, 39(1), 55-56, ACM Press, NY, USA, Chakrabarti, S., et al: Focused crawling: a new approach to topic-specific Web resource discovery. Computer Networks, 31 (11-16), Cho, J., Garcia-Molina, H.: Estimating frequency of change. ACM TOIT, 3(3), , Craswell, N., et al: Performance and cost tradeoffs in web search. In Proceedings of the 15 th Australasian Database Conference, , Dunedin, NZ, Cutting, D.: Lucene, Nutch. Apache Software Foundation. 7. Cutting, D., Pedersen, J.: Optimization for dynamic inverted index maintenance. In Proceedings of the 13 th SIGIR, , ACM Press, Dean, J., Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters. OSDI, San Francisco, USA, Fagni, T., et al: Boosting the performance of Web search engines. ACM TOIS, 24(1), 51-78, Galambos, L., et al: Compression of Semistructured Documents. IJIT, 4(1), 11-17, Galambos, L.: Dynamic Inverted Index Maintenance. IJCS, 1(2), , Galambos, L.: Egothor Gomes, D., Silva, M.J.: The Viuva Negra crawler. FI-FCUL, TR , Lisboa, Hafri, Y., Djeraba, C.: Dominos: A New Web Crawler s Design. IWAW, Bath, UK, Heydon, A., Najork, M.: Mercator: A scalable, extensible web crawler. WWW 2(4), , Hirai, J., et al: WebBase: A repository of web pages. In Proceedings of the 9 th WWW Conference, Amsterodam, Hovy, E., et al: Question Answering in Webclopedia. In Proc. of the TREC9 Conference, NIST, Kahle, B.: The internet archive. In RLG Diginews, 6(3), Koster, M.: Robots Exclusion Standard Kwok, C., et al: Scaling QA to the Web. WWW10, Hong Kong, 2001.

36 24 L.Galamboš: Vyhledávání na Webu 21. Lawrence, S., Giles, C.L.: Accessibility of information on the web. Intelligence, 11(1): 32-39, Lempel, R., Moran, S.: Predictive cahing and prefetching of query results in search engines. In Proc. of the WWW12, 19-28, ACM, Lim, L., et al: Dynamic Maintenance of Web Indexes Using Landmarks. In Proceedings of the 12 th WWW Conference, Lyman, P., Varian, H.R.: How much information Moffat, A., Zobel, J.: Self-Indexing Inverted files for Fast Text Retrieval. ACM TIS, 14(4), , Mignet, L., et al: Xyro: The Xyleme Robot Architecture. In DIWeb, 91-99, Najork, M, Heydon, A.: High-performance web crawling. COMPAQ SRC173, Saraiva, P.C., et al: Rank-Preserving Two-Level Caching for Scalable Search Engines. In Proc. of the SIGIR2001, 51-58, ACM, Shkapenyuk, V., Suel, T.: Design and implementation of a high-performance distributed web crawler. In Proceedings of the 18 th International Conference on Data Engineering, , San Jose, Zobel, J., Moffat, A.: Inverted files for text search engines. ACM CSUR, 38(2), 6pg, ACM Press, Annotation: Web Search The goal of this paper is to introduce and summarize several issues that are challenging for the Web search technology. Several details of robot and indexer modules are presented to point out problematic tasks. The paper is partialy based on the author experience with the search engine implementation.

37 Data mining v praxi Miloslav NEPIL Home Credit International a. s. Moravské náměstí 8, Brno miloslav.nepil@homecredit.net Abstrakt. Dolování dat v prostředí spotřebitelského financování přestává být konkurenční výhodou a stává se nutností pro konkurenceschopnost jakékoli společnosti podnikající v tomto bouřlivě se rozvíjejícím finančním odvětví. Představíme si průmyslové standardy pro dolování znalostí z databází a způsob jejich uplatnění při řešení konkrétních úloh z praxe. Klíčová slova: spotřebitelské financování, prediktivní modelování, segmentace klientského portfolia, řízení vztahu se zákazníky (CRM), cílený marketing, podpora návazného prodeje, udržení zákazníka 1 Prediktivní modelování v oblasti spotřebitelského financování Spotřebitelské financování prožívá v současné době dramatický vývoj, a to zejména ve střední a východní Evropě i v Asii. Zatímco v polovině 90. let bylo doménou malých firem, nyní se tato oblast klientsky orientovaných finančních služeb dostává do popředí zájmu bankovních institucí. Ve výsledku se tak hranice mezi bankovním a nebankovním sektorem do určité míry stírá. Životní cyklus klienta ve sféře spotřebitelského financování můžeme hrubě rozdělit do následujících tří etap: získání nového zákazníka (akviziční fáze), návazný prodej (cross-sell, up-sell vytěžovací fáze) a zabránění odchodu získaného zákazníka (udržovací fáze). Portfolio produktů spotřebitelského financování v sobě zahrnuje čtyři hlavní položky: spotřebitelské úvěry, hotovostní úvěry, revolvingové úvěry a kreditní karty. Spotřebitelský úvěr je účelově vázaný a obvykle se sjednává přímo u obchodníka při nákupu zboží nebo služeb. O hotovostní úvěr, který již vázaný není, může klient zažádat telefonicky, na poště nebo na pobočce společnosti. Při sjednání revolvingového úvěru dostává klient platební kartu, se kterou může opakovaně čerpat hotovost v síti bankomatů (ATM Automated Teller Machine), anebo platit opakovaně za zboží či služby prostřednictvím platebního terminálu obchodního místa (POS Point of Sale). Podobné vlastnosti jako revolvingový úvěr má i kreditní karta; rozdíl mezi těmito dvěma uvedenými produkty není pro účely naší prezentace podstatný, protože spočívá v podstatě pouze v odlišném nastavení smluvních podmínek. Každá společnost provozuje samozřejmě odlišné způsoby získání a vytěžení zákazníka, nicméně nejobvyklejší model je takový, že noví klienti jsou získáváni pomocí spotřebitelských úvěrů a následně je jim nabízen revolvingový úvěr, kreditní karta, případně hotovostní úvěr. Spotřebitelský úvěr tedy v tomto modelu figuruje coby akviziční produkt, zatímco ostatní produkty jsou vytěžovací. V praxi se používají samozřejmě i jiné modely, a to i současně v rámci téže společnosti. L. Popelínský, O. Výborný (eds.), DATAKON 2007, Brno, , str

38 26 M. Nepil: Datamining v praxi Proces řízení vztahu se zákazníky (CRM Customer Relationship Management) v užším slova smyslu se akviziční fáze klientského životního cyklu vlastně netýká, neboť tam pracuje běžný marketing a reklama, takže úlohy pro analytický CRM nastupují až ve fázi vytěžovací. Tam jde o to, abychom klientovi nabídli ve správný čas správným komunikačním kanálem ten správný vytěžovací produkt a poté vhodným způsobem připomínali tuto nabídku v případě, že klient neodpoví na první oslovení. Jestliže je tato aktivita úspěšná a klient přijme nabídku vytěžovacího produktu první volby (což je obvykle revolvingový úvěr či kreditní karta), musíme jej dále nabádat k tomu, aby svou platební kartu skutečně používal a začal pravidelně čerpat. V opačném případě, to znamená, nepodaří-li se nám klienta přimět k aktivaci platební karty, pak přichází na řadu nabídka hotovostního úvěru. Ovšem i klient, který si svou kartu aktivoval a začal čerpat, vyžaduje péči a pozornost: můžeme mu nabídnout navýšení úvěrového rámce, bezúročné období, případně další benefity, aby měl stále důvod svou kartu používat. Potřeby každého klienta se však s plynoucím časem neustále mění, takže mnozí úspěšně aktivizovaní uživatelé karet po určitém době přestávají čerpat a v tom okamžiku je nutno na jejich změněné potřeby zareagovat jinou nabídkou, což může být opět například hotovostní úvěr. Tímto způsobem vytěžovací činnost plynule navazuje a překrývá se s aktivitami směřujícími k udržení zákazníka a k zabránění jeho odchodu ke konkurenci 9. Z předchozího popisu je již jistě patrné, že každý bod životního cyklu klienta v sobě skrývá možnost uplatnění nějakého prediktivního modelu, jenž by nám pomohl předpovědět určité klientovo chování v blízké budoucnosti. Tyto modely můžeme hrubě rozčlenit do dvou kategorií: 1. modely náklonnosti ke koupi (PTB Propensity to Buy), jež odhadují pravděpodobnou reakci daného klienta na naši nabídku (odtud též responzní modely) 2. modely náchylnosti k odchodu zde se anglická terminologie různí podle odvětví: v telekomunikacích se odchodovost častěji označuje jako churn, kdežto ve finančnictví se spíše používá termín attrition Cílem těchto modelů je, obecně řečeno, zefektivnit celý proces řízení vztahu se zákazníky. Můžeme predikovat, které klienty by bylo nejlépe oslovit v daném okamžiku, jaký produkt jim nabídnout a také jaký komunikační kanál pro sdělení nabídky zvolit. Velmi častou motivací pro uplatnění prediktivních modelů při řízení marketingových kampaní je snížení nákladů na kampaň, resp. maximalizace zisku z dané kampaně 6. Ve čtvrtém odstavci si uvedeme příklad uplatnění a vyhodnocení responzního modelu. 2 Deskriptivní modelování a segmentace portfolia Analytický CRM se však nespoléhá pouze na prediktivní modely 7. Při práci s klientskou bázi potřebuje mít manažer marketingových kampaní přehled o portfoliu tak, aby mohl klientům rozesílat smysluplné nabídky a aby porozuměl jejich chování a potřebám. Postupujeme zde podobně jako u jiných explorativních analýz v jiných odvětvích: celek chceme rozčlenit na menší části, jež by byly vnitřně stejnorodé

39 Zvaná přednáška 27 tedy aby se skládaly z podobných jedinců a přitom aby tyto části byly vzájemně dostatečně odlišné tedy aby se klienti z jedné skupiny měřitelně odlišovali od klientů ze skupiny druhé. Tuto segmentaci klientského portfolia bychom jistě mohli provést třeba i ručně za pomoci expertní znalosti a intuice marketingového manažera. V mnoha případech se tento apriorní přístup stále praktikuje, ovšem k získání klientské segmentace můžeme s výhodou využít techniky shlukové analýzy. Oba přístupy mají samozřejmě své výhody a nevýhody. Expertní segmentace sice kopíruje intuici manažerů, nicméně tato segmentace nemusí zcela věrně odpovídat skutečnosti. Na druhé straně, pokud použijeme automatickou shlukovou analýzu, bude výsledek (téměř) optimální vzhledem ke stanoveným exaktním mírám, přesto však nemusí vyhovovat představám expertů, kteří z tohoto důvodu shlukové analýze mnohdy nedůvěřují a zdráhají se s ní pracovat. Pravdou je, že shluky nalezené technikami dolování dat mohou být překvapivé, ovšem to je z určitého hlediska vlastně jejich výhodou, protože expertní segmentace, jakkoli přesně odpovídá výchozím představám o portfoliu, nepřináší žádný nový pohled, nedává expertovi žádnou novou informaci. V následujících krátkých případových studiích si představíme dva příklady shlukové analýzy uplatněné při behaviorální segmentaci klientského portfolia za účelem porozumění potřebám zákazníků a pro jejich efektivní vytěžování. 2.1 Případová studie: Segmentace podle chování po aktivaci karty Do analýzy zahrneme zákazníky, kteří si aktivovali svou platební kartu, a sledujeme vývoj pohledávky na této jejich kartě po jednotlivých měsících od její aktivace. Omezme se na období dvou let po aktivaci karty a do zkoumání tedy pro zjednodušení zahrňme pouze ty klienty, již si kartu aktivovali před alespoň dvěma lety a jistě tedy mají dvouletou kreditní historii. Chtěli bychom všechny tyto klienty rozdělit do několika skupin podle vývoje jejich pohledávky. Pohledávku přitom vyjádříme relativně jako procentuální vyčerpanost úvěrového rámce na kartě, tedy (C- P) / R, kde C je kumulativní objem čerpání do daného data, P je kumulativní objem plateb do daného data a R představuje úvěrový rámec na kartě (kreditní limit). Zmíněná míra se pohybuje v intervalu [0%; 100%]. Představíme-li si vývoj pohledávky graficky jako křivku, chtěli bychom v datech identifikovat skupiny klientů mající podobný tvar této křivky. Nastíněný záměr odpovídá představě, že klienti se stejným nebo podobným vývojem pohledávky budou vykazovat podobné transakční chování. Pro každého klienta tedy vypočítáme 24-místný vektor, kde n-tý člen bude představovat procentuální vyčerpanost úvěrového rámce ke konci n-tého měsíce po aktivaci karty, čili: V = ( C P ) / R. n n n n Jelikož nás nezajímá absolutní výše pohledávky, nýbrž dynamika vývoje této pohledávky (tvar křivky), tak každý tento vektor znormalizujeme nejdříve tak, aby všichni klienti měli průměrnou vyčerpanost v oněch 24 měsících rovnu 50 %, tedy: V = V + V n n i 2 24 i= 1, pro n = 1, 2,...,24.

40 28 M. Nepil: Datamining v praxi Křivku podprůměrně čerpajících klientů tím pouze posuneme nahoru a naopak u nadprůměrně čerpajících klientů jejich křivku bez deformace posuneme na Y-ové ose dolů. Jsme v situaci, kdy všech 24 proměnných má zhruba stejný rozsah hodnot a dá se předpokládat, že ani jejich statistické míry polohy a rozptylu nebudou příliš odlišné. Přesto se chceme ujistit, že shluková analýza bude každý z oněch 24 měsíců brát do úvahy se stejnou váhou tedy že například podobnost na prvních 5-ti měsících bude hrát stejnou roli jako podobnost na posledních 5-ti měsících. Z tohoto důvodu musíme ještě znormalizovat každou proměnnou V n pro každé n = 1,2,,24 tak, aby platilo, že směrodatná odchylka S(V n ) = 1 a průměr P(V n ) = 0. Nyní jsme již připraveni spustit shlukovou analýzu metodou K-means 4, která funguje dostatečně rychle i pro velké množství případů. U metody K-means, na rozdíl od hierarchického shlukování, zadáváme hned na začátku požadovaný počet shluků, v tomto případě jsme zvolili čtyři shluky, jež jsou graficky znázorněny různými křivkami na Obr. 1. Každá křivka vyjadřuje průměrnou vyčerpanost rámce pro příslušný shluk po jednotlivých měsících. Velikosti jednotlivých shluků jsou zobrazeny koláčovým grafem na Obr. 2. Pokusili jsme se nabídnout jednoslovná pojmenování výsledných shluků, což je však úkol sám o sobě velmi nelehký. Interpretace a pojmenování jednotlivých shluků tvoří klíčovou část segmentačního projektu, na kterou je zapotřebí vyčlenit alespoň polovinu určeného času, neboť musíme dosáhnout koncensu napříč několika odděleními. V krátkosti bychom však mohli říci, že Čerpači jsou lidé, kteří svou kartu používají pravidelně a pravidelně také splácejí, Spláceči načerpají sice více, ovšem po určité době se snaží své pohledávky zbavit, Váhavým klientům naopak trvá, než se kartu naučí používat, ale po tomto nesmělém začátku jsou schopni dosáhnout poměrně vysoké pohledávky a tuto pohledávku držet, a nakonec zde máme Jednorázové uživatele karty, kteří se nechali přesvědčit, aby si vyzkoušeli většinou jediné čerpání, po němž už kartu dále nepoužívají. 100% 90% 80% Průměrná vyčerpanost rámce 70% 60% 50% 40% 30% 20% 10% Čerpači Spláceči Váhaví Jednorázoví 0% Měsíce po aktivaci karty Obr. 1. Shluky klientů podle transakčního chování v prvních 2 letech po aktivaci karty

41 Zvaná přednáška 29 Čerpači Spláceči Váhaví Jednorázoví Obr. 2. Zastoupení jednotlivých segmentů v portfoliu 2.2 Případová studie: Segmentace podle chování v nedávné době Základní nastavení je velmi podobné jako v předcházející úloze, avšak s tím, že nyní nebudeme sledovat každého klienta v relativním čase od aktivace jeho karty, ale podíváme se na transakční historii celého portfolia v absolutním čase o dva roky nazpět. Budeme proto analyzovat ty klienty, kteří v uplynulých dvou letech použili svou platební kartu alespoň jednou (čili provedli nějaké čerpání). Kdybychom v tomto případě shlukovali klienty na základě prostého průběhu jejich vyčerpanosti, nedostali bychom žádné rozumné shluky, neboť za těchto podmínek máme v datech různě staré klienty tedy jednotliví klienti si svou kartu aktivovali před různě dlouhou dobou, takže jejich periody a fázové posuny čerpání dávají dohromady málo srozumitelnou změť, proto metodu použitou v předcházející případové studii nyní uplatnit nelze. Proto nastupuje trik, s nímž se ve shlukové analýze v praxi setkáváme často: nejdříve expertně nadefinujeme několik proměnných, z nichž každá má za cíl vyjádřit nějakou agregovanou charakteristiku transakčního chování. Pro správnou funkci shlukové analýzy je přitom důležité, aby vybrané proměnné byly vzájemně co nejméně korelované. V našem případě jsme definovali následující sadu charakteristik: AAT CNT DMN PAY PMO POS průměrná výše jednoho čerpání počet čerpání celkem počet čerpání ku počtu měsíců, v nichž klient čerpal poměr objemu plateb ku objemu čerpání počet měsíců, v nichž klient splácel mimořádně, ku počtu měsíců, v nichž měl předpis podíl počtu transakcí POS z celkového počtu transakcí Proměnných je šest, proto každý klient je teď reprezentován pouze šestimístným vektorem. A protože komponenty tohoto vektoru jsou v této úloze různorodé, jejich normalizace má daleko větší důležitost než v minulém případě. Opět tedy zajistíme, aby pro každé n=1,,6 platilo, že směrodatná odchylka S(V n ) = 1 a průměr P(V n ) = 0. Uplatníme opět metodu K-means, tentokrát však budeme požadovat pouze tři shluky. Výsledné segmenty potom můžeme popsat průměrnými hodnotami zvolených šesti charakteristik (Tab. 1). Grafické znázornění je zde o něco obtížnější, neboť shluky tentokrát nelze popsat křivkou průběhu vyčerpanosti, přesto však uspokojivého výsledků dosáhneme, když pro každý shluk vytvoříme sloupcový graf a jednotlivé

42 30 M. Nepil: Datamining v praxi charakteristiky znormalizujeme tak, aby maximální hodnota představovala 100 %. Z grafů je patrné, že každá ze šesti vyjmenovaných proměnných přispívá k odlišení určitého segmentu od segmentů zbývajících, neboť pro jeden segment je její hodnota podstatně vyšší než pro segmenty ostatní. Navíc se zde nevyskytuje žádná dvojice atributů, jejichž hodnota by vzrostla nebo klesla současně. Dohromady tedy můžeme říci, že atributy nejsou korelované a že každý z nich má rozlišovací schopnost. Přiznáváme však, že slovní interpretace shluků je v tomto případě komplikovaná. Tab. 1. Popis tří získaných shluků pomocí charakteristik transakčního chování Shluk č Velikost AAT CNT 25,2 3,7 8,6 DMN 2,43 1,30 1,43 PAY 1,62 1,83 4,21 PMO 0,167 0,225 0,105 POS 14,5 % 6,8 % 6,1 % Shluk č. 1 AAT CNT DMN PAY PMO POS Shluk č. 2 AAT CNT DMN PAY PMO POS Shluk č. 3 AAT CNT DMN PAY PMO POS Obr. 4. Grafická reprezentace získaných shluků normalizovanými vektory

43 Zvaná přednáška 31 3 Předzpracování a příprava dat Dolování dat je dnes již velmi vyspělá a disciplína, takže pro její nasazení do praxe bylo zavedeno několik průmyslových standardů. Mezi dva nejběžnější patří CRISP- DM a SEMMA. Metodologie CRISP-DM (CRoss Industry Standard Process for Data Mining) je vyvíjena nezávisle na dolovacím nástroji, nicméně u zrodu tohoto projektu stála firma SPSS, a proto produkty této firmy (zejména nástroj Clementine) v sobě nepokrytě nesou základní myšlenky metodologie CRISP-DM. Naproti tomu konkurenční přístup, schovávající se pod akronymem SEMMA (Sample, Explore, Modify, Model, Assess), je výhradním dílem firmy SAS, takže produkty této firmy lze považovat za implementaci metodologie SEMMA. Metodologie CRISP-DM 1 popisuje dolování dat jako proces sestávající z následujících kroků: 1. pochopení obchodních souvislostí 2. pochopení dat 3. příprava dat 4. modelování 5. vyhodnocení modelů 6. nasazení modelů do obchodního procesu Jednotlivé kroky přitom na sebe nenavazují pouze sekvenčně, protože v procesu modelování často zjistíme, že data je nutno připravit trochu jiným způsobem a musíme se proto vrátit o krok zpět. V závěru z vyhodnocení získaných modelů dostaneme další poznatky o obchodních souvislostech, čímž se uzavírá nekonečný cyklus dolování znalostí. Mohlo by se zdát, že samotné modelování je klíčovým bodem celého procesu. Do určité míry je to sice pravda, ovšem tento krok nám v praxi zabírá pouze nepatrný zlomek zdrojů, neboť je již do značné míry zautomatizován vyspělými dolovacími nástroji. Těžiště úspěchu dataminingového projektu stále zůstává v prvních třech výše uvedených bodech: správné stanovení obchodního cíle, pochopení dat a příprava dat totiž klade obrovské nároky na spolupráci specialistů nejméně ze tří různých oddělení: 1) obchodního a marketingového, 2) oddělení datových skladů a 3) analytického oddělení. Tito lidé přitom musejí být flexibilní a otevření vstřícné komunikaci. Princip SEMMA 2 je v porovnání s metodologií CRISP-DM o něco specifičtější a zaměřuje se na jádro dolovacího procesu, v němž je zapotřebí provést tyto kroky: 1. Sample identifikovat vhodná učicí data na základě obchodního zadání: vybrat správné sloupce ze správných tabulek, určit odpovídající rozsah dat a zajistit, aby údaje pocházely z toho časového období, které nás zajímá. 2. Explore připravit popisné statistiky, jež poskytnou základní metadata o obsahu a kvalitě podkladových dat: rozložení a četnosti hodnot, podíl nevyplněných a neplatných hodnot, duplicity různých identifikátorů (zejména rodných čísel). 3. Modify transformovat data do tvaru vhodného pro dolovací algoritmus, jenž chceme použít v následujícím kroku. Spadá sem úprava transakčních dat, zpracování textových údajů a využití externích databází a číselníků.

44 32 M. Nepil: Datamining v praxi 4. Model tento krok je v praxi paradoxně nejsnadnější, neboť vyžaduje pouze znalost ovládání dolovacího nástroje. I zde je však stále prostor pro vylepšení modelu využitím některých pokročilých technik (ensemble methods, feature extraction, relational data mining) Assess vyhodnotit úspěšnost modelu (v případě prediktivních modelů), interpretovat model v obchodních souvislostech (u deskriptivních modelů) a případně implementovat model do obchodního procesu. Máme-li ve firmě fungující datový sklad, mohlo by se zdát, že jej lze přímočaře použít pro přípravu dat, čímž bychom si tento nejnáročnější krok procesu dolování dat odbyli velice snadno. Praxe však ukazuje, že tomu tak bohužel není. Důvod spočívá v tom, že datové sklady jsou budovány zejména pro potřeby pravidelného reportingu a vícerozměrné dynamické analýzy (OLAP), avšak pro účely modelování datové sklady coby zdroje dat selhávají. Neposkytují totiž dostatečnou úroveň detailu a data v nich uložená nikdy nejsou v takovém tvaru, jaký bychom pro naši konkrétní úlohu potřebovali. Proto přicházejí ke slovu databázové repliky, jež přinášejí naprosto věrný obraz celého transakčně orientovaného primárního systému. Transformaci dat do potřebné podoby potom provádíme z velké části pomocí jazyka SQL a dá se říci, že při konstrukci každého modelu vytváříme svá vlastní účelově zaměřená datová tržiště (agregované datamarty). Dalším nutným předpokladem pro vybudování robustního, časově stabilního modelu je existence historických údajů pro všechny časově proměnné atributy, jež chceme coby prediktory do modelu zahrnout. Jestliže bychom totiž pro modelování klientovy odezvy na naši nabídku použili hodnoty aktuální, snadno by se nám mohlo stát, že bychom predikovali chování klienta na základě událostí, jež ve skutečnosti nastaly až jako důsledek akce, kterou vlastně chceme predikovat! Na takto nesprávně připravených učicích datech lze sestrojit vynikající model, jenž je bohužel při nasazení na nových příkladech odsouzen k nezdaru. Jestliže tedy připravujeme data pro responzní model a čerpáme z databáze údaje o dříve uskutečněných marketingových kampaních, nesmíme použít žádnou informaci, která vznikla až po okamžiku oslovení to je totiž okamžik, v němž chceme provádět predikci. Prvním krokem přípravy dat by měla být přesná identifikace individua, jež bude předmětem predikce (zda to má být jednotlivé čerpání, úvěrová smlouva, či klient), a v dalším kroku bychom měli jednoznačně specifikovat cílovou proměnnou T. Zkrátka musíme říci, čeho se predikce týká a co budeme predikovat. Cílová proměnná T je obvykle binární a u modelů odhadujících responzi můžeme například za případ T=1 (pozitivní případ) považovat klienta, jenž si aktivoval kartu do čtyř měsíců od odeslání nabídky. Ostatní případy, tedy klienty, již si doposud kartu neaktivovali, anebo ji aktivovali až po čtyřech měsících od oslovení, označíme jako T=0 (negativní případy). Máme-li jasno ohledně cílové (závislé) proměnné, zbývá najít a vybrat proměnné vysvětlující (nezávislé). Tyto prediktory musíme upravit tak, aby vyhovovaly zvolenému dolovacímu algoritmu. Obvyklou volbou pro prediktivní modely ve finanční sféře je logistická regrese 8. Dáme-li se touto cestou, pak prediktory nejčastěji transformujeme následujícím postupem. Spojité proměnné zdiskretizujeme, což znamená, že rozsah jejich hodnot rozdělíme do několika intervalů a tím je v podstatě převedeme na proměnné kategoriální. Diskretizačních metod je celá řada; velmi dobře pracují zejména techniky, které při stanovování

45 Zvaná přednáška 33 hraničních bodů intervalů berou ohled na cílovou proměnnou (supervised discretization). V praxi se nám výborně osvědčila diskretizace systémem WEKA 3. S diskretizovanými i kategoriálními proměnnými potom pracujeme jednotným způsobem. Pro každý atribut A a pro každou jeho hodnotu v vypočteme: P( A, v, s) = freq( A = v T = s) freq( T = s), takže P(A,v,1) vyjadřuje podíl pozitivních případů s hodnotou v u atributu A ku všem pozitivním případům, zatímco P(A,v,0) určuje podíl negativních příkladů, u nichž má atribut A hodnotu v, ku všem negativním případům. Potom zbývá každou hodnotu v atributu A nahradit takzvanou vahou zřejmosti (Weight of Evidence): P( A, v,1) + ε W ( A, v) = log P( A, v,0) + ε kdeε je vhodně zvolená vyhlazovací konstanta, která zároveň zajistí, aby W(A,v) bylo definováno i pro případ, kdy P(A,v,1) = 0. Na takto transformované prediktory už lze aplikovat logistickou regresi. Potíž bývá s textovými údaji (název povolání, název zakoupeného zboží) a některými geografickými údaji (PSČ, město), neboť ty se vyznačují velkým počtem málo četných hodnot, pro něž je spolehlivý odhad podmíněných pravděpodobností P(A,v,s) nemožný. U takových atributů tedy musíme provést další sofistikované úpravy, které by řídkost dat snížily. V případě textových polí se můžeme například pokusit o hledání frekventovanějších podřetězců. A pokud jde o atributy geografické (PSČ), lze pro ně s úspěchem využít externí databáze, ze kterých získáme zeměpisné souřadnice daného místa a následně můžeme tato místa shlukovat podle jejich geografické vzdálenosti., 4 Vyhodnocení účinnosti prediktivního modelu Prediktivní modely analytického CRM se nepoužívají k přímé klasifikaci klientů do dvou nebo více tříd, nýbrž k uspořádání klientů podle pravděpodobnosti očekávaného jevu (responze na naši nabídku). Namísto klasifikace tedy provádíme skóring: nové klienty za pomoci modelu seřadíme a prvních N nejnadějnějších oslovíme určitou nabídkou. Přesto skóringový model lze snadno převést na tradiční binární klasifikátor tím, že si stanovíme určitou prahovou hodnotu výsledného skóre (takzvaný cut-off), přičemž hodnoty pod tímto prahem klasifikujeme do třídy 0, zatímco hodnoty přesahující daný práh přiřadíme do třídy 1. Po této úpravě bychom účinnost našich skóringových modelů mohli měřit tradičními mírami kvality, jako například správností klasifikace (procentem správně klasifikovaných příkladů; accuracy). Potíž však tkví v tom, že chceme měřit úspěšnost modelu bez ohledu na stanovený cut-off. Navíc zastoupení jednotlivých sledovaných tříd v klientském portfoliu je většinou nevyvážené (podíl respondujících klientů zpravidla nedosahuje poloviny z oslovených) a v těchto situacích je prostá správnost klasifikace zkreslující. Účinnost

46 34 M. Nepil: Datamining v praxi skóringových modelů proto měříme pomocí křivky ROC (Receiver Operating Characteristic), což je technika historicky přejatá z oblasti zpracování signálu. Před marketingovou akcí, kdy vybíráme klienty pro oslovení, se naše klientská báze dělí na dvě (předem neznámé) části: na klienty, kteří naši nabídku přijmou (Respondenti), a na klienty, kteří naopak na tuto nabídku neodpoví (Ne-Respondenti). Křivka ROC v pojetí skóringových modelů pak vypadá tak, že její X-ová osa udává podíl oslovených Ne-Respondentů ze všech Ne-Respondentů (False Negatives) a na ose Y-ové je vynesen podíl oslovených Respondentů ze všech Respondentů (True Positives). Příklad takového grafu je na Obr % 90% Prediktivní model Náhodné hádání 80% 70% Osloveno Respondentů 60% 50% 40% 30% 20% 10% 0% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Osloveno Ne-Respondentů Obr. 5. Příklad křivky ROC. Giniho index zde má hodnotu 0,522. V kontextu statistiky se pro tento graf také užívá název Lorenzova křivka. Poměr obsahu oblasti mezi obloukem křivky a úhlopříčkou ku obsahu celé oblasti nad úhlopříčkou se potom označuje jako Giniho index a jde o ukazatel pohybující se teoreticky v intervalu [0;1], přičemž hodnota 0 představuje náhodné hádání (prázdný model), zatímco hodnotu 1 bychom naopak dostali při naprosto ideálním modelu, jenž by skóroval klienty bez výjimky správně. Protože se zajímáme o plochu pod křivkou ROC, setkáváme se také s anglickým termínem AUROC (Area under ROC). Definice X-ové osy křivky ROC však není pro účely marketingových kampaní vždy nejvhodnější; spíše nás obvykle zajímá, jak velký díl Respondentů oslovíme, jestliže oslovíme určitý díl celé populace. Proto provádíme drobnou úpravu křivky ROC: předefinujeme X-ovou osu tak, aby udávala procento oslovených klientů ze všech klientů, jež máme k dispozici, čímž dostáváme takzvaný graf zisku (gain chart) a funkci zisku y=g(x). Příklad grafu zisku nalezneme na Obr. 6. Kvalita náhodného hádání, čili prázdného modelu, i zde splývá s úhlopříčkou a křivka pro ideální model tvoří spolu s úhlopříčkou tupý trojúhelník. Velikost tupého úhlu v tomto trojúhelníku se odvíjí od poměru zastoupení jednotlivých tříd (poměr počtu Respondentů ku počtu Ne-Respondentů) v populaci. Giniho index je však odvoditelný i z grafu zisku: jde

47 Zvaná přednáška 35 o poměr obsahu oblasti mezi obloukem a úhlopříčkou ku obsahu onoho tupého trojúhelníku. V grafu na Obr. 6 je kromě funkce zisku y=g(x) navíc vynesena také výsledná relativní responze (poměr respondujících klientů ku osloveným klientům), kterou dosáhneme, pokud pomocí modelu vybereme daný podíl klientů. Z Obr. 6 můžeme kupříkladu vyčíst, že pokud oslovíme horních 30 % ze všech klientů, jež máme k dispozici, pak se naše nabídka dostane k 60 % Respondentů a obdržíme relativní responzi 12 %, což je dvojnásobek relativní responze, kterou bychom dosáhli bez použití modelu, čili oslovením všech klientů. 100% 90% 80% 70% Osloveno Respondentů 60% 50% 40% 30% Reálný model Ideální model Prázdný model Výsledná responze 20% 10% 0% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Osloveno všech klientů Obr. 6. Graf zisku: porovnání reálného, ideálního a prázdného modelu Dalším možným ukazatelem kvality skóringového modelu může být graf navýšení (lift chart) demonstrovaný na Obr. 7, jenž nám říká, kolikrát je při daném poměru vybraných a oslovených klientů skóringový model lepší než náhodný výběr. Porovnáváme-li vzájemně kvalitu několika různých modelů, srovnáváme obvykle jejich Giniho index, případně index navýšení (lift) na desátém percentilu. Obecně je velmi těžké stanovit nějakou mez, od které lze model považovat za dobrý, protože odhad responze u odlišných typů kampaní může být velmi různě obtížný. Přesné porovnání kvality dvou modelů je sice důležitá věc, v praxi je však ještě mnohem důležitější vědět, jaký finanční dopad bude aplikace modelu mít. Máme-li prediktivní model hotový a známe-li pro něj funkci zisku y=g(x), pak k výpočtu jeho finančního přínosu potřebujeme zjistit hodnotu těchto čtyř parametrů: 1. celkové náklady C na obeslání jednoho klienta 2. čistý příjem I z jednoho Respondenta (po odečtení rizikových nákladů) 3. předpokládanou apriorní responzi R, čímž máme na mysli takovou relativní responzi, jakou bychom dosáhli bez použití modelu 4. počet klientů B, kteří potenciálně mohou být osloveni (velikost báze)

48 36 M. Nepil: Datamining v praxi Jestliže jsme schopni tyto čtyři údaje získat což nebývá snadné, neboť k tomu musíme posbírat informace z mnoha různých oddělení můžeme už snadno sestrojit křivku profitu (Obr. 8 a 9), která nám přesně řekne, jaké procento klientů bychom měli oslovit, abychom maximalizovali zisk z dané kampaně. Čistý zisk je totiž dán výrazem {G(x) I R x C} B, kde x značí procento oslovených klientů a G(x) je již dříve zmíněná funkce zisku. Je zřejmé, že pro náhodný výběr platí G(x) = x, což znamená, že příjmy i čistý zisk rostou lineárně a zisk je nejvyšší v bodě x = 100 %. 4 3,5 Navýšení oproti náhodnému výběru 3 2,5 2 1,5 1 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Osloveno všech klientů Obr. 7. Graf navýšení: index navýšení v prvním decilu je 2,7. Čtvrtý údaj B (velikost portfolia) nemá vliv na průběh křivek a tedy ani na optimální procento oslovených klientů, tato informace však slouží k tomu, aby Y-ová osa vyjadřovala srozumitelný údaj, a to čistý zisk akce v peněžních jednotkách. Porovnáním obrázků č. 8 a 9 snadno vidíme, že uplatnění prediktivních modelů je tím nevyhnutelnější, čím máme vyšší jednotkové náklady na oslovení, nižší příjem z respondujícího klienta a nižší předpokládanou apriorní responzi. Také je patrné, že poměrně malá změna těchto parametrů má velký vliv na profitovou křivku. Jsou-li parametry nastaveny tak, jak ukazuje Obr. 8, pak je čistý zisk maximalizován při oslovení 54 % klientské báze. Ovšem Obr. 9 vypadá po malé změně parametrů podstatně pesimističtěji: nejvyššího zisku dosáhneme při oslovení 21 % klientů a pokud jich oslovíme více než 68 %, dostaneme se dokonce do ztráty. Samozřejmě však mohou nastat situace, kdy je zisk maximalizován až při oslovení všech klientů v tom případě prediktivní model není zapotřebí. Lze si ovšem představit, že nás tlaky konkurenčního prostředí zavedou do takové konstelace parametrů, kdy bez použití responzního modelu k rozumnému zisku nedospějeme. Tímto způsobem je tedy možné optimalizovat jednu kampaň. Vyšší úrovně optimalizace ovšem docílíme tehdy, pokusíme-li se optimalizovat vytěžovací proces jako celek. Pokud máme například možnost oslovit klienty několika různými nabídkami, z nichž každá s sebou nese odlišné náklady na oslovení, jinou výši příjmu z responze i rozdílnou předpokládanou apriorní responzi, stojíme před poměrně náročnou optimalizační úlohou.

49 Zvaná přednáška 37 Obr. 8. Bilance výdajů a příjmů: zisk maximalizován při oslovení 54 % klientů Obr. 9. Při oslovení více naž 68 % klientů se dostaneme do ztráty

50 38 M. Nepil: Datamining v praxi 5 Shrnutí Zabývali jsme se dvěma metodologickými standardy pro dolování znalostí z databází v návaznosti na řešení konkrétních dataminingových úloh z praxe. Pokusili jsme se přiblížit čtenáři vývoj a uplatnění prediktivních i deskriptivních modelů (segmentace klientů) v oblasti spotřebitelského financování. Záměrně jsme se však vyhnuli dalším důležitým otázkám, které jsou spjaty s praktickým využitím dataminingových modelů. Máme na mysli zejména tyto výzvy: Jak nezkresleně vyhodnotit model na nových klientech, když tento vzorek populace je vychýlen právě v důsledku aplikace modelu? Jak na takto vychýlené populaci trénovat nové verze modelů? Jak zjistit, zda můžeme bez obav aplikovat model na nově příchozí klienty tedy zda náš model již nezestárnul? Stejnětak jsme vynechali problematiku vazby marketingových modelů na modely rizikové. Spojením vytěžovacího a rizikového pohledu lze dospět k velmi komplexnímu přístupu, kdy klienta posuzujeme jednak na ose náklonnosti ke koupi, ale také na ose náchylnosti k nesplacení úvěru. Kombinace těchto rozdílných pohledů by měla směřovat k vytvoření modelu čisté současné hodnoty klienta. Literatura 1. CRISP-DM: CRoss Industry Standard Process for Data Mining [online]: 2. SEMMA: Sample, Explore, Modify, Model, Assess [online]: 3. WEKA: Datamining Software in Java [online]: 4. Elektronická učebnice statistiky [online]: 5. Berka, P.: Dobývání znalostí z databází. Academia, Praha (2003) 6. Berry, M. and Linoff, G.: Data Mining Techniques for Marketing, Sales, and Customer Relationship Management. John Wiley & Sons, Indianapolis (2004) 7. Kelly, S.: Mining Data to Discover Customer Segments. In Journal of Interactive Marketing, 4 (3), (2003) 8. Rud, O. P.: Data mining: Praktický průvodce dolováním dat pro efektivní prodej, cílený marketing a podporu zákazníků (CRM). Computer Press, Praha (2001) 9. Van den Poel, D. and Larivière, B.: Customer Attrition Analysis for Financial Services Using Proportional Hazard Models. In European Journal of Operational Research, 157 (1), (2004) Annotation: Practices of Data Mining Data mining in the area of consumer finance services ceases from being just a competitive advantage and becomes necessary for every company in order to be able to compete in this rapidly evolving branch. We discuss the industrial standards for data mining and how to apply them to solve some particular business tasks.

51 Krizové řízení Jaroslav PEJČOCH T-SOFT spol. s r.o. Novodvorská 1010/14, Praha pejcoch@tsoft.cz Abstrakt. Krizové řízení je v poslední době stále více frekventovaným termínem. V souvislosti s vyšší četností přírodních katastrof, lokálními válečnými situacemi, epidemiemi a mezinárodním terorismem začíná tato problematika přitahovat řadu odborníků i firem, neboť v reakci na rozvoj homeland security zejména v USA sem tečou i nemalé finanční prostředky a je zde i jistá mediální přitažlivost pro politiky. V tomto příspěvku se pokusíme stručně popsat tuto půdu a ukázat možné využití informačních a komunikačních technologií. Klíčová slova: krizové řízení, procesní řízení, modelování, simulace, zdroje a prostředky, GIS, interoperabilita, bezpečnost. 1 Úvod Při odpovědi na dotaz co je to krizové řízení by ještě před cca 10 lety možná většina lidí mířila do oblasti záchrany krachujících firem, kdy nastoupí krizový management a ráznými zásahy se pokouší zachovat podnik naživu či ho efektivně dorazit. Po povodních na Moravě v roce 1997 a rozpacích při jejich zvládání se začalo mluvit více i o druhé oblasti aktivitách směřujících k záchraně životů a majetku při přírodních či průmyslových katastrofách, které přesahují rozsah běžných havárií. Krizové řízení zasahuje do řady různých oblastí lidské činnosti, pracuje s informacemi, které pocházejí z různých zdrojů jak v oblasti veřejné správy, tak podnikové sféry. Tato rozmanitost vyvstává zejména v poslední době, kdy hrozby teroristických útoků a možnost zneužití částí infrastruktury jako tzv. "civilních zbraní" přináší nutnost zabývat se pečlivěji kritickou infrastrukturou, jejíž případný kolaps hrozí extrémními následky. V současné době jsou k dispozici systémy a technologie, které usnadňují v tomto kontextu vytváření krizových plánů, meziresortní kooperaci, spolupráci státu se soukromými subjekty, monitorování infrastruktury a další nutné služby pro krizové manažery v různých organizacích. Některé z těchto systémů jsou již v rutinním používání a postupně je zajišťována jejich interoperabilita na základě standardů. Dá se říci, že vzhledem k multidisciplinárnímu charakteru krizového řízení zde naleznou využití veškeré vyspělé technologie. L. Popelínský, O. Výborný (eds.), DATAKON 2007, Brno, , str

52 40 J. Pejčoch: Krizové řízení 2 Krizové řízení Krizové řízení si pracovně můžeme definovat jako soubor aktivit, které plánovitě vedou k minimalizaci rizik a v případě katastrof pak k minimalizaci škod a rychlé a efektivní obnově. Bohužel v této oblasti není stále ještě definovaná náležitě terminologie, takže dochází k urputným střetům puristických zastánců toho či onoho výkladu, obvykle bez nějakého vlivu na samotnou podstatu. Zejména se vedou disputace na téma vztahu krizového řízení a bezpečnosti, což se dá opět pracovně vyřešit tím, že definujeme jakousi Unitární bezpečnost, která všechny jmenované věci zahrnuje a zabýváme se spíše vymezením hracího pole, jednotlivými hráči, jejich vztahy a aktivitami. Můžeme tak dojít k tomu, že krizové řízení není nic jiného než normální řízení, pouze soustředěné na zahrnutí hrozeb a řešení výjimečných či poruchových situací, které narušují standardní běh systému. Máme-li například v organizaci popsané a fungující procesní řízení, krizové řízení můžeme vidět jako část řízení rizik, tj. jejich analýzu, minimalizaci a popis náhradních či krizových procesů. Tyto speciální procesy slouží zejména k zamezení eskalace problému, zachování kontinuity života organizace a přechod do fáze obnovy, když je krize zažehnána. Jako organizaci si tady můžeme představit jak podnik, tak region, stát, svět, tak vlastní rodinu a její finanční hospodaření. Jak vidno, pole, kam se můžeme s krizovým řízením dostávat, může být velmi široké a závisí na dané organizaci, jak široce a zodpovědně ho pojme, jaké prostředky věnuje do přípravy, prevence a výchovy specialistů a jaké projekty v této oblasti podporuje. Existuje ovšem i přístup Deux ex Machina, kdy se jede na doraz, neboť jsou důležitější věci a když už k nějaké té kritické situaci dojde, povolá se Velký krizový manager a ten svou moudrostí a rozhodností vše vyřeší. Na první pohled to sice vypadá nesmyslně, nicméně i takový přístup může být plně funkční a dokonce optimální závisí čistě na výsledku zodpovědné analýzy rizik. Jak víme, riziko nelze odstranit, pouze zmenšit a náklady na ono zmenšení mohou být tak velké, že daleko překonají hodnoty, které mohou být nastalou krizovou situací ohroženy. 3 Hrací pole a hráči Problematiku krizového řízení můžeme studovat na vymezeném prostoru nějaké organizace, která je dostatečně velká či důležitá na to, aby to mělo smysl. Necháme-li stranou podniky a banky, nejzajímavější organizací z tohoto hlediska je stát, neboť ochrana obyvatel, majetku a životního prostředí je jedním ze základních práv zaručených ústavou. Stát, který působí na nějakém teritoriu, funguje obvykle v nějaké hierarchii a každý ze stupňů má své vlastní problémy a přístupy k jejich řešení. Na každém stupni může docházet ke kritickým stavům, které pro daný stupeň mohou představovat krizi, nicméně z hlediska vyššího celku jde pouze o havarijní stav, který je možno s danými prostředky vyřešit.

53 Zvaná přednáška 41 Hráči, kteří se na tomto poli vyskytují, jsou velmi různorodí - Stát a státní organizace - Specializované organizace Integrovaného záchranného systému (hasiči, policie, záchranky) - Armáda - Nestátní organizace (záchranné služby, dobrovolní hasiči, humanitární organizace, ) - Podniky kritické infrastruktury (energie, komunikace, zásobování, finance.) A v neposlední řadě (vlastně na prvním místě) občané my, pro které se to všechno dělá a pak rovněž velmi významný prvek média. Celá takto široká hráčská obec potřebuje k tomu, aby krizové situace buď nevypukly a nebo byly rychle pacifikovány společné znalosti a informace. Mluví se o tzv. Společném obrazu situace, který napomáhá spolupráci jak v horizontálním, tak ve vertikálním směru a zajišťuje tak nutnou interoperabilitu, bez které je veškeré snažení pouze více či méně koordinovaným chaosem s lokální optimalizací. 4 Informační podpora Krizové řízení je díky své průřezovosti ideálním adeptem pro využití komplexní informační podpory. Jedná se jak o analytické a plánovací aktivity, tak o podporu rozhodování v akci a automatizaci těch věcí, které automatizovat lze. Nebudeme jistě podléhat domněnce, že informační systémy nějak samy zasahují do řešení krizových situací. Můžeme však velmi dobře využít následujících nástrojů: - modelování hrozeb (jak aktuálních, tak pro účely plánování a výuky - kalkulace rizik - správu dokumentů - zobrazování a analýzy v rámci GIS - simulace krizových scénářů - automatizované vyrozumění - data-video konference - protokolování, statistiky,

54 42 J. Pejčoch: Krizové řízení V souvislosti s rozvojem interoperabilních rozhraní je možné informační systémy stále více provozovat on-line a propojovat a dosahovat tak uvedeného společného obrazu situace. Využívá se do značné míry standardů převzatých z ozbrojených složek či inspirovaných jimi. Vedle uzavřené specializované a chráněné informační oblasti pro stát a jeho složky, je vhodné uvažovat o co možná nejužší komunikaci i s ostatními hráči. Moderní ICT tuto činnost značně usnadňují a zefektivňují. V prezentaci bude uvedeno více detailů využití ICT v krizovém řízení, včetně pohledu na informační bezpečnost. 5 Závěr Tento příspěvek stručně popisuje některé aspekty krizového řízení a jeho informační podpory. Krizové řízení je popsáno jako multidisciplinární obor, kde kvalitní informační podpora může podstatně zvýšit efektivitu práce a ve výsledku tak zachránit lidské životy a majetek. Detailnější popis jednotlivých přístupů, technologií a jejich výsledků bude předložen při prezentaci příspěvku na konferenci. Literatura Vzhledem k šíři, nejednotnosti a překotnému vývoji tohoto oboru je vhodné sledovat a vyhledávat prameny spíše na webu. Adresy: poslouží jako vstupní body pro další vyhledávání informací. Annotation: Crisis Management Crisis management (or emergency management) has been more and more popular in recent years. Natural disasters, local wars, epidemies and terrorism attracts experts, politicians and companies, because in the reaction to the Homeland Security in the US there is increasing inflow of finances and sort of publicity attractiveness for politicians. In this paper we try briefly describe this playground and show possibilities of utilization of ICT in this area..

55 Bezpečnost IT podle standardu řady ISO2700x Jan MIKULECKÝ, Libor ŠIROKÝ Risk Analysis Consultants s.r.o. Španělská 2, Praha 2 Jan.Mikulecky@rac.cz Libor.Siroky@rac.cz Abstrakt: Řada norem 2700x má za sebou dlouhou historii sahající až do 80. let. Široké využívání norem ukazuje, že zvolený přístup od praxe ke standardu je ten správný. V současné době není bezpečnostního manažera, který by tyto normy každodenně nepoužíval. Řádná aplikace norem, jmenovitě 27002, je v některých českých organizacích potvrzena úspěšnou certifikací. Klíčová slova: ISO 27000, ISO 27001, ISO 27002, ISO 27004, ISO 27006, ISO 27007, ISMS, systém řízení, systém řízení bezpečnosti informací, informační bezpečnost, analýza rizik, analýza stavu, analýza dopadů, aktivum, hrozba, zranitelnost riziko, protiopatření. 1 Historie norem řady 27k Historie normy ISO/IEC je úzce propojena s historií normy ISO/IEC 27002:2005 a sahá až do roku 1989, kdy byl vytvořen jejich společný předchůdce. O vznik se zasloužila vládní organizace UK Department of Trade and Industry's (DTI) Commercial Computer Security Centre (CCSC), která měla dva hlavní úkoly. Jedním z nich bylo pomoci dodavatelům bezpečnostních produktů prostřednictvím vytvoření mezinárodně uznávaných kritérií pro hodnocení bezpečnosti, což dalo za vznik kritériím ITSEC. Druhým úkolem pak bylo pomoci uživatelům zajistit bezpečnost jejich informačních systémů (IS) prostřednictvím vytvoření sbírky nejlepších praktik (best practices). Tak vznikla první sbírka praktik, která byla následně dále vyvíjena britským National Computing Center (NCC) a později také konsorciem složeným z uživatelů vybraných z britských komerčních organizací. V polovině 90-tých let vyvrcholila aktivita pracovní skupiny v rámci BSI označované Technical Commitee BSFD/12 vytvořením standardu pro řízení bezpečnosti informací v organizacích, jako sbírky nejlepších doporučovaných praktik pro zvládání bezpečnosti informačních technologií, označovaného BS 7799:1995 Code of practice for Information security management. Verze BS 7799:1995 byla zaměřena na podporu organizace při zavedení opatření sbírky praktik bez důrazu na provedení hodnocení rizik. Použití normy předpokládalo, že implementace opatření pokryje dostatečnou měrou většinu rizik organizace. BS 7799:1995 po svém vydání vzbudila mezinárodní zájem a již tato verze byla navržena, aby byla přijata jako ISO. V této fázi se to však nezdařilo. Mezinárodní zájem okolo verze normy BS 7799 z roku 1995 dodával jejím tvůrcům motivaci pro L.Popelínský, O.Výborný(eds.), DATAKON 2007 Brno, , str

56 44 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x její další rozvoj a tak došlo k její další rozsáhlé revizi. Tyto změny byly završeny v roce 1999 výstupem z práce skupiny v rámci BSI označované Committe BDD/2 vydáním standardu BS 7799 ve dvou částech BS :1999 Code of practice for information security management a BS :1999 Specification for information system management systems. Kvalita BS 7799 byla potvrzena návrhem, aby se část 1 stala normou ISO. Přijetí BS jako normy ISO proběhlo ve zrychleném procesu (tzv. fast track) a v roce 2000 tak přišla na svět norma ISO/IEC 27002:2007, která se stala široce aplikovanou normou bezpečnosti informací po celém světě. V roce 2002 byla vydána nová verze druhé části normy ISO/IEC 27001:2005. Jejím cílem byla zejména harmonizace s ostatními normami popisujícími zavádění systémů řízení. Jedná se zejména o systém řízení jakosti dle ISO 9001:2000 a životního prostředí dle ISO 14001:2004. Od roku 2001 pak probíhala revize ISO/IEC 27002:2007, která byla završena v červnu 2005, kdy byla publikována druhá verze této mezinárodní normy pod označením ISO/IEC 17799:2005. Na jaře roku 2005 ohlásila mezinárodní organizace ISO zavedení nové série norem ISO 27k. Soubor těchto mezinárodních norem připravuje technická komise ISO/IEC JTC 1/SC 27. Soubor zahrnuje požadavky na systém řízení bezpečnosti informací, řízení rizik, metriky a měření výkonu a doporučení k implementaci. Z této série byla do této doby publikovány ISO/IEC 27001:2005, ISO/IEC 27002:2005 a ISO/IEC 27006:2007. Stávající ISO/IEC byla v roce 2005 ještě publikována pod označením ISO/IEC 17799:2005, v letošním roce došlo k jejímu přejmenování beze změny obsahu. Publikace ostatních norem série 27tisíc je plánována během následujících několika let. Kromě již publikovaných, jsou některé další normy této série do větší či menší míry rozpracovány a existují v tzv. draft verzích, jejich výčet je uveden v následujícím přehledu, viz také obrázek. Tučně jsou označeny finální verze norem, které již byly oficiálně publikovány: ISO/IEC Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary - definice pojmů a terminologický slovník pro všechny ostatní normy z této série; ISO/IEC 27001:2005 Information technology -- Security techniques -- Specification for an Information Security Management System - hlavní norma pro Systém řízení bezpečnosti informací (ISMS), dříve známá jako BS7799 část 2, podle které jsou systémy řízení certifikovány; ISO/IEC 27002: Information technology -- Security techniques -- Code of Practice for Information Security Management - norma poskytuje podrobný přehled (katalog) bezpečnostních opatření, které mohou být vybrány při budování ISMS podle ISO/IEC Aktuální verze normy byla publikována v červnu 2007, dříve byla známa po označením ISO/IEC a BS 7799 část 1; ISO/IEC Information technology -- Security techniques -- Information security management system implementation guidance (draft) norma je prozatím v pracovní verzi, měla by poskytovat návod k implementaci ostatních norem série 27tisíc; ISO/IEC Information technology -- Security techniques -- Information security management measurements - norma by měla být pro organizace pomůckou k měření a prezentaci efektivity jejich systémů řízení bezpečnosti informací (ISMS), zahrnující řídící procesy definované v ISO/IEC a opatření z ISO/IEC 27002;

57 Tutoriál 45 ISO Information technology -- Security techniques -- Information security risk management norma by měla poskytovat doporučení a techniky pro analýzy informačních rizik, jejím základem jsou revize dříve vydaných norem ISO/IEC TR :1998 a ISO/IEC TR :2000, zvažuje se využití některých částí britské BS 7799 část 3; ISO/IEC 27006: Information technology - Security techniques - Requirements for bodies providing audit and certification of information security management systems tato norma poskytuje doporučení a požadavky na certifikaci ISMS a je tedy zejména určená akreditovaným certifikačním autoritám a také těm autoritám, které o akreditaci na provádění certifikací ISMS teprve usilují, ISO/IEC Information technology -- Security techniques -- Guidelines for Information security management systems auditing (draft) norma měla by obsahovat doporučení k provádění auditů ISMS podle ISO/IEC 27001, obsahově by měla čerpat zejména z ISO 19011:2002 Směrnice pro auditování systému managementu jakosti a/nebo systému environmentálního managementu; ISO/IEC Information technology -- Security techniques -- Information security management guidelines for telecommunications norma by měla obsahovat doporučení a požadavky na řízení bezpečnosti informací v prostředí telekomunikačních operátorů. Jedná se tedy o obdobu ISO/IEC 27001, cílenou na specifické prostředí a rizika provozovatelů telekomunikačních služeb. Obr. 4 Rodina norem 2700x

58 46 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x 2 Zavedení ISMS Zásady budování a využívání systému řízení bezpečnosti informací (ISMS Information Security Management System) podle ISO/IEC 27002:2005 se dají interpretovat různými způsoby v závislosti na velikosti organizace. Jejich podstata však zůstává stejná informační bezpečnost musí být řízena. Doporučení, zda zavést ISMS, zní pro většinu organizací ANO a otázka jejich velikosti, zaměření nebo podílu na trhuje irelevantní. ISMS lze zavést a používat v organizaci s deseti pracovníky, a stejně tak i v obřím holdingu, kde se každý den můžete potkat s tisíci zaměstnanci. Továrna využije ISMS stejně jako banka. Zjednodušeně lze říci, že ISMS je jen jeden a to ten, který je popsán v normě. Interpretace a implementace jednotlivých doporučení se však může výrazně lišit podle rozsahu systému, počtu uživatelů, způsobů zpracování dat a jejich hodnoty apod. Například bezpečností politika, jako ten nejvyšší dokument o bezpečnosti informací v organizaci, může být velmi podobná pro živnostníka i pro velkou akciovku. Pokud se ISMS zavádí pro celou společnost, tak diametrální rozdíly je možné vidět v organizaci bezpečnosti - v týmu ISMS, kde pro tisíce uživatelů je nutné zřídit samostatné bezpečností oddělení s 5-10 lidmi, ve střední firmě na to stačí 2 pracovníci a pokud máme systém pro 10 lidí, tak jeden člověk na půl úvazku je až moc. 2.1 Strategie bezpečnosti Podpora managementu Strategie bezpečnosti nebývá ve středních firmách popsána nijak detailně, jako je tomu zvykem ve velkých společnostech. Zpravidla stačí, aby ředitel středně velké organizace měl vůli řešit bezpečnostní otázky, a pak není nutné sepisovat rozsáhlý dokument o koncepci řízení bezpečnosti. Je dostatečné, pokud se ředitel na své poradě s dalšími vedoucími pracovníky shodne na strategii a ta se začne prosazovat. V malých firmách je toto ještě jednodušší, protože od první úvahy ředitele je k započetí realizace stejně daleko, jako od jeho dveří k zasedací místnosti Správná volba a způsob prosazení strategie řízení bezpečnosti není jednoduchá záležitost a už v tuto chvíli je vhodné se obrátit na odborníky, pokud tito nejsou ve vlastních řadách. Pro střední a malé firmy je však samotnou strategií už jen to, že se organizace rozhodla řídit bezpečnost svých informací. Pokud se rozhodnutí rozšíří na řízení bezpečnosti v souladu se standardem [2] (definující způsob aplikace opatření z normy [1]), je strategie vcelku rozumně nalajnována a další diskuse o tom, co a jak a kdy provádět je zbytečná, protože zavedení ISMS má své pevné zásady a postupy. 2.2 Bezpečnostní politika Proces vytvoření a schválení Bezpečnostní politiky je společný pro všechny typy organizací včetně publikování politiky vůči všem zaměstnancům. Také rozsah a obsah dokumentu je velmi podobný. Zcela nedávno jsme v rámci projektu zavádění ISMS tvořili bezpečnostní politiku pro velkou telekomunikační společnost (cca 3000 lidí). Souběžně jsme podobný projekt prováděli ve státní organizaci se stovkou zaměstnanců. Oba dokumenty měly strukturu podle ISO a na první pohled byly velmi podobné. Bezpečnostní politika definuje zásady a pravidla na úrovni cílů a ty jsou zpravidla shodné pro všechny organizace. Musí také obsahovat odkaz na dokument popisující rozsah ISMS, protože systém řízení bezpečnosti v malé ani

59 Tutoriál 47 střední firmě nemusí být zaveden pro celý informační systém (stejně jako systém řízení kvality podle ISO řady 9000). 2.3 Organizace bezpečnosti - Tým ISMS V dokumentu bezpečnostní politiky by měla být popsána mj. Organizační struktura bezpečnosti, která je však významná pouze u středních a velkých firem. A v tomto se také lišily obě výše zmiňované politiky. Popis bezpečnostních rolí a jejich odpovědností musí odpovídat velikosti systému a počtu uživatelů. Navíc je nutné respektovat zavedenou organizační strukturu a proto je možné pro stejně velké společnosti použít různé modely organizace bezpečnosti. V malých firmách nemusí být jmenován bezpečnostní ředitel na plný úvazek. Jeho kompetence zpravidla bere na sebe ředitel firmy, který prosazuje bezpečnostní zásady kombinací direktivního a osobního přístupu. Ředitel má na starosti mj. účinnou implementaci bezpečností politiky a vyhodnocování (ne analýzu) rizik a rozhodnutí o způsobu jejich pokrytí. Podobně je tomu i s dalšími bezpečnostními rolemi. Administrátor sítě má odpovědnost za praktické provedení bezpečnostních zásad a metodik, o kterých rozhodl ředitel. Některé činnosti z oblasti bezpečnostní dokumentace mohou být v kompetenci vybraného pracovníka, který může mít na starosti také audit. Kumulace práv a pravomocí souvisejících s bezpečností informací a se správou systému je pro malé organizace rizikem, které je nutné přijmout. Organizace bezpečnosti v souvislosti s kumulací práva a povinností v oblasti bezpečnosti není vyřešena ani v mnoha velkých organizacích. Téměř v každé se najde jeden nebo několik neomezených vládců systémů, na jejichž oddanost firmě všichni spoléhají. Pro tyto situace nelze nalézt univerzální řešení a proto jsou prosazována a uplatňována různorodá pravidla, jejichž popis je na samostatný článek. 2.4 Analýza rizik Znalost bezpečnostních rizik je základním kamenem pro vytvoření a správně řízení ISMS. Proto provedení Analýzy rizik je nutná nikoli však postačující podmínka pro všechny organizace. Rozhodnutí, zda provést detailní či jen základní analýzu, je na vedení firmy, nicméně pouze detailní analýza provedená podle vybrané metodiky může poskytnou podklady pro efektivní výběr a implementaci bezpečnostních opatření. Analýza musí zabrat celý rozsah ISMS a její hloubka závisí na dostupných zdrojích a požadovaných výstupech. V malé firmě lze provést detailní analýzu (například metodikou Octave, CRAMM nebo RA Tool) za dva až tři týdny. Je možné spolupracovat s jedním konzultantem nebo vše udělat za pomoci vlastních (znalých) pracovníků. Zatížení firmy je minimální a počet respondentů nepřevýší 5. Pro hodnocení dat se vyberou 2-4 zaměstnanci, kteří nejvíce znají charakter a použití definovaných datových aktiv, a administrátor sítě provede hodnocení hrozeb a zranitelností včetně identifikace existujících protiopatření. Detailní analýza ve středně velké organizaci trvá zpravidla 3-5 měsíců a důvodem není ani tak rozsah, který je samozřejmě větší než u malých firem, ale rychlost odezvy od respondentů či recenzentů (schvalovatelů) výstupů z analýzy. Pro malou firmu jsou závěry shrnuty v jedné zprávě o analýze rizik, po které následuje návrh implementačního plánu. Prezentace takových závěrů je velmi rychlá a jednoduchá

60 48 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x a odezva na ni téměř okamžitá. Ve středních firmách se projevují první známky nutné byrokracie a pro schválení závěrů je nezbytné (ale občas zbytečné), aby výstupní dokumenty prošli minimálně 3 pracovníci. Pokud je analýza prováděna dodavatelským či partnerským přístupem, jsou v týmu dva až tři externí pracovníci a stejný počet interních. Analýza prochází vždy napříč celou organizací a tomu odpovídá i zatížení dotčených pracovníků. Počet respondentů pro hodnocení dat se pohybuje mezi 5 až 15 uživateli a hodnocení hrozeb a zranitelností včetně zavedených protiopatření je úkolem pro 3-5 administrátorů sítě či další respondenty odpovědné za různé oblasti bezpečnosti (např. pracovník s odpovědností za fyzickou bezpečnost). Obsah dokumentace, která je výstupem z projektu analýzy rizik, je velmi podobný pro všechny typy organizací. Liší se jen rozsahem podpůrných reportů, které jsou zpravidla výstupem z použité metodiky, ale manažerský styl zpráv o aktivech a dopadech či o analýze rizik je shodný. Pro malé firmy je možné vytvořit jen jednu zprávu, ale pro střední organizace je vhodné závěry separovat minimálně do dvou dokumentů. 2.5 Program zvyšování úrovně bezpečnosti a Prohlášení o aplikovatelnosti Krokem logicky navazujícím na analýzu a poslední činností v části plánování podle modelu PDCA je vytvoření plánu implementace - programu zvyšování úrovně bezpečnosti a následně Prohlášení o aplikovatelnosti (opatření). Bezpečnostní protiopatření by měla být vybrána na pokrytí zjištěných rizik a způsob jejich výběru je nezávislý na velikosti organizace. Velký rozdíl však je ve způsobu a zejména v rychlosti jejich prosazení. Při výběru bezpečnostních opatření je vždy nutné zohlednit jejich dopad na uživatele a na procesy organizace. V malé firmě je možné jednouše a rychle změnit téměř jakýkoli proces, aby byl více bezpečný. Stačí vůle ředitele a o změně je rozhodnuto. Čím je organizace větší, tím je složitější měnit procesy a zavedené postupy. Proto je nutné při výběru protiopatření ve střední firmě více respektovat současný stav. Prohlášení o aplikovatelosti (opatření) je jedním z dokumentů nutných k certifikaci. Obsahuje informace o implementovaných opatřeních normy [2], případně dalších protiopatřeních navržených na pokrytí rizik. Hlavním cílem je dokumentovat rozhodnutí, proč dané protiopatření bylo či nebylo vybráno k zavedení. Pokud firma neplánuje být v budoucnosti certifikována, není nutné vytvářet samostatný dokument. Pro malou i stření firmu je plně dostačující, pokud se vhodným způsobem zaznamená rozhodnutí o výběru tak, aby i za několik měsíců bylo jasné, proč není nutné určité opatření normy implementovat. 3 Způsob implementace opatření a metody prosazení 3.1 Bezpečnostní dokumentace Značné rozdíly mezi malou a středně velkou firmou jsou ve formě a míře detailu dokumentace bezpečnosti. Není příliš známo, že uvedené normy [1,2] striktně nevyžadují papírovou formu dokumentace ani její pevnou strukturu, ale ponechávají

61 Tutoriál 49 na preferencích jednotlivých firem, jakou formu a obsah zvolí. Přitom právě obava z přílišné formální administrativy nejčastěji odpuzuje organizace od zavádění doporučení těchto norem. Dokumentace ISMS požadovaná k certifikaci dle normy [2] pochopitelně musí obsahovat určité, taxativně uvedené typy dokumentů, dané jednotlivými kroky procesu ISMS, ale jejich rozsah, obsah a forma může být překvapivě jednoduchá a flexibilní, jak si popíšeme dále. Pracovníci malých firem se osobně znají a velká část bezpečnosti je založena na jejich vzájemné důvěře. Není nutné vytvářet složitý systém politik, směrnic a postupů. Postačí stručné pravidlo, že bezpečnostní dokumentace je vedena ve sdílené složce elektronické pošty, definovat role a přístupy zodpovědných osob a nezbytné typy bezpečnostních dokumentů realizovat formou elektronických záznamů, obsahující stručný popis realizace daného pravidla, postupu nebo odpovědnosti. Středně velká firma se v této oblasti opatření blíží firmě velké. Zde je již nutné zavádět podrobnější administrativní procedury, neboť existuje více oddělených rolí a odpovědností a také více definovaných pravidel. Tato administrativa je nutná, aby byly eliminovány činnosti, které se dějí při práci s daty jen tak, na dobré slovo. Pracovníci středně velkých firem se většinou také znají, ale jistá úroveň anonymity může být impulsem k tomu, že se někteří budou snažit bezpečnostní procedury obejít zejména, když nebudou přesněji definovány a kontrolovány. Rozsah a aktuálnost bezpečnostní dokumentace bývá často jedním z klíčových kritérií při posuzování kvality ISMS a míry dosažené shody s požadavky norem [1,2]. 3.2 Program zvyšování bezpečnostního povědomí Mezi další metody prosazení bezpečnosti v organizacích patří program zvyšování bezpečnostního povědomí v organizacích.. Tento krok, jakkoliv komplikovaně znějící, je ve skutečnosti poměrně jednoduchá, levná a velice účinná metoda, která bývá bohužel mnohdy v malých a středně velkých organizacích opomíjena. Má za cíl zvýšit u všech zaměstnanců informovanost jednak o obecných principech a souvislostech informační bezpečnosti a o konkrétních rizicích, opatřeních, odpovědnostech a pravidlech, vyplývajících ze zaváděného nebo již provozovaného ISMS. V čem vlastně spočívá síla jednoduchosti tohoto opatření? Právě v tom, že je zaměřeno na zaměstnance (a na externí spolupracující osoby a pod.), kteří jsou často zdrojem bezpečnostních incidentů a kteří mohou, pokud jsou správně informováni, svým včasným jednáním šíření a škodám incidentů zabránit. Stále se ještě při každém bezpečnostním školení firem různých velikostí setkávám s mnoha užaslými tvářemi když vysvětluji, že nejvyšší hodnotu pro organizaci mají v informačním systému data a nikoliv hardware a software. Existuje také ještě mnoho uživatelů, kteří pokládají svou disketu nebo lokální harddisk svého PC v kanceláři za mnohem bezpečnější místo, než síťový disk s transparentně nastavenými přístupovými právy a pravidelným zálohováním. U malých firem postačí, pokud je zvyšování bezpečnostního povědomí opřeno o stručné vstupní školení všech zaměstnanců a občasné prodiskutování aktuálních bezpečnostních otázek dle potřeb organizace a vývoje nových potencionálních hrozeb (může být využito outsourcingu).

62 50 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x U středně velkých organizací se zvyšují nároky na informovanost zaměstnanců a rozsah jejich znalostí o bezpečnostní problematice, realizovaných opatřeních, povinnostech a odpovědnostech z nich vyplývajících. Základní bezpečnostní školení se doporučuje realizovat pro všechny nové zaměstnance bez rozdílu. Zde se však vyplatí potrápit zaměstnance trochu déle (vždyť je třeba využít toho že se nám podařilo soustředit je do jednoho společného prostoru a času) a více se zaměřit na popis a rozbor typických hrozeb a bezpečnostních incidentů. Bohužel právě odstrašující příklady, včetně zmínky o sankcích při nedodržování pravidel, zaberou i tam, kde dobrá rada nepřesvědčí. Samozřejmě i u středně velkých organizací by nemělo být opomenuto informovat všechny zaměstnance dle potřeby o aktuálních hrozbách a opatřeních, např. formou zřízení centrálního informačního místa o bezpečnostních otázkách na firemním Intranetu. 3.3 Způsob zvládání rizik za provozu Jedním z hlavních důvodů proč zavádět ISMS, je potřeba zajistit kontinuální proces zvládání a řízení informačních rizik. Základem pro jejich úspěšné řízení je identifikace a analýza všech potencionálních rizik a následné rozhodnutí o způsobu jejich zvládání a sledování v čase. Účelem řízení rizik není veškerá identifikovaná rizika bezezbytku pokrýt (mnohdy s vynaložením neadekvátních zdrojů), ale pokrýt zvolenými opatřeními pouze taková, u kterých je to efektivní. Ostatní rizika může organizace akceptovat a sledovat, některá může přenést na jinou organizaci, případně je pojistit. Pouze pokud organizace zná a sleduje všechna rizika související se zabezpečením informací a adekvátně rozhoduje o způsobu jejich zvládání, potom může prohlásit, že tyto rizika řídí (má je pod kontrolou). Tyto zásady jsou opět společné pro všechny velikosti a typy organizací. Otázkou je, jak se s nimi malé a středně velké organizace efektivně vypořádají? Vzhledem k tomu, že u těchto firem bude většinou velikost negativního dopadu bezpečnostního incidentu i pravděpodobnost jeho výskytu průměrně nižší než u velkých společností, je zřejmé, že vedení těchto firem bude mít tendence více rizika akceptovat a přesune svůj zájem spíše do oblasti jejich sledování a efektivního zvládání případných bezpečnostních incidentů. Pro sledování nových typů rizik a rozpoznání bezpečnostních incidentů je nutné aktivovat generování záznamů o nejdůležitějších bezpečnostních událostech (v papírové i elektronické formě) a tyto záznamy vyhodnocovat. Mezi takové záznamy patří minimálně záznamy o přístupech do budov a zabezpečených místností, přihlašování a odhlašování do počítačových systémů a citlivých aplikací, přístupy a manipulace se zvlášť citlivými informacemi apod. Řada těchto záznamů je generována automaticky po instalaci jednotlivých systémů (EZS, doménový řadič, účetní aplikace apod.). Na co se však často zapomíná, je jejich systematické ukládání, zabezpečení a vyhodnocování. U malých organizací bude proces řízení a zvládání rizik realizován neformálním způsobem, bez stanovení speciálních pravomocí a oddělení rolí. Je zde totiž účelné dosáhnout shodné úrovně informovanosti a pravomocí u všech zaměstnanců.pro středně velké firmy je již doporučeno rámcově definovat postupy, oddělit pravomoci a provádět namátkové revize tohoto procesu. Pro získání přehledu o způsobu a důslednosti plnění povinností při zvládání rizik a incidentů je namístě zřídit evidenci závažných hrozeb a zranitelností a způsobů jejich pokrytí.

63 Tutoriál Nároky na provoz opatření a zajištění bezpečnosti Součástí plánu zvládání rizik je i sledování nároků na provoz jednotlivých opatření a celkového zajištění bezpečnosti. Zatímco u malých firem není potřeba plánovat ani vyhrazovat samostatný rozpočet, neboť případný nákup a provoz nezbytných opatření je operativně schválen ředitelem a hrazen dle aktuálních potřeb organizace, u středních a velkých firem je nezbytné provádět alespoň rámcové plánování potřebných finančních i lidských zdrojů. Z hlediska preferencí při výběru opatření na pokrytí rizik hrají celkové nároky na jejich zavedení a provoz hlavní roli. Zatímco pro malé organizace není překážkou pružně zavádět opatření administrativní a personální bezpečnosti i za cenu vyšších požadavků na alokaci lidských zdrojů, úskalím pro malé firmy bývají finanční náklady na pořízení technologických opatření. U velkých společností lze tyto preference vysledovat obráceně, neboť pro ně bývá snazší pružně zavést nové technologické opatření, než jej nahradit administrativními či organizačními změnami. V případě preferencí středně velkých firem je stav logicky někde uprostřed a záleží na pružnosti řízení, technologické úrovni a znalostech pracovníků firmy, k jakým typům opatření se budou přiklánět více. 3.5 Zavedení opatření DRP a IRH Poslední důležitou oblastí opatření při zavádění a provozu ISMS je tvorba a údržba Havarijních plánů (DRP Disaster Recovery Planning) a Postupů řešení bezpečnostních incidentů (IRH Incident Response Handling). Stejně jako v případě ostatních formálních postupů i zde platí, že pro malé organizace je neefektivní vypracovávat a udržovat podrobné formální havarijní plány, dokonce ani přijímat zvláštní preventivní opatření. Pro obnovu systémů jim plně postačí vytvoření stručného univerzálního havarijního checklistu pro všechny možné případy havárie, který bude obsahovat postup bezpečného vypnutí a restartu technického vybavení a serverů, jednoduchý záznam výsledné konfigurace technologií a aplikací, postup obnovení dat ze záložních médií a seznam kontaktů na interní a externí osoby, které mohou pomoci při výskytu havárie nebo závažného bezpečnostního incidentu. Tyto havarijní postupy by měly být alespoň jednorázově otestovány a poté postačí testy opakovat až při zásadní změně používaných technologií a služeb. U středně velkých organizací je doporučeno rozšířit zmíněný havarijní checklist i o popis kroků instalace jednotlivých částí informačního systému a obnovy dat a aplikací ze záložních médií. U komplikovanějších informačních systémů je třeba rozlišit obnovu klíčových aktiv od ostatních a tomu přizpůsobit priority v havarijním plánování. Pro výběr strategie způsobu obnovy, nastavení priorit a pořadí obnovy jednotlivých aktiv je nejlépe realizovat analýzu dopadů na činnosti organizace (BIA Business Impact Analysis). Pokud byla správně realizována analýza rizik, lze informace o negativních dopadech nedostupnosti jednotlivých aktiv nalézt tam. Na základě těchto výsledků je vypracován strukturovaný havarijní plán obnovy, obsahující varianty postupu dle specifikovaných typů havarijních stavů. Takovýto plán je nezbytné pravidelně testovat a aktualizovat 1x ročně a na základě výsledků testů (v porovnání s cíly obnovy) vylepšovat.

64 52 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x 4 Monitorování a hodnocení ISMS 4.1 Monitoring provozu Monitoring provozu klíčových prvků IS a ochranných opatření je základním zdrojem informací pro kontrolu jejich funkčnosti a spolehlivosti. Pokud organizace zavádějící ISMS plánuje v budoucnu i jeho certifikaci, musí vytvářet a shromažďovat záznamy o fungování alespoň těch opatření, která jsou uvedena v Prohlášení o aplikovatelnosti (ty budou předmětem auditu). Bohužel ne všechny typy opatření samy automaticky generují záznamy o činnosti a tak je nezbytné přistoupit i v prostředí malých a středních firem k nepopulárnímu ručnímu generování záznamů u takových opatření, která tuto vlastnost nemají (především organizační a administrativní). Nemusí se přitom zdaleka jednat o únavnou administrativu, protože rozsah a složitost opatření, nebývá nijak velký. Příkladem toho, co postačí pro audit funkčnosti opatření bezpečnostní školení uživatelů IS, jsou seznamy účastníků školení a datum a předmět školení. Zodpovědná a systematická asistentka si je stejně pořídí a pokud tak učiní do připravené tabulky, kterou bude dle potřeby aktualizovat, je povinnost vůči auditu ISMS splněna. Pochopitelně pouze za opatření školení pracovníků Nicméně časová náročnost se pohybuje v rámci jednotek minut. Pro monitoring ICT postačí u malých organizacích výchozí nastavení logování dle standardní instalace většiny produktů a jejich ruční namátková kontrola pracovníkem, pověřeným na půl úvazku základními bezpečnostními povinnostmi. U středních organizací, je již vzhledem ke komplikovanosti IS infrastruktury nedostatečné spolehnout se pouze na namátkové ruční kontroly log souborů a je třeba využít automatických nástrojů pro jejich filtrování a vyhodnocování nestandardních událostí např. pomocí skriptů nebo dodatečných produktů. Podrobnější bezpečnostní monitoring se vyplatí aktivovat pouze krátkodobě, při podezření na výskyt bezpečnostního incidentu (což při pozdní reakci může skončit příslovím s křížkem po funuse ). 4.2 Testování funkčnosti opatření Abychom při provozu IS pomyslnému funusu předešli, je třeba uvedené pasivní metody kontroly doplnit i o aktivní a preventivní způsoby, jakými jsou např. aplikační kontroly chyb výpočtů a zpracování dat nebo testování zranitelností, případně penetrační testování systémů. Zatímco komplikovanější a časově i finančně náročnější penetračního testování má za cíl simulaci reálných útoků ze zvoleného prostředí a identifikaci možných negativních dopadů na IS, bezesporu jednodušším, rychlejším a levnějším způsobem testování odolnosti vůči útokům je vyhledání a testování zranitelností provozovaných ICT produktů. Oba způsoby mohou být prováděny z interní sítě, nebo častěji z externího prostředí zpravidla Internetu nebo bezdrátových sítí, což by měly být v případě malých a středních firem hlavní oblasti prevence proti útokům na IS. Protože se v případě penetračního testování jedná o vysoce specializovanou činnost, vyžadující detailní znalosti o technikách a nástrojích hackingu, stejně jako o bezpečnostních slabinách jednotlivých ICT produktů a komunikačních protokolů, bývá tento úkol svěřován specializovaných externím firmám, které mají dostatečné profesní zázemí pro jejich kvalifikovanou

65 Tutoriál 53 realizaci. Naproti tomu testování zranitelností je proces, který si mnohdy mohou počítačově gramotní uživatelé udělat sami, pomocí volně dostupných programů (např. Microsoft Baseline Security Analyzer) nebo využít placené služby z www serveru za výrazně nižší poplatek než provedení penetračního testování. Pro malé organizace lze testování zranitelností doporučit, pokud využívají permanentní připojení k externím sítím nebo provozují bezdrátovou LAN v husté zástavbě. V případě vybalení a zapojení chytrého VLAN přístupového bodu se může stát, že po už několika minutách bude v moci aktivního souseda - hackera. Pro střední organizace by testování zranitelností klíčových serverů a služeb IS mělo být samozřejmostí, alespoň po implementaci bezpečnostních opatření a před rutinním provozem komunikačních spojů. Pokud střední organizace provozují citlivá data a aplikace na internetu, mohou zvážit realizaci penetračního testování nebo podrobný technický bezpečnostní audit konfigurace klíčových prvků IS a bezpečnostních opatření jako např. firewallu, DNS nebo internetového aplikačního nebo databázového serveru či routeru na rozhraní LAN/WAN. 4.3 Audit a kontrola bezpečnostních opatření Spolu s monitorováním provozu, testováním zranitelností a technicky zaměřeným auditem konfigurace ICT, je další metodou kontroly implementace a provozu IS / ISMS realizace auditu a kontrol bezpečnosti IS. Obecně lze říci, že audit opatření musí být prováděn v každém typu a velikosti organizace, která provozuje systém řízení nad opatřeními, jinak by neexistovala zpětná vazba o stavu reality vůči plánu a návrhu požadovaného cílového stavu. Každý typ auditu by se měl řídit pravidly (např. [3]) a měl by probíhat dle schváleného ročního i operativního plánu. Je zřejmé, že takovéto formální harakiri malé a střední organizace dobrovolně nepodstoupí a že přichází v úvahu pouze v případě potřeby certifikace systému řízení. V případě ISMS by měl audit zahrnovat kontrolu funkčních bezpečnostních i řídících opatření ISMS, která jsou deklarována v Prohlášení o aplikovatelnosti a popsána v bezpečnostní dokumentaci a ověřit jak jsou realizována v praxi. Postupy a předmět auditu opatření ISMS jsou popsány v [4]. U malých organizací není třeba vytvářet samostatná oddělení nebo pracovní funkce interního auditora, ale je nutné i v malé organizaci funkci interního auditora dedikovat, alespoň jako přidruženou pracovní náplň nějakému zaměstnanci. Jednou ročně je nezbytné projednání zjištěných výsledků plánovaných auditů i namátkových kontrol s majitelem / ředitelem organizace a následně se všemi zaměstnanci. V případě středně velké organizace se již doporučuje zvážit existenci samostatné funkce interního auditora, kterému připadne i funkce bezpečnostního auditora. I v tomto případě má za úkol provádění plánovaných i namátkových kontrol dle ročního i operativního plánu auditu, který je sestavován s přihlédnutím k největším rizikům a nálezům předchozích auditů. Pro dosažení vyšší odborné úrovně a komplexnosti výsledků kontroly je doporučeno realizovat alespoň jednou ročně přehledový srovnávací audit stavu ISMS, vzhledem k požadavkům normy [2] s účastí jednoho externího odborného konzultanta.

66 54 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x 4.4 Revize adekvátnosti a efektivnosti ISMS Kromě ověření funkčnosti, spolehlivosti a úplnosti funkčních i řídících opatření je třeba přibližně jednou ročně zrevidovat rozsah, adekvátnost a efektivnost celého ISMS ve vztahu k potřebám, cílům a prostředí organizace. Výsledek této celkové revize ISMS by měl být stejně jako souhrnné výsledky auditů opatření projednán s vedením organizace a pořízeny záznamy o přijatých závěrech. Jelikož se jedná o činnost vyžadující široký přehled a značné zkušenosti z oblasti bezpečnosti informací a implementace ISMS v organizacích, musejí se malé i střední organizace spolehnout na pomoc externích specialistů, stejně jako v případě analýzy informačních rizik v etapě Plánuj. 5 Zlepšování ISMS 5.1 Vyhodnocení fáze Kontroluj Základním předpokladem pro správné rozhodnutí co a jak dál by vždy měly být co nejpřesnější a nejúplnější informace o aktuálním stavu a cílech organizace. Informace o aktuálním stavu týkající se monitoringu provozu, evidence chyb a bezpečnostních incidentů, výsledků testování funkčnosti a spolehlivosti implementovaných opatření, výsledků testování zranitelností a výsledky interních i externích auditů poskytuje předcházející fáze Kontroluj (CHECK). Vyhodnocení těchto informací provádí v malých firmách pracovník pověřený činností bezpečnostního managera na částečný úvazek, jako přidruženou činnost ke své pracovní náplni. Výsledky svého šetření by měl minimálně jednou ročně předložit majiteli nebo řediteli firmy a společně provést jejich analýzu a vyhodnocení. U středních a velkých organizací se již vyplatí přidat do tohoto kroku také revizi nápadů a možných zlepšení bezpečnosti informací i procesu ISMS, jejichž evidenci zajišťuje fórum pro bezpečnost informací, složené ze zástupců uživatelů, dodavatelů a odborných rolí delegovaných pro oblast bezpečnosti informací v organizaci. V rámci procesu řízení rizik je prováděno také pravidelné přehodnocování úrovně zbytkových a přenesených rizik, s ohledem na změny v organizaci, technologiích, podnikatelských cílech a vnějších událostech a hrozbách. 5.2 Identifikace a analýza neshod I když byla revize výsledků auditu zahrnuta již do předcházejícího kroku, je vhodné tuto činnost popsat podrobněji. Identifikace a analýza neshod má za úkol rozebrat výsledky interního i případného externího auditu a posoudit, které z nalezených neshod jsou skutečné, které pouze potenciální a vyřadit nesprávně identifikované neshody. Toto rozhodnutí je opět vhodné zaevidovat formou tabulky. Nakonec je pro odstranění skutečně identifikovaných neshod třeba navrhnout nápravná opatření a pro zabránění opakovaného výskytu skutečných i potencionálních neshod v budoucnu je třeba navrhnout preventivní opatření. Jejich výběr, implementace a ověření funkčnosti je již náplní dalších paralelních PDCA procesů (koleček), které jsou spuštěny pro každé nově navržené opatření.

67 Tutoriál 55 U malých firem provede tuto analýzu neshod majitel nebo ředitel, ve spolupráci s pracovníkem pověřeným funkcí bezpečnostního managera. S výsledným rozhodnutím je vhodné seznámit všechny zaměstnance. Implementace těchto rozhodnutí bývá velmi rychlá a flexibilní. Pokud malá firma usiluje o certifikaci ISMS, je vhodné obrátit se pro pomoc na externího konzultanta, případně zrealizovat srovnávací audit procesu ISMS vzhledem k normě [2] externí specializovanou firmou a s její pomocí navrhnout potřebná nápravná opatření pro dosažení souladu. U středních firem bude interpretace výsledků auditů i návrh nápravných a preventivních opatření komplikovanější a formální proces, řízený pracovníky interního auditu ve spolupráci s dalšími zainteresovanými odbornými pracovníky organizace. Při přípravě na certifikaci ISMS se i zde doporučuje sáhnou pro pomoc externích odborníků, pokud takoví nejsou ve vlastních řadách. 5.3 Nápravná a preventivní opatření Nápravná opatření slouží k odstranění skutečně nalezených nedostatků a chyb, spojených s implementací a provozem ISMS a k zabránění jejich dalšímu trvání (opakování). Jedná se například o neúplnou implementaci opatření zvolených v Prohlášení o aplikovatelnosti opatření, o chybějící dokumentaci těchto opatření, o nedostatečné proškolení pracovníků zainteresovaných v procesu ISMS apod. Preventivní opatření jsou vybírána s cílem zabránit výskytu potencionálních neshod v budoucnu, tedy za účelem eliminace příčin, které by mohly vést ke vzniku reálné nežádoucí situace a reálné neshody. Příkladem takové potencionální neshody může být například nedodržení segregace rolí u některých činností a opatření ISMS nebo nedůsledné provádění potřebných monitorovacích a kontrolních činností. Pro malé organizace je typická rychlá praktická změna bez byrokratických průtahů a příklon především k organizačním a personálním opatřením, jejichž pořízení a zavedení bývá pro majitele malých firem nejpřijatelnější. Pro střední organizace, stejně jako ve fázi Dělej (popis nároků na provoz opatření), není již hledisko nákladů na pořízení a zavedení opatření tak palčivé jako pro malé organizace a bude při jejich výběru více rozhodovat jeho účinnost a pokrytí nalezených nedostatků. 5.4 Doporučení zda certifikovat ISMS Odpověď zda certifikovat ISMS jednoznačná není. Zavedení ISMS má prokazatelně pozitivní efekt. Vzhledem k narůstající závislosti firem na informačních systémech, jejich propojování a sdílení informací v rámci B2B a B2C aplikací a vzhledem k požadavkům platné národní a nadnárodní legislativy na zabezpečení informací a dat je správně zavedený a provozovaný ISMS chápán jako vysoký stupeň záruky adekvátní ochrany dat. Zvyšující se počty projektů implementace ISMS i v České republice jsou toho důkazem. Lze ale míru (stupeň) zabezpečení informací v IS organizace objektivně měřit? Celková bezpečnost informací v organizacích je zajišťována kombinací technologických opatření, fyzických, personálních a administrativních, které by měly být implementovány v rozsahu a kvalitě odpovídající prostředí a potřebám každé jednotlivé organizace. Jednou z možností jak hodnotit míru bezpečnosti informací je

68 56 J.Mikulecký, L.Široký: Bezpečnost IT podle standardu řady ISO2700x posouzení kvality procesu řízení bezpečnosti informací ISMS, vyhodnocením míry souladu s požadavky na tento proces dle normy [2]. Pro malé a střední firmy představuje proces přípravy a samotné certifikace akreditovanou certifikační autoritou nemalou investici, kterou je třeba manažersky a ekonomicky zvážit. Pokud firma podniká v sektoru, kde je důvěryhodnost vysoce ceněným faktorem a podmínkou úspěšných obchodních vztahů, může být pro takovou firmu užitečné realizovat certifikaci bezpečnosti informací jako další důkaz kvality řízení k certifikátu QMS nebo EMS. Certifikace ISMS do prostředí firem, kde je již certifikován jiný systém řízení, je méně náročnou variantou. Vzhledem k harmonizovanému PDCA modelu ISMS, QMS a EMS je řada procesů a odpovědností již nastavena. 6 Certifikace ISMS Při praktické aplikaci normy BS (současné ISO/IEC 27001) organizacemi v UK, ale i jiných částech světa, byly získány zkušenosti, které vedly jak k vytvoření podmínek pro certifikaci. Ačkoliv o vznik normy se zasloužila Velká Británie, bylo to Nizozemí, které přišlo s myšlenkou vytvořit certifikační schéma, umožňující organizacím prezentovat prokazatelně úroveň bezpečnosti informací. Tato myšlenka byla následně, tentokrát opět na britské straně, rozvinuta a bylo vytvořeno certifikační schéma c:cure, kterým se prováděla certifikace ve Velké Británii. Myšlenka certifikace narazila postupem času na zásadní problém. Jelikož BS 7799:1995 byla sbírkou praktik, jak tedy ohodnotit, zda organizace naplňuje opatření, a že naplňuje ta správná opatření. Odpovědí na tento problém bylo vytvoření druhé části BS :1999, která přesně vymezila, co organizace musí učinit, aby mohla být úspěšně certifikována. Postupem času došlo k paradoxnímu poznání, že druhá část normy, popisující systém řízení bezpečnosti informací (Information Security Management System, ISMS), má ještě větší význam, než samotná sbírka praktik v první části. To proto, že systém řízení bezpečnosti informací umožňuje vedení organizace, prostřednictvím řízení a monitoringu bezpečnosti, minimalizovat rizika působící na organizaci a poskytuje záruky, že jsou naplňovány požadavky organizace, legislativy a v neposlední řadě zákazníků organizace. V roce 1999 získalo certifikační schéma c:cure konkurenci díky vytvoření alternativního certifikačního schématu definovaného dokumentem EA7/03 vydaným European cooperation for Accreditation (EA). Dokument nese název Vodítka pro akreditaci organizací provádějících certifikaci systémů řízení bezpečnosti informací (Guidelines for the Accreditation of Bodies operating Certification/Registration of Information Security Management Systems). Tento dokument se stal široce uznávaným nejen po celé Evropě a svou mezinárodní silou nechal schéma c:cure zaniknout. Důsledkem tohoto dokumentu je to, že národní akreditační orgány (u nás Český institut pro akreditaci) mohou provádět akreditaci soukromých národních subjektů, které na základě této akreditace mohou provádět certifikace systémů řízení bezpečnosti informací. Dalším důležitým důsledkem je to, že významné mezinárodní společnosti, jako např. DNV, RW TUV nebo BSI, mohou provádět certifikace např. v České republice, aniž by vlastnily národní akreditaci. Je to z toho důvodu, že jimi obdržené zahraniční akreditace jsou mezinárodně uznávány.

69 Tutoriál 57 Literatura 1. ISO/IEC 27002:2005 Information technology -- Security techniques -- Code of Practice for Information Security Management 2. ISO/IEC 27001:2005 Information technology -- Security techniques -- Specification for an Information Security Management System 3. ISO 19011: Guidance for management systems auditing 4. ISO/IEC Information technology -- Security techniques -- Guidelines for Information security management systems auditing (draft) Annotation: IT Security According to ISO2700x Standards The set of ISO2700x standards has got a long history since 80 s. Wide exploiting of the standards shows that selected approach from practice to standard is the best one. Currently, there is no security manager knowing nothing about these standards and not using them every day. Proper application of the standards (particularly 27002) could be confirmed with an official certification of ISMS.

70 Velké textové korpusy v praxi Karel PALA, Pavel RYCHLÝ Laboratoř zpracování přirozeného jazyka Fakulta informatiky Masarykova Univerzita Botanická 68a, Brno {pala,pary}@fi.muni.cz Abstrakt. První část tutoriálu pojedná obecně o korpusech textů a jejich typech a uvede příklady korpusů. Poté se soustředí na způsoby a nástroje pro vytváření korpusů a na značkování textu v nich (morfologie, lemmatizace, gramatické relace). Další část se týká nástrojů pro vyhledávání v korpusech, aplikačního rozhraní a dotazovacích jazyků. Závěrečná část se soustředí na pokročilé statistické zpracování kontextů a nástroj Sketch Engine. Klíčová slova: zpracování přirozeného jazyka, korpus, korpusový manager, dotazovací jazyk, značkování, Sketch Engine. L.Popelínský, O.Výborný(eds.), DATAKON 2007 Brno, , str. 58.

71 Vizualizace geografických dat Karel STANĚK Geografický ústav, Přírodovědecká fakulta Masarykova Univerzita Brno Kotlářská 2, Brno Abstrakt. Tutoriál navazuje na loňský kurs o geografických informačních systémech. Po stručném pojednání o prostorových databázích se soustředí na vizualizaci geografických dat. Hlavní důraz je položen na adaptivní geovizualizaci např. podle uživatele, situace a zobrazovacího zařízení a adaptivní mapy. Závěrečná část se zaměří na použití adaptivní geovizualizace při živelných katastrofách. Klíčová slova: prostorové databáze, geografická data, vizualizace, adaptivní vizualizace, adaptivní mapy, krizový management, živelné katastrofy. L.Popelínský, O.Výborný(eds.), DATAKON 2007 Brno, , str. 59.

72 Ontologické inženýrství Vojtěch SVÁTEK 1, Miroslav VACURA 2 1 Katedra informačního a znalostního inženýrství, Vysoká škola ekonomická v Praze nám. W. Churchilla 4, Praha 3 svatek@vse.cz 2 Katedra filosofie, Vysoká škola ekonomická v Praze nám. W. Churchilla 4, Praha 3 vacuram@vse.cz Abstrakt. Ontologické inženýrství je moderní oblastí informatiky, která se zaměřuje na návrh, implementaci a aplikaci ontologií: sdílených a (převážně) formalizovaných znalostních modelů podporujících korektní modelování reality, sémantickou interoperabilitu a automatické odvozování v softwarových aplikacích. Ontologické inženýrství se původně vyvíjelo v rámci umělé inteligence, postupně se však posouvalo k praktickému využití při návrhu aplikací a zpřístupňování datových zdrojů, a v současné době hraje ústřední roli v iniciativě tzv. sémantického webu. Moderní pojetí ontologie v informatice se v řadě bodů liší od klasické ontologie jako součásti filozofie, ovšem má s ní také významné styčné body, kterými jsou zejména tzv. základní ontologie zachycující nejobecnější kategorizaci entit. Praktická tvorba ontologií se v současnosti opírá o sofistikované metodiky, zahrnující i využití základní ch ontologií a z nich vycházejících tzv. obsahových návrhových vzorů. Předností dnes nejrozšířenějšího jazyka pro reprezentaci ontologií, OWL, je existence mapování na rodinu tzv. deskripčních logik, které umožňuje na navržené ontologie aplikovat odvozovací nástroje. Vazba na exaktní logickou interpretaci ovšem na druhé straně způsobuje, že konkrétní implementace dané konceptualizace není triviální. Hlavním prostředkem pro přizpůsobení konceptualizace danému reprezentačnímu jazyku a logickému kalkulu jsou tzv. logické návrhové vzory. Implementace a využívání ontologií se ve finální fázi uskutečňuje prostřednictvím specializovaných softwarových prostředků; jedná se především o editory (z nichž nejznámější je Protégé), zpravidla vybavené zásuvnými moduly pro řadu dalších úloh s ontologiemi souvisejících. Klíčová slova: ontologie, deskripční logika, metodika, návrhové vzory. 1 Úvod V posledních letech se tématika ontologií a ontologického inženýrství diskutuje v kruzích teoretické i aplikované informatiky stále častěji. Mnozí si kladou otázku: jedná se skutečně o perspektivní technologii, která v příštích desetiletích významně ovlivní koncepci informačních systémů, nebo jde spíše o módní vlnu, která za několik let beze stop odezní? V tomto stručném materiálu neposkytneme na uvedenou otázku přímočarou odpověď. Pokusíme se však, pro čtenáře, který je ochoten připustit L.Popelínský, O.Výborný(eds.),DATAKON 2007,Brno, , str

73 Tutoriál 61 variantu první, vymezit určité mantinely, co je možné a vhodné za ontologie pokládat, vysvětlit, z jakých kořenů jejich výzkum v informatice pochází, a naznačit, jaký okruh metod a nástrojů lze při jejich tvorbě a další práci s nimi využít. Text vychází z velkého množství podkladových materiálů i z vlastních zkušeností autorů. Snahou přitom bylo, vedle podrobněji rozebraných dílčích problémů, zejména upozornit na užitečné zdroje, které jsou dostupné na webu nebo případně v knižní podobě 1. Pojem ontologie má za sebou několik století pozvolného vývoje v kontextu filosofie, na který vcelku plynule navázal (původně širší informatické veřejnosti nepříliš známý) výzkum možností ontologií jako prostředku formální reprezentace znalostí v kontextu umělé inteligence. Výrazný nárůst popularity informatických ontologií (a také termínu samotného, i ve spíše okrajových významech) však vyplynul až z jejich sepětí s prostředím WWW na konci 90. let, ztělesněné zejména širokou iniciativou sémantického webu. Text se bude zabývat ontologiemi jak v obecnějším smyslu, tak i problémy spojenými s jejich reprezentací a logickým odvozováním nad nimi v rámci konkrétního formalismu jednoznačně nejrozšířenějšího webového ontologického jazyka OWL podloženého tzv. deskripční logikou. Vzhledem k omezenému prostoru se však jen lehce dotkneme problematiky syntaktické reprezentace, adresování a dalších otázek spojených s bezprostředním využívání ontologií na WWW 2, a soustředíme se na konceptuální a logické aspekty ontologického inženýrství. Zmíněné důrazy se promítají do celkové struktury textu. Kapitola 2 se pokouší propojit ontologii jako tradiční filosofickou disciplínu se soudobým výzkumem ontologií v informatice. Kapitola 3 podává obecnou typologii ontologií, a podrobněji se věnuje dvěma hlavním typů ontologií z obsahového hlediska: základním ontologiím včetmě jejich tradičního filosofického zázemí a zpravidla pragmatičtěji pojatým doménovým ontologiím. Kapitola 4, věnovaná stručnému přehledu reprezentačních jazyků pro ontologie, je do jisté míry odbočkou ve výkladu. Po ní ovšem následuje kapitola 5, která je opět zaměřena na věcný obsah ontologií, přesně řečeno na prostředky podporující jeho korektní a efektivní tvorbu. Kapitola 6 se pak věnuje (specificky pro jazyk OWL a jemu podobné) vztahu mezi ontologiemi a logickým odvozováním, jak z hlediska odvozovacích procedur jako takových, tak z hlediska potřeby zohlednit logickou reprezentaci a odvozování při samotné tvorbě ontologie. Následují dvě kapitoly zaměřené spíše na praxi: kapitola 7 poskytuje rychlý přehled vybraných softwarových nástrojů pro práci s ontologiemi, a kapitola 8 referuje o některých příkladech aplikace ontologií v reálném prostředí. Závěrečná kapitola 9 pak už jen rekapituluje poslání textu. 1 Zde je na místě zmínit se o přehledové knize o ontologickém inženýrství zkušených autorů z Universidad Politécnica de Madrid, která již po třech letech od prvního vydání letos vychází ve vydání druhém [13]. 2 Budeme předpokládat, že zejména databázově orientovaný čtenář má již o problematice sémantického webu jako takového určité povědomí. Problematikou ontologií v kontextu WWW se mj. zabýval předchozí tutoriál jednoho z autorů [51]. Současný tutoriál věnuje podstatně menší prostor např. koncepci sémantického webu nebo historii ontologických jazyků, naopak podrobněji rozebírá tvorbu ontologického obsahu či deskripční logiku.

74 62 V.Svátek, M.Vacura: Ontologické inženýrství 2 Filosofické kořeny Mezi první ontologické koncepce patřily už názory předsokratických myslitelů, 3 které se povětšinou omezily na snahu redukovat rozličnost smyslového světa na určitý základní princip (arché). Významnější pokrok přineslo až myšlení Platóna [37] a posléze jeho žáka Aristotela, u kterého se zastavme, protože u toho nacházíme první ontologickou koncepci, kterou můžeme považovat za předchůdce moderních ontologií. Aristotelés svoji teorii předkládá ve spisech Metafyzika a Kategorie, kde mluví o tzv. první vědě, která kromě ostatních určení zkoumá zejména jsoucí jakožto jsoucí a to, co mu samému náleží. Výrazy metafyzika, ontologie a aristotelská první filosofie se často ve filosofii používají jako synonyma. Zatímco se tedy vědy speciální věnují pouze určitému vymezenému okruhu jsoucen nebo určitým vymezeným aspektům skutečnosti, ontologie se v tomto pojetí věnuje tomu, co je všemu jsoucímu společné. Aristotelés se však už nesnaží o pouhou redukci veškeré skutečnosti na jeden základní princip jako předsokratičtí myslitelé, ale snaží se rozpoznat základní vlastnosti a rozčlenění veškeré skutečnosti. Základním protikladnými charakteristikami pak jsou akt a potence, následně pak substance a akcident, látka a forma. Pro nás podstatné je rozlišení tzv. deseti kategorii, tedy substance 4 a devíti akcidentů: kvantita, kvalita, relace, kde, kdy, poloha, mít, činnost a trpnost. Těchto deset kategorií mělo vyčerpat všechny základní třídy toho, co může být. Nezávislé bytí přitom měla vždy pouze jsoucna kategorie substance, zatímco jsoucna ostatních kategorií vždy nějak na bytí nějaké substance participovala. Například červená, jakožto určitá kvalita, nemá samostatné bytí, ale vždy existuje jen prostřednictvím nějaké červené věci. Pro nás je přitom zajímavé, že kategorie měly vnitřní hierarchickou strukturu. Není přitom jasné, nakolik sám Aristotelés tuto hierarchickou strukturu např. v případě přírodovědných oborů rozpracoval, protože ačkoli víme, že se této problematice věnoval, téměř všechny tyto spisy jsou ztraceny. Nejstarším dochovaným rozpracováním této hierarchické struktury je tak spis novoplatonika Porfyria ( ) nazvaný Isagoge, v podstatě úvod do Aristotelova spisu Kategorie. Toto dílo obsahuje tzv. Porfyriův strom (Arbor porphyriana), který je hierarchickou klasifikací aristotelských substancí, ze které dodnes do jisté míry vychází klasifikační systém používaný v biologii [23]. Alternativní klasifikační systém se objevil až ve 13. století, kdy se Ramon Llull ( ) ve svém hlavním díle Ars Magna pokusil vypracovat logickokombinatorický grafický systém pro klasifikaci veškerého poznání, nezávislý na jazyku, náboženství a kultuře. Hlavní vliv tohoto díla byl na rozvoj matematické kombinatoriky např. u Leibnize, jakožto klasifikační systém se neprosadil. Ve středověku se pak rozvíjením klasifikačních přístupů, především v Porfyriově tradici, zabýval např. William Ockham ( ) a další. 3 Za zakladatele filosofické ontologie je tradičně považován Parmenidés a za první dílo věnující se ontologii jeho báseň O přírodě. 4 Pro Aristotela je základní (první) substancí konkrétní objekt (např. Sókratés), následně zavádí tzv. druhé substance, což jsou obecniny (např. člověk). Substance (řec. ousia, lat. sustantia to, co stojí pod) tak představuje jakousi základní jednotku skutečnosti, to skutečně jsoucí, proto u různých filosofů nabývalo toto slovo různých významů (např. pro atomisty jsou atomy substancemi).

75 Tutoriál 63 Samotný výraz ontologie je poměrně nový, objevil se v 17. století v pracích německých filosofů R. Göckela [18] a J. Lorharda [24], a prosazený byl patrně Ch. Wolffem, jedním z nejvýznamnějších německých filosofů před I. Kantem, který ho použil pro nahrazení tradičního termínu metafyzika ve smyslu nauky o jsoucnu a bytí jako takovém, v spise Philosophia prima sive ontologia (1736) [35,44]. Wolff byl systematickým filosofem, který se ve svém díle snažil integrovat aristotelskou a scholastickou ontologii s myšlenkami Descarta a Leibnize, s použitím eukleidovských axiomaticko-deduktivních principů. Pro zkoumání otázek klasifikační povahy, tj. jaké třídy jsoucen existují a jaké jsou mezi nimi vztahy, se používá označení formální nebo deskriptivní ontologie. Ze současných myslitelů je pak v tomto ohledu zajímavý zejména P. F. Strawson, a jeho spis Individuals [48], který je věnován mj. právě otázkám klasifikace. V oblasti informatiky poprvé výraz ontologie použil pravděpodobně J. McCarthy v textu o nemonotónním odvozování [28]. Do souvislosti s informatikou dával ontologie v 80. letech i J. F. Sowa [45] v kontextu tématiky modálních logik. Obvykle citovaná definice se v roce 1993 objevuje v textu T. Grubera, který definuje ontologii jako explicitní specifikaci konceptualizace [15]. J. F. Sowa pak navrhuje v roce 2000 následující definici: Předmětem ontologie je studium kategorii věcí, které existují nebo mohou existovat v určité doméně. Výsledek tohoto studia, nazývaný ontologie je katalog věcí, jejichž existenci předpokládáme v dané doméně D, z perspektivy osoby používající jazyk L, aby mluvila o D. [46] V tomto kontextu bývá také někdy doporučováno, aby pro označení vědecké disciplíny bylo používáno výrazu Ontologie, zatímco pro informační artefakt, který je výsledkem analýzy určité domény (případě pro studium konkrétní domény), výrazu ontologie [19,35]. V oblasti tvorby ontologií přitom můžeme rozlišit dva základní přístupy: shora dolů ( top-down ) přístup, který je typický pro filosofické nebo filosoficky inspirované ontologie, které začínají pokusem rozčlenit oblast všeho, co je, na určité základní kategorie první příklad jsme již viděli u Aristotela. Druhým přístupem je zdola nahoru ( bottom-up ), který vychází z důkladného popisu konkrétních objektů bezprostředního zájmu dané aplikace. V důsledku tak výsledkem jsou dva odlišné typy informačních artefaktů, v případě postupu shora dolů je výsledkem základní ontologie, naopak výsledkem postupu zdola nahoru 5 bývají doménové ontologie. Podrobněji se rozčlenění typů ontologií a jejich významným reprezentantům věnuje následující kapitola. 3 Typy ontologií 3.1 Stručný přehled Ontologie mohou být klasifikovány na základě některých významných vlastností [6]. První takovou vlastností je operacionalizace, která rozlišuje ontologie hrubé (coarse) a jemné (fine-grained). Hrubé ontologie se vyznačují použitím jazyka s malou expresivitou a malým počtem axiomů (viz část 4). Jemné ontologie naopak využívají vysoce expresivní modelovací jazyk a zahrnují obvykle velké množství axiomů. 5 Případně jeho modifikace od středu ven ( middle-out ), viz část 5.2.

76 64 V.Svátek, M.Vacura: Ontologické inženýrství Jemné ontologie přitom mohou přinášet vyšší nároky na odvozování. Někdy se také jemné ontologie označují jako referenční či vývojové (development-time), zatímco hrubé jako sdílené (shared) či provozní (run-time) [19]. Další důležitou vlastností je expresivita 6, na základě které dělíme ontologie na těžké (heavy-weight) a lehké (light-weight). Těžké ontologie vyjadřují ontologické závazky explicitně a obsahují rozsáhlou axiomatizaci. Lehké ontologie vyjádření ontologických závazků neobsahují a často se soustředí jen na ty oblasti, které jsou autory považovány za relevantní. Významnou vlastností je také specifičnost ontologie. Ontologie může být obecná (generic), jádrová (core) a doménová (domain). Obecné ontologie se věnují konceptům, které přesahují rozsah jednotlivých domén (např. proces, událost), jádrové modelují centrální koncepty určité domény, doménové ontologie obsahují koncepty specifické pro danou doménu. Základní ontologie jsou pak obecné, ovšem ne každá obecná ontologie je základní. Ontologické závazky (ontological commitments) jsou určité základní teoretické předpoklady týkající se přístupu k modelování reality, z nichž daná ontologie vychází, a které mohou být explicitně či implicitně vyjádřeny (někdy se pro souhrn ontologických závazků používá i výraz cognitive bias ). Pokud používáme určitou ontologii, měli bychom si být vědomi, jaké ontologické závazky s sebou nese, protože to zároveň omezuje možnou integraci s ontologiemi nesoucími jiné ontologické závazky. V následující části vyjdeme z analýz v [26,27,40] a stručně popíšeme základní typy ontologických závazků. Ontologie se může zahrnovat jednotliviny, obecniny nebo obojí. Jednotliviny jsou entity, které nemohou mít instance, zatímco obecniny je mít mohou (ač zrovna v daný moment žádnou mít nemusí). Ontologie může být buď deskriptivní nebo revizionistická. Deskriptivní ontologie vychází ze běžného chápání skutečnosti (common sense), bývá založena na vztazích vyplývajících z běžného jazyka a obvyklého porozumění, vývoj ontologie pak vychází především ze studia jazyka. Revizionistická ontologie se na přirozený jazyk a běžné porozumění neváže, snaží se vycházet z vědeckých a odborných přístupů a v případě, že jsou v rozporu s běžným rozuměním, dává jim přednost [49]. Ontologie můžeme také rozdělit na multiplikativní nebo redukcionistické. Redukcionistický přístup se snaží vycházet z malé skupiny základních konceptů a ostatní koncepty rekonstruovat z této malé základní skupiny primitivních prvků. Multiplikativní ontologie se snaží o co největší expresivitu i za cenu větší složitosti a většího počtu základních konceptů. Multiplikativní přístup také typicky připouští kolokalizaci entit (více entit se může vyskytovat na jedné časoprostorové lokaci). Při modelování skutečnosti můžeme volit také buď posibilistický nebo aktualistický přístup. Aktualistická ontologie popisuje pouze to, co aktuálně existuje. Posibilistická popisuje i to, co může existovat, tzv. possibilia. Podobná volba je i s ohledem na čas buď presentistický nebo eternalistický přístup. Presentistický přístup modeluje jen to, co v daný okamžik aktuálně existuje. Eternalistický přístup modeluje vše, co existovalo v minulosti, existuje nyní či bude existovat v budoucnosti. Vše to je považováno za existující. 6 Expresivita ontologie se nemusí odvíjet od expresivity použitého jazyka, ale týká se obsahu.

77 Tutoriál 65 S tím související je i volba 3D nebo 4D modelovacího přístupu, která má vliv na modelování změn. Při použití třírozměrného modelovacího přístupu jsou běžné předměty plně přítomny v každém časovém okamžiku a jsou proměnné, neboli v různých okamžicích mohou mít různé vlastnosti. Při použití čtyřrozměrného modelovacího přístupu jsou běžné předměty chápány jako časoprostoroví červi, jsou jen částečně přítomny v každém časovém okamžiku, skládají se tedy z fází, v rámci kterých mohou mít různé vlastnosti. 3.2 Základní ontologie Základní ontologie (v angličtině nazývané např. foundational, top-level nebo upper-level ) obvykle poskytují primární rozlišení veškeré jsoucí skutečnosti do určitých základních kategorií. Poskytují tak základní rámec porozumění mezi komunikujícími agenty (lidskými nebo umělými), zjednodušují vyloučení pojmových nejasností a víceznačností a umožňují explicitní vyjádření ontologických závazků [1]. Základní ontologie mají obecně následující charakteristiky [40]: Poskytují referenci pro srovnávání různých ontologických přístupů, a rámec pro analýzu, harmonizaci a integraci ontologií a metadatových standardů. Poskytují výchozí bod pro tvorbu nových ontologií. Základní ontologie obsahují předdefinovanou skupinu ontologických entit, které mohou být znovu využity. V ideálním případě také základní ontologie definuje návrhové vzory pro běžně se vyskytující případy modelování. Pomáhají uživateli vypořádat se s typickými problémy, na které může při návrhu ontologií narazit. Podívejme se nyní na některé významné základní ontologie (podrobnější srovnání lze nalézt v [1] nebo [32], a další informace např. v [6,27]): BFO Basic Formal Ontology (BFO) 7 byla vyvinuta týmem B. Smitha na Univerzitě v Lipsku (institut IFOMIS). BFO sestává ze série subontologií, které representují určité perspektivy pohledu na realitu. Nejdůležitější jsou přitom SNAP, což je série ontologií přestavujících každá katalog entit existujících v daném časovém okamžiku, a SPAN, což je katalog procesů probíhajících napříč časem. DOLCE Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) je základní ontologie vyvinutá v institutu ISTC-CNR v Římě, původně jako referenční ontologický modul pro knihovnu ontologií v rámci WonderWeb projektu. 8 DOLCE je založena na metodologii OntoClean [34] a snaží se explicitně vyjádřit své ontologické závazky: vychází z běžného jazyka a snaží se zachytit základní kategorie odpovídající běžnému chápání ( common sense ) skutečnosti. Zároveň připouští kolokalizaci entit a používá tak multiplikativní přístup k modelování skutečnosti. DOLCE také obsahuje primitivní relace typu závislost nebo část a obsahuje rozsáhlou axiomatizaci

78 66 V.Svátek, M.Vacura: Ontologické inženýrství OCHRE Object-Centered High-Level Reference ontology (OCHRE) je základní ontologie také vyvinutá na ISTC-CNR [41]. OCHRE se snaží zkombinovat deskriptivní přístup založený na běžném chápání skutečnosti ( common sense ) s využitím menšího množství základních kategorií a axiomů, používá tedy spíše redukcionistický přístup, z čehož také vyplývá odmítnutí kolokalizace entit. OCHRE je zaměřená na objekty, které mají v jejím ontologickém chápání privilegované postavení, a je založena na extensionalistickém přístupu, tedy předpokládá, že objekty, které mají totožné části, jsou totožné. OpenCYC Ontologie OpenCYC 9 byla vyvinuta v MCC (Microelectronics and Computer Consortium) v rámci projektu CYC, který měl modelovat velkou část běžného chápání skutečnosti. OpenCYC je tou základní částí výsledné ontologie, která je volně dostupná. Celá CYC ontologie pak pokrývá mnoho oborů i konceptů každodenního použití, obsahuje tisíce konceptů. Skupiny konceptů tvoří mikroteorie (kontexty), které se zabývají určitou vymezenou doménou. SUMO Suggested Upper Merged Ontology (SUMO) 10 byla vyvinuta skupinou IEEE Standard Upper Ontology (SUO). SUMO nevychází ze specifického teoretického základu. Autoři SUMO vyšli z existujících základních a vyšších ontologií, ty analyzovali, identifikovali základní kategorie, které byli IT komunitou obecně sdílené. Tyto základní ontologie byly syntakticky převedeny na společný formát SUO-KIF, a následně pomocí sémantického sloučení ( semantic merge ) byla vytvořena ontologie, která měla určitým způsobem zahrnovat ostatní [30]. KR ontologie KR ontologie 11 byla vyvinuta J. F. Sowou a je ovlivněna filosofickými postoji Ch. S. Pierce a A. N. Whiteheada [46]. S ohledem na její ontologické závazky bychom KR ontologii mohli charakterizovat jako revizionistickou a redukcionistickou. Její základní kategorizace je založena na pojmech relace, substance a času. S ohledem na relaci rozlišuje tři základní kategorie entit: nezávislé, relativní, a zprostředkující (independent, relative, mediating). S ohledem na substanci rozlišuje dvě základní kategorie: fyzická a abstraktní (physical, abstract). S ohledem na čas rozlišuje kategorie endurant (též continuant) a perdurant (též occurent). Na základě těchto základních kategorií vzniká jejich vzájemnou kombinací dvanáct podřazených kategorií, přičemž každá entita spadá do některé z nich. Následující tabulka přehledně shrnuje hlavní vlastnosti popsaných základních ontologií

79 Tutoriál 67 BFO DOLCE OCHRE OpenCYC SUMO KR Deskriptivní Ne Ano Ne Ano Ano Ne Multiplikativní Ne Ano??? Ne Posibilistická Ne Ano Ano??? 4D Ano Ano Ano Ano Ne Ano 3.3 Doménové ontologie Jedním z podstatných významových posunů pojmu ontologie bylo jeho rozšíření na modely reality popisující specifické, často i velmi úzce vymezené, věcné oblasti domény. Doménové ontologie vznikají typicky jedním ze dvou způsobů: Přímou tvorbou již jako plnohodnotná ontologie v určitém formalismu Adaptací (v horším případě jen hrubou syntaktickou konverzí) již existujícího, jednodušeji strukturovaného zdroje. V následujících odstavcích se stručně zmíníme o nejpopulárnějším nebo nejzajímavějších doménových ontologiích z různých oblastí. Biomedicína Biomedicíncká oblast pravděpodobně zaujímá první místo v míře pokrytí doménovými ontologiemi. Ontologie zde zpravidla vznikají na základě starších terminologických zdrojů, postihujících akumulované zkušenosti generací lékařů. Relativně nejmenší posun od tradičních zdrojů asi představuje UMLS 12 Unified Medical Language System, vyvíjený Národní lékařskou knihovnou USA. Základní složkou UMLS je metatezaurus, který na sebe mapuje pojmy z velkého počtu samostatně vzniklých specializovaných tezaurů včetně jazykových verzí (mezi nimi je např. i česká verze tezauru MeSH). Více ontologický charakter má ovšem jiná část UMLS, sémantická síť o 135 sémantických typech ( třídách entit) a 54 možných vztazích mezi nimi. Každý specializovaný pojem je v UMLS podřazen alespoň jednomu sémantickému typu. Na obr. 1 je část sémantické sítě, s výběrem konceptu Congenital Abnormality (vrozená abnormalita). Je vidět, že vyšší úrovně sémantické sítě jsou jednoduchou obdobou základních ontologií, zatímco nejnižší již mají doménový charakter. V každém případě se však nejedná o ontologii postavenou na striktně logických základech, nýbrž o primárně terminologický zdroj. Dalším tradičním zdrojem je Foundational Model of Anatomy 13 (FMA) vyvíjený na University of Washington. Obsahuje přibližně 75 tisíc tříd a asi 120 tisíc speciálních termínů. Na obr. 2 je ukázka s podrobnější informací o termínu, Parietal bone (lebeční kost). Můžeme si povšimnout, že FMA již sleduje konkrétnější informace odpovídající situaci entit v reálném světě: odlišuje např. taxonomii tříd a podtříd (levá strana) od taxonomie vztahů celek-část (vpravo nahoře): lebeční kost je částí skeletu hlavy ( Skeleton of head ), a její částí je např. lebeční hrbolek ( Parietal tuber ); dokonce specifikuje, zda má objekt daného typu nenulový rozměr (což nemají abstraktní entity typu vývojové stadium ), hmotu (což nemá např. povrch určitého orgánu) a zřetelné ohraničení (což nemají např. látkové entity, jako je krev)

80 68 V.Svátek, M.Vacura: Ontologické inženýrství Obr. 1. Část sémantické sítě UMLS Obr. 2. Část ontologie FMA

81 Tutoriál 69 Patrně nejvýznamnějším pokusem konceptualizovat lékařskou problematiku pomocí logických nástrojů je projekt GALEN 14. Na rozdíl od předchozích projektů zde nebylo cílem pokrýt vyčerpávajícím způsobem terminologii oboru, nýbrž vytvořit kolekci provázaných definic pojmů, z nichž by se daly (do jisté míry automaticky) vytvářet nové pojmy a vyhledávat nové taxonomické vztahy. Podstatnou součástí modelu jsou proto definice a omezení, vyjádřená v jazyce GRAIL, postaveném na tzv. deskripční logice (viz dále kap. 6.1). Příkladem je definice odnětí plicního laloku : (SurgicalDeed which ismainlycharacterisedby (performance whichg isenactmentof (Excising which playsclinicalrole SurgicalRole) which actsspecificallyon (Lobe which isspecificsoliddivisionof Lung))). Z ontologií orientovaných převážně na klinickou medicínu se nakonec zmíníme o kolekci ON9 [11] vzniklé v rámci projektu ONIONS koordinovaného italskou Laboratoří aplikované ontologie (LOA). V řadě ohledů je obdobou GALEN, odlišuje se však důrazem na těsné sepjetí doménové ontologie se základními ontologiemi, a na snahu maximálně využít tradiční zdroje typu UMLS, s tím, že je nutné v nich opravit nekonzistentní místa a tím je převést do podoby skutečných ontologií. V poslední době se v ontologickém inženýrství věnuje velká pozornost aplikacím v oblasti genetiky. Zde je již tradičním zdrojem Gene Ontology 15 (GO). Jedná se o poměrně málo strukturovaný, spíše databázově orientovaný zdroj, popisující biologické procesy, buněčné komponenty a molekulární funkce vztahující se k jednotlivým genům. Podnikání, obchodování, právo V oblasti podnikání a obchodování lze vysledovat minimálně dva podstatně odlišné typy ontologií. První z nich podrobně strukturují obchodní komodity a mají význam zejména pro oblast e-commerce. Druhé se zabývají fungováním podniku jako organizace a směřují tudíž k aplikacím uvnitř podnikových informačních systémů. Hlavními zástupci první skupiny jsou produktové katalogy, jako je UNSPSC 16, americký NAICS 17, německý E-cl@ss 18, nebo RosettaNet 19. Podobně jako medicínské terminologie jsou velmi rozsáhlé, vznikly původně mimo znalostní prostředí, a jejich ontologizace je předmětem intenzivního výzkumu. Podnikové ontologie reprezentují především Enterprise Ontology 20 a TOVE 21, obě vzniklé již v 90. letech

82 70 V.Svátek, M.Vacura: Ontologické inženýrství Elektronické obchodování je také hlavní aplikací pro ontologie webových služeb. V této oblasti má zřejmě největší vliv komunita okolo ontologie WSMO 22. Volně související problematikou jsou právní ontologie, které jsou předmětem intenzivního výzkumu [3]. Technika a přírodověda I v oblasti technického návrhu lze vysledovat rozdělení na rozsáhlé, v praxi používané, ale jednodušeji strukturované zdroje, a menší avšak sofistikované ontologie. Do první skupiny patří především STEP 23 jakožto soubor protokolů pro popis produktů včetně procesu jejich výroby. Do druhé skupiny patří například EngMath [16] nebo PhysSys [4], které se věnují vlastnostem a chování obecných fyzických systémů zejména z hlediska prostoročasového a procesního, s cílem podpořit simulační aplikace. Obdobné určení má i Engineering Ontology vzniklá v rámci tuzemského projektu KSMSA 24. V oblasti přírodních věd je pak rozvinuto zejména modelování chemických substancí a procesů [9]. Na rozhraní techniky a přírodovědy stojí kupříkladu modelování problematiky rybářství [12]. Kulturní dědictví Vysokou míru zájmu o ontologie projevuje oblast kulturního dědictví. Klíčovou roli zde hraje rozsáhlá ontologie CIDOC CRM 25, která umožňuje modelovat kategorizaci historických a uměleckých artefaktů i proces jejich vzniku a uchovávání. Různé Z dalších oblastí stojí za zmínku aplikace ve vojenství, odvíjející se z intenzivní účasti americké vojenské výzkumné agentury DARPA v komunitě znalostního inženýrství. Vojenské ontologie (z nichž některé byly zveřejněny) mapují zejména oblast plánování vojenských operací. Neméně velký okruh ontologií, zpravidla ovšem vyvíjených veřejně a distribuovaným způsobem, se věnuje tématům souvisejících se sociálními vazbami a volnočasovými aktivitami. Mezi ně patří zejména nevelká ale velmi využívaná ontologie FOAF 26, zachycující různorodé informace o lidech a jejich vzájemných vztazích, a perspektivní ontologie SIOC 27, řešící problematiku sémantického propojení diskusních platforem typu elektronických konferencí, blogů apod. Již řadu let existuje potřeba sémanticky anotovat vedle textových zdrojů také zdroje multimediální. Již etablovaným, komerčně šířeným univerzálním standardem v této oblasti je ontologie MPEG-7 28, která je ovšem spíše rozsáhlým datovým schématem než plnohodnotnou ontologií. V posledních letech jsou stále častější pokusy zkombinovat obsah MPEG-7 s principy ontologického inženýrství: jedním Viz např

83 Tutoriál 71 z nejslibnějších výsledků v této oblasti je COMM 29 jádrová ontologie multimédií, a na ni navazující ontologie pro různé typy multimediálních dat. V rámci výzkumných projektů také vznikla také pestrá paleta doménových ontologií, jejichž hlavním účelem jsou, spíše než přímé praktické nasazení, podpora výuky ontologického inženýrství nebo různé teoretické experimenty. Z nich se můžeme zmínit například o ontologii vín 30, použité mj. v rámci úvodu do jazyka OWL 31, nebo ontologii pizz 32, na které jsou ilustrována úskalí téhož jazyka pro nezkušeného vývojáře (viz část 6.2); soubor ontologií o problematice pořádání konferencí 33 se zase používá jako testovací pro nástroje mapování ontologií. 4 Jazyky pro reprezentaci ontologií Z technologického hlediska problematika reprezentace a zpracování ontologií bezprostředně navazuje na tzv. rámcové přístupy k reprezentaci znalostí v umělé inteligenci. První rozšířenější jazyk pro reprezentaci ontologií, Ontolingua [15], který vznikl na Stanfordské univerzitě počátkem 90. let pod vedením již citovaného T. Grubera, byl původně navržen jako výměnný mezijazyk pro rámcové znalostní systémy. Ve srovnání se současným dominantním zástupcem ontologických jazyků, OWL, měl širší možnosti definování pojmů (využití plného aparátu predikátové logiky), to ovšem vedlo i k obtížím při implementaci odvozovacích nástrojů. Někteří výzkumníci šli následně cestou užšího sepětí s odvozováním v jazyce LISp (který byl v té době syntaktickým základem prakticky všech jazyků pro reprezentaci znalostí) příkladem je OCML [29], který je spíše programovacím jazykem a tvorba ontologií je v něm víceméně nadstavbou. Bohatým jazykem spadajícím do oblasti tvrdého jádra umělé inteligence, ovšem vzhledem ke spojení s komerčními aktivitami používaným omezenou skupinou vývojářů, je CyCL, sloužící k tvorbě rozsáhlé všeobecné ontologie CyC 34. Alternativou k rámcovým jazykům dále dlouhodobě byly (a v menší míře stále jsou) konceptuální grafy, navržené rovněž již citovaným J. Sowou. Vedle toho se však ve 2. polovině 90. let rozvíjel i směr usilující o užší sepětí ontologií se vznikajícími webovými standardy, jako byl HTML, XML a později RDF. Za historicky první webový ontologický jazyk lze považovat SHOE 35, ve kterém se ontologie zapisovaly pomocí speciálně pro tento účel navržených (tj. nestandardních) značek HTML. O trochu později vznikaly i jazyky na bázi nativního XML, jako byly XOL 36 a OML 37. Už na samém konci 90. let, bezprostředně po publikování (nyní již zastaralé) specifikace jazyka RDF 38 jako doporučení konsorcia W3C, však diskuse OML/Simple OML.htm; zajímavostí jazyka je využití konceptuálních grafů (namísto rámcového přístupu) jako formálního základu. 38 Aktuální soubor specifikací jazyka RDF včetně RDF Schema je na

84 72 V.Svátek, M.Vacura: Ontologické inženýrství odborné komunity o úloze XML versus RDF jako syntaktického rámce pro reprezentaci strojově zpracovatelných dat (faktů) na WWW dokonvergovala k názoru, že RDF je vhodnější zejména z důvodu své modularity a formálně-logické interpretovatelnosti. V zájmu syntaktického sjednocení webových faktů a ontologií definujících jejich význam se posléze jazyk RDF (ovšem sám kanonicky zapisován serializován pomocí XML) stal i základní úrovní reprezentace ontologií. Nejjednodušším ontologickým jazykem nad RDF je RDF Schema, který je dnes na úrovni specifikací již propojen s RDF samotným. Umožňuje definovat vztahy podřazenosti mezi třídami zdrojů a také mezi vlastnostmi (predikáty, tj. binárními relacemi definovanými mezi třídami), a dále definiční obor a obor hodnot vlastností. Na trochu vyšší úrovni složitosti stojí jazyky, jejichž výrazový aparát odráží možnosti vybraných variant deskripční logiky. Jedná se především o jazyk OWL 39, zpracovaný jako specifikace W3C v r (jeho předchůdci byly obdobně pojaté jazyky OIL, DAML-ONT a DAML+OIL, publikované postupně od r. 2000), který díky podpoře W3C doznal značného rozšíření, a většina populárních ontologií ho používá přinejmenším jako alternativní způsob zápisu. Oproti RDFS navíc nabízí např. definování tzv. lokálních omezení (existenčních, univerzálních, kardinalitních) nad vlastnostmi vztaženými k určité třídě, možnost postulovat disjunknost tříd, odlišit nutné a postačující podmínky příslušnosti ke třídě apod. K vyjadřovacímu aparátu jazyků na úrovni OWL se bude vztahovat výklad konkrétních logických problémů v části 6.2, proto jej zde nebudeme podrobně rozebírat. Za zmínku ale stojí, že popularita OWL přesáhla okruh znalostního a webového inženýrství začala se jím zabývat jedna z klíčových organizací softwarového inženýrství Object Management Group (OMG). V roce 2003 vznikl na základě výběrového řízení metamodel (rozšíření notace UML) zachycující konstrukce OWL, který by měl umožnit začlenění ontologií jako komponent návrhu rozsáhlejších softwarových aplikací 40. Jazykem velmi blízkým OWL, vzniklým de facto v téže odborné komunitě, je WSML 41, který je ovšem speciálně navržen pro účel modelování složitých webových služeb. Na úrovni teoretických návrhů se objevují také pokusy o rozšíření ontologických jazyků o reprezentaci neurčitosti. Příkladem je Fuzzy OWL [47]. Vedle středního proudu reprezentovaného OWL jako jazykem s vyjadřovací silou (v případě nejběžnější verze jazyka, OWL DL) nižší než má predikátová logika prvního řádu existují i přístupy, které předpokládají vyjadřovací sílu ekvivalentní či vyšší, než má predikátová logika příkladem je GOL [22]. Jiným způsobem, jak zvýšit vyjadřovací sílu ontologií, je zkombinování ontologického jazyka s na něj navazujícím jazykem pravidlovým, který poskytuje komplementární možnosti odvozování. V prostředí sémantického webu je pro tento účel často používán SWRL 42 (Semantic Web Rule Language) navržený v r Na druhé straně je ovšem daleko častější situace, kdy jsou i prostředky deskripční logiky považovány uživateli za příliš komplikované a neintuitivní. V takových případech návrháři sahají buďto po RDFS, nebo po jiných technologiích, které si v určitých komunitách již získaly okruh příznivců. Zajímavá je v tomto směru

85 Tutoriál 73 technologie Topic Maps 43, sloužící k vytváření a zpracování tzv. map témat. Ontologický jazyk Topic Maps je v některých aspektech principiálně odlišný od sémantického webu, mimo jiné proto, že mapy témat jsou (v nejrozšířenější variantě notace) zapisovány v nativním XML. Také jejich datový model je ovšem odlišný od RDF, je postaven na množině témat (topics) propojených asociacemi a majících konkrétní informační zdroje jako svoje výskyty (occurrences). Na rozdíl od jazyků ontologií sémantického webu je možné v Topic Maps definovat i asociace s aritou vyšší než 2; asociace jsou samy o sobě neorientované (takže nemá smysl rozlišovat dvojici relací vzájemně inverzních, jako v OWL), a k určení pozice zúčastněných témat v asociaci se používají navíc tzv. role. Jazyk nemá ambice sloužit pro strojové odvozování, ale jen pro katalogizaci a vyhledávání zdrojů, proto není vázán na formálně-logický aparát. V mnoha ostatních ohledech je plnohodnotnou alternativou k RDF a OWL, komunita jeho uživatelů a vývojářů je ovšem podstatně menší, ale na druhé straně s velkým podílem firem, a tudíž důrazem na jednoduchá, bezprostředně aplikovatelná řešení. Všechny uvedené jazyky v sobě v zásadě obsahují předpoklad, že třídám ontologie lze přiřadit instance (označované také jako individua, objekty, event. zdroje), tak, že množina instancí podtřídy je vždy podmnožinou množiny instancí nadřazené třídy. Tato množinová sémantika už není chápána jako zavazující u lexikálních ontologií (víceméně splývajících s tradičními tezaury), kde vztah nadřazeného a podřazeného pojmu může být nejen vztahem třídy a podtřídy, ale také třídy a její instance, případně také celku a části. Pojmy se zde primárně nechápou jako odkazy na množiny objektů reálného světa, nýbrž jako sémantické značky pro slova obsažené v textech. Z hlediska společného reprezentačního jazyka zde můžeme jako jednotný celek zmínit tzv. wordnety jedná se jak o původní anglický WordNet 44 z univerzity v Princetonu, tak i o velký počet národních wordnetů sdružených v mezinárodní asociaci GWA 45 : mezi velmi dobře zpracované jazyky patří, díky dlouhodobé práci týmu z Masarykovy univerzity, i čeština. Za účelem dosažení alespoň částečné kompatibility tezaurových zdrojů s ontologiemi zapsanými v jazycích typu RDFS resp. OWL pak vznikl SKOS 46 (Simple Knowledge Organisation System); jazyk je sám definován jako ontologie pomocí RDFS, a tudíž je i možné ho s jinými ontologiemi kombinovat. Jde o odlehčený ontologický jazyk přizpůsobený zdrojům charakteru tezauru, umožňuje definovat např. vztah mezi pojmem a jeho slovní definicí, vztah obecnějšího a speciálnějšího pojmu (pomocí relací typu skos:broader, tj. nikoliv jako třídu a podtřídu). Za extrémně jednoduché ontologie jsou někdy považovány i ad hoc hierarchie, např. tématické taxonomie používané ve znalostním managementu v podnikovém prostředí nebo struktury záhlaví ve webových katalozích typu Yahoo! či Seznam. Zde ovšem není systematicky zohledněna sémantika ani množinová ani lexikální, a jediným styčným bodem se skutečnými ontologiemi je přítomnost hierarchické struktury pojmů, což je pro adekvátnost používání označení ontologie málo viz též český tutoriál J. Koska na

86 74 V.Svátek, M.Vacura: Ontologické inženýrství 5 Prostředky pro podporu ontologické konceptualizace 5.1 Stručný přehled Ačkoliv se na první pohled může zdát, že pečlivé zpracování specifikací ontologického jazyka a jeho podpora odvozovacími nástroji je postačující podmínkou pro vznik prakticky využitelných ontologií, ve skutečnosti tomu tak není. Ontologický artefakt, který je z formálního hlediska zcela v pořádku, může být zcela neadekvátní z hlediska obsahu. V [52] jsou charakterizovány tři klíčové aspekty adekvátnosti ontologického obsahu: Přesnost: obsah ontologie by měl co nejvěrohodněji odpovídat situacím v reálném světě. Mnoho ontologických modelů je oproti realitě natolik zkreslených či zjednodušených (ať už vinou nedostatečně pečlivé analýzy reality, nebo kvůli omezením reprezentačního jazyka), že formálně správná odvození nad nimi vedou k nesmyslným závěrům. Srozumitelnost: ontologie by měla být co nejlépe srozumitelná lidem, kteří se na jejím vývoji nepodíleli. Zde má velký význam vhodné pojmenování prvků ontologie (např. vyvarování se žargonu), ale také modularizace na části, které je člověk schopen rozumově obsáhnout. Způsobilost k odvozování: nad ontologií (pokud má mít vyšší ambice než tradiční tezaury a klasifikační schémata) by mělo být možné netriviálně strojově odvozovat. Pro to je třeba využít možností formálního aparátu jazyka. Mezi těmito aspekty lze vypozorovat různé pozitivní i negativní vazby. Snaha o bohaté odvozovací možnosti nad ontologií někdy vede k přidávání vztahů, které platí pouze modelově a nikoliv paušálně 47, čímž se snížuje přesnost. Podobně i snaha o maximální srozumitelnost pro nezasvěcené uživatele může vést ke snižování přesnosti (např. pokud se přesné avšak málo známé pojmy nahradí běžnými ale nepřesnými). Na druhé straně vysoká míra formalizace (pro potřebu odvozování) může napomoci odhalit již ve fázi úvodního návrhu některé odchylky např. taxonomické kostry oproti realitě. V následujícím textu se podrobněji zmíníme o několika typech prostředků, které se v posledních letech používají jak podpora vzniku ontologického obsahu relativně nezávisle na konkrétním jazyce formalizace: o strukturovaných metodikách, o využití základních ontologií (resp. s nimi úzce spojených obsahových vzorů) jako východiska pro tvorbu ontologií doménových, a o automatické analýze podkladových materiálů (někdy označované jako učení ontologií z textů ). 5.2 Strukturované metodiky pro vývoj ontologií Podobně jako v softwarovém inženýrství a později i ve znalostním inženýrství chápaném jako tvorba znalostních softwarových aplikací [42] se potřeba obecných doporučených postupů práce objevila i v ontologickém inženýrství jakožto specifické 47 To lze částečně řešit pomocí rozšíření jazyků o formalizaci neurčitosti.

87 Tutoriál 75 součásti znalostního inženýrství zaměřené na dílčí datově-softwarové 48 artefakty ontologie. [13] popisuje a porovnává sedm obecných metodik pro vývoj ontologií, převážně vzniklých zobecněním zkušeností z jednoho či více konkrétních projektů. V následujícím textu se pokusíme zobecnit posloupnost hlavních kroků, která se objevuje ve většině metodik. Ujasnění účelu a rozsahu ontologie Na začátku je potřeba vymezit, jaké úlohy budou s pomocí ontologie řešeny, a jaká část dané věcné oblasti má být modelována. To je způsob, jak překonat tzv. problém rozsahu ( hugeness problem ), tj. skutečnost, že k libovolné věcné doméně se zpravidla vztahuje (třebas okrajově) nezvládnutelné množství pojmů a vztahů. Vedle obecných scénářů či případů použití, pojatých obdobně jako v softwarovém inženýrství konvenčních aplikací, stojí za zmínku tzv. kompetenční otázky [17]. Jedná se o příklady konkrétních otázek, které by hypotetický znalostní systém s pomocí vyvíjené ontologie měl být schopen zodpovědět. Je ovšem potřeba si uvědomit, že ontologie by neměla být jednoúčelová. Měla by sice každopádně být navržena tak, aby vyhověla potřebám úlohám řešeným v rámci daného projektu, na druhou stranu by však měla předjímat i rozumně velké spektrum dalších úloh z téže domény, tj. zůstat otevřená pro znovupoužití (reuse). Specifikace terminologické části ontologie Přestože znalostní ontologie svým pojetím sémantiky přesahují čistě terminologický pohled, vhodným výchozím bodem pro jejich vlastní tvorbu je seznam relevantních termínů, prozatím ještě bez rozčlenění na třídy, relace, instance atd. Prostý seznam termínu je ale možné doplnit jejich vysvětlením, event. definicemi, formou volného textu. Tím se ze seznamu stane glosář, který může později sloužit i jako dokumentace dané ontologie pro člověka. Přinejmenším v této fázi bývá efektivní použít prostředky pro automatickou analýzu podkladových materiálů, kterým se věnuje podkapitola 5.4. Odlišení ontologických typů Principiálním rozdílem mezi slovníky/glosáři a byť jen jednoduchými ontologiemi je explicitní rozlišování ontologických typů, kterými jsou zejména třídy, relace (plus atributy) a instance tříd. Zatímco v některých případech volba víceméně jednoznačně vyplývá z povahy věci, jindy je možné tentýž objekt či vztah modelovat více způsoby. Již v této fázi je proto třeba zohlednit cílovou aplikaci; pomůckou mohou být logické vzory, viz část 6.2. Specifikace taxonomie Taxonomická struktura je ve většině ontologických jazyků chápána jako kostra, na kterou se teprve navazují další vztahy. Taxonomii je možné budovat odshora (topdown), tj. od nejobecnějších pojmů dané domény, pokud možno opřených o základní 48 Tato dualita pohledu na ontologie je poměrně významná. Tvorba ontologie se na jedné straně podobá návrhu datového modelu, na druhé straně kódování jejích axiomů ve formálním jazyce nemá daleko k programování v jazycích typu Prolog nebo LISp.

88 76 V.Svátek, M.Vacura: Ontologické inženýrství ontologie, viz níže, nebo také odspoda (bottom-up), tj. od nejkonkrétnějších pojmů (např. individuových jmen), za nejvhodnější se však ve většině případů považuje postup od středu (middle-out). Při tomto přístupu se jako výchozí bod vezmou středně obecné doménové pojmy, protože ty mají největší šanci být použitelné pro velkou řadu aplikací; k nim se pak přidávají pojmy obecnější nebo naopak konkrétnější, ovšem pouze tehdy, když jsou skutečně potřeba a nelze je substituovat středně obecnými pojmy. Ve fázi tvorby taxonomie je také nutné vyřešit otázku importu již existujících doménových ontologií, a také mapování na základní ontologie, kterému se věnuje podkapitola 5.3. Vytvoření struktury netaxonomických relací, atributů a instancí Na základní taxonomickou strukturu se postupně navazují netaxonomické relace mezi třídami. Důležité je zde zvolit vhodnou hierarchickou úroveň, ke které se relace budou vztahovat. Totéž platí i pro atributy tříd 49. Instance se ve většině případů do ontologií zařazují pouze tehdy, když mají v dané oblasti významné, jedinečné postavení. Některé návody a metodiky postulují, že instance by měla být do ontologie zařazena pouze tehdy, když je nutná k definování určité třídy 50. Nasazení a údržba ontologie Vedle ústředního procesu vlastní tvorby ontologie se do jejího životního cyklu popsaného metodikami často zahrnuje, tak jako u jiného softwarového artefaktu, fáze jejího nasazení a údržby, která má samozřejmě odlišný časový horizont než předchozí fáze. Některé metodiky zde např. odkazují na metody testování a verzování ontologií. Poznamenejme, že některé důkladnější metodiky, jako je METHONTOLOGY [13], předpokládají, že ontologie zpočátku vzniká v podobě neomezené (nebo jen málo omezené) cílovým logickým formalismem. Jednotlivé konstrukty i vztahy mezi nimi jsou zaznamenávány do tabulek, a logické formule formou pseudojazyka (např. s vyjadřovací silou predikátového kalkulu), nad kterým se ještě nepředpokládá odvozování. První verze ontologie pak tedy může existovat na úrovni textového dokumentu; některé softwarové nástroje, jako (v současnosti ovšem již neudržovaný) WebODE 51, specificky podporují takovou reprezentačně nezávislou tvorbu ontologií, a umožňují následnou konverzi do různých formátů. Zcela automatická konverze by však vyžadovala sofistikované zohlednění logických vzorů pro cílový jazyk (viz část 6.2), jaké v současnosti ještě v žádném systému zřejmě implementováno není. 49 V některých jazycích je mezi relacemi a atributy úzký vztah. Příkladem je OWL, kde se označují za objektové resp. datotypové vlastnosti, a mají některé společné charakteristiky. Datotypové vlastnosti v OWL mohou, stejně jako objektové, nabývat více hodnot, protože se jedná v obou případech o binární relace, ne nutně funkce. 50 Příkladem takové definice je (ve slovním vyjádření) např.: X je instancí třídy anglickyhovořící-člověk právě tehdy, když je pro něj vlastnost mluví-jazykem nabývá hodnoty angličtina, přičemž individuum angličtina je instancí třídy jazyk. 51

89 Tutoriál 77 Metodiky, které podporují spíše přímé kódování ontologie, pak naopak samozřejmě postulují průběžné nebo alespoň dodatečné zdokumentování ontologie a procesu jejího vzniku. 5.3 Aplikace základních ontologií a obsahových vzorů Návrh ontologií je náročnou činností, která vyžaduje jak rozsáhlé znalosti v oblasti modelování, tak i porozumění dané předmětné doméně, která je modelem zachycována. Pro usnadnění procesu modelování je možné využít, vedle výše popsaných základních ontologií, i další postupy. Významná je zejména specializovaná metodologie OntoClean, jejímž cílem je omezit výskyt nejběžnějších modelovacích chyb, a zajistit konzistenci výsledné ontologie. Dalším nástrojem jsou návrhové vzory, které umožňují podobné oblasti modelovat podobným způsobem, na základě důkladně propracovaných vzorových přístupů a šablon. OntoClean je metodologie pro ontologickou analýzu vyvinutá N. Guarinem a C. Weltym [20]. Vychází z obecně teoretických výzkumů v oblasti filosofické ontologie a aplikuje je s cílem zajistit, aby ontologie, která je výsledkem modelování, byla konzistentní a neobsahovala zásadní konceptuální chyby. OntoClean tak pak vychází z určitých abstraktních ontologických pojmů, na základě nichž definuje specifické metavlastnosti, pomocí nichž pak popisuje jednotlivé součástí navrhované ontologie. Přirazené metavlastnosti pak jednak omezují další vývoj ontologie pouze na s ohledem na OntoClean konzistentní rozšíření, a zároveň umožňují vykázat existující nekonzistence v dané ontologii. Podívejme se tedy na několik základních ontologických pojmů, se kterými OntoClean pracuje. Prvním takovým pojmem je esencialita, a týká se vztahu mezi entitou a její vlastností. Vlastnost je pro entitu esenciální, pokud ji daná entita musí mít. Speciálním typem esenciality je rigidita. Vlastnost je rigidní, pokud je esenciální ve všech svých případech. Například vlastnost být osobou je obvykle považována za rigidní, neboť pokud ji kterákoliv entita, která ji má, ztratí, přestane být tím, čím je (například smrtí se ze člověka stane mrtvola). Naopak vlastnost být tvrdý není rigidní, neboť různé entity ji mohou nabývat a ztrácet, aniž by přestaly být tím, čím jsou (například mokrá houba je měkká, po usušení je tvrdá, přesto je to stále houba). Vlastnosti, které v některých případech jsou esenciální a v jiných ne, jsou nazývány semirigidní a vlastnosti, které nejsou nikdy esenciální, jsou nazývány antirigidní. Při aplikaci metodologie OntoClean, je všem vlastnostem v ontologii přiřazena jedna z těchto metavlastností rigidita, semirigidita nebo antirigidita. Výhodným výsledkem je následně i jednoduchá identifikace tzv. páteřní taxonomie dané ontologie, která sestává ze všech rigidních vlastností. Dalšími důležitými pojmy, kterými se OntoloClean zabývá, jsou pojmy identity a jednoty. Problém identity je otázka, v jakém případě považovat dvě entity za identické. Klasickým případem je identita Jitřenky a Večernice, jiným příkladem je aplikace sledující kamerami určitý prostor a nutnost rozhodnout se, kdy člověk zabíraný kamerou A je identický s člověkem, který byl před chvílí snímán kamerou B v jiné lokaci. Ve všech takových případech je podstatné explicitní vyjádření tzv. kriteria identity, tj. podmínek, které dvě entity musí splňovat, aby byly prohlášeny za identické. Obecně předpokládáme, že každá entita v ontologii by měla mít určité kriterium identity a rigidní vlastnosti, které toto kritérium identity popisují. Téma

90 78 V.Svátek, M.Vacura: Ontologické inženýrství jednoty se týká otázky, v jakém vztahu jsou části určité entity k celku. Problémovým konceptem je třeba voda, jehož instance jsou určitá množství vody, ale obvykle nejsou považována za nějaké jednoty nebo vymezené celky. Pokud naopak chápeme například Černé moře jako určitý jeden vymezený celek, můžeme jej chápat jako instanci konceptu moře, ale dále už nemůžeme moře jednoduše považovat za podtřídu třídy voda. Tento problém podle autorů OntoCleanu vychází z mnohoznačnosti jazyka, protože moře ve skutečnosti nejsou druhy vod, ale jsou složeny z vody. Proto metodologie OntoClean rozlišuje prostřednictvím metavlastností ty koncepty, jejichž instancemi jsou nějaké jednotné entity, celky, a ty, u nichž tomu tak není. OntoClean také věnuje pozornost vztahu subsumpce mezi koncepty (resp. podtřídy mezi třídami), který je základním vztahem pro většinu ontologií a často se v jeho použití chybuje. Základní charakteristikou tohoto vztahu je, že všechny instance podřazeného konceptu jsou nutně i instancemi konceptu nadřazeného. Typický problém je zaměňování vztahu subsumpce a instanciace. Autoři OntoCleanu uvádějí následující příklad: Člověk je podtřídou třídy Savec a Sokrates je instancí třídy Člověk. Jak je to ale se vztahem třídy Biologický druh k třídě Člověk? Často se stává, že nezkušený návrhář ontologie určí třídu Člověk jako podtřídu třídy Biologický druh. Pokud ovšem určíme kriterium identity pro entity spadající pod třídu Člověk a kriterium identity pro entity spadající pod třídu Biologický druh zjistíme, že jsou zásadně odlišná. Pokud by Člověk byl podtřídou Biologického druhu pak by jistě zdědil jeho kriteria identity. Ve výsledku docházíme k závěru, že Člověk je instancí třídy Biologický druh, a to je třída druhého řádu. Dalšími problémovými oblastmi návrhu ontologií, kterým se metodologie OntoClean věnuje, jsou záměny vztahu subsumpce a vztahu část-celek, problematika polysémie a další. Metodologie OntoClean je v současnosti používaná v praxi, a existují softwarové nástroje pro podporu jejího nasazení. Například pro jeden z nejpoužívanějších ontologických editorů Protégé existuje modul pro doplňování metavlastností definovaných metodologií OntoClean. Obsahové vzory Obsahové návrhové vzory Conceptual (or Content) Ontology Design Pattern (CODeP) jsou nástrojem, šablonou pro zjednodušení a standardizaci řešení modelovacích problémů při návrhu ontologií. A. Gangemi [10] definuje některé charakteristické vlastnosti obsahových návrhových vzorů: Návrhový vzor je obvykle vytvořený na základě určité referenční základní ontologie, ale je aplikovatelný i v jiných ontologiích postavených na odlišných základních ontologiích. Návrhové vzory jsou obvykle dobře vizualizovatelné, a jsou přiměřeného rozsahu, aby byly snadno zapamatovatelné a lehce využitelné. Návrhové vzory mohou využívat jeden druhý nebo mohou vytvářet hierarchii podle úrovně zobecnění. Konkretizované návrhové vzory pro danou doménu mohou být vytvořeny doménovými experty s použitím obecnějších návrhových vzorů a obecných doménových schémat.

91 Tutoriál 79 Návrhové vzory mohou také zachycovat doporučované postupy ( best practices ) pro určité oblasti modelování. Návrhové vzory mohou připomínat databázové schéma, ovšem na rozdíl od nich jsou definovány s ohledem na referenční ontologii a mají obvykle obecnější charakter. Jako nejběžnější příklady obsahových návrhových vzorů uvádí [10] modelování přítomnosti v časoprostorové lokaci a reifikaci časově indexované relace. Jádro prvního vzoru, který je součástí knihovny základní ontologie DOLCE [26], tvoří relace účasti (participace), která je mezi objektem a událostí. Časová indexace je zajištěna lokalizací dané události v určitém časovém intervalu. Vzor poskytuje možnost hierarchizace objektů i událostí, umožňující podporu jednoduchého odvozování. Pokud je objekt účasten události, jsou účastny události i jeho části. Pokud je objekt trvale účasten nějaké nadřazené události, je účasten i událostí, které jsou časovými částmi této nadřazené události. Viz Obr. 3. Obsahový vzor reifikace časově indexovaných relací (reifikace zvěcnění, z lat. res věc, facíre učinit) představuje určitou alternativu pro první příklad. Abstraktní koncept Time-Indexed-Participation zvěcňuje, tj. vytváří entity reprezentující vztah mezi objektem, událostí a časovým intervalem. Viz Obr. 4. Obr. 3: Přítomnost v časoprostorové lokaci. Obr. 4: Reifikace časově indexovaných relací.

92 80 V.Svátek, M.Vacura: Ontologické inženýrství Můžeme tedy pro danou konkrétní situaci často vybrat z více aplikovatelných návrhových vzorů ten nejvhodnější. Pro vytváření knihoven návrhových vzorů je doporučena popisová šablona, k zachycení podstatných charakteristik každého návrhového vzoru [10]. 5.4 Automatická analýza podkladových materiálů Tvorba ontologie byla tradičně považována za sofistikovanou a tudíž čistě lidskou aktivitu. Přibližně od roku 2000 se však začalo ve větší míře uvažovat o zapojení automatických metod i do této oblasti. Důvodem je zejména vysoká časová náročnost a možnost ovlivnění subjektivním pohledem na doménu při vymezování okruhu relevantních termínů jako úvodní fázi vlastní tvorby ontologie. Pokud jsou pro danou oblast k dispozici rozsáhlejší textové zdroje, je možné v nich detekovat relevantní termíny metodami známými z dokumentografických informačních systémů (běžně se pro tento účel používá např. míra TDIDF). Druhou možností, která funguje spíše v úzce vymezených oborech, je využití syntaktických vzorů nad (povrchovou či hloubkovou) větnou strukturou; např. pokud se v lékařském textu vyskytne určité podstatné jméno bezprostředně před slovesem postihuje, můžeme předpokládat, že se jedná o slovo, které bude kandidátem na zařazení do ontologie. Ambicióznější metody učení ontologií [5,25] jdou pak ještě dál: jejich cílem je nabídnout uživateli na základě nejen seznam termínů, ale také uspořádat je do hierarchické struktury (např. ve výše uvedeném příkladě by se nové slovo mohlo označit za kandidáta na podtřídu či instanci třídy Nemoc), nalézt potenciální relace mezi pojmy, případně i navrhnout složitější logické axiomy. Míra přesnosti výsledků takových automatických metod je zpravidla nepříliš vysoká, pro tvůrce ontologie však přesto mohou představovat užitečný vstup. 6 Ontologie a logické odvozování Web Ontology Language (OWL) má tři odlišné standardizované podoby Full, DL a Lite. OWL Full označuje kompletní jazyk OWL, zatímco verze DL a Lite jsou určitým způsobem redukovány a mají tudíž i nižší expresivní schopnost. OWL Lite je přitom redukována oproti OWL DL a je určena pro aplikace s požadavkem na jednoduchou implementaci a obsahuje pouze základní sadu konstruktů jazyka pro nejjednodušší použití. OWL DL je jazyk korespondující s deskripční logikou, která je teoretickým podkladem pro algoritmizované odvozování v oblasti ontologií. 6.1 Odvozování v deskripční logice Deskripční logika V následujícím oddíle podáme základní neformální přehled deskripční logiky zájemce o přesné formální vymezení odkazujeme na standardní příručku [2]. Deskripční logika je logika pojmů neboli konceptů. Primárně tedy zachycuje vzájemné vztahy mezi pojmy. Pojem můžeme zjednodušeně chápat jako obecný výraz, pod který spadá či může spadat více individuí. Příkladem jsou výrazy jako

93 Tutoriál 81 židle, nábytek, otec, planeta, muž, žena atd. Pojmy odlišujeme od vlastních jmen, která označují jedno konkrétní individuum, např. Václav Klaus. Koncepty pak ze sémantického hlediska můžeme chápat jako množiny individuí, spadajících pod příslušný pojem. Můžeme tedy také vyslovit tvrzení o tom, že určité individuum spadá pod určitý koncept: Muž(Petr), tedy že Petr je muž. Ze základních konceptů (např. Muž a Rybář) je možno konstruovat složené koncepty. Například koncept Muž Rybář zahrnuje ta individua, která jsou zároveň mužem a rybářem (sémanticky se jedná o průnik příslušných množin individuí). Analogicky koncept Muž + Rybář zahrnuje ta individua, která jsou buď mužem anebo rybářem (sémanticky se jedná o sjednocení příslušných množin). Koncept Muž zahrnuje ta individua, která nespadají pod koncept Muž. Druhou základní součástí deskripční logiky jsou role. Role můžeme naopak sémanticky chápat jako množiny uspořádaných dvojic, tedy jako binární relace. Příkladem rolí pak mohou být obíhákolem (např. Země obíhá kolem Slunce), jeotcem (např. Karel je otcem Petra). Formálně pak můžeme příslušné fakty zapsat například: obíhákolem(země,slunce) a jeotcem(karel,petr). S použitím role obíhákolem můžeme zkonstruovat další koncepty, například obíhákolem.hvězda, což je koncept planety (pro každou planetu existuje hvězda, kolem které obíhá), nebo jeotcem.muž což je koncept zahrnující všechna individua, jejichž všechny děti 52 jsou mužského pohlaví. Všimněme si, že symboly a mají jiný význam než ve standardní predikátové logice, nicméně formuli deskripční logiky lze na první pohled odlišit od formule predikátové logiky podle syntaxe. Nehrozí tedy záměna. Formálně se konstruktor z hlediska syntaxe deskripční logiky používá ke konstrukci výrazů typu R.C, kde R je role a C je koncept. Z hlediska sémantiky (vyjádřeno v jazyce predikátové logiky) popisuje tento koncept množinu {x ; y (R(x,y) C(y)) }. Tedy v případě výrazu jeotcem.muž se jedná o takovou množinu prvků x, kde všechna y, pro která platí jeotcem(x,y), spadají pod koncept Muž(x). Což znamená, jak už bylo řečeno, že se jedná o množinu všech otců dětí jen mužského pohlaví. Analogicky se konstruktor z hlediska syntaxe používá ke konstrukci výrazů typu R.C, kde R je role a C je koncept. Z hlediska sémantiky popisuje tento koncept množinu {x; y (R(x,y) C(y)) }. Tedy v případě výrazu obihákolem.hvězda se jedná o takovou množinu prvků x, pro které existuje y, kde platí zároveň obíhákolem(x,y) a Hvězda(y). Tedy jedná se o množinu objektů, které obíhají kolem nějaké hvězdy, tzn. definujeme koncept planety (předpokládáme, že objekt může v daný okamžik obíhat jen kolem jednoho objektu, a za univerzum diskursu považujeme jen velká vesmírná tělesa). Univerzální koncept zahrnuje všechna individua z univerza diskursu, prázdný koncept nezahrnuje žádné individuum. Deskripční logiku můžeme vlastně chápat jako určitý fragment predikátové logiky prvního řádu, používající odlišnou syntaxi predikátová logika prvního řádu je expresivnější než deskripční logika. Deskripční logika je na rozdíl od predikátové logiky rozhodnutelná. Deskripční logika přitom není jen jedna, rozeznáváme celou rodinu deskripčních logik s různou expresivitou, zachovávající si však rozhodnutelnost. Základní deskripční logika AL připouští pouze následující 52 Přesněji: všechny děti, kterým jsou otcem, protože matky koncept nezahrnuje.

94 82 V.Svátek, M.Vacura: Ontologické inženýrství konstrukty: A, C D, R.C, R., kde R je atomická role a A je atomický koncept a C, D jsou koncepty. Znalostní báze deskripční logiky je tvořena TBoxem a ABoxem (někdy se mluví ještě o RBoxu obsahujícím axiomy rolí). TBox obsahuje terminologické axiomy formátu A C nebo A µ C (např. Člověk Živočich Rozumný), dále axiomy týkající se rolí formátu R S nebo R µ S (přípustný až logice SH). ABox obsahuje extenzionální axiomy týkající se spadání individuí pod koncepty a účasti v rolích, například C D(a) nebo R(a,b), kde a,b jsou individua. Další rozšíření základní deskripční logiky se vyznačují písmenem přípustné konstrukce shrnuje následující tabulka (konkrétní deskripční logika se pak označuje kombinací písmen, např. ALCN): Označení Přípustná rozšíření U Sjednocení C+D E Plný existenční kvantifikátor R.C N Numerické restrikce (kardinalitní omezení) βnr a ρnr C Plná negace C Symbolem S se označuje deskripční logika ALC r+, tzn. deskripční logika ALC rozšířená o axiomy tranzitivity rolí. Symbolická označení pokročilých deskripčních logik shrnuje další tabulka: Označení S SH SHf SHO SHOI SHOIN SHOIQ Přípustné rozšíření S = ALC + axiomy tranzitivity rolí SH = S + axiomy hierarchie (inkluze) rolí SHf = SH + funkcionální axiomy rolí SHO = SH + nominálové axiomy SHOI = SHO + inverzní role SHOIN = SHOI + numerické restrikce SHOIQ = SHOI + kvalifikované numerické restrikce Transitivní role nesmí být použity v numerických restrikcích, jinak je výsledná deskripční logika nerozhodnutelná. Množiny transitivních rolí a funkcionálních rolí by mely být disjunktní. Nyní můžeme konstatovat, že OWL DL odpovídá deskripční logice SHOIQ. V současné době je připravována verze OWL 1.1, která má přinést řadu rozšíření, a z teoretického hlediska bude odpovídat expresivnější deskripční logice [14]. Základní odvozovací úlohy v deskripční logice jsou následující: Kontrola konzistence znalostní báze zjišťuje, zda definice každého konceptu připouští náležení alespoň jednoho individua. Kontrola individuí zjišťuje, zda dané individuum spadá pod daný koncept. Realizace nalezne nespecifičtější koncept, pod který individuum spadá. Vyhledání nalezne všechna individua spadající pod zadaný koncept. Kontrola subsumpce zjišťuje, zdali je jeden zadaný koncept podkonceptem druhého.

95 Tutoriál 83 Většina odvozovacích systémů je v současnosti založena na tablových (tableau) algoritmech. Pro OWL ontologie je k dispozici řada funkčních odvozovacích softwarových nástrojů, např. Pellet [43], Racer [21] nebo FaCT++ [53]. 6.2 Strukturní a logické problémy při tvorbě ontologií Jak už jsme naznačili v části 5, tvorba obsahu ontologie skrývá pro běžného informatika některá úskalí, o kterých se zmíníme v následující části. Nejprve se dotkneme jednodušších jmenných a strukturních konvencí, a poté se budeme věnovat hlubším problémům logické interpretace ontologií specificky pro jazyk OWL, a specificky vytvořeným tzv. logickým návrhovým vzorům. Struktura a pojmenování tříd, relací a instancí Přestože s požadavkem, že všechny instance dané třídy by měly být současně instancemi každé z jejích nadtříd, každý začínající ontologický inženýr ochotně deklaruje souhlas, je skutečností, že v málokteré ze začátečnických (a leckdy dokonce i profesionálních) ontologií je požadavek bezezbytku splněn 53. Často je za vztah třídy a podtřídy vydáváno to, co je ve skutečnosti vztahem třídy a instance (třeba Firma IBM) nebo vztahem celku a části (třeba Počítač Procesor). Někdy je také vztah samotný zamýšlen dobře, ale není vhodně realizován na úrovni pojmenování tříd, protože předpokládá interpretaci názvu třídy v kontextu nadřazených tříd (třeba Počítač Stolní). Dalším zdrojem nejasností je pojmenování relací, které neevokuje směr relace. Pokud relaci vyjadřující vztah vyrábějící firmy a vyráběného produktu nazveme třeba výrobek, nemusí být nezasvěcenému člověku jasné, zda tvrzení IBM výrobek ThinkPad znamená IBM vyrábí výrobek ThinkPad nebo IBM je výrobek (firmy) ThinkPad. Vhodnější je tedy rozlišovat vzájemně inverzní relace třeba takto: je_výrobkem / má_výrobek, tj. hlavním slovem názvu relace by mělo být sloveso, eventuelně předložka. Pro lepší čitelnost složitějších axiomů je navíc dobré od sebe třídy, relace a případně i instance odlišit typografickou konvencí. Často se alespoň názvy tříd píší s velkým počátečním písmenem. Logické paradoxy Pro informatiky zvyklé na databázové vidění světa může tvorba ontologie v OWL DL skrývat další úskalí, která propagátoři ontologií z iniciativy CO-ODE 54 nápaditě zviditelnili pomocí demonstrační ontologie pizzas a vysvětlujících materiálů k ní. Prvním problémem je chápání existenčního a univerzálního kvantifikátoru, a (v syntaxi OWL allvaluesfrom a somevaluesfrom ). Poměrně nasnadě je asi nesprávnost definice vegetariánské pizzy jako pizzy s vegetariánskou náplní 55 (kde třída Vegetariánská_náplň zahrnuje podtřídy jako Rajčatová_náplň, Houbová_náplň 53 O problému jsme se zmínili již v části 5.3 v souvislosti s metodou OntoClean. Je však natolik zásadní, že není na škodu na něj upozornit na více místech Nepříliš výstižný avšak v praxi používaný překlad anglického topping ; kvůli němu jsou některé uvedené příklady pro českého čtenáře drobně modifikovány.

96 84 V.Svátek, M.Vacura: Ontologické inženýrství atd.), tj. Vegetariánská_pizza Pizza má_náplň.vegetariánská_náplň. Pizza totiž (pokud není relace má_náplň deklarována jako funkce) může mít náplní víc, definice ovšem pouze požaduje, aby byla vegetariánská aspoň jedna z nich. Někoho ale možná zaskočí, že problém nevyřeší prostá výměna existenčního kvantifikátoru za univerzální, čili: Vegetariánská_pizza Pizza má_náplň.vegetariánská_náplň. Pojem vegetariánské pizzy totiž pak zahrnuje kromě opravdových vegetariánských pizz také pizzy, které nemají žádnou náplň (a tudíž lze říci, že všechny náplně, které mají, jsou vegetariánské ). K dosažení žádoucího stavu je tedy nutno na pravé straně definice uvést konjunkci existenčního a univerzálního axiomu: Vegetariánská_pizza Pizza má_náplň.vegetariánská_náplň má_náplň.vegetariánská_náplň. Jinou záludností kupříkladu je, že množinu všech deklarovaných podtříd určité třídy nelze apriorně chápat jako rozklad této třídy, ani tyto podtřídy nejsou vzájemně disjunktní. To může vést k problémům např. ve spojení s další, pro databázisty nezvyklou, skutečností: omezení na definiční obor a obor hodnot relace se chápou jako logické formule (nad kterými probíhá odvozování), ne jako integritní omezení. Pokud tedy kupříkladu deklarujeme, že definiční obor relace má_náplň je třída Pizza, a poté uvedeme třeba u třídy Šlehačkový_dort (která nebude explicitně prohlášena za disjunktní s třídou Pizza) podmínku má_náplň.šlehačka, důsledkem bude, že odvozovací nástroj zařadí Šlehačkový_dort jako podtřídu třídy Pizza. Mnoho dalších paradoxů je podrobně rozebráno v [38]. Logické návrhové vzory Třetí skupinu problémů spojených s tvorbou ontologie ve formálním jazyce lze charakterizovat tak, že není na první pohled patrné jednoznačné převedení intuitivní konceptualizace do daného, omezeného jazyka. Pro řešení těchto problémů jsou postupně vytvářeny 56 návrhové vzory v mnoha směrech blízké vzorům známým v softwarovém inženýrství. Od obsahových vzorů uvedených v části 5.3 se liší vazbou na konkrétní jazyk a naopak (relativní) nezávislostí na věcné doméně. Velmi frekventovaným problémem v OWL je například nemožnost přímo modelovat relace s aritou větší než 2. Návrhový vzor [31] doporučuje pro většinu případů provést reifikaci relace, tj. n-ární relace (např. vztah mezi prodávajícím, kupujícím, kupovaným předmětem, případně cenou a dalšími účastníky relace) je převedena na třídu (např. Obchodní transakce ) a ostatní objekty jsou již pak k ní připojeny binárními relacemi. Složitějším problémem, řešeným vzorem s mnoha alternativami [32], je situace, kdy potřebujeme na jedné straně modelovat hierarchickou strukturu (např. živočišných druhů, rodů, čeledí atd.) a na druhé straně na prvky hierarchie odkazovat relací (např. spojující určité informační zdroje se skupinami živočichů, o kterých pojednávají). Zdá se, že bychom tedy potřebovali, aby mohla samotná třída (např. Lev ) a nikoliv jen její konkrétní instance (konkrétní lvi) být argumentem relace. To sice lze, ale pouze v OWL Full, nad kterým se odvozuje obtížněji, než nad OWL DL. Jendnou z alternativ je kupříkladu vytvořit k hierarchii tříd paralelní hierarchii individuí, vyjadřujících různé tématiky (např. tématika lvů ); relace 56 Nejčastěji v rámci pracovní skupiny W3C Semantic Web Best Practices and Deployment, viz

97 Tutoriál 85 pojednává o pak může odkazovat na ně a nikoliv na třídy interpretované jako množiny fyzických živočichů. Posledním problémem (a návrhovým vzorem), o kterém se zmíníme, je potřeba odlišného modelování proměnlivých aspektů objektů oproti trvalým. Příkladem je rozlišení tvrzení, že určitý objekt je člověk, od tvrzení, že tentýž objekt je učitel. Zatímco člověkem je objekt po celou dobu své existence (jde o esenciální charakteristiku, viz část 5.3), učitelem přestane být nejen tehdy, když zemře, ale i tehdy, když změní povolání nebo odejde do trvalého důchodu z hlediska ontologie bychom pak museli tentýž objekt přemisťovat mezi třídami. Být učitelem je totiž role, kterou daný objekt hraje, a nikoliv třída v základním smyslu slova. Primitivním řešením problému je např. třídu Učitel vůbec nezavádět a spokojit se s relací být_učitelem. To však vede ke sníženým možnostem odvozování. [50] proto navrhuje modelovat role (např. při konverzi z některého jazyka, který má pojem role přímo ve svém metamodelu) v OWL pomocí komplexního logického vzoru. Vzor rozlišuje třídy odpovídající základním, konceptům jako je Člověk nebo Škola, třídy odpovídající rolím ( role concepts ), jako je Role_učitele, a třídy odpovídající držitelům role ( role holder ), jako je Učitel. V rámci vývoje jazyka, jako je OWL, existuje přirozený trend k přesouvání frekventovaných konstrukcí z úrovně logických návrhových vzorů na úroveň rozšíření normy jazyka o potřebné konstrukce. Tak se například problém tzv. kvalifikovaných kardinalitních omezení (současný požadavek na kardinalitu relace a na třídy, jejíž instance smějí být hodnotami relace), původně nedokonale řešený pouze na úrovni návrhového vzoru, definitivně vyřešil zařazením potřebné konstrukce do nové verze jazyka 57, OWL Specializované nástroje pro tvorbu a využívání ontologií 7.1 Editory ontologií Z hlediska ontologického inženýrství jsou samozřejmě základními nástroji editory, které umožňují ontologii vytvářet, ale zpravidla také testovat, a v mnoha případech jsou vybaveny i rozšiřujícími moduly s rozličnou funkčností. Pro ontologie v OWL (a RDFS) je v současnosti jednoznačně nejrozšířenějším editorem volně šířený stanfordský Protégé 58 se svým OWL Plugin, který je sám složen z řady volitelných komponent. Protégé se svou stabilitou vyrovná komerčním nástrojům, a díky více než stovce zásuvných modulů (např. pro vizualizaci, tvorbu pravidel ve SWRL, mapování ontologií, validaci, importy/exporty) řeší alespoň jednoduchým způsobem prakticky všechny myslitelné úlohy v rámci ontologického inženýrství. Jednodušší (a tudíž méně časově a paměťově náročný) editor s důrazem na webové adresování a kombinování více ontologií je SWOOP 59, vzniklý na univerzitě v Marylandu. Mezi komerčními nástroji dnes patří k hlavním konkurentům

98 86 V.Svátek, M.Vacura: Ontologické inženýrství TopBraid Composer 60 od firmy TopQuadrant, OntoStudio (nástupce OntoEdit) od firmy Ontoprise 61, a SemanticWorks od firmy Altova 62. Tvorba Topic Maps je podporována zejména nástroji firmy Ontopia 63 jako je OKS (Ontopia Knowledge Suite). 7.2 Další specializované nástroje Vzhledem k obrovskému počtu vývojových týmů, které v oblasti ontologického inženýrství působí, zde můžeme uvést jen velmi stručný výběr. Vzhledem k rostoucímu počtu dostupných ontologií se stále častěji nabízí možnost nevytvářet ontologii na zelené louce, nýbrž využít některou z ontologií již na webu dostupných. Analogicky k nedávné historii webových katalogů vs. vyhledávačů mají za sebou již svůj zenit pasivní knihovny ontologií typu DAML Library 64. Popularitu si získávají indexovací a vyhledávací služby jako je Swoogle 65, případně novější OntoSelect 66 či Watson 67 ; zpravidla umožňují vyhledávat jak ontologie, tak i jimi anotované dokumenty. Zatímco Swoogle svým pojetím silně připomíná vyhledávač Google (s rozšířenou verzí algoritmu PageRank, nazvanou OntoRank), OntoSelect klade důraz na možnost vícejazyčného vyhledávání, a Watson na automatické hodnocení kvality nalezených ontologií a na možnost jejich kombinování. S vyhledáváním ontologií úzce souvisí jejich vzájemné mapování, které je často podmínkou integrovatelnosti nezávisle vzniklých aplikací. Hlavní webový rozcestník pro tuto oblast 68 uvádí více než dvacet nástrojů pro zcela či částečně automatické mapování ontologií; vesměs se ale jedná spíše o experimentální prototypy. Ze specializovaných nástrojů pro učení ontologií z textů je třeba zmínit především Text2Onto 69 a OntoGen 70, v obou případech se jedná o volně šířené nástroje. 8 Nasazení ontologií v praxi Množství aplikací ontologií nasazených dlouhodobě (tj. nejen např. po dobu trvání určitého výzkumného projektu spolufinancovaného EU) v praxi stále výrazně zaostává za objemem teoretického a aplikačního výzkumu. Přesto pozvolna roste zájem komerčních i neziskových organizací, který je asi nejlépe patrný na statistikách prakticky orientovaných konferencí o sémantických technologiích americké Semantic Technology Conference 71 i evropské ESTC firma byla nedávno odkoupena firmou Bouvet

99 Tutoriál 87 Lze říci, že nejlépe si, z hlediska všeobecného přijetí, vedou rozsáhlé doménové ontologie s jednoduchou strukturou a bez ambicí na rozsáhlejší automatické odvozování (např. medicínské či produktové taxonomie), a také poměrně malé ontologie, které jsou však spojeny s velkým objemem dat distribuovaně uložených v rámci sémantického webu (např. FOAF). Jednou z možných průlomových aplikací v prostředí velkých firem je připravované řešení managementu znalostí ve firmě Vodafone 73. Možnosti ontologií pro integraci informací a konkurenční zpravodajství jsou dlouhodobě zkoumány i dalšími telekomunikačními společnostmi. Mezi ně patří France Télécom, který se podílí na testování nástrojů sémantického webu, nebo British Telecom, jehož vývojové centrum přišlo s vlastním nástrojem pro konkurenční zpravodajství využívajícím ontologie Data Foundry [39]. Mezi další místa opakovaného nasazení ontologií patří instituce státní správy, kulturní organizace (např. muzea), mediální agentury, průmyslové podniky (např. automobilky a výrobci letadel), firmy pracující v oblasti lidských zdrojů apod. Topic Maps se uplatňují např. jako základ dynamicky upravovaného informačního portálu norského ministerstva kultury 74. Samostatnou kapitolu by si zasloužily aplikace lingvistických ontologií (např. WordNetu) při zpracování přirozeného jazyka, a tzv. extrakčních ontologií při získávání znalostí z WWW [8]. Obecně je poměrně pomalý nástup ontologií jako běžného technologického řešení do praxe spojen se specifiky znalostních technologií jako takových: formalizované znalosti jsou (na rozdíl od jednoduchých dat) obtížně převoditelné do jednotné podoby, pro jejíž zpracování lze efektivně vyvinout hromadně šířený softwarový nástroj. Každý projekt zahrnující ontologie je proto do značné míry jedinečný a vyžaduje nasazení expertů s předchozími zkušenostmi jak s technologickým řešením tak i s věcnou oblastí. Na druhé straně však mají již vzniklé ontologie, při dodržení některých zásad naznačených i v tomto textu, solidní naději na opakované a dlouhodobé využívání. 9 Závěr Cílem tohoto doprovodného textu k tutoriálu bylo pomoci posluchačům i případným dalším čtenářům zlepšit si orientaci v rozsáhlém světě ontologií, propojit si obvyklou představu o ontologii jako filosofické disciplíně s moderním informatickým pojetím, a získat představu o zdrojích a postupech, které jim mohou být užitečné, pokud by v určité aplikaci potřebovali využít existující ontologii nebo dokonce sami navrhnout ontologii vlastní. 10 Poděkování Autoři by rádi poděkovali kolegům, kteří se podíleli na testování některých nástrojů pro práci s ontologiemi, zejména pak Janu Nemravovi, Ondřejovi Švábovi a Janu

100 88 V.Svátek, M.Vacura: Ontologické inženýrství Zemánkovi. Užitečné jim byly také zkušenosti získané v rámci hostujících přednášek Giancarla Guizzardiho na pracovišti VŠE Praha 75 a spolupráce s partnery v projektech EU K-Space 76 a Knowledge Web 77. Tutoriál je součástí přípravy kurzu Znalosti a ontologické inženýrství v rámci nového magisterského studijního programu Kognitivní informatika na VŠE Praha 78. Literatura 1. Arndt, R., Troncy, R., Hardman, L., Staab, S., Schenk, S., Vacura, M., Nemrava, J., Šváb, O., Bailer, W., Petridis, K., Buitelaar, P.: K-Space Deliverable 4.1. Přístupné online na adrese /KS-D4.1-KU-MultimediaOntologyInfrastructurev1.0.pdf 2. Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D., Patel-Schneider, P. F. (Eds.): The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press Benjamins, R., Casanovas, P., Breuker, J., Gangemi, A. (Eds.): Law and the Semantic Web: Legal Ontologies, Methodologies, Legal Information Retrieval, and Applications. Springer, Borst, P., Benjamins, J., Wielinga, B., Akkermans, H.: An Application of Ontology Construction. In: ECAI'96 Workshop on Ontological Engineering, Budapest, 5-16, Buitelaar, P., Cimiano, P., Magnini, B. (eds.), Ontology Learning and Population, IOS Press, Cimiano, P., Eberhart, A., Hitzler, P., Oberle, D., Staab, S., Studer, R.: The smartweb foundational ontology. SmartWeb Project Report, Decker, S., et al.: The Semantic Web on the respective roles of XML and RDF. IEEE Internet Computing, Embley, D. W., Tao, C., Liddle, S. W.: Automatically extracting ontologically specified data from HTML tables of unknown structure. In: Proc. ER'02, , London, UK, Springer-Verlag. 9. Fernández-López, M., Gómez-Pérez, A., Pazos-Sierra, A., Pazos-Sierra, J.: Building a Chemical Ontology Using METHONTOLOGY and the Ontology Design Environment. IEEE Inteligent Systems & their applications, Gangemi, A.: Ontology Design Patterns for Semantic Web Content. In: Proc. of International Semantic Web Conference Gangemi, A., Pisanelli, D.M., Steve, G.: Some Requirements and Experiences in Engineering Terminological Ontologies over the WWW. In: Proceedings of the 1998 Knowledge Acquisition Workshop KAW Materiály ke kurzu jsou přístupné na webové adrese 76 Viz 77 Viz 78 Viz

101 Tutoriál Gangemi, A. et al.: A Core Ontology of Fishery and its Use in the Fishery Ontology Service Project. In: Proceedings of the EKAW 04 Workshop on Core Ontologies in Ontology Engineering, online Gomez-Perez, A., Fernandez-Lopez, M., Corcho, O.: Ontological Engineering: With Examples from the Areas of Knowledge Management, E-Commerce and the Semantic Web, 2nd edition. Springer, Grau, B. C., Horrocks, I., Parsia, B., Patel-Schneider, P., Sattler, U.: Next Steps for OWL. In Proc. of OWL: Experiences and Directions, available electronically at CEUR, Gruber, T. R.: A Translation Approach to Portable Ontologies. In: Knowledge Acquisition, 5(2), 1993, str Gruber, T. R., Olsen, G. R.: An Ontology for Engineering Mathematics. Principles of Knowledge Representation and Reasoning, Gruninger, M., Fox, M. S.: Methodology for the design and evaluation of ontologies. In Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal, Göckel, R. Lexicon philosophicum. Frankfurt a.m Guarino, N.: Formal Ontology and Information Systems. in: Guarino, N. (ed) Proceedings of FOIS 98, IOS Press, Amsterdam: Trento, Italy, 1998, str Guarino, N., Welty, C.: Evaluating ontological decisions with ONTOCLEAN. Communications of the ACM, 45(2):61--65, February Haarslev, V., Moller, R.: RACER system description. In: Proc. of IJCAR 2001, Heller, B., Herre, H.: Ontological Categories in GOL. Axiomathes 14(1):57-76 Kluwer Academic Publishers, Hennig, W.: Grundzüge einer Theorie der phylogenetischen Systematik. Berlin Lorhard, J. Ogdoas scholastica. St. Gallen Maedche, A.: Ontology Learning for the Semantic Web. Kluwer Academic Publishers, Masolo, C., Borgo, S., Gangemi, A., Guarino, N., Oltramari, A.: Ontology library. WonderWeb Deliverable no.18, Online available from deliverables/d18.shtml. 27. Masolo, C., Borgo, S., Gangemi, A., Guarino, N., Oltramari, A., Schneider, L.: The WonderWeb Library of Foundational Ontologies (WFOL). Technical report, WonderWeb Deliverable no. 17, deliverables/d17.shtml, McCarthy, J.: Circumscription A Form of Nonmonotonic Reasoning. In: Artificial Intelligence, 13, 1980, str Motta, E.: Reusable Components for Knowledge Modelling: Principles and Case Studies in Parametric Design. IOS Press, Amsterdam, 1999.

102 90 V.Svátek, M.Vacura: Ontologické inženýrství 30. Niles, I., Pease, A.: Towards a Standard Upper Ontology. In: Proceedings of the 2nd International Conference on Formal Ontology in Information Systems, Chris Welty and Barry Smith, eds, Ogunquit, Maine, October 17-19, Noy, N., Rector A.: Defining N-ary Relations on the Semantic Web: Use With Individuals. W3C Working Draft 21 July 2004 Latest version: Noy, N., Uschold, M., Welty, C.: Representing Classes As Property Values on the Semantic Web. W3C Working Group Note 5 April Latest version: Oberle, D., Lamparter, S., Grimm, S., Vrandecic, D., Staab, S., Gangemi, A.: Towards Ontologies for Formalizing Modularization and Communication in Large Software Systems. Journal of Applied Ontology, 1(2): , Oltramari, A., Gangemi, A., Guarino, N., Masolo, C.: Restructuring WordNet s top-level: the OntoClean approach. In: Proceedings of OntoLex2002: Workshop on Ontologies and Lexical Resources, Las Palmas, Canary Islans, Øhrstrøm, P., Andersen, J., Schärfe, H.: What Has Happened to Ontology. Conceptual Structures: Common Semantics for Sharing Knowledge 2005, Pan, J. Z.: Description Logics Reasoning Support for Semantic Web. PhD Thesis Reale, G.: Platón. Pokus o novou interpretaci. Praha Rector, A. L. et al.: OWL Pizzas: Practical Experience of Teaching OWL-DL: Common Errors & Common Patterns. Proc. EKAW 2004, Roberts, M., Zancani, L., Enweani, B.: On The Application of Semantic Technologies in Model-Driven Telecommunications OSS Systems. In: Proc. ESTC 07, Vienna, Austria. 40. Romanelli, M., Buitelaar, P., Engel, R., Sonntag, D., Reithinger, N., Loos, B., Porzel, R., Zorn, H.-P., Micelli, V., Schmidt, C., Weiten, M., Burkhardt, F., Zhou, J.: DOLCE ergo SUMO: On foundational and domain models in SWIntO (SmartWeb integrated ontology). Technical report, AIFB, University of Karlsruhe, Schneider, L.: How to Build a Foundational Ontology. The Object-Centered High-level Reference Ontology OCHRE. In: Guenther, A., Kruse, R., Neumann, B. (eds), KI 2003: Advances in Artificial Intelligence. Proceedings of the 26th German Conference on Artificial Intelligence (KI 2003). LNCS Heidelberg: Springer, str Schreiber, G. et al.: Knowledge Engineering and Management The CommonKADS Methodology. MIT Press, Cambridge, Massachusetts; London, England, Sirin, E., Parsia, B., Grau, B. C., Kalyanpur A., Katz, Y.: Pellet: A practical OWL-DL reasoner. Journal of Web Semantics, 5(2), Smith, B.: Ontology and Informations Systems. SUNY at Buffalo Sowa, J. F.: Conceptual Structures: Information Processing. In: Mind and Machine, Addison Wesley, Reading, MA, 1984.

103 Tutoriál Sowa, J. F.: Knowledge Representation. Logical, Philosophical, and Computational Foundations. Brooks Cole Publishing Co., Pacific Grove, CA, Stoilos, G. et al.: Fuzzy OWL: Uncertainty and the Semantic Web. In: Proc. Int'l Workshop OWL: Experiences and Directions, 2005; papers/398.pdf. 48. Strawson, P.F.: Individuals: An Essay in Descriptive Metaphysics, Routledge Stubkjær, E.: Integrating ontologies: Assessing the use of the CyC ontology for cadastral applications. In: Bjørke, J.T. and H. Tveite, (Eds): Proceedings of ScanGIS 2001, Agricultural University of Norway, 2001, str Sunagawa, E., Kozaki, K., Kitamura, Y., Mizoguchi, R.: A Model of Roles in Ontology Development Tool: Hozo. In: Proc. EKAW 2006, Springer-Verlag, LNCS Svátek, V.: Ontologie a WWW. In: Proc. Datakon 2002, D. Chlapek (Ed.), Masarykova univerzita, Brno (2002), Svátek, V.: Design Patterns for Semantic Web Ontologies: Motivation and Discussion. In: 7th Conference on Business Information Systems, Poznaň Tsarkov, D., Horrocks, I.: Efficient reasoning with range and domain constraints. In: Proc. of the 2004 Description Logic Workshop (DL 2004), Annotation: Ontological engineering The tutorial provides an introduction to ontological engineering, including the relationship to traditional ontology and to description logics reasoning. Attention is paid to the available support methods and tools, including structured methodologies, upper-level ontologies, design patterns and ontology learning tools. Practical applications of ontologies are also discussed.

104 Chování uživatelů elektronické pošty Dan CVRČEK 1,2, Kamil MALINKA 1 1 Ústav inteligentních systémů, Vysoké učení technické v Brně Božetěchova 2, Brno {cvrcek,malinka}@fit.vutbr.cz 2 Computer Lab, Cambridge University 15 JJ Thomson Av, CB3 0FD, Cambridge dc352@cl.cam.ac.uk Abstrakt. V tomto článku popíšeme některé výsledky, které jsme získali analýzou záznamů o používání elektronické pošty. Zdrojem dat je SMTP server, který slouží pro uživatele několika fakult Vysokého učení technického v Brně. Tyto záznamy byly anonymizovány, abychom zajistili ochranu osobních dat uživatelů. Takto upravené záznamy jsme použili jako vstupní data pro analýzu chování uživatelů a pro zjištění charakteristik sociálních sítí, které uživatelé vytvářejí. Klíčová slova: chování, SMTP, soukromí, anonymita, sociální síť. 1 Úvod Oblast soukromí při používání elektronických zařízení a zvláště Internetu se stala v poslední době velice zajímavou oblastí výzkumu. Současně je to i obecně velmi populární téma, hlavně v rámci Evropy. David Chaum publikoval první návrh mixu nástroje pro zajištění nespojitelnosti odesilatele a příjemce zpráv v roce 1981 [2]. Jeho původní představa vedla k implementaci anonymitních systémů hlavně v průběhu posledních deseti let [1,3,5,6]. Existence těchto systémů podpořila nejen obecné snahy o zlepšení soukromí uživatelů informačních systémů, ale také odstartovala rozsáhlý výzkum v oblasti měření soukromí a útoků na tyto systémy. Mix je v podstatě router, který se snaží skrýt souvislost mezi svými vstupy a výstupy. Pro dosažení tohoto cíle používají kombinaci různých technik. Každá zpráva je rozdělení zpráv do bloků o stejné velikosti a každý blok je potom přeposílán přes různé množiny mixů. Dále se může např. využít náhodného zpožďování zpráv v mixech. Dle využívaných technik rozeznáváme několik typů mixů: časové mixy, prahové, zásobníkové, nebo kaskádové. Časové mixy při přijetí zprávy vygenerují náhodné zpoždění, o které je příchozí zpráva pozdržena, prahové mixy naopak sbírají bloky na vstupu a teprve při dosažení určitého počtu je naráz přepošlou dál. Zásobníkový mix je pak zobecněním prahového mixu tak, že nejsou mixovány všechny zprávy, ale jen náhodně vybraná podmnožina o určité velikosti. Kaskádové mixy mají dva výstupy a podle vlastností zpráv se rozhoduje na který z nich je zpráva přeposlána. L.Popelínský, O.Výborný (eds.), DATAKON 2007, Brno, , str

105 Vybraný příspěvek 93 V posledních zhruba deseti letech bylo publikováno množství prací zkoumajících vlastnosti mixů a popisující různé útoky. Asi nejdůležitějším typem útoků je analýza provozu. Jeden z prvních článků o analýze provozu (traffic analysis) se objevil v roce 1993 [9]. Jeho autoři si uvědomili problém analýzy provozu v informačním systému a navrhli systém odolný proti některým útokům. Články o analýze provozu se pak začaly pravidelně objevovat od roku V současné době můžeme říci, že jsme schopni velice dobře pochopit a definovat limity anonymitních systémů. V několika článcích byly definovány i výpočetní hranice, které je nutné překonat pro prolomení soukromí a úspěšný útok na anonymitní systémy [4,7,8,10]. Obecně je již dlouho známo, že hlavním problémem všech systémů pro zajištění soukromí je předvídatelné chování uživatelů, které obsahuje opakující se vzory, které jsou pak snadno identifikovatelné proti agregovanému chování ostatních uživatelů, které vypadá jako bílý šum. Tato skutečnost je pak běžně používána pro úspěšné a efektivní útoky na bezpečnostní vlastnosti anonymitních systémů. Mnoho článků zabývajících se útoky na anonymitní systémy ovšem používá několik silných a dosud nedokázaných předpokladů o chování uživatelů. Jedno z takových pravidel např. tvrdí, že 80 procent dat odesílaných uživatelem jde k pouhým 20 procentům potenciálních adresátů, tj. k 20 procentům z osob, které jsou součásti sociální sítě daného uživatele. Zbylých 20 procent dat (např. ů) je pak rozděleno mezi zbylých 80 procent přátel, či známých. Ve skutečnosti ale neexistuje žádná důkladná analýza komunikačního chování reálných uživatelů. A jelikož skutečné chování uživatelů je klíčové pro bezpečnostní vlastnosti anonymitních systémů, je velice obtížné odhadnout soukromí uživatelů v reálných systémech. Hlavním problémem je v současné době nedostatek reálných dat, nad kterými by mohly být nové systémy, příp. modely nových systémů pro zajištění soukromí testovány. Jedinou výjimkou z tohoto pravidla je práce [11], kde jsou publikovány výsledky dat získaných z konkrétního anonymitního systému. Tento článek popisuje analýzu dat, které byly získány ze SMTP serveru a jde tedy o obrázek běžné ové komunikace. Vzhledem k tomu, že daný SMTP server je používán uživateli university, jejichž vzdělání není v oblastí elektroniky ani informačních technologií, tak se domníváme, že zachycené chování odráží relativně dobře běžné uživatele. 2 Základní datová množina Podařilo se nám získat přístup k anonymizovaným záznamům ze SMTP serveru, který zajišťuje odesílání a přijímání dat několika menších fakult Vysokého učení technického v Brně. Předmětem dále popsané analýzy jsou data, která byla zpracována tímto serverem v období zhruba čtyřiceti dnů v létě Jelikož jde o univerzitu, tak je asi korektní říci, že je to období, kdy je aktivita s ohledem na posílání ů mnohem nižší, než během školního roku. Zpracovávaná data jsou podmnožinou většího vzorku, který máme k dispozici a který budeme dále analyzovat. Soubory, se kterými pracujeme mají standardní formát, kdy každý řádek reprezentuje jeden a neobsahují žádné informace o faktickém obsahu u.

106 94 D.Cvrček, K.Malinka: Chování uživatelů elektronické pošty Záznamy byly navíc ještě anonymizovány (adresy, ID ových zpráv), aby nemohlo dojít k žádnému zneužití dat. Každý řádek pak obsahuje následující údaje. MD5 haš ové adresy odesilatele, MD5 haš domény adresy odesilatele (část za zavináčem), MD5 haš ové adresy příjemce, MD5 haš domény z adresy příjemce, přesný čas, odeslání ové zprávy, MD5 haš z message ID, pokud existuje (součást hlavičky u), SpamAssassin scoring pouze zprávy menší, než cca 100 kb jsou hodnoceny, větší zprávy mají hodnotu nastavenou na 0, příznak, jestli obsahoval virus, jestli šlo o spam (kromě SpamAssassin se používají i blacklisty již známých spamů), nebo o regulerní zprávu, velikost u v bajtech. ové adresy byly před aplikováním algoritmu MD5 důkladně zpracovány, aby neobsahovaly zbytečné textové informace, které by zapříčinily duplicitní haše pro fakticky stejné adresy. Příklad záznamu je na následujícím obrázku. 1B2M2Y8AsgTpgAmY7PhCfg chxunh2dwinskhpa6jnsxw kiv5zamuzjbgonwtf7ofzg QyfwyB/TfdE/hGz0DDyBdQ :41:04 5TUrF1P3W48zBGBL1edsoQ ok 9817 Obr. 1: Ukázka záznamu ze souborů, které analyzujeme. Následující analýzy byly provedeny nad zhruba záznamy. Z tohoto množství bylo 4000 označeno jako virus a jako spam. 3 Předmět analýzy Většina analýz byla prováděna nad množinou zpráv, jelikož za normálních okolností by data byla všechna anonymizována a doručena pokud by nebyla zavedena opatření na omezení toku dat. Analýzy, které se týkají chování uživatelů a jejich sociální sítě byly pak prováděny s podmnožinou zpráv, které nebyly označeny jako spam. George Danezis nám dovolil používat své skripty pro analýzy sociálních sítí, takže jsme v některých případech mohli porovnat dvoje nezávisle získané výsledky. Původní získané skripty jsme upravili pro velké datové množiny a rozšířili jsme je o výpočet dalších charakteristik. Při analýzách nás zajímali následující informace: časová zpoždění mezi zprávami jednak základní statistické rozložení intervalů mezi zprávami, ale také agregované informace užitečné pro implementaci mixů, např. počet zpráv v časových oknech o určité velikosti, počet zpráv odeslaných určitým uživatelem zatím můžeme jen odhadovat, jaké budou vlastnosti (z hlediska sociální sítě) pravděpodobného cíle útočníka, jestli někdo, kdo posílá jen několik zpráv za měsíc, nebo pravidelný uživatel

107 Vybraný příspěvek 95 informačního systému; předpokládali jsme, že rozdělení uživatelů z tohoto hlediska může být zajímavé, velikost ových zpráv ovlivňuje zatížení sítě a je dalším důležitým faktorem, který silně ovlivňuje, co je schopen pasivní útočník získat sledováním datových toků v anonymitním systému, sociální sítě toto je jedna z nejzajímavějších oblastí, které lze s dostupnými daty analyzovat. Zajímalo nás např. rozložení příjemců zpráv pro jednotlivé odesílatele, rozsah komunikace uvnitř ových domén (tj. uvnitř fakult), apod. Tyto analýzy byly samozřejmě prováděny jen s podmnožinou dat, která obsahovala zprávy, které nebyly označeny jako spam. Další text obsahuje popis výsledků výše popsaných analýz. Jak jsme již zmínili, tak motivace pro tuto práci pochází z oblasti soukromí a anonymitních systémů. Rádi bychom představili data, která by zlepšila naše porozumnění bezpečnostních (anonymitních) možností anonymitních systémů v reálných aplikacích. Výsledky ale mohou být zajímavé i z hlediska studia sociálních struktur a jejich vlivu na chování uživatelů informačních systémů. 4 Výsledky analýz Začněme výsledkem, který je naprosto nekontroverzní a který jsme naprosto očekávali. Tím je rozložení časových vzdáleností mezi následujícími zprávami. Toto rozložení je na obr. 2 a vytváří na začátku téměř hladkou křivku. Obr. 2: Pravděpodobnost příchodu další zpráv v sekundách. Obr. 3: Rozložení velikosti zpráv (x 1KB). Zajímavé je, že této pravděpodobnostní funkci neodpovídá ani exponenciální, ani Poisson, ani Chi funkce. Ačkoliv je křivka pro prvních několik desítek vteřin téměř ideální, tak z tohoto tvrzení vybočuje hodnota pro interval 7 vteřin. Pokoušeli jsme se zjistit, co je pro tento interval specifické a narazili jsme na zajímavost, že při zpoždění 7 vteřin je větší pravděpodobnost, že obě zprávy byly odeslány ze stejné adresy (viz. tab. 1). Další analýza ukázala, že jde o dobu potřebnou pro přeposlání u SMTP

108 96 D.Cvrček, K.Malinka: Chování uživatelů elektronické pošty serverem a anomálie je dána velkým množstvím zpráv přeposílaných mezi účty administrátorů. Zpoždění (s) P stejný odesilatel Tab.1: Pravděpodobnost zpráv s daným zpožděním od stejného odesílatele. Obr. 3 ukazuje rozdělení zpráv podle velikostí. Pokud bychom chtěli implementovat anonymitní systém, tak se musíme rozhodnout pro velikost anonymizovaných bloků a je třeba zvolit kompromis mezi velkým množstvím bloků a velkým nárůstem zarovnávacích dat. Zdá se, že ideální velikost je blízko 30 kb. Podívejme se nyní na časové rozložení zpráv v čase z hlediska implementace anonymitního systému. Vzhledem k tomu, že existuje mnoho přístupů k definici mixu, tak jsme se rozhodli pro dvě nejzákladnější charakteristiky, které se zdají být z tohoto pohledu nejzajímavější. 4.1 Počet zpráv v časovém okně o konstantní velikosti Tato statistika je důležitá pro implementaci mixů, které zaručují určité maximální zpoždění. Takový mix pak sbírá zprávy jen po určitou dobu a poté provede samotnou anonymizaci (mixování) a všechny je najednou odešle. Následující graf (obr. 4) ukazuje počet zpráv, které byly doručeny na SMTP server v časových oknech o velikosti 10, 20 a 60 minut. Obr. 4: Počet zpráv v časových oknech o velikosti 10, 20 a 60 minut. Obr. 5: Znázornění skutečné anonymity v počet zpráv. Tento graf je zajímavý i z toho hlediska, že opět neodpovídá žádnému z běžně používaných rozložení. Samotný graf pak ukazuje, jak bude kolísat anonymita určitého uživatele při použití mixu za předpokladu, že jeho způsob používání ů (v jakou denní dobu a ve kterých dnech) bude odpovídat chování ostatních uživatelů. Vzhledem k tomu, že mixy obvykle rozkouskují zprávy na bloky o konstantní délce (aby nebylo možné slinkovat přijaté a odeslané zprávy podle délky), tak jsme předchozí graf upravili tak, že dlouhé zprávy jsou nahrazeny několika zprávami o délce 2 kb (což je velmi nízká hodnota viz. začátek sekce). Obr. 5 pak ukazuje

109 Vybraný příspěvek 97 poměr počtu zpráv vůče velikosti anonymitní množiny, tj. kolik jednotlivých uživatelů odesílalo zprávy. Hodnoty jsou v logaritmické stupnici, protože anonymita se často vyjadřuje jako logaritmus velikosti anonymitní množiny. Jak je vidět, tak anonymita klesna téměř o třetinu. 4.2 Délka časového okna pro konstantní počet zpráv Druhým, velmi rozšířeným přístupem k implementaci mixů je tzv. prahová architektura, kdy mix čeká, dokud nedojde k doručení určitého množství ů (bez ohledu na to, jak dlouho to může trvat) a teprve poté dojde k mixování a odeslání nashromážděných zpráv. Následující obrázek (obr. 6 svislé čáry označují půlnoci) ukazuje časové zpoždění zpráv, jestliže je práh nastaven na 128, nebo 1024 zpráv (množství zpráv, které jsou mixovány). Co nás relativně dost překvapilo, jsou velice krátká období během dne, kdy je zpoždění velice nízké (hromadné y?), která jsou následována dlouhým intervalem, kdy je zpoždění na nějaké střední hodnotě. Obr 6: Zpoždění na mixu pro okna 128 a 1024 zpráv. Obr 7: Zpoždění na mixu pro okno 1024 zpráv (reálný čas). Obr 8: Časové zpoždění na mixu v závislosti na denní hodině.

110 98 D.Cvrček, K.Malinka: Chování uživatelů elektronické pošty Z hlediska administrátora systému, který se bude snažit zjistit použitelnost svého mixu, může být zajímavý obdobný graf, kdy osa Y nebude zobrazovat počet zpráv, ale podíl času, kdy bude zajištěna určitá úroveň anonymity (obr. 7). Průměrné hodnoty zpoždění jsou pro okna 128 a 1024 zpráv rovny 880 s a 7090 s (váženo podle počtu zpráv) a 1450 s a s váženo podle času. Ještě jeden zajímavý úhel pohledu může být možná dosažená anonymita v závislosti na čase, příp. dni. Vzhledem k tomu, že analyzovaná datová množina je za období pouhých 40 dnů, tak následující graf (obr. 8) ukazuje potenciální úroveň anonymity v závislosti na denní hodině. 4.3 Pravděpodobnostní rozdělení příjemců zpráv Toto je analýza, která přinesla asi zatím největší překvapení. Již v úvodu jsme zmínili, že obecně platí pravidlo 80/20, kdy čtyři pětiny zpráv jsou doručeny jedné pětině potenciálních příjemců daného uživatele. A takový výsledek jsme obecně předpokládali. K našemu překvapení jsme ale žádnou takovou závislost nezjistili. A dalo nám relativně hodně práce, než jsme vytvořili graf, který se k něčemu takovému začal trochu přibližovat. Obr. 9 ukazuje několik grafů. Rozdíl je v tom, podle jakého klíče jsme vybírali uživatele, které jsme pak použili pro vytvoření pravděpodobnostní funkce. Kritéria, která jsme použili v tomto grafu jsou následující: minimální počet odeslaných zpráv (bez ohledu na počet příjemců), minimální počet příjemců (bez ohledu na počet zpráv). Zkusmo je přidán jeden graf, kdy jsme snížili váhu odesílatelů, kteří produkovali velké množství zpráv. Obr. 9: Rozdělení zpráv mezi možné příjemce. Obr. 10: Počet uživatelů, jež odeslali určitý počet zpráv (log scale). Jak je vidět, tak grafy jsou v podstatě lineární se skoky, které jsou dány uživateli s malým množstvím sousedů počet příjemců je nepřímo úměrný počtu uživatelů s daným počtem příjemců (obr. 10), což má za následek nelinearitu v grafech. U grafu, kde jsme změnili váhu uživatelů, jsme dokázali posunout graf směrem k předpokládané nelinearitě, ale s nepříliš velkým úspěchem. Vizuálním prohlížením vlastnostní jednotlivých uživatelů jsme ale zjistili, že v logu existují uživatelé, kteří by mohli mít předpokládané rozložení příjemců. Trochu problém byl ale je vybrat, nejlepší se ukázalo kritérium poměru počtu zpráv

111 Vybraný příspěvek 99 k počtu různých příjemců. I přes velice pečlivý výběr uživatelů ale pravidlo 80/20 rozhodně není potvrzeno a mohli bychom ho parafrázovat maximálně jako 30/20 79, nebo 70/50. 5 Sociální sítě Tato část si zaslouží další analýzy, jelikož datový soubor nám poskytuje relativně velké množství informací. V tomto textu bychom ale rádi popsali základní vlastnosti sociálních sítí, které jsme ve zdrojových datech identifikovali. Obecně se předpokládá, že sociální sítě je optimální v modelech nahrazovat pomocí takzvaných scale-free sítí. Pro uzly v těchto sítích platí následující jednoduchá rovnice: P(x) x -α Kde x je mohutnost uzlu (daný nějakou metrikou, např. počet sousedů, nebo množství přenášených dat), P(x) je pravděpodobnost výskytu uzlu s danou mohutností a α je parametr. Následující graf (obr. 11) ukazuje, jak vypadají sociální sítě v rámci jednotlivých domén. Zdá se, že sociální síť, která je zde počítána pouze z komunikace uvnitř největší domény (pravděpodobně ekvivalent fakulty) odpovídá scale-free síti s koeficientem α=2.3. Obr. 11: Zobrazení konektivity uvnitř jedné sociální sítě pravděpodobnost výskytu uzlů s určitým počtem sousedů. 6 Závěr V článku jsme poukázali na několik zajímavých vlastností vzhledem k chování uživatelů, kteří používají elektronickou poštu. Na základě předložených dat je možné odhadnout, jak moc se zhorší vlastnosti mixu buď s ohledem na zpoždění, nebo 79 Obdobný graf získaný těsně před dokončením článku z mnohem většího datového souboru posunul nelinearitu ještě trochu dál k 50/20.

112 100 D.Cvrček, K.Malinka: Chování uživatelů elektronické pošty s ohledem na anonymitu jeho uživatelů v závislosti na denní hodině, nebo dni v týdnu. Velice důležitým závěrem, a troufáme si říci, že naprosto neočekávaným je velmi lineární závislost rozdělení zpráv mezi adresáty jednotlivých uživatelů. Jestliže tyto výsledky dále potvrdíme, tak tím znatelně snížíme účinost některých statistických útoků. 7 Poděkování Rádi bychom na tomto místě poděkovali Ivo Hamžukovi, který byl velmi vztřícný k našim prosbám a pomohl nám s prvotním zpracováním dat, které jsme pak použili k popsaným analýzám. Rovněž bychom chtěli poděkovat Georgu Danezisovi, který nám výrazně pomohl vůbec začít analyzovat sociální sítě a který nám poskytl první skripty pro analýzu dat. Tento výzkum byl podpořen Výzkumným záměrem č. MSM , Výzkum informačních technologií z hlediska bezpečnosti. Literatura 1. O. Berthold, H. Federrath, and S. Kopsell. Web MIXes: A System for Anonymous and Unobservable Internet Access. In Workshop on Design Issues in Anonymity and Unobservability, pages , D. Chaum. Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms. Communications of ACM, 24(2):84-88, G. Danezis, R. Dingledine, and Nick Mathewson. Mixminion: Design of a Type III Anonymous R er Protocol. In Proceedings of 2003 Symposium on Security and Privacy, pages IEEE Computer Society, May C. Díaz, S. Seys, Joris Claessens, and Bart Preneel. Towards measuring anonymity. In Proceedings of Privacy Enhancing Technologies Workshop (PET 2002), Springer-Verlag, LNCS 2482, R. Dingledine, N. Mathewson, and P. F. Syverson. Tor: The Second-Generation ONion Router. In USENIX Security Symposium, pages , M. J. Freedman, R. Morris. A Peer-to-Peer Anonymizing Network Layer. In SIGSAC: 9th ACM Conference on Computer and Communications Security. ACM SIGSAC, N. Mathewson and R. Dingledine. Practical Traffic Analysis: Extending and Resisting Statistical Disclosure. In Proceedings of Privacy Enhancing Technologies workshop (PET 2004), LNCS 3424, R. E. Newman, I. S. Moskowitz, P. Syverson, and A. Serjantov. Metrics for Traffic Analysis Prevention. In Proceedings of Privacy Enhancing Technologies workshop (PET 2003), Springer-Verlag, LNCS 2760, C. Rackoff and D. R. Simon. Cryptographic Defense Against Traffic Analysis. In Proceedings of ACM Symposium on Theory of Computing, pages , 1993.

113 Vybraný příspěvek A. Serjantov and G. Danezis. Towards an Information Theoretic Metric for Anonymity. In Proceedings of Privacy Enhancing Technologies Workshop (PET 2002), Springer-Verlag, LNCS 2482, C. Díaz, L. Sassaman, and E. Dewitte: Comparison between two practical mix designs. Computer Security (ESORICS). Samarati et al. (Eds), Springer, LNCS 3193, pp , 2004 Annotation: user behavior This paper describes an empirical analysis of traffic of several faculties of a large university. The goal of the paper is to better understand impact of traffic properties on the effectiveness and efficiency of anonymus mix r ers. The SMTP log records were used as input data for user behaviour analysis and for characterization of social networks created by users. We obtained information from following areas: message arrival times, number of messages sent by individual users, size of messages and social networks.

114 Formálny model pre dolovanie synsetov a jeho využitie Ján GENČI Katedra počítačov a informatiky, Technická univerzita v Košiciach Letná 9, Košice genci@tuke.sk Abstrakt. Projekty Wordnet a EuroWordNet definujúce významy slov a ich vzťahy, sú založené (samozrejme, nielen) na pojme synsetov. Prostredníctvom súboru synoným umožňujú definovať konkrétny význam slova. Následne sú tieto synsety (významy slov) zaradené do sémantickej siete. Príspevok sa pokúša o formalizáciu modelu prekladu významov slov na báze špecifikácie významu synsetu a následné využitie tohto modelu pre vytvorenie synsetov slovenského jazyka či už na báze synsetov projektu WordNet, ale aj na základe použitia bilingválnych on-line prekladových slovníkov. Klíčová slova: WordNet, synset, synonymum, preklad slov. 1 Úvod Wordnet a EuroWordNet sú dva známe projekty, cieľom ktorých je podchytiť sémantiku a vzťahy slov. Kým Wordnet je zameraný iba na angličtinu, ambíciou EuroWordNetu sa stalo spojenie niekoľkých európskych jazykov do jednej sémantickej siete. Z hľadiska používateľa, základom oboch riešení je tzv. synset (set of synonyms, špecifikácia významu slova pomocou synoným). Formálne môžeme povedať, že ide o prienik homonymických významov blízkych slov, výsledkom ktorého je jediný význam skúmaného slova. Práve význam slova zohráva kľúčovú úlohu v uvedených projektoch. Z rôznych dôvodov nie všetky európske jazyky mohli byť zapojené do projektu EuroWordNet. Z druhej strany, výsledky projektu vzbudili záujem o dodatočné pripojenie ďalších jazykov. Práve v takejto situácii sa nachádza aj slovenčina. Vzhľadom na to, že prakticky pre všetky jazyky existujú také lingvistické nástroje ako sú napr. synonymické slovníky, prekladové slovníky, základné kodifikačné slovníky a pod., je našim cieľom využiť ich na prípadne doplnenie, alebo aspoň čiastočné zautomatizovanie prípravy podkladov pre následnú manuálnu kontrolu slovenských synsetov vo väzbe na synsety projektu WordNet alebo EuroWordNet. L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

115 Vybraný příspěvek Formálny model prekladu synsetov Preklad slov medzi jazykmi musí byť založený na významoch slov. Pre lepšie pochopenie procesu prekladu, pokúsime sa preň navrhnúť formálny model. Def. Nech W i je slovo, vyjadrujúce význam V. Synset S (set of synonyms) je množina slov, vyjadrujúca význam V. Formálne: kde n počet členov synsetu. S={W i 0<i<n}, Def. Nech V i je význam, vyjadrený slovom W. Homset H (set of homonyms) je množina všetkých významov, vyjadrovaných slovom W. Formálne: kde n je počet významov. H={V i 0<i<n}, Uvažujme slovo W. Vo všeobecnosti, slovo W môže mať niekoľko významov, t.j. je prvkom homset-u H, s r členmi. Každý z významov homsetu H, môže byť vyjadrený samostatným synsetom S i (1 i r) (Obr. 5). S = { w, w, K, W, K, w } s1 S = { w, w, K, W, K, w } s2 K S = { w, w, K, W, K, w } r r1 r 2 rs r Obr. 5. Synsety homonymických radov Príklad Aby sme ilustrovali uvedený prístup, použijeme on-line verziu projektu WordNet [6]. Uvažujme napr. slovo accident. Výsledok vyhľadávania v systéme WordNet je na Obr. 6. Môžeme vidieť, že homset slova accident má dva prvky (t.j. slovo accident, podľa WordNet-u, má dva významy): 1. an unfortunate mishap; especially one causing damage or injury 2. anything that happens suddenly or by chance without an apparent cause Prvý význam je jednoprvkový synset, druhý je synset, pozostávajúci z niekoľkých slov (accident, stroke, fortuity, chance event). L L1 Def. Označme 2 Sémanticky, preklad 2 T ( W ) operáciu prekladu slova W z jazyka L 1 do jazyka L 2. T ( W ), môžeme vyjadriť schémou podľa Obr. 7 L L1

116 104 J. Genči: Formálny model pre dolovanie synsetov a jeho využitie Obr. 6. Výsledok vyhľadávania v databáze WordNet pre slovo accident S = { w, w, K, W, K, w } V S = { w, w, K, w, K, w } L1 L1 L1 L1 L1 L2 L2 L2 L2 L s i 1t1 S = { w, w, K, W, K, w } V S = { w, w, K, w, K, w } L1 L1 L1 L1 L1 L2 L2 L2 L2 L s i 2t2 K L2 L2 S = { w, w, K, W, K, w } V S = { w, w, K, w, K, w } L1 L1 L1 L1 L1 L2 L2 L2 r r1 r 2 rsr r r r1 r 2 L L1 Výsledok operácie 2 Obr. 7 Sémantika prekladu slova W L2 L2 L2 T ( W ) teda môžeme vyjadriť ako { S1, S2, K, S r } 1 Je zrejmé, že slovo W je súčasťou každého synsetu, čo vyplýva z množiny jeho prekladaných významov. Každý význam, reprezentovaný synset-om v zdrojovom jazyku je preložený do cieľového jazyka ako množina slov - synset, reprezentujúci prekladaný význam v cieľovom jazyku. Využitím dvojcestného prekladu (tam a späť) pre zadané slovo W, zrekonštruujeme jednotlivé synset(y) s použitím prekladového slovníka na základe nasledujúceho algoritmu: L L1 1. get 2 L2 L2 L2 T ( W ) = { S1, S2, K, S r } S L i 2. for each 2 w S L i a. for each 2 S L1 R ( ) i TL w 2 i L i b. 1 i L1 L1 L1 = = K // get back translation t i =I k = 1 R k 1 2 S L i { S, S,, S q } ri rt r

117 Vybraný příspěvek 105 Takýmto spôsobom sme schopní zrekonštruovať korešpondujúce si synsety v oboch jazykoch. 3 Applikácia modelu na reálne prekladové slovniky Prezentovaný model reprezentuje ideálny stav, založený na predpoklade úplných a jednoznačných synsetov a úplných a symetrických prekladových slovníkov. V skutočnosti, existuje veľa obmedzení, brániacich priamočiarej aplikácii vyššie uvedeného prístupu: špecifikované synsety nepredstavujú presné vyjadrenie významu (ako sa zvyčajne uvádza v synonymických slovníkoch uvedené synonymá reprezentujú blízke významy); v prekladových slovníkoch prakticky nikdy nie sú uvádzané kompletné synsety; rôzny pohľad jednotlivých zostavovateľov (autorov) slovníkov na synsety a homsety autori prezentujú v slovníkoch rôzne podmnožiny významov a tieto významy sú prekladané do rôznych synsetov; prekladové slovníky pre význam slova zvyčajne nešpecifikujú úplné synsety a taktiež neuvádzajú všetky významy slova; obojsmerné slovníky (zvlášť tlačené verzie) nie sú symetrické nemôžeme w L w 1 2 si byť istí, že pre preklad nájdeme v slovníku spätný preklad L2 L1 w w. mnoho on-line prekladových slovníkov nešpecifikuje synsety, ale len súbor slov, ktoré sú prekladom zadaného slova. To vedie k tomu, že nie je možné priamo určiť počet významov slova. Na základe uvedených obmedzení je potrebné podstatným spôsobom modifikovať pôvodne prezentovaný prístup. Avšak, základná myšlienka ohľadom homset-ov a synset-ov a prekladového modelu ostáva zachovaná. V súčasnosti uvažujeme o troch prístupoch na určenie (zrekonštruovanie) synsetov: 1. využitie synsetov z databázy WordNet na určenie korešpondujúcich synsetov v inom (nie anglickom) jazyku; 2. využitie bilingválnych on-line prekladových slovníkov; 3. využitie synonymických slovníkov ako zdroja synsetov; V krátkosti rozoberieme prvé dva prípady na príklade slovenského jazyka, tretí len naznačíme. 3.1 Využitie databázy WordNet Ako už bolo spomenuté v úvode, projekt WordNet definuje významy slov prostredníctvom synsetov a okrem toho špecifikuje vzťahy medzi slovami slová majú definované väzby na slová so všeobecnejším (hypernymá) a taktiež špecifickejším významom (hyponymá). L

118 106 J. Genči: Formálny model pre dolovanie synsetov a jeho využitie Na určenie synsetov cieľového jazyka (v tomto prípade slovenského), používame dva prístupy: 4. prienik prekladov jednotlivých prvkov synsetu z databázy WordNet 5. preklad príbuzných slov v sieti WordNet (všeobecnejšie a špecifickejšie) Prvý prípad využijeme vtedy, ak zadané anglické slovo má v databáze WordNet definovaný viacprvkový synset. Druhý prístup je použitý v prípade jednoprvkového synsetu. V tomto prípade sa výsledok formuje ako prienik prekladov priamych hyperným a hyponým. Ilustrujme si uvedený prístup na príklade slova computer. Podľa WordNet-u, toto slovo má dva významy vo funkcii podstatných mien: 6. computer, computing machine, computing device, data processor, electronic computer, information processing system (a machine for performing calculations automatically); 7. calculator, reckoner, figurer, estimator, computer (an expert at calculation (or at operating calculating machines)); Výsledok formovania slovenského synsetu je uvedený na Obr. 8. Obr. 8. Formovanie slovenských synsetov Aplikáciou uvedeného prístupu na viacero cieľových jazykov je možné vo väzbe na anglické synsety vytvárať rady ekvivalentných synsetov vo viacerých jazykoch Obr Využitie on-line prekladových slovníkov Klasické prekladové slovníky pre zadané slovo špecifikujú synonymické rady pre jeho významy. Z praktických dôvodov, ako už bolo spomenuté, významy a im prislúchajúce synsety nie sú úplné. Ich rozsah závisí od veľkosti a kvality slovníka. Špecifikované synsety (aj keď neúplné), podobne ako pri využití WordNet-u, sa však môžu stať základom pre sformovanie synsetov v zdrojovom jazyku. Problémom však je ich dostupnosť v elektronickej podobe.

119 Vybraný příspěvek 107 Obr. 9 Multijazyčný rad synsetov Na rozdiel od klasických, tlačených, slovníkov, elektronické verzie slovníkov zvyčajne nerešpektujú zaužívané členenie hesiel na synsety podľa homsetov. Napr. z prvých desiatich odkazov, linky na ktoré poskytne Google pre vyhľadávanie podľa podmienky slovnik site:sk, iba jeden slovník ([2]) vráti výsledky v zaužívanom slovníkovom členení. Ostatné slovníky, vrátane ich rôznych verzií pre rozdielne jazyky, ako preklad poskytujú len súbor rôznych prekladov daného slova. Ukazuje sa však, že aj takýto prístup, s využitím priameho a spätného prekladu môže priniesť určité výsledky. Pokúsime sa tento prístup ilustrovať na príklade. Uvažujme slovenské slovo jednotka. Prekladom tohto slova do angličtiny slovníkom [3] a následné spätné preloženie anglických prekladov do slovenčiny získame preklady podľa Tab. 2 (vo výsledku sú z prekladu eliminované všetky slovné druhy okrem podstatných mien). Vzájomným prienikom spätných prekladov (s vylúčením pôvodného slova jednotka), získame výsledky podľa Tab. 3. Doplnením pôvodného slova jednotka, získame výsledok podľa Tab. 4. Len pre zaujímavosť - v Tab. 4 vidíme, že anglické slovo unit je obsiahnuté vo všetkých nájdených synsetoch, okrem posledného. Doplnili sme v nej teda stĺpec, ktorým sme sa pokúsili namapovať jednotlivé synsety (1-4) na synsety slova unit podľa WordNet-u. Zaujímavý je možno 2. synset, ktorý by podľa slovenského významu zrejme bolo možné namapovať na 3. synset tabuľky Tab. 5. Anglický synset však zrejme indikuje iný význam, ktorý vo WordNete nie je podchytený. Otvorenou ostáva aj otázka zjednotenia 3. a 5. synsetu. V oboch prípadoch sa však dostávame na tenký ľad hlbšej lingvistickej analýzy, ktorú autor prenechá radšej profesionálom - lingvistom.

120 108 J. Genči: Formálny model pre dolovanie synsetov a jeho využitie Preklad do angličtiny drive element entity force handler item scaler timer unit unity Spätný preklad do slovenčiny jazda, pohon, nápor, vychádzka, cesta, vozovka, budenie, jednotka, mechanika, zariadenie, podnikavosť, motivácia, prevod, nábor, riadenie, výjazd člen, častica, živel, súčiastka, časť, článok, prvok, element, jednotka, zložka podstata, jednotka, celok, bytosť, bytie, teleso, objekt, entita, existencia, predmet sila, úsilie, vplyv, moc, vodopád, tlak, tiaž, zbor, oddiel, jednotka, platnosť, účinnosť, pôsobnosť, násilie, donútenie, zmysel, tvárnik, zasahovanie, zásah, útvar zariadenie, jednotka, manažér poznámka, prvok, bod, vec, jednotka, článok, odstavec, číslo, položka, člen, slovo, rovnako, detail, zápis, odsek reduktor, čítač časovač, rozdeľovač, krokovač, hodiny, jednotka, čas jednotka, celok, oddiel, útvar, jednička, jedna, zväz, diel, agregát, stroj, prístroj, zariadenie, lístok, ročník, kurz, terminál, kus, skupina, zložka, blok, člen, spojenie zhoda, súdržnosť, zomknutosť, jednotka, jednota Tab. 2 Priamy a spätný preklad slova jednotka P.č. Prienik podľa slovenského slova (príp. kombinácie) Anglické slová, obsahujúce uvedené slovenské slová 1. celok entity, unit 2. zariadenie handler, drive, unit 3. člen element, item, unit 4. útvar, oddiel force, unit 5. prvok, článok element, item Tab. 3 Výsledok prieniku spätných slovenských prekladov P.č. Slovenský synset Anglický synset Význam podľa Tab jednotka, celok entity, unit 4,6 2. jednotka, zariadenie handler, drive, unit - 3. jednotka, člen element, item, unit 5 4. jednotka, útvar, oddiel force, unit 3 5. jednotka, prvok, článok element, item X Tab. 4 Priradenie slovenských a anglických synsetov

121 Vybraný příspěvek 109 P.č. Synset Význam 1. unit of measurement, unit any division of quantity accepted as a standard of measurement or exchange 2. unit an individual or group or structure or other entity regarded as a structural or functional constituent of a whole 3. unit, social unit an organization regarded as part of a larger social group 4. unit a single undivided whole 5. unit, building block a single undivided natural thing occurring in the composition of something else 6. whole, unit an assemblage of parts that is regarded as a single entity Tab. 5 Synsety a významy slova unit 3.3 Využitie synonymických slovníkov ako zdroja synsetov Synonymické slovníky predstavujú prirodzený zdroj synsetov pre zdrojový jazyk. V zjednodušenej forme sa jedná o riešenie, popísané v časti 3.1. Využitím prekladov jednotlivých prvkov synsetu a následným prienikom výsledkov (podobne, ako to bolo písané v časti 3.2), môžeme dospieť k relevatnému synsetu v cieľovom jazyku. Z priestorových dôvodov tento prístup nebudeme detailnejšie popisovať. 4 Záver Prezentované riešenia predstavujú štúdiu uskutočniteľnosti prezentovaných prístupov. Prístup opísaný v časti 3.1 bol praktický overený v prácach [1] a [4] a prístup opísaný v časti 3.2 bol overený v práci [5]. Hlavným problémom pri overovaní prezentovaných prístupov boli on-line prekladové slovníky. Medzi doteraz nespomenuté problémy patrí aj to, že väčšina dostupných bilingválnych slovníkov pre slovenský jazyk pochádza z jedného zdroja. Naše doterajšie skúsenosti nás utvrdzujú v tom, že najúčinnejším prístupom pravdepodobne bude kombinácia prístupov špecifikovaných v príspevku, prípadne ich rozšírenie o ďalšie prístupy. Nakoniec nedá neuviesť, že táto práca nás priviedla k presvedčeniu, že nová generácia on-line prekladových slovníkov by mala byť založená na prekladoch podľa významu špecifikovaného už v zdrojovom jazyku, teda na synsetoch zdrojového jazyka špecifikujúcich význam prekladaného slova. Literatura 1. Lapoš P.: Overenie budovania EuroWordNet synsetov na báze on-line slovníkov. Diplomová práca KPI FEI TU Košice

122 110 J. Genči: Formálny model pre dolovanie synsetov a jeho využitie 2. Online Dictionary. Slovensko-maďarský slovník 3. Prekladový slovník FEEHA Sudynova M.: Rozšírenie práce Overenie budovania EuroWordNet synsetov na báze on-line slovníkov o ďalšie slovníky. Semestrálny projekt. Interná správa KPI FEI TU Košice Sudynová M.: Nástroj na generovanie slovníkových záznamov. Diplomová práca KPI FEI TU Košice WordNet - a lexical database for the English language. Annotation: Formal model for synsets mining and its application. Paper presents formal model of translation dictionaries based on word senses (homonyms) each expressed by set of synonyms (synsets). Drawbacks of model regarding real on-line translation dictionaries are specified. Through application of the model we present two approaches how to build bilingual (or even multilingual) corresponding synsets. The first one is based on translation of WordNet synsets, second one is based on two way (forth and back) translation of given word. Third approach, based on translation of data from thesaurus, is mentioned.

123 Web Search with Variable User Model P. GURSKÝ 1, T. HORVÁTH 1, J. JIRÁSEK 1, S. KRAJČI 1, R. NOVOTNÝ 1, V. VANEKOVÁ 1, P. VOJTÁŠ 2 1 P.J. Šafárik University {peter.gursky, tomas.horvath, jozef.jirasek, stanislav.krajci, robert.novotny, veronika.vanekova}@upjs.sk 2 Charles University, Czech Academy of Science peter.vojtas@mff.cuni.cz Abstrakt. We propose a middleware system for web search adaptable to user preference querying as well as user independent fulltext search. We cover also induction of user preferences and effective query answering. A prototype of a new annotation tool is described. The system employs a formal model of user preferences based on fuzzy logic. Experimental implementation of this system integrates several independent software tools. Klíčová slova: user model, annotation, induction, top-k search, fuzzy DL 5 Introduction and Motivation To make web accessible for automatic processing, we need systems which understand the whole process from wrapping and annotating page, up to the user querying. We present a model of a middleware system permitting users to search objects of one domain but from heterogeneous sources. This system consists of several integrated software tools. It supports different approaches to solve the main task of such a system return to user the best objects relative to his/her preferences. The schema of parts of the system is depicted in Figure 1. We exclude a web source download part which is not integrated in our system so far (in experiments we use either manually downloaded pages or simply wrapped pages). Before we start searching for the best objects, we need to unify the information from heterogeneous sources to one common format. We use a domain ontology [14], i.e. a database of objects and attribute values in OWL format. Common HTML pages and also data structured sources can be converted to instances of domain ontology by semantic annotation (OMIN tool described in chapter 2.1). If the domain ontology is filled with necessary data, the system can answer user queries. We combine two different approaches where query answering can be user dependent or user independent. The user independent part is based on tf-idf vector model of fulltext search with indexes stored in a database (JDBSearch tool). This tool is further described in chapter 2.2. It works with plain text, not the domain ontology. The same key word L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

124 112 P. Gurský a kol.: Web Search with Variable User Model query will lead to the same answer for any user. This part of the system can be also used to find objects similar to some concrete suitable object. In the user dependent approach (detailed in chapter 2.3), the same query can produce different answers for different users. Our user dependent model (chapter 2.3.3) is based on modeling preferences by fuzzy sets and fuzzy logic, arising from [17]. We propose a model which integrates user preference components on all layers of the system (both inductive and deductive/querying tasks). fulltext query JDBSearch Fulltext Search display JDBSearch Similar Objects display indices retrieval find rules display Object Display and Evalutaion object evaluation User user preference Learning global preferences (IGAP) Suitable Object Search (Top k) user profile objects annotated object instances Annotation Process (OMIN) Filesystem (Text, HTML, CSS) SQL database crawled HTML pages RDF repository Indices Fig. 1 Data flow schema Data Repository Let us consider the following example: Imagine a user looking for a hotel which has good price, good distance from an airport and has good equipment in rooms. Concepts like good price are naturally vague and imprecise, they can be different for every user. For instance one user prefers cheap hotels (student), second prefers expensive hotels (manager) and the other one prefers middle price (professor). The natural meaning of this ordering is that the user determines the relations better or worse between two values of given property. For each such property, user has a notion about the ordering of objects based on real value of property from an attribute domain. We call these orderings of particular attribute domains the user local preferences (see chapter 2.3.1).

125 Vybraný příspěvek 113 Local preferences are not enough to say for any two objects which one is better than the other. We often find two hotels, one of which has better price and another has better equipment. We need to combine the values of objects obtained by user local preferences in some way. This feature is modeled e.g. in multicriterial decision making. The combination of user local preferences that leads to overall values of objects for a concrete user, is called global preference (see chapter 2.3.2). It can be represented as a set of IF-THEN rules or weighted average. Having both local and global preferences, we face the deductive task of effective retrieval of top-k answers (the Top-k tool is described in chapter 2.3.5). Searching of suitable objects for user, based on local and global preferences, is the typical user dependent query answering. Preferences can be obtained in several ways. Our intelligent user profile incorporates various operating modes. First, when a new user wants to find suitable objects, we give him/her a set of objects, representative samples, and their properties (i.e., in our example some hotels with their attributes). Object evaluation part evokes learning user fuzzy aggregation function (IGAP tool). Using this aggregation and query optimization (Top-k tool) we retrieve the answer. This cycle of object evaluation, aggregation learning and top-k objects finding can be repeated several times. The display and evaluation part is able to couple text search with evaluate- IGAP-Top-k part. 6 Models, Methods and Tools In this chapter we describe models, methods and tools which drive the information from the web to the user. 6.1 OMIN An Annotation Tool Semantic annotation represents a specific sort of metadata extracted from documents or web sources. In the later, we distinguish between web sources which are dominantly text oriented, sources with richer structure (e.g. tables) and sources with dominantly visual information (Flash-based content). There are many approaches to semantic annotation. Generally it is possible to reuse existing systems, such as Lixto ([1, 13]). However, we have done some independent preliminary explorations in this topic. The first method is based on the proposition that many web pages representing detailed product information (for example detailed information about particular hotel) are generated from the web template engines. Therefore the HTML sources of two pages, which have been generated from the same template, are very similar. We have observed that the differences between sources usually fall into following categories: either they are differences in the element structure, i.e. one page contains a HTML subtree not appearing in the other page. An example of this is a hotel with more information provided (additional properties or extended data). The other category encompasses the differences in HTML attributes. However, these attributes usually contain irrelevant data, typically styling information, element identifiers, or hyperlinks. The last category contains the differences in the HTML node values, which can be considered as the possible candidates for the extraction. Providing the sufficient number of

126 114 P. Gurský a kol.: Web Search with Variable User Model different pages which were generated from one template can minimize number of mismatches (e. g. differences which do not correspond to the attribute values) and maximize the number of matches (since potential candidates will be discovered only in the differences). The Figure 2 shows an example of differences. The areas in red rectangles represent the differences in contents of corresponding HTML elements (since we have used a classical diff algorithm, red-highlighting denotes the exact positions of differences). Fig. 2 Differences and corresponding HTML areas However, after the discovery of potential candidates it is necessary to map these values to the corresponding attributes. In this case, one solution could be mapping of attributes to regular expressions which describe the possible values of a given attribute. Another proposal is to find nearest HTML elements and try to utilize their visual presentational form e. g. CSS or HTML formatting instructions, since it is more probable that the attribute labels will be presented in the emphasized form be it a bolder text or different forward or background color. Such visually important elements can stand out as potential candidates for attribute values. This technique can be used also to improve the efficiency of potential candidate discovery (even in cases when there are no explicit attribute labels). It could be seen that both price and hotel name is visually emphasized (this is achieved by CSS rules) and therefore potentially more important than the other differences occurring in the document. Human only readable sources, like flash animations, represent information that cannot be retrieved directly from the web page source. We plan to solve this problem by OCR processing. 6.2 Text-based Approach In user independent querying we use well known vector model [2,6]. The adopted vector model requires defining a number of fundamental notions. In this model, a document is defined as a vector in m-dimensional vector space (m denotes the number of unique terms in the text of all documents). This vector is comprised of the weights of the document terms.

127 Vybraný příspěvek 115 The weight of each of these elements can be calculated by using the inversion document frequency formula idf j and tf ij the number of occurrences of the term t j in the i-th document as w ij = tf ij. idf j (1) To start indexing source documents, it is usually needed to remove all metainformation hidden to user (HTML tags). Having plain text sources we can create tfidf index. Our implementation of the index is based on the relational database as in [11, 12]. This method has multiple advantages: well-known and well-defined structure (based on the database tables) and the relatively high-speed of current relational databases. The matching of the question on the document collection can be ordered by cosine measure. We can map each of the query types on a particular SQL query. Executing this query against the database can give us the sorted resulting list of documents, including their relevancy. We can easily use this index also to retrieve similar documents when we put on the input not only few words but whole document. This feature underbid an easy way (by one click) to find more good objects based on a single one object. 6.3 User-dependent Search In the user-dependent search different users can obtain different answers for the same question. Searching is based on user preferences that can be created during current and previous sessions as well. Detecting Local Preferences To learn local preferences, we give to user a representative sample of hotels (see table 1) with several attributes. The attributes in our example are: distance from the city center, price of the accommodation and equipment of rooms (without equipments, TV, internet or both). The user classifies every hotel into one of the three classes (categories): poor, good and excellent according to the relevance of the hotel to him. In real world we use 7 classes of Likert scale. Hotel distance price equipment Evaluation Apple 100 m 99 $ none poor Danube 1300 m 120 $ TV good Cherry 500 m 99 $ internet good Iris 1100 m 35 $ internet, TV excellent Lemon 500 m 149 $ none poor Linden 1200 m 60 $ internet, TV excellent Oak 500 m 149 $ internet, TV good Tab. 1. Representative sample of hotels evaluated by the user The local preferences can be detected in several ways. In this chapter we discuss statistical models. Note that equipment is a text attribute so it needs no ordering detection. We focus on distance and price. The task is to find attribute domain ordering which makes user object evaluation monotone according to this ordering. The first model of ordering detection (local

128 116 P. Gurský a kol.: Web Search with Variable User Model preferences) is QUIN [3] a system of qualitative data mining which discovers trends in data. USER's ordering of distance USER's ordering of price 1 1 Quality Quality distance price Fig. 3. Local preference ordering The final result is obtained by combination of several statistical methods (see Figure 3) and shows that the price has negative influence and the distance has positive influence on the user evaluation/ranking. In other words, the user classification decreases with increasing price of a hotel and it increases with increasing the distance of a hotel from an airport. Learning Global Preferences We learn user s global preferences by the method of Ordinal Classification with Monotonicity Constraints described in [9,10]. The IGAP tool is based on Inductive Logic Programming ILP system ALEPH [15], the well-known relational data mining model [4]. In the learning process we compute the user s global preferences with help of his/her local preferences. We use ILP because our local preferences (orderings) can be represented well in this framework by definite clauses. For illustration, consider that we have discretized values of distance to three classes: near, middle and far. The different orderings of these classes for different users can be: near middle far (non-decreasing) near far middle far middle near (non-increasing) far near middle middle near far (the middle values are better than near or far) middle far near A usual aggregation function can be easily simulated by monotone classification rules in the sense of many valued logic. The results of our approach (the user s global preferences) computed from the data in our illustrative example are the following classification rules about the relevance of hotels to user preferences: evaluation = excellent IF distance 500 AND price 99 AND services = {TV, internet} evaluation = good IF (distance 500 AND services = {TV}) evaluation = good IF (price 99 AND services = {internet}) From our results we can obtain also additional information about crisp attributes (equipment) The meaning of any classification rule is as follows: If the attributes of an object x fulfill the expressions on the right side of the rule (body) then the overall value of x is at least the same as on the left side of the rule (head). We can, of course, assign the explicit values to vague concepts like excellent or good. During the simulation of aggregation function computing, we can simply test the validity of requirements of the rules from the strongest rule to weaker ones. When we find the

129 Vybraný příspěvek 117 rule that holds, we can say that the overall value of the object is the value on the left side of the rule. The rules are sorted, therefore we always rank the object with the highest possible value. We can see that the ordered meaning of the classification is preserved in our results: hotels classified in the grade excellent by the user also fulfills requirements for good and poor hotels, and good hotels fulfills requirements for poor ones (e.g. the hotel with 800 m distance from airport and 45$ price equipped with internet and TV is at least as appropriate as the hotel 300 m far from the airport and 40$ price equipped just with internet) according to the local preferences (farther and cheaper is better). Model of User Preference Ontology As we have seen in the previous chapters, it is possible to learn user local preferences from the evaluation of a sample set of objects. Objects (hotels) are resources from domain ontology and therefore it is convenient to store user preferences in a separate ontology. User preference ontology is created from domain ontology. For example if we are interested in hotel prices with descending ordering, we name this instance of user local preference cheap because the ordering returns cheap hotels first. For the same property and ascending ordering, we name the instance expensive. Many users can share the same local preference, for instance users that prefer cheap hotels or hotels with internet. Different combinations of local preferences yield some typical user types. An example of such user type can be user preferring cheap hotels with internet, far from the airport. The user preference ontology contains finite number of orderings and therefore also finite number of user types. But even users from the same type can have different global preference. By applying the global preference (monotone aggregation function) on these values we compute the relevance of every hotel to user as in [5]. This function can be unique for every user, but very often similar for similar user types. Fuzzy RDF Based on Fuzzy Description Logic In this chapter we analyze the model of fuzzy RDF/OWL based on fuzzy description logic. The terms like cheap, expensive or near represent fuzzy sets as in [17]. Our model of fuzzy RDF includes such fuzzy sets stored as RDF triples. We get RDF triples <hotel_id, ordering_type, relevance> where hotel_id comes from the domain ontology and ordering_type from user preference ontology. Relevance is RDF literal with a number from [0, 1]. We will use fuzzy RDF as middle level in the process of retrieving best objects from domain ontology. Let cheap U be a local preference of user U for hotel price defined by nonincreasing membership function: (max x currency) cheap U ( x) = (max min) The following RDF triples are created for hotels Apple and Danube from Table 1 and ordering type cheap. We get the relevance via the function from cheap as follows: cheap U ( 99 $) = =

130 118 P. Gurský a kol.: Web Search with Variable User Model cheap U ( 120 $) = = The value of currency is the exchange rate which is equal to 1 for given prices in US dollars. The values of max and min are maximal and minimal price values from Table 1, i.e. 149 and 35. We use the evaluations to create following RDF triples: <Apple, cheap U, 0.44> <Danube, cheap U, 0.25> One important feature of our model is that we can prepare fuzzy RDF independently from user global preference. This is because we can adapt to user by adjusting his aggregation This makes the processing of data more effective, because we do not need to order data for every user query. We already have the data pre-ordered and we just combine the relevancies from fuzzy RDF into one result. Example. We have developed also a formal model of fuzzy description logic f-el as the motivation for creating a model for fuzzy RDF. We describe it by an example. It consists of: Crisp properties N R = {price, distance_from_airport} where price and distance_from_airport are RDF predicates from domain ontology. Fuzzy concepts N C = {cheap U, close U } where cheap U and close U are fuzzy functions explicitly figured by user preference ontology. Instances N I = {Apple, Danube, 99, 120, } In Herbrand-like interpretation H we have: Apple H = Apple, Danube H = Danube, 99 H = 99, 120 H = 120 cheap H U (99) = 0.44, cheap H U (120) = 0.25 price H ={(Apple, 99), (Danube, 120)} For simplification we overload our concept cheap U also for hotels (usually we must create new concepts in this case e.g. cheap_hotel U ): cheap H U (x) = ( price.cheap) H (x) then cheap H U (Apple) = sup{cheap H U (y): (Apple,y) price H }=0.44 cheap H U (Danube)=sup{cheap H U (y): (Danube,y) price H }=0.25 The supremum affects the case when we have more different prices for one hotel. Then we take the biggest result. Let aggregation function for an user U U, close U ) = (3 close U + 2 cheap U )/5. If the value of close H U (Apple) is 0.33, then the overall relevance of hotel Apple will be: (@(cheap U, close U )) H (Apple) (cheap H U (Apple), close H U (Apple)) = (3 close U H (Apple) + 2 cheap H U (Apple))/5 = ( )/5 = Consider the type of user preferring cheap hotels. There can be many users that prefer cheap hotels. We want to share the same instance cheap U for them. However, their notion of cheapness can be slightly different. For example one user can say that cheap hotels have price lower than $30, while for some other user cheap hotel ends at $50. We can easily adjust the overall evaluation of objects to reflect these individual requirements (for details see [8]).

131 Vybraný příspěvek 119 Relevant Object Search Now we have orderings of properties from learning of local preferences, rules from learning of global preferences and prepared ordered data stored in fuzzy RDF. Our last task is to find top k objects to user. We use the extension of middleware search of Ronald Fagin [5]. The main idea is to browse only necessary data until the system is sure that it has top-k objects already. Thus we do not need to calculate with whole data from domain ontology. Retrieving only k best objects can save time and is usually sufficient for user. Saving of time grows with the number of objects stored in domain otology and also with the number of properties we consider. The model in [5] considers two kinds of accesses to the ordered properties stored in possibly distributed lists: sorted and random access. The sorted access gets the next best object from the list after each access, so we can retrieve data ordered from the best to the worst. The random access asks for the value of a particular property it includes for a concrete object. Each random access requires searching of the value of concrete object. In the case of sorted access the results are prepared immediately (values can be preordered, in fuzzy RDF in our case, to the several orderings before user comes) and, moreover, data can be sent in blocks. Because of this feature in our system we prefer mainly the algorithms, which use only sorted access. In our application we use 3P-NRA (3 Phased No Random Access) algorithm, which is an improvement of NRA [5] algorithm (see also [7]). As we found in our experiments (with our top-k tool), using the techniques of topk search can significantly save number of needed accesses and accordingly the time needed especially in huge sets of objects. 7 Conclusions In this paper we have described a model of system enabling users to search objects from the same domain and heterogeneous sources. Data are collected from various sources are processed to vector index and to a domain ontology. The system implements both user independent search and personalized search for users with different preferences. Our theoretical model integrates all parts of the system from collected data in classical RDF form to the user query answering. We do not have a model for web resource downloading and ontology annotation part. Presented model was experimentally implemented 80 and integration was tested using Cocoon and Spring Framework [16]. Our approach is used also in the Slovak project NAZOU Tools for acquisition, organization and maintenance of knowledge in an environment of heterogeneous information resources to find relevant job offers for the user according to his/her preferences. The domain of this project is different from the one used in this paper, thus we have another domain for testing purposes. We can constitute that our model is domain-independent. 80 An experimental implementation of our system is available on URL (with user interface in Slovak).

132 120 P. Gurský a kol.: Web Search with Variable User Model Acknowledgements Partially supported by Czech projects MSM , 1ET and 1ET and Slovak projects VEGA 1/3129/06 and NAZOU. References 1. Baumgartner, R., Flesca, S., Gottlob, G.: Visual Web Information Extraction with Lixto VLDB Baeza-Yates, R., Ribeiro-Neto, B. A.: Modern Information Retrieval. ACM Press / Addison-Wesley, Bratko, I., Šuc, D.: Learning qualitative models. AI Magazine 24 (2003) Džeroski, S., Lavrač, N.: An introduction to inductive logic programming. Relational data mining, S. Džeroski, N. Lavrač eds., Springer 2001, Fagin, R.: Combining fuzzy information from multiple systems, J. Comput. System Sci. (1999) 58: Grossman, D. A., Frieder, O.: Information Retrieval: Algorithms and Heuristics, Kluwer Acamedic Publishers, Gurský, P.: Towards better semantics in the multifeature querying. Proc. Dateso Gurský P., Horváth T., Jirásek J., Krajči S., Novotný R., Vaneková V., Vojtáš P.: Knowledge Processing for Web Search An Integrated Model, Proceedings of IDC Horváth, T., Krajči, S., Lencses, R., Vojtáš, P.: An ILP model for a graded classification problem. J. KYBERNETIKA 40 (2004), No. 3, (2004), p: Horváth, T., Vojtáš, P.: Ordinal Classification with Monotonicity Constraints. In. Proc. ICDM 2006, Leipzig, Germany: LNAI 4065, Springer, 2006, pp Lencses, R.: Indexing for Information Retrieval System supported with Relational Database, Sofsem 05 Communications, Vojtáš et al. (ed.) Bratislava 2004, Lencses, R.: Dopytovanie v systéme zameranom na získavanie informácií s podporou relačnej databázy, Proc. Datakon 04, Masaryk University, Brno, 2004, p Lixto. [online] McGuinness, D. L., van Harmelen, F.: OWL Web Ontology Language Overview. W3C Recommendation, Srinavasan, A.: The Aleph Manual. Technical Report, Comp.Lab., Oxford University 16. The Spring Framework Vojtáš, P.: Fuzzy logic programming, Fuzzy Sets and Systems, 124(3) (2001)

133 Vybraný příspěvek 121 Anotace: Webové vyhľadávanie s prispôsobiteľným používateľským modelom Prekladáme návrh middleware systému pre podporu webového vyhľadávania zahŕňajúceho referenčné aj fulltextové vyhľadávanie. Preferenčné dopytovanie je zložené z anotácie webových stránok, indukcie používateľových preferencií a efektívne dopytovanie. Systém je založený na formálnom modeli používateľských preferencií nad fuzzy logikou. V experimentálnej implementácii systému integrujeme viacero nezávislých softvérových nástrojov.

134 Vyhledávání a porovnávání znaků českého znakového jazyka Michal KOPECKÝ Katedra softwarového inženýrství, MFF UK Praha Malostranské nám. 25, Praha kopecky@ksi.ms.mff.cuni.cz Abstrakt. Příspěvek se zabývá možnostmi obousměrného elektronického slovníku mezi českým jazykem (ČJ) a českým znakovým jazykem (ČZJ). Podstatným rysem slovníku je využití notačního systému a virtuální reality pro trojrozměrnou reprezentaci znaku. Je diskutována možnost využití tohoto modelu pro vyhledávání znaků ČZJ na základě částečné znalosti o jeho podobě a porovnávání vzájemné vizuální podobnosti znaků. Klíčová slova: český znakový jazyk, slovníky, virtuální realita, vyhledávání 1 Úvod Český znakový jazyk je přirozený jazyk Neslyšících s vlastním slovníkem a vlastní gramatikou. Není odvozený od mluveného jazyka. Liší se od něj způsobem své existence. Zatímco mluvený jazyk je audio-orální a má psanou podobu, znakový jazyk je vizuálně-motorický a psanou podobu nemá. Je založen na tvarech, pozicích a pohybu těla především rukou v trojrozměrném prostoru, a vnímá se zrakem. Tato forma je velmi obtížně graficky zachytitelná. Ani nejobvyklejší způsob videosekvence nevystihuje znak přesně. Zachycuje pouze dvojrozměrnou projekci třírozměrné podoby znaku, a bez použití záznamu z více úhlů pohledu může snadno dojít k zakrytí některých detailů. Absence psané podoby znakového jazyka komplikuje tvorbu slovníků. Všechny stávající slovníky českého znakového jazyka jsou založené na českém jazyce a umožňují překlad do české znakové řeči. Tištěné slovníky [1], [8], [9] reprezentují znaky pomocí statických obrázků se šipkami. Současné elektronické či internetové slovníky [4], [5], [15] využívají pro stejný účel videosekvence. Jejich jednosměrnost však představuje výrazné omezení. Je snadné nalézt obrázek či videosekvenci ke slovu zapsanému v běžném jazyce. V okamžiku, kdy je potřeba naopak najít význam znaku na základě přibližné znalosti jeho znakované podoby, či znaky vizuálně podobné znaku zobrazenému, je takový slovník nepoužitelný. Při výuce znakového jazyka je pro slyšící i Neslyšící mnohem vhodnější slovník, který dovolí prezentovat znaky ve třech rozměrech a především umožňuje snadné vyhledávání znaků na základě úplné či jen částečné znalosti jejich vizuální podoby. Následující kapitola popisuje základní principy a některé z možností, které nabízí první obousměrný elektronický slovník pro překlad z českého jazyka do českého L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

135 Vybraný příspěvek 123 znakového jazyka a zpět. Třetí kapitola je věnována možnostem, jak dále rozšířit možnosti vyhledávání znaků tak, aby podobnost více odpovídala skutečné vizuální podobě. Čtvrtá kapitola seznamuje s některými z naměřených výsledků, získaných pilotní implementací navržených porovnávacích algoritmů. Závěr je kromě celkového shrnutí věnován rovněž nastínění dalšího vývoje slovníku. 2 Zpracování znaků českého znakového jazyka Možností, jak lépe zachytit pohyb rukou během znakování je několik, od snímání osoby z více nezávislých pohledů až po její snímání pomocí stereoskopických kamer a rekonstrukce plného třírozměrného pohledu. Ze získaného videozáznamu mohou být spočteny pozice rukou a jejich tvarů. Možnostem analýzy videozáznamu a rozpoznávání se věnuje například [11]. Toto řešení je však poměrně náročné na pořízení záznamu i reprodukci. Navíc se stále jedná o jeden třírozměrný či více předdefinovaných dvourozměrných pohledů na znakující osobu. Optimální pro výuku by bylo pokusit se zachytit pohyby rukou tak, aby je bylo možné sledovat z libovolného úhlu v libovolném přiblížení a rychlosti. Prvním slovníkem, který tento aspekt pro český znakový jazyk řeší je elektronický slovník českého znakového jazyka ZNAK, který vznikl v roce 2006 jako softwarový projekt na MFF UK v Praze [2], [3]. Pro trojrozměrnou animaci byl zvolen popis znaku v jazyce VRML. Ten dovoluje animace v klasickém klientském programu stejně jako v internetovém prohlížeči. Vykreslovanou scénu je možné libovolně otáčet a přibližovat. Je možné dokonce reagovat na události, které uživatel ve scéně generuje pomocí myši nebo klávesnice. Pokud by však byl pro každý znak ručně vytvářen jeho popis v jazyce VRML, vedlo by to k neúměrné složitosti zadávání znaků do slovníku. Také možnost vyhledávání a porovnávání animací v tomto jazyce je obtížně myslitelná. Je proto potřeba nalézt vhodnější systém popisu znaků, který by jejich zadávání vyhledávání a porovnávání umožnil. 2.1 Notační systém pro popis znaků ČZJ Pro možnost zachycovat znaky či jejich části pomocí psané podoby lingvisté v řadě institucí, které se znakovým jazykem zabývají, vytvářejí různé notační systémy. V roce 1960 byla vytvořena první notace pro zápis Amerického znakového jazyka. Jejím autorem je Dr. William C. Stokoe [13]. Každý znak je zapsán jako trojice <místo znakování; tvar ruky; pohyb a orientace>. Jednotlivé fonémy 81 jsou zapisovány lineárně za sebou pomocí běžné abecedy. Pro usnadnění čtení se však dnes obvykle používá speciální typ písma. Odlišný typ notace představuje SignWriting, navržený v Dánsku [14]. Jedná se o notaci, zobrazující znak pomocí dvojrozměrného obrázku, složeného z několika symbolů po obličej, ruce a jejich pohyb. Bohužel nelze hovořit o tom, že by byl některý z vytvořených notačních systémů široce přijat. Společným cílem všech těchto systémů je zachycení manuální složky znaku, tedy tvaru rukou, jejich pohybů a místa artikulace. Tyto informace je možné z notačních 81 Základní prvky jazyka přímý pohyb, obloukový pohyb, kruhový pohyb, a pod.

136 124 M. Kopecký: Vyhledávání a porovnávání znaků českého znakového jazyka zápisů zpětně algoritmicky zrekonstruovat. Žádný z existujících systémů nezachycuje nemanuální složku znaků tvořenou mimikou obličeje a případně pohyby celého těla. Tuto informaci lze proto nadále zjistit pouze z videosekvence, zachycující mluvčího během znakování. Mezi jednotlivými notacemi se pro účely tvorby slovníku jako nejvhodnější ukázal systém, vytvořený na FF UK v Praze [6] s úpravami a rozšířeními, provedenými tamtéž Karlem Benešem 82. Tato notace je jednou z mnoha variant Stokoe notace. Používá lineární podobu zápisu s využitím speciální znakové sady. Znak ČZJ pro slovo sklo se v této notaci zapíše jako zatímco znak pro slovo fialový je notací zachycen ve tvaru Každý jednoruční znak se v notačním zápisu sestává z pětice TAB DEZ ORI1 ORI2 SIG. První složka notace TAB (tabula) v tomto případě značka, určuje znakovací místo před čelem osoby. Druhá složka DEZ (designator) značka A 0, popisuje tvar ruky na začátku znakování. Značka A 0 odpovídá v notaci tvaru Následují značky ORI1 a ORI2 (orientation), určující orientaci ruky v prostoru. Kombinace značek < informuje o tom, že normála dlaně směřuje vzad a záprstní kosti směřují vlevo. Složka SIG (signature), nejsložitější část z notačního zápisu, popisuje pohyb ruky během znakování. Dotyk vnitřní plochy dlaně s čelem, následovaný pohybem dlaně vpravo. 2.2 Využití notačního systému pro prezentaci znaku Zvolený notační systém byl dále zjednodušen tím, že rozlišuje pouze tři kategorie znaků: Jednoruční znaky, které jsou znakovány pouze dominantní (obvykle pravou) rukou Dvojruční znaky, ve kterých je aktivní pouze dominantní ruka, zatímco druhá je po celou dobu znakování ve výchozí pozici. Dvojruční znaky, ve kterých jsou aktivní obě ruce. V nich se během znakování pohybují obě ruce, ať už symetricky, či nikoli. Dvojruční znaky s jednou aktivní rukou vyžadují zadání v podobě desetice TAB l DEZ l ORI1l ORI2l HA TAB r DEZ SIG r r ORI1r ORI2r. Složka HA (hand arrangement) určuje vzájemnou polohu rukou na začátku znakování. Tedy zda jsou vedle sebe, nad sebou, a podobně. Složka SIG není pro první uváděnou ruku (levou, nedominantní) 82 Hlavním přínosem je rozšíření notace o šikmé směry a detailnější popis kruhových pohybů. Práce nebyla samostatně publikována.

137 Vybraný příspěvek 125 důležitá, protože se ruka během znakování nehýbe. V posledním případě, kdy jsou obě ruce během znakování aktivní, je potřeba uvést celkem jedenáct položek notace v pořadí TAB l DEZ l SIG l ORI1l ORI2l HA TAB r DEZ r ORI1r ORI2r SIG r. Výsledná notace dokáže znak popsat natolik přesně, že je možné nejen generovat dostatečně přesnou trojrozměrnou animaci postavy pouze na jeho základě, ale také znaky snadněji do systému zadávat, vyhledávat a vzájemně porovnávat. VRML model pro znakování obsahuje kompletní kostru obou rukou. Každá z rukou obsahuje ramenní, loketní, a zápěstní kloub společně se třemi klouby pro každý z pěti prstů. Klíčovým pro zobrazování znaků pomocí VRML modelu je převod notace znaku na VRML prezentaci. Vstupem je zápis v notačním systému. Výstupem je inicializační soubor VRML a soubor interpolátorů. Inicializační soubor obsahuje rotace všech 2*(3+5*3)=36 kloubů kostry, potřebných k převedení základní pozice modelu do výchozí pozice pro znakování. Druhý soubor popisuje pohyby kloubů kostry během znakování. Model pro znakování slova sklo ve výchozí pozici je včetně detailu hlavy zobrazen na obrázku 1. Obr.1. Model, znakující slovo sklo 2.3 Využití VRML modelu pro zadávání znaků Algoritmus pro převod notace na trojrozměrnou animaci je možné z výhodou použít i pro zadávání nových znaků do systému. Složka TAB, tedy znakovací místo je možné vybrat z panelu nabídek, nebo přímo ukázat myší na VRML modelu, jak lze vidět na obrázku 2. Obr.2. Zadávání pozice znakování s pomocí modelu

138 126 M. Kopecký: Vyhledávání a porovnávání znaků českého znakového jazyka Ostatní části notace je možné vybrat z odpovídajícího panelu. I jen částečně zadané údaje o notaci znaku jsou zároveň ihned zobrazovány na modelu, čímž je uživateli poskytnuta zpětná vazba, umožňující snadnou vizuální kontrolu. 3 Vyhledávání znaků Výhodou využití notačního zápisu je možnost vyhledávání znaků, které mají zadanou notaci, nebo jsou jí podobné. Na základě shodnosti notace je možné snadno vyhledat homonyma v českém znakovém jazyce, tedy znaky se shodným znakováním, ale odlišným významem. Pro hledání podobných znaků, případně znaků, pro které není celá notace známa, je nutné definovat mezi znaky vzájemnou podobnost. Metoda vyhledávání, implementovaná v prototypové realizaci projektu, dovoluje pouze vyhledávání znaků podle složek TAB a DEZ notačního zápisu. Počítání podobnosti dvou znaků není podporováno. Pro vyhledávání jsou místa znakování i tvary rukou lineárně seřazeny tak, aby sobě blízká znakovací místa a podobné tvary rukou ležely blízko sebe. Podobnost znaků je následně odvozována dle vzdálenosti v obou uspořádáních. Toto řešení nalezne pro dotaz TAB= (neutrální znakovací prostor před tělem postavy), DEZ=A odpovědi: medvěd =1 neděle =1 pravidelně =1 hnědý =0,333 A A A sa Je zřejmé, že pro implementovaný systém vyhledávání jsou znaky pro první tři slova nerozlišitelná, ačkoli se na první pohled liší postavením dlaní v prostoru a dokonce i pozicí zápěstí. Chtěli bychom proto najít takový způsob výpočtu podobnosti, který by zohlednil podobu modelů a dokázal odstupňovat vzájemnou podobnost mezi znaky medvěd, neděle a pravidelně. S pomocí metody, která dokáže dostatečně přesně odvozovat podobnosti dvojic znaků je navíc možné slovník obohatit o další důležité vlastnosti. Například: Dohledání všech podobných znaků ke znaku právě zobrazenému. To zájemci o český znakový jazyk dovolí přecházet volně mezi podobnými znaky ve slovníku a především si tak snáze uvědomit i jemné odlišnosti mezi znaky, které mohou vést ke vzájemným záměnám a nesprávnému pochopení smyslu sdělení. Automatické generování testů pro zkoušení slovíček. Mezi odpověďmi by například mohla být kromě té správné umístěna i nějaká s velmi

139 Vybraný příspěvek 127 podobným znakováním a tedy velmi pravděpodobná a naopak nějaká zcela nesprávná. Autoři [17] se ve slovníku Amerického znakového jazyka rozhodli implementovat vyhledávání nad zápisem ve Stokoe notaci. Oproti tomu zde navrhovaný výpočet podobnosti nepracuje s notací, ale přímo s geometrickým popisem znakování. Výpočet se tak stává nezávislým na konkrétní použité notaci a bude použitelný v libovolném znakovacím jazyce. Ve slovníku ZNAK je možné potřebné údaje získat s využitím převodu notačního zápisu na animovaný model. Použijeme informace o rotacích kloubů pro výchozí pozice porovnávaných znaků. Bylo by však možné získat je i analýzou videozáznamu. Zápis znaku 1 Převod Interpolátory Rotace kostry 1 Výpočet podobnosti Rotace kostry 2 Inicializace modelu Inicializace modelu Zápis znaku 2 Převod Interpolátory Obr.2. Zadávání pozice znakování s pomocí modelu Informace o rotaci kostry modelu obsahuje celkem 36 položek, 18 pro každou ruku. Každá položka definuje osu rotace a úhel, o který kloub otáčí. Každé kosti modelu je dále přiřazena její délka l. Pro vizuální podobnost mezi znaky jsou rozhodující následující charakteristiky: Pozice zápěstí v prostoru, určené bodem C = [cx, cy, cz] v globální souřadné soustavě o Čím jsou odpovídající si body dvou znaků dále od sebe, tím jsou znaky méně podobné. Normála dlaně p = <px, py, pz> o Pokud jsou dlaně v porovnávaných znacích otočené pod zřetelně odlišným úhlem, klesá vizuální podoba a zaměnitelnost znaků pro pozorovatele. Směr záprstních kostí s = <sx, sy, sz> o Pro podobnost znaků zde platí obdobná úvaha, jako v předchozím případě. Pozice konců prstů D 1,, D 5 v souřadné soustavě, určené vektory p, s, p s o Pozice konce prstu téměř jednoznačně určuje, jakým způsobem je prst na ruce ohnutý. Není proto potřeba sledovat pozice ostatních kloubů v prstech ani směry jednotlivých kostí v nich. Výrazně odlišná pozice prstů přitom snižuje pravděpodobnost vzájemné záměny dvou znaků.

140 128 M. Kopecký: Vyhledávání a porovnávání znaků českého znakového jazyka Výpočet podobnosti je prováděn nad čtveřicemi <C, p, s, <D 1,, D 5 >>, odpovídající složkám TAB, ORI1, ORI2 a DEZ notace. Popisovaná podobnost znaků je tedy odvozována z podobnosti výchozí pozice bez ohledu na následný pohyb v prostoru. Zahrnutí pohybu do výpočtu podobnosti je předmětem dalšího studia. Čtveřici <C, p, s, <D 1,, D 5 >> lze zároveň chápat jako osmici <C, p, s, D 1,, D 5 >. Pro dvojici znaků Z 1, Z 2 je jejich podobnost spočtena ze vzdáleností, počítaných pro jednotlivé složky zvlášť podle následujících pravidel: Pro dva body X 1, X 2 je jejich vzdálenost definována předpisem X 2 X 1 Dist( X 1, X 2) = (1) nejvyšší možná vzdálenost Pro dva vektory v 1, v 2 je jejich vzájemná vzdálenost definována předpisem Dist( v1, v2) = ( 1 Sim( v1, v2) )/ 2 (2) Podobnost Sim(v 1, v 2 ) odpovídá kosinové míře, známé z vektorových modelů [12]. Oba předpisy pro výpočet vzdálenosti vrací hodnoty z intervalu <0; 1>. Vzdálenost 0 odpovídá shodě porovnávaných veličin, vzdálenost 1 maximální možné neshodě, kdy jsou vektory vzájemně opačně orientované. Výsledkem je získání osmice vzdáleností D = [d 1, d 2,, d 8 ] <0; 1> 8. Pro získání celkové podobnosti znaků pro jednu ruku je potřebné získané výsledky zkombinovat do jediného čísla. Toho lze docílit několika způsoby. Například s využitím vzorců pro fuzzy logiku [10] dostaneme předpis (, ) = Fuzzy( D) = min( 1 ) 8 ZSim Z Z w d (3.1) 1 2 k k Změna znakovacího místa bude určitě snáze postřehnutelná, než změna polohy malíčku na ruce. Koeficienty w k <0; 1> proto dovolují zohlednit důležitost jednotlivých charakteristik pro vizuální rozlišení znaků. Lze však uvažovat i další způsoby výpočtu podobnosti, odvozené z MinMax [16] modelu ZSim Z k = Z 2 α k= 1 (, ) = MinMax( D) = min( 1 ) + ( 1 ) max( 1 ) α wk Dk wk D (3.2) k pro vhodně zvolený parametr α <0,5; 1>, nebo Paice [7] modelu ZSim Z 8 k= 1 8 k ( 1, 2) Paice( D) = ( 1 ) Z = r k = 1 w ik D ik (3.3) s parametrem 0 < r < 1. U dvouručních znaků je potřeba do výsledné podobnosti ZnakSim(Z 1, Z 2 ) zohlednit dvě hodnoty ZSim pro pravou i levou ruku. Opět lze použít některý z Fuzzy, MinMax a Paice modelu. 4 Výsledky porovnávání znaků Praktické výsledky ukazují, že Fuzzy model je pro účely porovnávání znaků příliš striktní. Výraznější odchylka v jediné z charakteristik velmi sníží celkovou podobnost. Navíc se často stává, že jsou podobnosti pro různé znaky shodné, jak je vidět z následujících příkladů.

141 Vybraný příspěvek 129 medvěd, neděle ZnakSim(, ) = 0,50000 medvěd, pravidelně ZnakSim(, ) = 0,50000 medvěd, hnědý ZnakSim(, ) = 0,48837 hnědý, pravidelně ZnakSim(, ) = 0,48837 Podíváme-li se na výsledky podrobněji, zjistíme, že: ZnakSim( medvěd, neděle ) = Min( Min( ; ; ; ; ; ; ; ) Min( ; ; ; ; ; ; ; ) ) ZnakSim( medvěd, hnědý ) = Min( Min( ; ; ; ; ; ; ; ) Min( ; ; ; ; ; ; ; ) ) Hodnoty podobnosti a 0,48837 tedy odpovídají pouze změnám v orientaci záprstních kostí, respektive pozic palců ve dvojicích modelů. Ostatní charakteristiky se na výsledné podobnosti neprojeví. V následujících výsledcích byly podobnosti pro jednotlivé ruce spočteny s využitím Paice modelu pro r = 0,5 a následně zkombinovány pomocí MinMax modelu pro α = 0,75 medvěd, neděle ZnakSim(, ) = 0,78607

142 130 M. Kopecký: Vyhledávání a porovnávání znaků českého znakového jazyka medvěd, pravidelně ZnakSim(, ) = 0,78596 medvěd, hnědý ZnakSim(, ) = 0,76097 hnědý, pravidelně ZnakSim(, ) = 0,68316 Tyto výsledky jsou věrohodnější a lépe odpovídají intuici. 5 Závěr Dosud otevřený je problém nalezení optimální kombinace metod výpočtu podobnosti, případně volby vhodných parametrů. Velkým přínosem bude rovněž zahrnutí animační části notace do procesu porovnávání. Již nyní je ale zřejmé, že využití notačního zápisu a jeho přímého algoritmického převodu na animaci třírozměrného modelu postavy je vhodným nástrojem pro tvorbu obousměrného slovníku českého znakového jazyka. Dovoluje uživatelům zobrazit detaily postavení rukou a jejich pohybů, které mohou při pohledu na videosekvenci zůstat zcela skryty. Model a převodní algoritmus se velmi dobře uplatní i při zadávání notace nového znaku do slovníku. Neocenitelnou pomoc však představují především možnost vyhledávání znaků jazyka na základě částečné či úplné znalosti jeho podoby. Při dotazování má uživatel neustále možnost konfrontovat pohyby odpovídající zadané části notačního zápisu se skutečností. Rozšířením dosud implementované verze vyhledávání o přesnější porovnávání znaků se před uživateli otevírají rovněž možnosti snadné navigace mezi skupinami vzájemně podobných či homonymních znaků a v neposlední řadě možnosti cíleného přezkušování na základě automaticky generovaných testů. Navržený algoritmus porovnávání není závislý na notačním zápisu, ale pouze na geometrii převedeného modelu. To umožňuje jeho využití i pro znakové jazyky s odlišnou notací nebo v situacích, kdy je k dispozici model postavy získaný přímým rozpoznáváním zachyceného videozáznamu. Literatura 1. Gabrielová, D., Paur, J., Zeman, J.: Slovník znakové řeči, Nakladatelství Horizont, Praha, 1988

143 Vybraný příspěvek Eckhardt, A., Fried, V., Hoffmann, Hoksza, D., Matýsková, M.: ZNAK - Programátorská dokumentace, Eckhardt, A., Fried, V., Hoffmann, Hoksza, D., Matýsková, M.: ZNAK - Uživatelská dokumentace, Kolektiv autorů: Základní slovník znakové řeči. Pedagogické centrum Plzeň, Plzeň, Macurová, A.: Proč a jak zapisovat znaky českého znakového jazyka. Speciální pedagogika 6 (1996) Paice, C.D.: Soft evaluation of boolean search queries in information retrieval systems. Information Technology: Research and Development. 3(1) (1984) Ptáček, V., Buberle, V.: Slovník českého znakového jazyka, UNIE Ptáček, V., Kotvová, M.: Slovník znakové řeči., Praha, Radecki, T.: Fuzzy set theoretical approach to document retrieval. Information Processing & Management. 15(5) (1979) Rybach, D.: Appearance-Based Features for Automatic Continuous. Sign Language Recognition, Aachen University, Aachen, Germany, Salton, G.: Automatic Text Processing: The Transformation, Analysis, and Retrieval of Information by Computer., Addison-Wesley Stokoe, W. C.: Sign language structure: An outline of the visual communication systems of the American deaf., Silver Spring, USA, Sutton, V.: Examples of Notation of Danish Deaf Sign Language, 1974, Copenhagen, Denmark Wailer WG, Kraft DH. A mathematical model of a weighted boolean retrieval system. Information Processing & Management. 15 (1979) Wilcox S., Scheibman J., Wood D., Cokely D., Stokoe W. C.: Multimedia Dictionary of American Sign Language, ACM SIGACCESS Conference on Assistive Technologies, str. 9-16, Marina Del Rey, California, United States, 1994 Annotation: Search and comparison of signs in Czech sign language The paper deals with aspects necessary to build bi-directional dictionary of Czech language and Czech sign language. It describes advantages of the notational system utilisation. One of them is the possibility to automatically generate VRML model for the sign presentation. This model can be seen from any perspective, at any speed and in any detail. Main goal of the paper is to provide the notion of searching and comparison of signs according to the visual similarity of the model. It utilizes geometrical characteristics of the initial position of models to deduce the similarity between them. Providing the proper similarity measure, the bi-directional dictionary can be further extended by traversing between most similar signs, as well as by practical automatic tests generator.

144 Nasazení federací ve velkém distribuovaném prostředí: systém pro správu interakcí léků Daniel KOUŘIL, Martin KUBA, Michal PROCHÁZKA Masarykova univerzita, Botanická 68a, Brno CESNET, z.s.p.o, Zikova 4, , Praha 6 {kouril,makub,michalp}@ics.muni.cz Abstrakt. Koncept federací zavádí nový přístup ve správě přístupu uživatelů ke službám. Samotné služby již nemusejí spravovat uživatelské účty, tuto zodpovědnost přebírají domovské instituce uživatelů. Tím se celý systém stává decentralizovaný a není omezena jeho škálovatelnost. Uživatelé mohou využít paletu služeb za použití pouze jedněch přihlašovacích údajů, které navíc poskytují pouze své domovské instituci. Koncept federací jsme využili pro řešení problému jak zabezpečit přístup k systému pro správu interakci léků, která musí být veřejně dostupná, ale zápis do ni mohou provádět pouze lékaři. Klíčová slova: federace, shibboleth, CZTestFed 1 Úvod Doba, kdy na Internetu byly dostupné pouze bezplatné služby a dostupné všem, je se vzrůstající penetrací Internetu pryč. Placené a personalizované služby změnily pohled a požadavky na služby jako celek. Autentizace a autorizace uživatelů se stala nezbytnou součástí. Absence jednotného standardu pro autentizaci a autorizaci zapříčinila situaci, kdy služby implementují vlastní bezpečnostní mechanismy. Případ, kdy několik služeb využívá stejný autentizační nebo autorizační mechanismus ještě neznamená, že uživatel bude mít k těmto službám přístup pomocí jedněch přihlašovacích údajů. Služby by musely sdílet správu uživatelů a to je samozřejmě u služeb, které provozují cizí subjekty velice nepravděpodobné. Současný stav, kdy je uživatel nucen spravovat několik jednotek, ale i desítek přihlašovacích údajů je neudržitelný. Uživatelé si ve většině případů přihlašovací údaje zaznamenávají do souborů nebo na papírky a tím samozřejmě oslabují bezpečnost služeb. Řešení, která předpokládala centrální správu uživatelů se ukázala jako nepoužitelná. Se vzrůstajícím počtem uživatelů se staly tyto systémy nespravovatelnými. Federace umožňují řešit výše zmíněné problémy. Jsou založeny na decentralizované správě uživatelů, kde každý uživatel má svého správce identity. Zároveň federace zvyšují bezpečnost autentizačního mechanismu tím, že uživatel vždy zadává své přihlašovací údaje pouze u své domovské instituce, i když přistupuje ke vzdáleným službám. Jelikož se uživatel autentizuje u své domovské instituce, ta L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

145 Vybraný příspěvek 133 může po úspěšné autentizaci předat službě atributy, které poskytují o uživateli dodatečné informace nutné k autorizačnímu rozhodnutí. 2 Model federovaných systémů Informační systémy zpracovávají informace, které zpravidla nebývají veřejné a přístupné, ale přístup k nim je povolen jen specifikovaným uživatelům. Příkladem mohou být firemní systémy spravující vnitřní agendu organizace, databáze státních organizací se soukromými údaji občanů nebo systémy digitálních knihoven, které umožňují svým předplatitelům přístup k plným textům spravovaných dokumentů. Nedílnou součástí takových systémů samozřejmě musí být zajištění patřičné úrovně bezpečnosti, zejména spolehlivé autentizace a autorizace uživatelů. Správa uživatelů v takových systémech je zpravidla zcela autonomní a nepočítá s využitím v dalších systémech, ani s možností využít data o uživatelích z jiných stávajících systémů pro správu uživatelů, které obsluhují jiné organizace. Důsledkem této nezávislosti je nutnost registrovat všechny uživatele v databázi, která je součástí informačního systému. Pokud uživatel potřebuje využívat více takto nezávislých systémů, tak se musí zaregistrovat do všech. Ke každému systému samozřejmě obdrží samostatné přihlašovací údaje, které jsou určené pouze pro přístup k tomuto systému a nelze je použít pro autentizaci k dalším systémům. Tato situace může vést až k faktickému oslabení bezpečnosti. Např. v případě, že autentizace je založena na použití hesla, lze předpokládat, že běžný uživatel bude používat stejné heslo pro přístup ke všem systémům. V případě kompromitování jednoho takového systému a prozrazení uživatelského hesla budou zranitelné i všechny systémy, které daný uživatel takto používá. Situace bude o to horší, že systémy jsou autonomní, nevědí o sobě a administrátoři nejsou informováni ani o kompromitaci jiného systému ani o tom, že byl používán také jejich uživatelem a že tedy může být potřeba nasadit nějaká ochranná opatření. I když odhlédneme od těchto potenciálních bezpečnostních problémů, stále zůstává pro uživatele nutnost registrace do používaných systémů. Tato registrace často představuje administrativní zátěž jak pro uživatele, tak i pro správce systému. Nezřídka je nutné, aby se uživatel dostavil osobně na kontaktní místo, případně doručil nějaká papírová potvrzení apod. Po registraci je navíc nutné údaje udržovat a kontrolovat, že odpovídají skutečnosti. Každá změna údajů se musí promítnout do všech informačních systémů, ve kterých je uživatel zaregistrován. Vzhledem k nezávislosti systémů je nahlášení změny zpravidla výhradně odpovědností samotného uživatele, což nemusí být příliš spolehlivé. Uživatel může buď zapomenout na některý ze systémů nebo změnu dokonce úmyslně zatajit. Popsaný stav je možné zvládnout pokud se jedná o několik málo jednotlivých samostatných systémů. Situace se ale rapidně zhoršuje se zvyšujícím se počtem systémů, do kterých je uživatel takto zapojen. V následujících letech lze očekávat, že spíše poroste počet systémů, které nabízejí služby autentizovaným uživatelů, a proto se hledají cesty pro efektivnější správu uživatelských informací. Slibný pokrok v této oblasti nabízí model federací, který umožňuje oddělit správu uživatelů od vlastního přístupu k informacím v systému a umožňuje sdílení informací o spravovaných uživatelích byly s dalšími informačními systémy ve federaci.

146 134 D. Kouřil a kol.: Nasazení federací ve velkém distribuovaném prostředí: systém pro správu interakcí léků Hlavní myšlenka federačního uspořádání je založena na faktu, že zpravidla každý uživatel spadá pod nějakou,,domovskou organizaci, která o něm spravuje informace ve svém systému. Takovou organizací je např. škola v případě studentů nebo zaměstnavatel v případě zaměstnanců. Domovská organizace ve vlastním zájmu pečuje o to, aby spravovaná data byla aktuální, protože to potřebuje pro zajištění své provozní agendy (výplaty mezd, organizaci studia, apod). Organizace také zpravidla pro své uživatele provozují informační systémy, včetně sekcí s řízeným přístupem, kam se uživatelé musí přihlásit pomocí autentizačních mechanismů a údajů získaných od své instituce. Federační model umožňuje využít informací spravovaných domovskou institucí i informačními systémy, které nejsou s touto institucí přímo propojeny, ale které jsou zapojeny v infrastruktuře pro výměnu dat o uživatelích,,federaci. Systémy zapojené do federace jsou schopné získat informaci o uživateli přímo z jeho domovské instituce, kde je největší záruka toho, že informace jsou aktuální a není tedy potřeba aby si udržovaly vlastní systémy spravující uživatelské záznamy. Takové uspořádání navíc usnadňuje práci i samotným uživatelům, protože ti se vždy prokazují pouze autentizačními údaji, které používají pro přístup do svého domovského systému. Infrastruktura federace pak zajistí, že systémy si mezi sebou předávají potřebné údaje, tato komunikace je však pro uživatele transparentní. 2.1 Založení a provoz federace Ustavení federace probíhá v několika krocích. Z technického pohledu je potřeba, aby se zúčastněné organizace dohodly na jednotném rozhraní, kterým budou získávat informace z institucí. Toto rozhraní (tzv. Identity Provider) pak nabízí každá zapojená instituce poskytující data o svých uživatelích, zpravidla ve formě specializované služby běžící nad vnitřním systémem správy uživatelů. Identity Provider nabízí data o uživatelích, která jsou využívána koncovými službami ve federaci (tzv. Service Providers). Tyto informace lze rozdělit do dvou kategorií, jednak je to binární informace o tom, zda daný uživatel prošel autentizačním mechanismem na domácí instituci a jednak je to množina atributů, které poskytují upřesňující informace o uživateli. Atributy mohou určovat např. kategorii poměru uživatele k instituci (např. zda se jedná o studenta, akademického pracovníka nebo pracovníka administrativy), zpřesňovat kategorii zaměstnání (lékař, uklízečka), určovat vztah k vnitřní struktuře organizace (člen konkrétní fakulty), apod. Pomocí těchto atributů pak koncové služby mohou provádět komplexní řízení přístupu. Dnes je například obvyklé, že fakulta zakoupí pro své zaměstnance a studenty přístup k odborným textům v nějaké digitální knihovně. V současné době je řízení přístupu v této oblasti založeno na síťových IP adresách, kdy je přístup povolen, pokud uživatel přistupuje ke knihovnímu systému z předem specifikovaného rozsahu IP adres. Samozřejmě tento přístup není ideální ani pro provozovatele knihovny (protože přístup tak mohou mít i uživatelé, na které se licence nevztahuje), ani pro uživatele (protože jsou buď omezeni na práci ze své organizace nebo musí složitě konfigurovat různé síťové tunely apod.). Pokud by poskytovatel knihovny a příslušná fakulta byly součástí federované infrastruktury, mohl by poskytovatel obsahu povolit přístup jen pro uživatele, kteří mají ve svých atributech specifikovánu příslušnost k dané fakultě, resp. i pracovní zařazení (např. s požadavkem, že se musí jednat pouze o studenty, či akademické pracovníky).

147 Vybraný příspěvek 135 Dále je potřeba dohodnout způsob předávání atributů, kdy existují dva základní přístupy. Prvním je tzv. push model, ve kterém klientská část zajistí získání potřebných dat o uživateli, která následně pošle na server spolu s požadavkem na přístup k aplikačním datům. Druhou možností je pull model, ve kterém je aktivní server, který kontaktuje uživatelský domovský systém poté, co obdrží požadavek od klienta. V současné době existuje několik nástrojů implementujících tyto modely a na základě vyhodnocení konkrétních požadavků na funkci federace, lze z těchto nástrojů vybrat nejvhodnější řešení. Do oblasti vzájemné komunikace mezi systémy patří samozřejmě problematika bezpečnosti, protože systémy s uživatelskými informacemi často obsahují data podléhající předpisům o ochraně osobních údajů a přístup k nim by tedy měl být omezen pouze na vybrané služby. Je tedy často nutné zajistit i šifrování těchto dat během přenosu. I v případě, že předávaná data nejsou citlivého charakteru, je nutné zajistit minimálně jejich integritu tak, aby příjemce mohl ověřit, že data nebyla během přenosu změněna. Opět existuje několik mechanismů pro implementaci požadovaných bezpečnostních kritérií. Většina federací využívá elektronické podpisy a infrastrukturu veřejných klíčů [1], která je velmi dobře škálovatelná i s velkým počtem zapojených institucí. Přistupuje-li uživatel ke službě, musí nějakým způsobem poskytnout informaci, kde je jeho Identity Provider. K tomuto účelu slouží služba WAYF (Where Are You From). Tato služba je předřazena přístupu ke každé službě v rámci federace, uživatel zde vybere ze seznamu všech Identity Providerů celé federace toho, kdo provede jeho ověření. Služba WAYF je pevně svázána s federací, protože musí pracovat s aktuálním seznamem Identity Providerů. Další oblastí, kterou je potřeba definovat během zakládání federační infrastruktury je tzv. schéma atributů, které specifikuje jaké atributy popisující uživatele jsou pro danou federaci zajímavé a potřebné. Je potřeba dohodnout syntax těchto atributů i jejich přesnou sémantiku. Praktické zkušenosti ukazují, že zejména tato druhá část je velmi problematická, protože každý zapojený člen federace má trochu odlišnou interpretaci atributů. Příkladem může být atribut edupersonaffiliation ze schématu eduperson, které vzniklo pro popis atributů člena akademické instituce. Atribut edupersonaffiliation popisuje zařazení v rámci organizace, např. student, zaměstnanec, učitel. Zde vyvstávají otázky typu je učitel zároveň zaměstnanec?, apod. Zatím neexistuje shoda na mezinárodní a často ani na národní úrovni o přesné sémantice jednotlivých atributů. Federace přinášejí možnost efektivního přístupu k uživatelským záznamům, ale také zavádějí nový model důvěry, kdy služba (Service Provider) přestává nést zodpovědnost za správu uživatelů, kteří ji využívají. Tato zodpovědnost je delegována na domovské instituce uživatelů a služba tak ztrácí přímý vliv na fungování této složky. Nezbytnou součástí každé produkční federace tedy musí být specifikace politik, které se všechny jednotlivé organizace zaváží dodržovat při implementaci. Přesná podoba politik závisí na zamýšleném zaměření federace. Politiky mohou být specifikovány neformální dohodou zúčastněných stran, ale také to mohou velmi podrobné dokumenty popisující přesně procedury, které jsou pro provoz systémy používány. Z definice federačního prostředí musí organizace při zapojení do federace souhlasit s tím, že bude informace o svých uživatelích zpřístupňovat všem poskytovatelům služeb ve federaci.

148 136 D. Kouřil a kol.: Nasazení federací ve velkém distribuovaném prostředí: systém pro správu interakcí léků 2.2 Federace z uživatelského pohledu Federované prostředí je velmi příjemné pro uživatele, protože jim stačí jediná sada přihlašovacích údajů pro přístup ke všem systémům zapojeným ve federaci. Přístup k dnešním informačním systémům je často založen na protokolu HTTP, který podporuje mechanismus přesměrování, kdy server může odkázat klientský prohlížeč na jinou adresu, kterou je nutné navštívit před použitím samotné služby. Díky tomuto mechanismu může Service Provider odkázat uživatele nejprve na stránku jeho domovské organizace, kam se uživatel nejprve přihlásí. Po úspěšné autentizaci je opět jeho prohlížeč přesměrován na původní Service Provider s tím, že jako součást přesměrování je předána informace o uživateli. Tuto informaci použije Service Provider pro řízení přístupu k poskytované službě. Uživatelé na tomto mechanismu ocení zejména to, že se vždy autentizují pomocí své domovské webové aplikace, na kterou jsou zvyklí, a to i v případě, že požadují přístup ke službě, která není provozována jejich domovskou organizací. Mají tak pouze jednu sadu přihlašovacích údajů pro přístup ke všem systémům, které jsou zapojené ve federaci. Vedle toho, že takové uspořádání je uživatelsky příjemné, poskytuje i větší bezpečnost. Uživatelé si totiž zvyknou zadávat údaje vždy na jediné aplikaci, která má stálý vzhled. Po náležitém proškolení tak vzrůstá pravděpodobnost, že uživatelé nebudou automaticky zadávat přihlašovací údaje do všech aplikací, které od nich tyto údaje mohou vyžadovat. Pěstování těchto,,hygienických návyků je velice užitečné, zejména v době, kdy vzrůstá počet phishingových útoků, které lákají z uživatelů citlivá data. Víceméně jako vedlejší efekt poskytují federace možnost anonymizace, kdy Identity Provider nezpřístupňuje službám jméno uživatele, ale předává pouze jeho atributy, případně jednoznačný identifikátor uživatele, který však nenese informace o jeho skutečné identitě. Uživatel tak nadále může přistupovat ke službám, které omezují přístup jen na určitou množinu uživatelů (definovanou jejich atributy), ale koncová služba se přímo nedozví identitu konkrétních klientů. 3 Implementace federací Výše jsme zmínili, že existuje několik přístupů k implementaci federací. V oblasti přístupu k počítačovým sítím je hojně používána služba Radius [2]. Naopak v oblasti webu je nejčastěji používán middleware Shibboleth [3]. 3.1 Radius Radius server (Remote Authentication Dial In User Service) je určen k ověřování identity uživatelů, dále provádí autorizaci uživatelů a accounting. Radius protokol umožňuje vzdálené ověření uživatele, identitu uživatele nejčastěji ověřují síťové prvky jako jsou bezdrátové přístupové body nebo síťové switche. Radius servery využívané k vytvoření federace jsou seskupeny do hierarchie, kde na nejvyšší úrovni jsou definovány top-level radius servery, dále každá větší organizační složka provozuje vlastní radius servery a samozřejmě je má i každá koncová instituce. Radius servery v cílových organizacích zajišťují ověření identity vlastních uživatelů. Národní a top-level radius servery se starají o předávání

149 Vybraný příspěvek 137 autentizačních požadavků. Pokud na jakýkoliv radius server přijde požadavek na ověření identity uživatele, je z jeho uživatelského jména vyextrahován realm, který určuje uživatelskou instituci. Jedná se tedy o implicitní WAYF, kdy je domovský server uživatele specifikován transparentně bez uživatelova explicitního zásahu. Pokud není požadavek schopen ověřit tento radius server, pak je přeposlán na nadřazený server. V případě, že chce uživatel přistoupit k síti připojí se k přístupovému bodu nebo switchi, který kontaktuje lokální radius server. Radius server ověří identitu uživatele proti databázi uživatelů, pokud se jedná o domácího uživatele, v opačném případě je požadavek přeposlán dále do federace radius serverů až k jeho domácímu radius serveru. Mezi uživatelem a domácím radius serverem se vytvoří zabezpečený tunel přes infrastrukturu radius serverů, kterým jsou poslány přihlašovací údaje. Domácí radius server výsledek ověření uživatele pošle zpět přístupovému prvku, který na jeho základě uživatele vpustí nebo nevpustí do sítě. 3.2 Shibboleth Systém Shibboleth je primárně určen do webového prostředí, tzn. přístup k webovým stránkám a webovým službám. Federace postavená na middleware Shibboleth se sestává z jednoho centrálního místa, které udržuje tzv. metadata nesoucí informace o všech poskytovatelích identit (Identity Providers) a služeb (Service Providers) a zároveň poskytuje službu WAYF. Identity Providers stejně jako v případě Radius ověřují identitu uživatelů, ale zároveň poskytují v autentizační odpovědi atributy o uživateli. Hodnoty atributů jsou čerpány z databáze uživatelů udržované domovskou organizací, hodnoty atributů mohou být také generovány až ve chvíli autentizace uživatele a mohou se lišit i podle toho, ke které službě uživatel přistupuje. Autentizační proces systému Shibboleth sleduje model popsaný v kapitole 2, včetně použití přesměrování na úrovni protokolu HTTP. Současná implementace Shibboleth také nepodporuje Single Sign-On (SSO), tuto funkcionalitu musí zajistit externí služba, která je provozována současně s IdP. 3.3 Existující federace Nejznámější federací, která je provozována nadnárodně (v současné době zahrnuje skoro celou Evropu spolu s Japonskem a Austrálií) je EduRoam [4]. Tato federace je budována za účelem podpory mobility akademických pracovníků a usnadnění připojení k počítačové síti během jejich cest. Nejčastěji je EduRoam využíván pro přístup k bezdrátovým sítím. Celá federace je stavěna na recipročním principu, kdy instituce, která umožní svým uživatelům využívat služeb federace musí poskytnou pro uživatele ostatních institucí přístup do počítačové sítě ve svých prostorách. Z konceptu federací využívá Eduroam pouze decentralizovanou správu uživatelů a autentizaci. Ve federaci Eduroam se nepřenášejí žádné atributy o uživateli, poskytovatele služeb (přístup do sítě) pouze zajímá, zda uživatel patří do nějaké instituce v rámci federace. Eduroam middleware používá infrastrukturu Radius serveru (viz kap.3.1). Federace, které umožňují i autorizaci na úrovní služeb a jsou orientovány na prostředí webu, dnes existují pouze na národní úrovni. Příkladem může být

150 138 D. Kouřil a kol.: Nasazení federací ve velkém distribuovaném prostředí: systém pro správu interakcí léků akademická federace ve Švýcarsku SWITCH AAI. Tato federace byla založena jako jedna z prvních a podařilo se do ní zapojit valnou většinu švýcarských vysokoškolských institucí. V současné době provozují třináct služeb v rámci federace, převážně se jedná o e-learningové programy. Další významnou federací je americká InCommon, která zastřešuje 36 vysokoškolských institucí. V Evropě existuje ještě několik úspěšných federací, ve Finsku provozují federaci pro vysoké školy Haka, ve Velké Británii UKFederation. Výše zmíněné federace využívají jako middleware Shibboleth (viz kap 3.2). Další velká a produkčně nasazená federace je norská FEIDE, která oproti ostatním využívá middleware Sun Federation Manager. Oba middlewary budou v nových verzích využívat protokol pro předávání informací SAML 2.0 [5], což zajistí vzájemnou interoperabilitu, která je dnes zajišťována pomocí pluginů a specifických úprav v obou systémech. Ve všech zmíněných federacích jsou nejčastěji zastoupeny služby pro přístup k elektronickým zdrojům a různým informačním systémům. V současné době se správci národních federací nejvíce zabývají rozšířením, integrací nových poskytovatelů služeb a tvorbou dokumentů, které definují politiky a postupy. V České republice vzniká federace akademických institucí, která je založena na systému Shibboleth. V současné době je k dispozici ověřovací implementace této federace pod názvem CZTestFed83, která poskytuje IdP šesti institucí a devět služeb, které slouží primárně k demonstračním a testovacím účelům. 3.4 Problémy federací Federace jako každý koncept má i své problémy. Shoda na definici atributů patří k nejvíce diskutovaným problémům. Problém s atributy ve schématu eduperson již byly zmíněny, proto v rámci Trans-European Research and Education Networking Association (TERENA) vznikla skupina, která se zabývá harmonizací významu atributů mezi akademickými institucemi a zajišťuje definici postupů pro registraci nových atributů. S atributy je svázán také problém požadavků na atributy od poskytovatelů služeb. Se vzrůstajícím počtem poskytovatelů obsahu a jejich různorodosti vznikají požadavky na další atributy zasílané od IdP pro možnost větší granularity autorizace. Tyto požadavky vedou k neškálovatelnému řešení, kdy IdP má definována pravidla pro vydávání atributů pro různé poskytovatele. Decentralizace na úrovní správy identit a autentizace je velkou výhodou federací, bohužel i toto schéma má své negativní stránky. Pokud uživatelé nepřistupují ke službám z kontrolovaného prostředí, pak nemají jistotu, zda přihlašovací údaje zadávají své domovské instituci. 4 Federace v medicínském prostředí V rámci projektu MediGrid jsme narazili na problém, který je současnými nástroji takřka neřešitelný, ale který lze elegantně vyřešit pomocí federovaného uspořádání. Tímto problémem je správa přístupu k informačnímu systému, který udržuje informace o interakcích mezi léky a který je nutné neustále rozvíjet a přidávat k němu 83

151 Vybraný příspěvek 139 nově objevené interakce. Současná legislativa přikazuje každému lékaři hlásit nově objevenou interakci tak, aby byla dostupná všem ostatním lékařům i veřejnosti. V současné době však není k dispozici informační systém, který by uživatelům dovoloval taková data udržovat a vyhledávat v databázi známých interakcí. Primárním důvodem proč takový systém neexistuje je absence mechanismů, které by umožňovaly poznat lékaře mezi všemi uživateli, kteří k systému přistupují. Systém z principu svého fungování musí fungovat jako obecně dostupná služba, odkud informace může číst kdokoliv, ale pouze lékaři jsou oprávněni data vkládat a měnit. Veškeré změny musí samozřejmě být auditovatelné tak, aby bylo možné dohledat uživatele, který změnu provedl. Jak jsme diskutovali v předchozí části příspěvku, není samozřejmě reálné vybavit všechny lékaře jménem a heslem nebo jinými autentizačními údaji, které budou určeny pro přístup k takovému systému. Správa interakcí není jediným systémem, ke kterému je potřeba řídit přístup na základě profesních atributů. Lékařská komunita například využívá služeb portálu mediclub.cz, který ale obsahuje informace, které by měly být přístupné pouze lékařské veřejnosti. V současnosti se problém omezení přístupu řeší čestným prohlášením uživatele, při prvním přístupu na stránku, což samozřejmě není nijak spolehlivá metoda ověření. Současné technologie tedy neposkytují dostatečné nástroje pro spolehlivou realizaci řízení přístupu k těmto lékařským systémům. Na druhou stranu se ovšem přímo nabízí využít federační technologie a na nich založených mechanismů pro správu uživatelů a řízení přístupu. 4.1 Budování systému pro správu interakcí V rámci projektu MediGrid jsme se tedy rozhodli vybudovat experimentální systém založený na federačním modelu, který bude nabízet manipulaci s informacemi o interakcích léků. Tato aktivita má sloužit třem hlavním cílům: 1. lékařům umožní vyzkoušet systém pro správu informací o interakcích 2. seznámí uživatele (tj. především lékaře) s mechanismy federací 3. poskytne potřebnou zpětnou vazbu, kterou budeme moci využít pro návrh dalších systémů, založených na federačním uspořádání Vzhledem k tomu, že cílem je primárně demonstrovat použitelnost federačních technik, je funkcionalita vlastní aplikace poměrně jednoduchá. Jejím primárním úkolem je umožnit lékařům zadávat interakce ke dvěma lékům a takto zadané informace spravovat v databázi, jejíž obsah je veřejně přístupný. V současně době je hotová ověřovací implementace této služby, která realizuje popsanou funkcionalitu přes webové rozhraní84. V současně době jsou informace o lécích a jejich interakcích dynamicky stahovány z veřejné databáze Státního ústavu pro kontrolu léčiv (SÚKL). Pomocí webového formuláře uživatel nejprve zadá názvy dvou léků o jejichž vzájemnou interakci se zajímá. Protože zpravidla existuje více léků stejného jména (např. od různých výrobců), aplikace nabídne uživateli seznam všech registrovaných léků, které mají stejný název a uživatel si zvolí požadovaný lék podle jeho kódu. Následně aplikace zobrazí ke každému léku popis jeho interakcí. Pro léky, které nemá aplikace ve své databází se zobrazí informace získaná z veřejně dostupných informací na SÚKL. 84

152 140 D. Kouřil a kol.: Nasazení federací ve velkém distribuovaném prostředí: systém pro správu interakcí léků Pro zobrazení těchto informací nejsou potřeba žádná specifická oprávnění a informace jsou veřejně přístupné. Pokud si však uživatel přeje změnit stávající popis interakce nebo přidat nový, musí prokázat, že je lékařem. K tomuto účelu jsme naši aplikaci napojili na federaci CZTestFed, která spravuje informace informace o uživatelích ze zapojených institucí. Napojení na federaci CZTestFed je realizováno pomocí softwarového vybavení, které nabízí projekt Shibboleth. Zejména se jedná o démon shibd, který je zodpovědný za komunikaci s IdP uživatele a získávání jeho atributů. Pomocí těchto nástrojů jsme realizovali proces přihlašování k naší aplikaci, který je aktivován, pokud uživatel chce měnit interakce. Autentizace tak odpovídá standardnímu procesu ve federačním prostředí, kdy je uživatel nejprve přesměrován na svou domovskou instituci, kde se autentizuje a poté je jeho prohlížeč přesměrován zpět na aplikaci. Aplikace si poté vyžádá atributy o uživateli od jeho domovského IdP a provede rozhodnutí o poskytnutí přístupu ke službě. Jelikož právo měnit záznamy mají pouze lékaři, aplikace musí vyhodnotit, zda daný uživatel je lékařem. Přesná podoba vyhodnocování není ještě ustálená a může se také lišit pro jednotlivé IdP. V současné době za lékaře považujeme držitele titulu MUDr., tj. uživatele v jehož atributech je položka,,titul obsahující řetězec MUDr. Pro nasazení v lékařském prostředí samozřejmě musíme mít IdP na každé instituci, která lékaře organizačně spravuje. V pilotní fázi aktivity usilujeme o ustavení takové služby u nemocnic, které se účastní projektu MediGrid. Každá z těchto institucí spravuje svůj informační systém, ke kterému poskytuje autentizovaný přístup svým uživatelům a ve kterém spravuje informace o uživatelích, zejména o tom, zda pracují jako lékaři. Vedle tohoto systému lze postavit samostatný IdP, který bude přebírat část dat z hlavního systému a zpřístupňovat je poskytovatelům služeb ve federaci. V současné době je v ověřovacím provozu IdP Masarykovy nemocnice v Ústí nad Labem, od jehož provozu očekáváme získání zkušeností pro nasazení IdP i v jiných lékařských zařízeních. Díky federační infrastruktuře bude služba pro správu interakcí otevřena všem lékařům ze zapojených institucí. Vzhledem k autentizaci bude možné provádět audit změn, tj. sledovat kdo provedl kterou změnu v seznamu interakcí. V pilotní fázi bude systém otevřen pro uživatele, jejichž organizace poskytuje IdP kompatibilní se systémem Shibboleth. Pro uživatele, kteří nejsou pokryti takovou službou poskytneme nezávislý IdP umožňující uživatelům přístup k omezené funkcionalitě aplikace tak, aby mohli lépe pochopit jak její principy, tak i základy federačních mechanismů. Tato služba bude založena na IdP, který provozujeme pro účastníky projektu METACentrum. 5 Závěr V příspěvku jsme představili model federací, který lze využít pro efektivní správu uživatelů v rozsáhlém distribuovaném prostředí. Popsali jsme problém správy interakcí léků, který nelze reálně řešit současnými prostředky a popsali aktivitu pro implementaci takového systému nad federačním modelem.

153 Vybraný příspěvek Poděkování Tento výzkum je podporován z prostředků výzkumného záměru,,optická síť národního výzkumu a její nové aplikace (MSM ) a výzkumného projektu,,medigrid - metody a nástroje pro využití sítě Grid v biomedicíně (Akademie věd ČR, grant T ). Literatura 1. R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF RFC April C. Rigney, S. Willens, A. Rubens, W. Simpson. Remote Authentication Dial In User Service (RADIUS). IETF RFC June S. Cantor. Shibboleth Architecture Protocols and Profiles. September L. Florio, K. Wierenga. Eduroam, providing mobility for roaming users. In Proceedings of the EUNIS 2005 Conference, Manchester, S. Cantor, J. Kemp, et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. Organization for the Advancement of Structured Information Standards (OASIS), Billerica, MA, Annotation: Deployment Federations in Large Distributed environment: a System for Drugs Interaction Management We provide an overview of the federalization model and describe how federations can be used to address problems that cannot be solved using current tools. Than we describe a system for management of drugs interactions allowing physicians to maintain information on drugs. The systems demonstrates how federations can be used to implement an easy-to-use application without the need distribute new sets of credentials.

154 Úložiště dat v servisně orientovaných systémech Jaroslav KRÁL 1,2, Michal ŽEMLIČKA 1 1 Katedra softwarového inženýrství, MFF UK Praha Malostranské nám. 25, Praha kral@ksi.mff.cuni.cz, zemlicka@ksi.mff.cuni.cz 2 Katedra počítačových systémů a komunikací, FI MU Brno Botanická 68a, Brno kral@fi.muni.cz Abstrakt. Servisní orientace a servisně orientovaná architektura (SOA) bývá implementována různým způsobem. Pro takové systémy článek diskutuje integraci existujících aplikací a to i takových, které pracují v dávce. Ukazuje se, že tato implementace je vhodná i pro podporu byznys procesů. Je ukázáno, že je výhodné použít službu DS zapouzdřující datová úložiště. DS může být použita k podpoře komplexních variant komunikačních protokolů a k virtualizaci přístupu k datům. DS lze použít k obejití potřeby využívat centrální služby při řízení byznys procesů. Centrální služby jsou cizím elementem v SOA. Spolu s DS jsou diskutovány další typy služeb na podporu SOA, jako jsou předřazené brány a manažeři procesů. Je ukázáno, že všechny tyto typy služeb lze chápat jako varianty služby implementující zobecněné Petriho místo. Klíčová slova: předřazená brána, strukturovaná analýza v SOA, datová úložiště v SOA, zobecněné Petriho místo. 1 Úvod Servisní orientace je technologie, o které kdekdo tvrdí, že ví, o co se jedná, a že je to právě to, co umí. To vede k tomu, že se za servisně orientované systémy považují systémy, které mají velmi rozdílné vlastnosti i z hlediska architektury. Pak se nelze divit, že servisní orientace je mnohdy považována za marketingový trik. A často dokonce jen obálka umožňující skrýt zastaralé technologie za přitažlivým rozhraním. Takové postoje známé jako antipattern Well, What s New? [2] mohou výrazně ohrozit využití servisně orientovaných přístupů,které jsou rozhodujícím prostředkem metod tvorby softwaru. Domníváme se, že je žádoucí se zaměřit na tu oblast a zúžit pojem servisní orientace tak, aby ten pojem byl relativně úzký a přitom pokrýval nejdůležitější oblasti aplikací především oblast velkých systémů. Ukážeme, že takové zúžení má smysl a je vhodné právě pro takové aplikace jako jsou velké podnikové systémy, e-government, atd. Ukážeme, že v této oblasti je servisní orientace v tomto zúženém smyslu jediná schůdná cesta vybudování a modernizace velkých systémů a je to zároveň cesta k tomu, aby se software stal L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

155 Vybraný příspěvek 143 moderním hi-tech produktem v obecném smyslu. Jako servisně orientované systémy budeme rozumně rozumět virtuální peer-to-peer systémy, kde uzly se chovají podobně jako služba v lidské společnosti. Budeme ji nazývat softwarová služba na rozdíl od IT-služby ve smyslu např. [9]. Z našich předpokladů plyne, že softwarové služby jsou permanentně aktivní procesy vzájemně komunikující prostřednictvím middlewaru obvykle asynchronním způsobem. Softwarové služby nemusí být (ale mohou být) webové služby, middlewarem může, ale nemusí být Internet. Middleware dokonce nemusí být založen na jediné technologii, může být tvořen např. na protokolech TCP/IP, na message queues, na komunikaci přes datová úložiště, atd. Použití servisní orientace v našem smyslu je nutností v řadě oborů. Může být překvapující, že principy SOA jsou nejen známy, ale i používány v oblasti řízení procesů po desetiletí. Ještě více překvapující je fakt, že tato skutečnost je jedním z důvodů pomalého prosazování servisní orientace, neboť vzniká falešný dojem, že servisní orientace není nic nového. Tento přístup jsme výše diskutovali jako SOA antipattern "Well, What's New?". Ukážeme, že servisní orientace ve většině případů musí integrovat existující aplikace a, což je ještě obtížnější, koncové uživatele. Ještě více překvapivé je, že jak z důvodu znovupoužitelnosti, tak i z důvodů věcných je třeba použít postupy známé z oblasti strukturovaného vývoje (např. použít datová úložiště a subsystémy pracující v dávce). 2 Servisní orientace jako paradigma Hlavní problém využití servisní orientace je fakt, že se jedná o samostatné specifické paradigma. Je totiž obecně známo, že nové paradigma vyžaduje specifické nástroje, specifické dovednosti a specifické způsoby myšlení, nové obchodní přístupy a změny praxe. V neposlední řadě i podstatné změny ve výchově a školení specialistů v dané oblasti. Taková výchova je ale v případě servisní orientace velmi obtížně uskutečnitelná během klasického VŠ studia, neboť vyžaduje kontakt s rozsáhlými systémy, jejichž kvalitní práce je zásadně důležitá pro chod velkých podniků. Pro odborníky z praxe je frustrující, že musí opustit zavedené dovednosti, změnit vývojové procesy a musí projít školením. Někdy to znamená, že starší generace vůbec není schopná se s tím vyrovnat. Zmapujeme tento problém na příkladu vzorů a antivzorů, které jsou výrazně rozdílné pro objektově orientované a servisně orientované přístupy. Některé objektové vzory (viz např. [5]) jsou servisními antivzory a naopak. Příklady: Existující aplikace (legacy systems) Využití existujících aplikací je jeden ze základních antivzorů v objektové oblasti. To je známo jako antivzor "Ostrov automatizace či "Stovepipe system" [3]. V servisní orientaci je to ale zásadní vzor, neboť nové aplikace mohou vzniknout právě integrací existujících aplikací. Pokud to uskutečníme s využitím výhod přenosu zpráv přes vhodný middleware, dosáhneme úrovně znovupoužitelnosti, která není dosažitelná v objektovém případě. To zároveň umožňuje snížit náklady přeškolováním specialistů s konverzí dat, insourcingem a outsourcingem, a postupnou modernizaci systému.

156 144 J. Král, M. Žemlička: Úložiště dat v servisně orientovaných systémech Dávkové (batch) systémy Jiným příkladem je možnost využití klasických dávkových systémů propojených prostřednictvím specifických služeb zapouzdřujících funkcionalitu datových úložišť a umožňujících propojení dávkových a interaktivních systémů. To má dva efekty. Některé existující dávkové systémy se nemusí přepisovat. Navíc můžeme používat takové algoritmy, které např. při rozvrhování vyžadují příliš dlouhý čas běhu (jsou nevhodné k interaktivní práci a musí tedy pracovat dávkovým způsobem). Všimněme si, že v tomto případě se v servisní orientaci považuje za vzor využití tzv. funkční dekompozice, což je v objektové orientaci antivzor [3]. Dávková služba řídící zprávy uživatelé nebo řídící služby Vstupní/výstupní soubor Architekturní služba Datové úložiště ostatní služby Obr.1: Dávkové služby v servisně orientované architektuře Na druhé straně je všeobecně známo, že metody v objektově orientovaných systémech mají tendenci být jemnozrnné (fine-grained). To se považuje za správný vzor. Přenesením tohoto pravidla do prostředí služeb dostáváme však antivzor jemnozrnné služby (Fine-Grained Services, [2]). Je tedy patrné, že přístupy servisní orientace se od objektově orientovaného přístupu výrazně liší. 3 Datová úložiště jako služba Datová úložiště jsou nejvhodnější způsob propojování dávkových systémů, což je dobře známo ze strukturovaného návrhu [11] a z pravidel vytváření návrhů toků dat. V servisně orientovaných systémech je důležité, aby se datová úložiště chovala stejně, jako standardní služby, tj. jako uzly virtuální p2p sítě. Služba datové úložiště má pak rozhraní ukázané na obr. 1. Datové úložiště je ovládáno vhodnými kontrolními příkazy předávanými např. přes middleware. Dávkové služby ukládají své výstupy do služby datové úložiště. Naopak dávkový subsystém může číst data z datového úložiště, je-li to požadováno řídícím příkazem.

157 Vybraný příspěvek 145 Jinými slovy jde o implementaci funkcionální dekompozice v prostředí servisní orientace. Důležitou výhodou funkcionální dekompozice je fakt, že dávkové služby mohou být velmi snadno oustsourcovány. Existují outsourcingové firmy, které těží právě z tohoto faktu. Funkcionální dekompozice je tedy osvědčené řešení s dobrými výsledky, jako je znovupoužitelnost, outsourcovatelnost, srozumitelnost pro uživatele. Služba typu Datové úložiště umožňuje uplatnit prvky funkcionální dekompozice v SOA s obdobně výhodnými vlastnostmi jako měly systémy založené na principech strukturovaného návrhu. Musíme připomenout, že funkcionální dekompozice (známá též jako ostrovy automatizace ) je pro objektové vývojáře důležitým antivzorem (tj. často používaným nevhodným řešením) na rozdíl od SOA, kde je řešením dobrým a úspěšným. Příklady, kdy je použití datových úložišť žádoucí až nutné: 1. Některé procesy nemohou být spouštěny on-line, protože jsou příliš náročné na čas. Důvodem může být časová a datová náročnost algoritmů v nich použitých, případně to, že interagují s reálným světem (např. s uživateli). Příkladem mohou být plánovací a rozvrhovací úlohy. 2. Pokud může být nějaký proces používán jako dávkový, může být výhodné jej jako dávkový (tj. komunikující s okolím přes služby datová úložiště) koncipovat z důvodu snazší implementace, jednoduššího outsourcingu a větší bezpečnosti a spolehlivosti. 3. Datová úložiště mohou být použita k implementaci důmyslných komunikačních protokolů (např. zobecněný publish-subscribe protokol) nebo k umožnění zásahů oprávněných/zodpovědných uživatelů do komunikace (např. pro interaktivní změny adresátů v byznys procesech). 4. Datové úložiště může být použito jako prostředek pro implementaci nástrojů pro tvorbu žurnálů komunikace s cílem umožnit analýzu a dohled uživatelů systému, analýzu efektivnosti práce systému i jako ladící nástroj. 5. Datová úložiště mohou být použita jako řešení dilematu: v SOA se neosvědčují služby mající z logického hlediska centrální pozici. Příkladem takové služby jsou centrální repozitáře, jako je UDDI 85 [10]. Pomocí vhodných typů služeb (srv. Process Manager popsaný níže) lze najít vyvážené řešení, kdy služba může mít centrální pozici, ale nemusí být využívána, neníli to výhodné. 4 Uživatelsky orientovaná rozhraní Funkcionální dekompozice vede k vytváření služeb, pro které bývá snadné implementovat rozhraní tak, že je hrubozrnné a snadno pochopitelné pro uživatele. Tato rozhraní jsou např. podobná komunikaci se službami reálného světa (jejich rozhraní). Takto navržené zprávy i rozhraní, která je využívají, jsou srozumitelné pro uživatele, a proto je nazveme uživatelsky orientované. 85 Centrální repozitář zpráv v nástroji BizTalk od Microsoftu je pravděpodobně hlavní příčinou nižší úspěšnosti tohoto produktu

158 146 J. Král, M. Žemlička: Úložiště dat v servisně orientovaných systémech Jsou-li zprávy uživatelsky orientované, lze celkem snadno implementovat datová úložiště, která mají výše uvedené výhody. Uživatelsky orientovaná rozhraní mají další podstatné přednosti: 1. Jsou málo ovlivněna implementačními detaily a tedy jsou stabilní (je málo důvodů je měnit z implementačních i věcných důvodů) to je způsobeno tím, že vycházejí z již dlouhou dobu používaných a víceméně neměnných rozhraní reálného světa a jsou spíše deklarativní a hrubozrnná a jsou tedy zpravidla nezávislá na implementačních detailech. 2. Služby s uživatelským rozhraním bývají autonomní a s využitím nástrojů jako jsou obrazovkové prototypy založené na přesměrovávání zpráv [7] je možné je vyvíjet jako téměř nezávislé aplikace. 3. Nad službami s uživatelským rozhraním lze snáze budovat byznys procesy (snáze se implementuje orchestrace takovýchto služeb viz služby proces manažer popsané níže). Navíc lze poměrně snadno implementovat dohled, tj. kontrolu a potvrzování jednotlivých kroků procesů. To je podmínka pro to, aby někdo mohl být odpovědný za obchodní důsledky procesů. Zároveň to umožňuje, aby vlastník procesu mohl agilně (on-line) mohl měnit strukturu procesu při výpadcích. 4. Poněvadž uživatelsky orientovaná rozhraní dobře zakrývají implementační detaily, není nutné příslušnou službu měnit jen proto, že je založena na zastaralé technologii. 5 Další výhody integrace existujících aplikací Vybavíme-li existující aplikaci (legacy system, LS) vhodným rozhraním (to by mělo umožňovat asynchronní komunikaci, což nemusí být vždy snadné; může to vyžadovat využití datových úložišť jako je MQ od IBM), můžeme LS integrovat technicky celkem snadno. To přináší kromě toho, co jsme uvedli výše, mnoho dalších výhod: 1. Integrace umožňuje znovupoužitelnost a tím přímé úspory 2. Správně provedená integrace LS otevírá cestu k tomu, že lze používat daný subsystém pro existující funkce téměř beze změn. To znamená podstatné úspory, neboť to snižuje náklady na přeškolení uživatelů a množství problémů způsobených uživateli, kteří zatím dostatečně nezvládli nový systém. 3. Existují i další subtilnější výhody. Jednotlivá oddělení mohou systém používat s důvěrou, protože z jejich hlediska nejdůležitější subsystémy zůstaly takové, jak byly kdysi navrženy jsou stále jejich. Mohou dokonce snáze prosazovat své návrhy. To zvyšuje pocit autonomie a nakonec zvyšuje i politický vliv dané organizační jednotky. 4. V některých oblastech nelze jinak. To platí například pro integraci informačních systémů (IS) jednotlivých úřadů při budování e-governmentu. Podobná situace je i při implementaci pokročilých technik spolupráce s obchodními partnery v SCM a CRM. Pak je nutná přímá spolupráce informačních systémů účastníků této spolupráce.

159 Vybraný příspěvek Tento přístup usnadňuje integraci nově koupených součástí a usnadňuje outsourcing. 6. Lze vytvořit virtuální centrální databázi, tj. databázi s rozhraním centrální databáze, která je však de facto rozptýlena po jednotlivých službách. Pokud mají služby nevhodné rozhraní, lze rozhraní zlepšit s využitím technologie předřazených bran (viz níže). 6 Databáze jako sítě služeb Jak jsme uvedli, v servisně orientovaných systémech není výhodné, aby se v nich využívaly centrální služby tedy ani databáze. Dle [4] není řešením ani replikace dat. Řešením je často ponechání dat na místě, kde vznikla 86 a přístup k datům koncipovat jako kompozitní službu [8]. Zde je ale jeden podstatný problém kvalita dat. Jaká má být kvalita dat z (virtuálního) datového úložiště vzniklého virtuální integrací dat různé kvality? Při současném stavu znalostí (a možná, že navždy) bude asi o kvalitě celku muset rozhodovat uživatel, neboť jen on ví, co je žádoucí a možné. Jinými slovy virtuální síť dat nebude zpravidla zcela integrována a její integrace zcela zautomatizována 87. Probereme nyní některé důvody podrobněji: 1. Kvalita dat a informací jako multidimenzionální koncept závisí na potřebách a cílech uživatelů a také na aplikacích, které s daty pracují. 2. Různí uživatelé využívají (musí využívat) různé charakteristiky kvality a různé metody hodnocení kvality. Například data nepoužitelná v účetnictví mohou být velmi dobré kvality pro management nebo statistické výpočty. 3. Služby v SOA jsou autonomní a mohou proto poskytovat/potřebovat data různé kvality a různé struktury. 7 Manažeři procesů Byznys procesy nemohou z principu být plně automatizované v tom smyslu, že neumožňují ruční zásahy do svého chodu. Je sice možné požadovat, aby za jistých okolností proběhly bez zásahu člověka. Zásahy člověka ale musí být možné. Důvody jsou tyto: 1. Byznys proces je založen na využívání dat, která nejsou vždy dostupná v dostatečné kvalitě. Data mohou být nepřesná, dočasně nedostupná, neúplná, atp. 2. Data nebo i model procesu nemusí být použitelný, neboť se změnily obchodní podmínky nebo došlo k výpadkům až škodám. 3. Odpovědný pracovník ( vlastník procesu) musí mít možnost (často má dokonce i povinnost) potvrdit klíčové obchodní kroky. Jinak by nebyl nikdo odpovědný za případné škody. 86 Tedy uvnitř jednotlivých služeb. Tento přístup je důležitý pro aplikace na webu. 87 Malá poznámka: toto drobnost může být hlavním důvodem zatím malého úspěchu Sémantického webu. Plná transparentnost přístupu k datům může být chiméra.

160 148 J. Král, M. Žemlička: Úložiště dat v servisně orientovaných systémech 4. Model M (definice) procesu by měl být uložen jako část byznys inteligence (BI). Je žádoucí z důvodu zachování BI, aby model M mohl být definován různými prostředky jako jsou BPEL [1], Aris [6], text, atd. Aby byly použitelné modely kdysi dávno zapsané v těchto prostředcích. 5. Je žádoucí, aby repozitář modelů mohl existovat jako distribuovaná databáze kontaktovaná co nejméně (viz omezení vlivu centrální služby diskutované výše). Těmto požadavkům například vyhovuje níže uvedený architekturní a návrhový vzor Manažer procesů. 1. Během aktivace byznys procesu BP je nejprve na žádost budoucího vlastníka V procesu BP vygenerována nová služba (tj. nový uzel p2p sítě) P. P nazveme manažerem procesu BP. Při vytváření P může být využit model M procesu BP uložený ve vhodném úložišti. V konečné fázi generace P je model M transformován do tvaru řídících dat C. Načtení M z repozitáře může být alternativně nahrazeno zadáním M vlastníkem V. P může mít vlastní uživatelské rozhraní. 2. Při běhu BP jsou data z C využívána ke generovaní (obvykle asynchronních) volání služeb potřebných k provedení BP. V krizových situacích může vlastník V data C modifikovat agilně (interaktivně). 3. V je průběžně informován o průběhu procesu a může případně potvrzovat jednotlivé kritické kroky. Tato jeho úloha je podstatně usnadněna, jsou-li rozhraní služeb uživatelsky orientována. P je jednoduše implementovatelný nástroj na orchestraci služeb. 8 Zobecněná Petriho místa V servisně orientovaných systémech musíme často měnit formáty zpráv tak, aby byly uživatelsky orientované. Tato vlastnost může záviset na typu adresáta. To lze implementovat pomocí služby zvané předřazená brána (front-end gate, FEG). Můžeme potřebovat více rozhraní (portálů) a potřebujeme i nástroj na integraci (kompozici) služeb. Všechny tyto potřeby můžeme pokrýt službami, které nazveme architekturními službami. Je rozumné chápat je společně s datovými úložišti jako zjednodušení služby, kterou nazveme zobecněné Petriho místo (generalized Petri place, GPP).

161 Vybraný příspěvek 149 Řídící zprávy Zdrojové služby Zobecněné Petriho místo (GPP) Cílové služby Obr. 2: Zobecněné Petriho místo (zjednodušeno) GPP (Obr. 2) je služba přijímající n-tice vstupních XML zpráv a transformující je v m-tice výstupních zpráv (srv. XSLT 2.0). GPP může přitom využívat datový sklad a být řízena zprávami, obvykle od obsluhy. Předřazená brána (FEG) v každém okamžiku dostává nejvýše jednu zprávu od tak zvaných partnerů a transformuje ji do jedné nebo více zpráv pro službu S, pro níž funguje jako proxy (obr. 3). Naopak G transformuje zprávy od S do tvaru vhodného pro partnery. Portál Portál Middleware Předřazená brána Předřazená brána Předřazená brána brána Aplikace brána Stávající systém Obr. 3: Vícenásobné předřazené brány

162 150 J. Král, M. Žemlička: Úložiště dat v servisně orientovaných systémech Kompozitní služba tvořená službami S 1 až S k může být vytvářena tak, že použijeme GPP ve tvaru z Obr. 4 (nemá databázi ani řídící zprávy). Je navíc splněna podmínka, že každá zpráva od služby S 0, která není totožná se žádnou ze služeb S 1 až S k, musí být poslána přes GPP A. A naopak, každá zpráva od některé služby S 1 až S k pro S 0 musí být poslána prostřednictvím A. Portál může být chápán jako zvláštní případ předřazené brány předřazené uživatelskému rozhraní. ostatní části systému A - Záhlaví kompozitní služby služby (S i ) tvořící kompozitní službu Omezení: libovolný požadavek na službu S i od služeb z ostatních částí systému musí jít přes A. Obr. 4: Záhlaví kompozitní služby Portál služby uživatel Omezení: libovolná zpráva od uživatele či k uživateli musí projít portálem Obr. 5: Portál jako GPP a FEG 9 Závěr Ve většině servisně orientovaných systémů nemůže mít databáze centrální roli. Ve většině případů je lépe, aby data zůstala uvnitř jednotlivých služeb a byla přístupná jako virtuální a centrální databáze. Toto řešení je vyhovující, jsou-li všechna data vyhovující kvality. Pokud tomu tak není, je ve většině případů nutné, aby se virtuální integrace dat prováděla pod dohledem uživatelů. Přístup k datům je vhodné implementovat jako architekturní služby, které mohou být s výhodou použity jako zapouzdřená datová úložiště, která lze výhodně využít pro integraci aplikací běžících v dávkovém režimu, pro rozšíření možností komunikačních protokolů a virtualizaci centrální databáze.

163 Vybraný příspěvek 151 Literatura 1. Andrews, T., Curbera, F., Dholakia, H., Goland, H., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: Specification: Business process execution language for web services version 1.1, Ang, J., Cherbakov, L., Ibramim, M.: SOA antipatterns. Nov ibm.com/developerworks/webservices/library/ws-antipatterns/ 3. Brown, W.J., Malveau, R.C., McCormick, III, H.W.S., Mowbray, T.J.: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, New York, Fuller, T., Morgan, S: Data replication as an enterprise SOA antipattern. Microsoft Architect Journal, July Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, Boston, MA, IDS Scheer. Aris Process Platform Král, J., Žemlička, M: Service orientation and the quality indicators for software services. In: R. Trappl (Ed.) Cybernetics and Systems, vol. 2. Austrian Society for Cybernetic Studies, Vienna, Austria, (2004), Král, J., Žemlička, M: Crucial patterns in service-oriented architecture. In: Proceedings of ICDT 2007 Conference, IEEE CS Press, Los Alamitos, CA, USA (2007). 9. OGC the Office of Government Commerce (UK): IT Infrastructure Library, UDDI Initiative. Universal definition, discovery, and integration, version 3, Yourdon, E.: Modern Structured Analysis. Prentice-Hall, 2nd edition, Annotation: Service orientation and service-oriented architecture (SOA) can be implemented in different ways. The paper discusses integration of applications for such systems even in the case of systems having applications operating in batch mode. It seems that the proposed way of integration is suitable for the support of business processes as well. It is shown that it is advantageous to use data store (DS) services encapsulating data stores. DS can be used to support complex variants of communication protocols and for virtualizing data access. DS can be used to bypass the need to use a central service in business process control. Central services are alien elements in SOA. Together with DS there are discussed also other types of services supporting SOA as front-end gates and process managers. It is shown that all these service types can be understand as variants of a service implementing generalized Petri places.

164 Data Preparation for User Profiling Marek KUMPOŠT Department of Program Systems and Communications, Faculty of Informatics, Masaryk University Botanická 68a, Brno Abstract. This paper presents our current work on traffic log processing. Our goal is to find an approach to modelling user behaviour based on behavioural patterns. Since the amount of input data we have is really large, effective preprocessing is crucial for the profiling to provide significant results. This paper presents our approach to restricting the input data with respect to its relevance. We use histogram clustering to identify sets of users with similar frequencies of communication; entropy and TF-IDF (Term Frequency -- Inverse Document Frequency) help to select destinations that are relevant for a given set of users; PrefixSpan algorithm is used to find frequent communication patterns. Keywords: entropy, histograms, PrefixSpan, TF-IDF, user behaviour 1 Introduction User profiling is a technique that services use to provide customizable content to their users. These services operate with a user profile that reflects users' behaviour in the past (information about their interests and social background). Instead of requiring users to state their interests, a service could learn this information from users' past activities. We can learn a lot about an individual based on his context and we can also predict possible future actions by combining several types of context information in an efficient way. This can reveal some private data about users and therefore privacy protection issues must be carefully taken into consideration. A critical term here is a user profile. If we have a good profile of a user (his behaviour) we can try to find and link together similar profiles and, with some probability, identify a user in this case, of course, we do not know the real identification of a user, we just know that a given set of profiles exhibits some similarities. Accuracy of such a model is a key feature for effective predictions of users' future actions that are based on this model. The main question is how much private information can be derived from context information that is related to an individual. The second question is to what extent a behaviour pattern can be used to pinpoint an individual among others. Discovering valuable information in huge databases involves several phases such as data preprocessing and cleaning; data transformation into some common structure; data mining techniques to identify interesting patterns or correlations among parts of input L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

165 Vybraný příspěvek 153 data; interpretation of the results such as visualization or some kind of user friendly format. In this paper we would like to focus on the data pre-processing phase, which is one of the key issues for the whole process to be successful. We will introduce our approaches to working with the data, what restrictions that we use to limit the input data in a reasonable way. We will also discuss how efficient these restrictions are. Our expectations are that these restriction rules will help to optimize the input data in terms of relevance and help to focus on data that has some interrelations. One such a technique is to split data into different levels according to some characteristics and process these levels individually. This helps to concentrate on specific pieces of data. We will describe our techniques for identifying different levels of activity and different levels of relevance. Filtered data forms vectors of behaviour that are used as the input for the profiling. Again, we can use a clustering method (to find sets of users whose vectors of behaviour exhibit some similarities), but we also want to try to process the data with the PATS model (Privacy Across the Street) [4], which aims to incorporate all relevant available context information in order to find how much private information can be inferred. 2 Input data Significant user profiling cannot be successful with small amounts of input data. Thanks to our network administrators we were granted access to the global IP traffic log of our university network. This log collects information about all communication in the network and with the outside world. For every connection, both source and destination IPs are stored, as well as source and destination ports and amount of data transmitted. Tables are created every hour and at the end of each day all hourly tables get aggregated into daily tables. Daily tables are further aggregated into weekly and finally monthly tables. On average, everyday load is around rows in hourly tables. In the aggregation process irrelevant data (like SNMP and other management-based communication) is dropped to decrease the number of rows and multiple rows related to one communication are put together. Daily tables consist of rows on average. The whole dataset is stored in MySQL database on a dedicated machine. To cope with this extremely large input data in an efficient way, we have to deploy some set of restrictions that let us work with a focused piece of data. It would not be reasonable to take the whole database as such and start with some profiling techniques, since the output would not be significant in any way. Data selection and optimization is crucial to get a significant output that can be used for some future predictions of users' behaviour. There has always been a trade-off between the size of the input data and its actual relevance. On one hand, the more data we use the more accurate results we get (in terms of predictions of future actions). On the other hand, to get clearly bounded results one would start decreasing the amount of data while keeping the relevance as high as possible. We use cluster analysis to find sets of users with similar behaviour tendencies and therefore we are aiming for significant results in terms of the clustering process (i.e. reasonable number of bounded clusters). Users

166 154 M.Kumpošt: Data Preparation for User Profiling in these clusters can be explored with additional input data to find more detailed information about actual differences in behavioural characteristics. 3 Data preparation In order to get conclusive results out of the final clustering process, a careful data preparation has to be carried out. This section is dedicated to the description of our current approach, reporting interesting findings and discussing deployed mechanisms. Source IP addresses, destination IP addresses, destination port and the number of connections that were made during a particular period of time (day(s), week(s) or month(s)) is important information from the database. Putting this together, we can create a two-dimensional matrix, where each column is one destination IP and each row is one source IP address. Every cell (i,j) then contains the number of connections that were initiated from the source IP i to the destination IP j. Each row of this matrix reflects the communication pattern of a particular source IP (we can call it a vector of source IP behaviour). The idea is to process all these vectors with a clustering algorithm to get sets of similar vectors as the output. From the information above and the description of the input data in the section 2 one can easily observe that the dimensions of the matrix would be quite large. This is a problem we have to deal with, because clustering these vectors will not give very significant and reasonably interpretable results. Final dendrogram (graphical representation of a clustering process) is very detailed without any bounded clusters. In addition to the matrix dimensions there is another problem. The matrix contains many zeroes and overall is very sparse. So the aim is to decrease the dimensions and try to push the number of zeroes as low as possible. Before we describe specific approaches to optimize the matrix, we need to mention the very first set of restrictions performed with the input data. In this step we create a new table that consists of selected source IP ranges and destination ports (e.g., our faculty and ports 22,80 ssh, http). This is done both to decrease the size of the database tables and to focus on data that are expected to have some inner relations. We cannot expect great similarities across multiple departments, because of the different interests of people working there. An example of a good type of restriction can be an IP range of a particular department and a network-covered dormitory where students of this department live. We can expect that students will tend to exhibit similar activity no matter where they get connected to the network. Some kind of visualization should help to get an initial view on the data. We decided to use a simple scatter plot indicating whether there was a communication (no matter how frequent) between any two source and destination IPs. This can help to detect commonly visited destinations and some patterns of similar behaviour (as shown in the figure 1.

167 Vybraný příspěvek 155 Fig.1. Scatter plot x-axis represents destination IPs and y-axis represents source IPs; points mean that there was a communication between a source IP to a destination IP (frequencies are not considered). There is an indication of one commonly visited destination as well as some behavioural similarities. The initial restriction possibilities described above are very basic. The resulting matrix is still quite large. Data is stored in a new table so we do not need to take account of the computational time since the new table is many times smaller than the original one(s). Working with the original table(s) would be a quite hard issue, because MySQL was not originally intended for such extreme loads (when compared, applying subnet(s) restrictions in the original table(s) took tens of minutes and since we want to work with this restricted subnet(s) only, this computation would have to be done at each step). 3.1 Source IPs optimization If we want to use clustering to find sets of source IPs with similar behavioural tendencies and we expect some reasonable level of significance, we need to preprocess the set of source IPs in an efficient way. The idea is that there are several levels of source IPs activity some sources are quite passive in communication, while other sources are extremely active. If there is a set of IPs with similar behaviour, it will exhibit some similarity in frequency of communication. Therefore

168 156 M.Kumpošt: Data Preparation for User Profiling separating source IPs into different levels of activity increases the accuracy of the consecutive processes. Our approach to finding different levels of source IPs activity is quite straightforward. We build histograms for all sources to describe how many destinations were visited how many times during a preset period of time. First we find the maximum number of accesses and then create aggregated intervals of ten accesses. Then for each source IP and each interval the number of visited destinations is found (e.g., source IP A visited two destinations five times). We discovered during our experiments that the majority of records fall into the first category, that is zero to ten accesses. Therefore we decided to split the first interval into ten groups, each of which represents a specific number of accesses. Figure 2 shows such a histogram. Information from each histogram is stored as a vector to a CSV (comma-separated values) file. This file is processed with a clustering algorithm to find clusters consisting of IPs with similar frequency vectors. The set of vectors is processed with R [6] and the Ward's clustering method [8] is used. Ward's clustering method seems to be the best option for this case since it produces quite sharp and balanced clusters. Let us describe this method in a little more detail. Fig.2. Frequency plot displays frequencies of accesses. First ten levels are fixed numbers of accesses. Eleventh interval denotes accesses; twelfth interval denotes and so on. Ward's clustering procedure is somewhat different from the classical approaches that measure the distances between clusters in a geometric way. It calculates the information loss to evaluate the distances between clusters and it aims to minimize this information loss. At each step of the process, all possible cluster pairs are considered and the two clusters whose fusion gives the smallest information loss are combined. Information loss was defined by Ward in terms of an error sum-of-squares criterion (ESS). As an example, consider six values (0,0,1,1,3,3). All values in one cluster will result in ESS=9.5=2*(0-1.5) 2 +2*(1-1.5) 2 +2*(3-1.5) 2, while three clusters (0,0), (1,1), (3,3) give ESS=0 (1.5 is a mean of values). The benefits of Ward's clustering method include strong tendency to split data in groups of roughly equal size and no clusters with only one or few elements. This method is not efficient for data with large natural clusters since it will tend to split them. Our data does not have this property, so we can use this method.

169 Vybraný příspěvek 157 Classical methods such as complete linkage, single linkage or average linkage result in imbalanced dendrograms with no visible clusters. According to our experiments, the Ward's method is the best option to find different levels of source IPs communication frequencies. To process the individual sets separately, we need to know which cluster every source IP belongs to. We use R and the cutree method to cut the dendrogram by specifying either the number of cuts we want to get or a height at which a cut will be processed. After this step we have distinct sets of source IPs. The approach we have just described seems effective for reducing the size of the matrix with regard to the source IP attribute. We concentrate on IPs that show some initial similarity. This helps to produce more significant and conclusive results. This process is only one half of the whole optimization of the matrix. The other part focuses on the set of destinations and aims to decrease the second dimension of the matrix. It also helps to increase its density (minimize the number of zero cells). 3.2 Destination IPs optimization So far we have discussed our approach to source IP addresses optimization. We also have to take into account the large number of destination IPs. This step is heavily influenced by the very first restriction rules discussed in section 3. The number of destinations depends on which destination port(s) were considered (e.g. 22 ssh vs. 80 http). Based on this fact the destination IPs' optimization should be applied only if needed (contrary to the source IPs' optimization which use is reasonable under any circumstances). The goal for this optimization is both to decrease the dimensions of the matrix and to increase its density. We need to be able to differentiate between destinations to say how relevant it is for the current set of sources. Based on this knowledge we can drop (or process separately) destinations with small relevance. We use information entropy to find the distribution of visits to a particular destination. This value is computed and compared with the maximum possible entropy to learn valuable information about each destination. If there is a destination that is visited by almost all sources, its entropy will be close to the maximal entropy. This type of destinations can be dropped since their existence does not bring any new information. On the other hand, if the entropy is zero, we know that there is only one visitor. We could also drop these destinations, but here we need to be more careful. Destinations with only one source and few accesses can be dropped without any significant implications. If many (experiments showed that for http this value starts at few dozens) accesses are made by only one source, we can tell that the source is really interested in that destination. This helps a lot to identify a source IP, especially if this interest persists for a long period of time. There is another technique that can be used to evaluate destination relevance. This approach is very widely know in the text mining and information retrieval area and is called TF-IDF (Term Frequency Inverse Document Frequency) [1,2]. TF-IDF is a weight used to evaluate the importance a word is to a document in a collection of documents. Inverse document frequency is a measure of the general importance of the term in a set of documents. The formula for TF-IDF is [1]: weight i, j) tf log ( n / df ), if tf 1, ( = i, j 2 i i, j

170 158 M.Kumpošt: Data Preparation for User Profiling where tf i,j is the number of occurrences of the i-th term within the j-th document d j and df i is the number of documents (out of n) in which the term appears. If we consider one destination IP as a term and a vector that describes source IP behaviour as a document, we can use TF-IDF to evaluate the importance of a given destination for a given source in a collection of all sources and destinations. If we do not use TF-IDF, but only IDF (log 2 (n/df i )), we can generalize the approach to evaluate how important a destination is for a given set of sources. This is precisely what we are interested in. Boundaries within which IDF falls range from zero (this is the case where every source visited that destination log 2 (n/n)) to log 2 (n/1) (this is the case where only one source visited that destination). It can be easily seen that the upper bound log 2 (n) is actually the maximal possible entropy. Entropy and IDF are in negative correlation with increasing entropy IDF decreases and vice versa. IDF evaluates destination relevance and relies on the number of sources that visited that destination. The IDF weight will be same for those destinations with the same number of sources. Entropy for destinations with the same number of sources will vary because a probability of a visit is also considered. We can use both facts to identify different levels of destinations with more evenly distributed visits. If we sort destinations based on IDF into a descending order and use entropy as a second criterion we can identify those levels. For each level of IDF we select the destination with the highest entropy. Using this approach (or a modification of it) we are able to distinguish different levels of interest that help to decrease the matrix dimensions and bring more focused information into the profiling process. If there is a set of users with similar behaviour then the sequence of destinations will be same. Therefore we can consider using a sequential pattern mining algorithm to search for frequent sequences of destinations in the matrix of IPs. With this information we can process these destinations separately, find respective source IPs and observe their behavioural characteristics. We use PrefixSpan [5] a sequence mining algorithm which recursively searches for frequent pattern by projecting a sequence database into a set of smaller databases based on frequent prefix mined so far. Sequences identified with PrefixSpan do not need to be continuous in the input file. As an example let assume that the input files contains a, b, d, e, f, h as a set of destinations visited by source IP A and c, b, g, e, f as a set of destinations visited by source B. PrefixSpan will find (in addition to b, f and e, f) two occurrences of a sequence b, e, f. In order to use PrefixSpan we have to decide the ordering of input sequences. Currently we simply sort destination IPs in ascending order and store these sequences for each source IP. This input is then processed with the PrefixSpan algorithm. PrefixSpan supports several options for the processing process such as minimal support minimal number of occurrences of sequences and minimal length of a sequence. Output is in form of frequent sequences and number of their occurrences. Experiments done so far produced many sequences (sometimes very long) with more than three occurrences. Processing these destinations separately reveals corresponding source IPs that performed this communication. This approach can significantly help to decrease the matrix dimensions and to concentrate on a very specific subset(s) of the original matrix.

171 Vybraný příspěvek Behaviour profiles clustering After we apply some of the restrictions described in section 3, we obtain a matrix of behavioural vectors with decreased dimensions and fever zero cells. Rows of the matrix describe each source IP behaviour and form a vector. These vectors can be then processed using cluster analysis to find sets of source IPs that tend to have similar behaviour (with respect to the restrictions we applied). Our goal for this paper was to describe the data preparation phase and therefore we do not present any detailed information about the process of the final clustering. But from the experiments done so far we were able to find different sets of sources with similar behaviour and the results were more significant when we applied the restrictions described above. 5 Conclusion and future work In this paper we have presented our current work on user profiling, particularly the data preparation phase, which is crucial for the profiling to be both significant and successful. We discussed the data that we work with and since the input is extremely large, we pointed out that methods for its optimization are of great importance. It would not be reasonable to work with the whole dataset, because it consists of several interrelated parts and putting them onto the same level would decrease the significance of results. We discussed our methods for decreasing the matrix of behavioural vectors so as to make it contain relevant information; its dimensions are of some reasonably size; and the number of zero cells is minimal. We use histogram clustering to identify different levels of activity and entropy, together with IDF, to identify different levels of destinations. This approach seems to work well and helps a lot to optimize the input data in terms of relevance. During the process of level identification, some information is dropped, but once we have the levels formed we can use more input data as a basis for a more detailed investigation. PrefixSpan frequent sequences mining algorithm is used for searching for small sets of destinations that are frequently visited. This helps to identify sources with same communication patterns. During the deployment of these restrictions many other possibilities arose, so there are other open possibilities to test (mainly the destination IPs restriction approach). Experiments done so far showed that this way of data preparation has a positive impact on the final clustering and increases the significance of results. At this time, applying these restriction rules is only semi-automatic, but we intend to try to make the preprocessing phase more automatic in the future. Since there is (still) no way of getting the name of a real person, who used a source IP, we need to split the data into training and testing parts. The latter will be pseudonymized, which will let us verify whether our predictions based on the training set were true or false.

172 160 M.Kumpošt: Data Preparation for User Profiling References 1. Michael Berry. Survey of Text Mining: Clustering, Classification, and Retrieval. Springer, 1 edition, September Jae-Woo Lee and Doo-Kwon Baik. A Model for Extracting Keywords of Document Using Term Frequency and Distribution. In Alexander F. Gelbukh, editor, Computational Linguistics and Intelligent Text Processing, 5th International Conference, CICLing 2004, volume 2945 of Lecture Notes in Computer Science, pages Springer, M. Levin. B. Mirkin, Mathematical Classification and Clustering. Journal of Global Optimization, 12(1): , V. Matyáš and D. Cvrček. On the Role of Contextual Information for Privacy Attacks and Classification. In Privacy and Security Aspects of Data Mining Workshop, Brighton, UK, November IEEE ICDM. 5. J. Pei, J. Han, Mortazavi B. Asl, H. Pinto, Q. Chen, U. Dayal, and M. C. Hsu. PrefixSpan: Mining Sequential Patterns Efficiently by Prefix-Projected Pattern Growth. In ICDE 01: Proceedings of the 17th International Conference on Data Engineering, page 215, Washington, DC, USA, IEEE Computer Society. 6. R Development Core Team. R: A Language and Environment for Statistical Computing. R Foundation for Statistical Computing, Vienna, Austria, ISBN Stephen Robertson. Understanding Inverse Document Frequency: On Theoretical Arguments for IDF. Journal of Documentation, 60(5): , Joe H. Ward. Hierarchical Grouping to Optimize an Objective Function. Journal of the American Statistical Association, 58(301): , Annotation: Příprava dat pro profilování uživatelů V článku se zabývame metodami přípravy dat pro profilování uživatelů. Příprava je nutná z důvodu velikosti a rozmanitosti vstupních dat. Vlastní příprava dat, kromě snížení velikosti, má význam v tom, že data po optimalizaci již mají určitý vnitřní vztah. V článku jsou diskutovány techniky pro dosažení tohoto cíle: shlukování histogramů je použito k identifikaci množin uživatelů s podobnými frekvencemi komunikace; entropie a TF-IDF (Term Frequency - Inverse Document Frequency) pomáhá určit destinace, které jsou relevantní pro danou množinu uživatelů; algoritmus PrefixSpan je použit k vyhledávání často se vyskytujících vzorů komunikace. Filtrovaná vstupní data jsou zpracována pomocí shlukováé analýzy pro nalezení množin uživatelů, které vykazují podobnosti v profilech chování.

173 Testování kvality snímků otisků prstů Filip ORSÁG 1, Martin DRAHANSKÝ 2 1 Fakulta informačních technologií, Vysoké učení technické v Brně Božetěchova 22, Brno orsag@fit.vutbr.cz 2 Fakulta informačních technologií, Vysoké učení technické v Brně Božetěchova 22, Brno drahan@fit.vutbr.cz Abstrakt. Článek se zabývá metodami měření kvality snímků otisků prstů. Jsou zde představeny metody evaluace kvality snímků otisků prstů poskytnutých dostupnými senzory. Tyto metody jsou založeny na různých principech: kontrast snímku, separabilita histogram a sledování papilárních linií otisku prstu. Klíčová slova: otisk prstu, kvalita, kontrast, histogram, papilární linie. 1 Hodnocení kvality snímku otisku prstu Přesně definovat pojem kvalita snímku je téměř nemožné. Pro různé situace je možné definovat různé požadavky kladené na snímek, tj. jednou hraje velmi důležitou roli například kontrast, jindy je důležitá spojitost přechodů mezi zobrazenými elementy atd. Obecná, pro všechny typy snímků platná definice neexistuje. Speciálně v případě otisků prstů můžeme nalézt několik typických vlastností, s jejichž pomocí můžeme změřit kvalitu snímku otisku. K hodnocení kvality snímků otisků prstů můžeme použít některou z metod, nebo jejich kombinaci, uváděných v tomto článku. 1.1 Kontrast Kontrast snímku je definován jako lokální změna intenzity v jednotlivých elementech snímku, přičemž pro tyto účely rozlišujeme dva typy kontrastů [2, 3] Weberův a Michelsonův kontrast. Weberův kontrast je definován takto: C Weber L L =, (1) kde L je intenzita pozadí a L je rozdíl mezi intenzitami elementů v popředí a pozadí snímku. Popředím snímku rozumíme u snímků otisků prstů papilární linie a pozadím je vše ostatní. Michelsonův kontrast je popsán takto: L.Popelínský, O.Výborný (eds.),datakon 2007,Brno, , str

174 162 F.Orság, M.Drahanský: Testování kvality snímků otisků prstů ( Lmax L C Michelson ( L + L max min ) ) min =, (2) přičemž L max je maximální intenzita popředí a L min je minimální intenzita pozadí. Celkový kontrast snímku pak odpovídá průměrné hodnotě všech lokálních rozdílů. Jinou možností je například sledování všech rozdílů intenzit jednotlivých diskrétních intervalů [3]. Ve snímcích s vysokým kontrastem jsou téměř všechny rozdíly intenzit rozloženy rovnoměrně. Toto nastane tehdy, když všechny sousední pixely vykazují maximální rozdíly. Pokud se rozložení rozdílů liší od pravoúhlého rozdělení, je celkový kontrast menší, což vede k závěru, že podobnost rozdělení rozdílů intenzit s pravoúhlým rozdělením je možné využít jako míru kontrastu obrazu. 1.2 Střední hodnota odstínů šedi Střední hodnota odstínu snímku je další možnou mírou pro určení kvality snímku otisku prstu. Postup výpočtu začíná vytvořením histogramu, kde na horizontální ose jsou odstíny šedi vyskytující se ve snímku (typicky 256 odstínů, přičemž 0 odpovídá černé a 255 bílé) a na ose vertikální je vynesena četnost výskytů jednotlivých odstínů. Histogram můžeme definovat jako: nk Hist( rk ) =, k = 0,1, 2,, K 1 n K, (3) kde Hist(r k ) je diskrétní funkce, r k je odstín šedé, n k je počet bodů v odstínu r k, K je celkový počet odstínů šedé a n je celkový počet pixelů snímku. Příklad histogramu je na obrázku 1. Obr. 1: Histogram (vlevo) a jeho normalizovaný ekvivalent (vpravo). Aby bylo možné porovnat obrázky získaných různými senzory pro všechny dostupné technologie, je nutné histogramy normalizovat. V histogramu je nalezena maximální hodnota a touto jsou pak vyděleny všechny hodnoty histogramu. Tím dosáhneme toho, že se všechny hodnoty budou nalézat v intervalu od 0 do 1. Podíváme-li se na histogram na obrázku 1, můžeme vidět dva zřetelné vrcholy. Levý vrchol reprezentuje popředí (papilární linie) a pravý pozadí. Papilární linie byly, v tomto konkrétním případě, velmi tmavé a pozadí světlé. Takovýto histogram

175 Vybraný příspěvek 163 představuje téměř ideální případ. Často není téměř možné oba tyto vrcholy identifikovat, mnohdy však chybí pouze jeden z vrcholů. V optimálním případě by měla střední hodnota M ležet přesně ve středu histogramu (viz obrázek 2), tj. na pozici 128 u obrázků s 256 odstíny šedé. Lze říci, že obsah plochy S L pod křivkou nalézající se vlevo od střední hodnoty by měl být téměř shodný s obsahem S R plochy pod křivkou nacházející se vpravo od střední hodnoty. Obr. 2: Nalezená střední hodnota. Střední hodnota tak stanovuje další měřítko kvality oddělení papilárních linií od pozadí snímku. Střední hodnota může ležet v intervalu <0, 255> a odpovídá některému z odstínů šedé. Obsahy obou ploch S L a S R lze vypočítat takto: S M 1 L = hn ( i) a i= = h i (4) i= M S ( ) R n Kde M je hledaná střední hodnota (na počátku stanovujeme M = 128) a h n (i) jsou normované četnosti jednotlivých odstínů šedé. Pokud je S L < S R, pak zvyšujeme hodnotu M (v opačném případě ji snižujeme) dokud neplatí S L S R, kdy výpočet končí. Další možností, která se nám nabízí je výpočet odlučitelnosti popředí a pozadí. Tato metoda nevyžaduje žádné předchozí znalosti o obsahu obrazu a jako míru kvality vrací binarizační práh T. Jednotlivé hodnoty histogramu jsou zpracovány statistickými metodami. Základ tvoří pravděpodobnosti p(i) výskytu šedého odstínu i. Binarizační práh T rozděluje odstíny šedé na dvě skupiny C 0 a C 1. Pravděpodobnost výskytu pixelu v jedné nebo druhé skupině lze vyjádřit jako: T = p( i) a P1 = p( i) = 1 P0 i= 0 i= T P (5) Dále můžeme vyjádřit střední hodnotu odstínu šedé m 0, ze skupiny C 0, m 1 ze skupiny C 1 a m celého snímku jako: Odpovídající variance jsou: m = m0p0 + m1 P1 (6)