Ontologický model pro portály

Univerzita Hradec Králové Fakulta informatiky a managementu Katedra informačních technologií

Ontologický model pro portály Podtitul práce: Využití ontologií pro tvorbu funkčně bohatých, flexibilních a pře devším snadno integrovatelných ebusiness aplikací. Cíl práce: Na základě zběžné analýzy současného stavu v aplikacích pro prostředí Internetu a poznání v oblati sémantických sítí a ontologií navrhnout knihovnu on tologického jádra aplikací, s důrazem na otevřenost použitých technologií, ná strojů a standardů.

Diplomová práce

Autor:

Bc. David Zejda Informační management

Vedoucí práce:

Chrudim

Mgr. Daniela Ponce

duben 2005

Anotace – abstract Ontologický model pro portály Práce v úvodních částech systematizuje současný stav na poli webových portálů, ebusiness a jiných aplikací, sleduje trendy a odhaduje budoucí vývoj. Dále předkládá výběrový přehled formalismů pro zachycení složité informační struktu ry, s důrazem na sémantické sítě a ontologie a jejich možnosti. Především na pří padových studiích aplikací pro evidenci a organizaci dat, elektronický obchod a administraci serveru aplikací, u kterých zatím není využívání ontologií běžné ukazuje potenciál ontologií a zároveň odvozuje parametry univerzálně použitelné ho meta modelu ontologie. Větší část práce je tvořena analýzou a podrobným ná vrhem meta modelu a souvisejících provozních a konfiguračních požadavků. Na tomto základě je postaven návrh knihovny pro zachycení ontologie odpovídající tomuto meta modelu a manipulaci s ní. V závěrečné části jsou zvažovány archi tektury případných aplikací, které by na knihovně mohly být postaveny, a také technologie, nástroje a standardy, které mohou sloužit pro jejich implementaci.

Ontological model for portals Introductory parts of the work systematizes current state of web portals, ebusi ness and similar applications, traces the trends and predicts the incoming ad vancement. Following sections consist of the selective summary of formalisms for a tangled information structure representation, with emphasis on semantic net works, ontologies and their potentialities. Especially on the sequent case studies of applications for data organisation and management, eshop and server adminis tration – applications which are not enriched by ontologies commonly – demon strates the potential of ontologies and simultaneously deduces, which parameters of ontology meta model would lead to its possible universal utilisation. The major part of the thesis contains analysis and particularly detailed design of the meta model and the related operational and configuration requirements. The require ments makes the basis for design of the library, which will be able to catch and manipulate the ontology conforming the meta model. In the last part, the diverse architectures of applications utilising the library and also the technologies, tools and standards, useful for implementation are considered.

Poděkování Moje poděkování si zaslouží vedoucí práce, Mgr. Daniela Ponce za podnětné při pomínky a především za to, že mě před asi třemi lety vůbec přivedla na stopu on tologiím. Nemohu rovněž zapomenout na ten dlouhý zástup vývojářů a výzkumníků, kteří vložili svou energii a čas do kancelářského balíku OpenOffice.org, ve kterém prá ci píši, do vývojového prostředí NetBeans, systému pro jednotkové testování JUnit a mnoha a mnoha dalších nástrojů a knihoven, které jsem použil při vývoji prototypu. Velké poděkování zaslouží také celý velký sbor autorů těch všech knih, článků a webových stránek, ze kterých jsem tolik načerpal...

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

V Chrudimi dne 26. dubna 2005

David Zejda

Copyright ©2005 Informace, které jsou v tomto dokumentu zve řejněny mohou být chráněny jako patent. Jména produktů jsou pou žita bez záruky jejich volného použití. Některé názvy mohou být registrovanými známkami nebo jinak chráněny. Při sestavování textu jsem se snažil postupovat pečlivě, nicméně nemohu po skytnout záruku bezchybnosti. Všechna práva vyhrazena. Žádná část nesmí být reprodukována a distribuována bez předchozího svolení autora, výjimku tvoří použití krátkých části textu pro akademické, nekomerční účely a pro účely recenzí, vždy ale musí být uveden zdroj včetně adresy http://www.zejda.net/ontoportal.

Obsah I Úvod......................................................................................................................1 A Cíl....................................................................................................................2 B Motivace..........................................................................................................3 C Jak číst dál.......................................................................................................5 II Teoretická část......................................................................................................6 A Úvod a systematizace internetových aplikací..................................................7 A.1 Typy webových aplikací..........................................................................7 1.1 Systémy pro správu obsahu (CMS)......................................................8 1.2 Kolaborativní systémy........................................................................10 1.3 ECommerce.......................................................................................12 1.3.1 B2C.............................................................................................12 1.3.2 C2C.............................................................................................12 1.3.3 B2B a B2G..................................................................................13 1.4 .. a mnohé další...................................................................................14 A.2 Vize: Virtuální firma..............................................................................14 B Úvod do problematiky ontologií....................................................................16 B.1 Zachycení složité informační struktury..................................................16 1.1 Pojmenování a meta data....................................................................16 1.2 Grafy...................................................................................................18 1.3 Sémantické sítě...................................................................................19 1.4 Ontologie............................................................................................22 1.4.1 Význam.......................................................................................22 1.4.2 Ontologický model a meta model...............................................24 1.4.3 Souvislosti s jinými formalismy..................................................24 1.4.3.a Ontologie a datové modelování...........................................25 1.4.3.b Ontologie a objektové modelování......................................25 1.4.3.c Ontologie a rámce................................................................26 1.4.4 Ontologické inženýrství..............................................................27 1.4.4.a Nástroje................................................................................28 1.4.4.b Činnosti................................................................................29 1.4.4.c Znovupoužití ontologií.........................................................29 1.5 Konkrétní ontologické slovníky.........................................................30 1.5.1 Toplevel ontologie......................................................................30 1.5.1.a WordNet...............................................................................30 1.5.1.b Cyc.......................................................................................30 1.5.1.c The Suggested Upper Merged Ontology (SUMO)..............32 1.5.1.d Další zajímavé projekty.......................................................34 1.5.2 Vybrané ontologie pro podniky a obchod...................................34 1.5.2.a KSL......................................................................................34 1.5.2.b AIAI Enterprise....................................................................34 1.5.2.c Business Management Ontology (BMO).............................35 C Synergie ontologií a webových aplikací........................................................37 C.1 Vize: Ontologický Internet.....................................................................37 C.2 Obecné přínosy.......................................................................................38

2.1 Přehled a zvládnutelnost.....................................................................39 2.2 Spojení................................................................................................40 2.3 Komunikace a vzájemné porozumění.................................................41 C.3 Sémantický web.....................................................................................42 3.1 Obsah, tvorba a údržba.......................................................................42 3.2 Využití.................................................................................................44 C.4 Podle typu média....................................................................................45 4.1 Lexikografická data............................................................................45 4.2 Procesy a spolupráce..........................................................................46 4.3 Multimédia.........................................................................................46 4.4 Správa sítě..........................................................................................47 C.5 Podle architektury..................................................................................48 C.6 Podle oborů a činností............................................................................49 6.1 Komerční............................................................................................49 6.2 Nekomerční........................................................................................50 III Projektové studie..............................................................................................53 A Evidence a organizace dat.............................................................................55 A.1 O co jde..................................................................................................55 A.2 Běžné řešení bez ontologií.....................................................................56 A.3 Přínos ontologií......................................................................................57 A.4 Problémy a rizika řešení s ontologiemi.................................................59 A.5 Kostra architektury ontologického řešení..............................................60 5.1 Struktura.............................................................................................60 5.2 Charakter............................................................................................61 5.2.1 Charakter logiky dotazovacího modulu......................................62 5.3 Cíle.....................................................................................................64 5.3.1 Složitost modulů..........................................................................64 5.3.2 Kritéria posouzení úspěchu.........................................................65 5.4 Stav.....................................................................................................66 A.6 Klíčové parametry ontologického meta modelu....................................69 A.7 Významné koncepty a vztahy................................................................69 7.1 Základní koncepty..............................................................................69 7.2 Příklad doménově specifické aplikace...............................................70 7.3 Důsledky ontologického modelu pro dotazování...............................71 B Elektronická komerce....................................................................................73 B.1 O co jde..................................................................................................73 B.2 Běžné řešení bez ontologií.....................................................................74 B.3 Přínos ontologií......................................................................................74 B.4 Problémy a rizika řešení s ontologiemi..................................................76 B.5 Kostra architektury ontologického řešení..............................................77 5.1 Struktura.............................................................................................77 5.2 Charakter............................................................................................81 5.2.1 Uživatelské rozhraní....................................................................81 5.2.2 Ostatní moduly............................................................................82 5.3 Cíle.....................................................................................................82 5.4 Stav.....................................................................................................83

B.6 Klíčové parametry ontologického meta modelu....................................83 B.7 Významné koncepty a vztahy................................................................87 7.1 Základní koncepty..............................................................................87 7.2 Příklad doménově specifické aplikace..............................................88 7.2.1 Produkty......................................................................................88 7.2.2 Tvorba ontologie.........................................................................90 C Administrace serveru.....................................................................................93 C.1 O co jde..................................................................................................93 C.2 Běžné řešení bez ontologií.....................................................................93 2.1 Výchozí stav.......................................................................................93 2.2 Běžná řešení........................................................................................94 C.3 Přínos ontologií......................................................................................95 C.4 Problémy a rizika řešení s ontologiemi..................................................96 C.5 Kostra architektury ontologického řešení..............................................97 5.1 Základní komponenty.........................................................................98 5.2 Některé podstatné podrobnosti.........................................................100 5.3 Spolupráce........................................................................................101 5.3.1 Základní model spolupráce.......................................................101 5.3.2 Architektura založená na naslouchačích...................................103 C.6 Klíčové parametry ontologického metamodelu...................................103 C.7 Významné koncepty a vztahy..............................................................104 D Další možnosti praktické integrace.............................................................108 IV Projekt ontologického systému.......................................................................111 A Meta model ontologie..................................................................................114 A.1 Koncepty a instance.............................................................................114 1.1 Dilema instance................................................................................115 1.1.1 Problémy rozlišení konceptů a instancí.....................................116 1.1.2 Řešení těchto problémů ............................................................118 1.1.2.a Odvozené rozlišení konceptů a instancí.............................119 1.2 Entity................................................................................................120 1.3 Hodnotnost, umístění, externí zdroje................................................121 1.3.1 Samohodnotná ontologie...........................................................121 1.3.2 Meta ontologie..........................................................................121 1.3.3 Parametry řešení........................................................................122 1.4 Hierarchie.........................................................................................123 1.4.1 Kategorizace.............................................................................123 1.4.2 Dynamická kategorizace...........................................................124 1.4.3 Dědičnost, nejprve obecně........................................................125 1.4.4 Dědičnost vícenásobná..............................................................127 1.4.4.a Potřebujeme ji?..................................................................127 1.4.4.b Komplikace vícenásobné dědičnosti..................................129 A.2 Atributy................................................................................................132 2.1 Doména.............................................................................................133 2.1.1 Datový typ.................................................................................133 2.1.2 Relevance..................................................................................136 2.2 Prostředky pro zvýšení robustnosti...................................................137

2.2.1 Mechanismy vyžádání...............................................................137 2.2.2 Mechanismy podsouvání...........................................................138 2.3 Odvozený atribut..............................................................................138 A.3 Vazby....................................................................................................139 3.1 Orientace a navigabilita....................................................................140 3.1.1 Neorientované...........................................................................140 3.1.2 Orientované...............................................................................140 3.1.3 Navigabilita...............................................................................141 3.2 Hierarchie vazeb...............................................................................141 3.2.1 Vztahy meta modelu..................................................................141 3.2.2 Vztahy modelu..........................................................................142 3.3 Vazby více prvků..............................................................................143 3.3.1 Multilaterální.............................................................................143 3.3.2 Násobné.....................................................................................145 3.4 Prostředky zvýšení robustnosti.........................................................146 3.4.1 Rozhodovací řetězce.................................................................146 3.4.2 Struktura rozhodovacích řetězců...............................................147 3.4.3 Rozhodnutí v rozhodovacích řetězcích.....................................148 3.4.4 Mechanismus aplikace pravidel................................................149 3.4.5 Automatický typ vazby.............................................................149 3.5 Důsledky dědičnosti účastníků.........................................................150 3.5.1 Dědictví vazeb...........................................................................150 3.5.2 Další automatické manipulace vazbami....................................151 A.4 Pravidla................................................................................................152 4.1 Struktura pravidel.............................................................................153 4.2 Predikát.............................................................................................153 4.2.1 Báze...........................................................................................153 4.3 Efekty pravidel.................................................................................155 4.4 Operátory..........................................................................................156 B Provozní požadavky....................................................................................157 B.1 Sledování provozu................................................................................157 1.1 Správa změn a událostí.....................................................................157 1.1.1 Statistika....................................................................................157 1.1.2 Návrat........................................................................................158 1.1.3 Zachycení faktoru času.............................................................158 1.2 Události – naslouchači......................................................................158 1.2.1 Probublávání zpráv....................................................................159 1.2.2 Využití pro RSS.........................................................................160 1.3 Strategie vývoje................................................................................160 1.3.1 Strategie likvidace.....................................................................160 1.3.1.a Nakládání s potomky.........................................................161 1.3.1.b Nakládání s instancemi atributů.........................................161 1.3.1.c Nakládání s vazbami..........................................................161 1.3.2 Strategie duplicity.....................................................................162 B.2 Konfigurovatelnost meta modelu.........................................................162 2.1 Důvody pro konfigurovatelnost........................................................163

2.2 Mechanismus vynucené integrity.....................................................164 2.3 Konfigurovatelné vlastnosti meta modelu........................................164 2.3.1 Provozní nastavení....................................................................165 2.3.2 Dědičnost...................................................................................165 2.3.3 Atributy.....................................................................................165 2.3.4 Vazby.........................................................................................166 2.4 Profily nastavení meta modelu.........................................................166 2.4.1 Smysl a charakter profilů..........................................................166 2.4.2 Vybrané profily..........................................................................168 2.4.3 Znovupoužití profilů.................................................................169 2.5 Režimy a módy.................................................................................170 2.5.1 Základní režimy........................................................................170 2.5.2 Základní módy..........................................................................170 C Struktura a technologie................................................................................172 C.1 Systém jako celek.................................................................................172 1.1 Základní a rozšiřující části................................................................172 1.2 Příklad komunikace..........................................................................173 1.3 Původ jednotlivých komponent........................................................175 C.2 Jádro a API...........................................................................................176 2.1 Model................................................................................................176 2.1.1 Relační model............................................................................177 2.1.2 Model založený na XML..........................................................179 2.1.3 Objektový model.......................................................................179 2.1.4 Logické, deklarativní, pravidlové apod.....................................180 2.2 Platforma..........................................................................................182 2.2.1 Přenositelnost............................................................................184 2.2.2 Jazyky kompilované..................................................................185 2.2.3 Jazyky interpretované................................................................186 2.2.4 Jazyky interpretované s bytekompilací.....................................187 2.2.5 Volba jazyka..............................................................................188 C.3 Zajištění perzistence.............................................................................189 3.1 Soubory.............................................................................................189 3.1.1 Serializace.................................................................................189 3.1.2 XML mapování.........................................................................190 3.2 Objektově orientované databázové systémy.....................................191 3.3 Objektověrelační mapování.............................................................191 3.4 Objektověrelační technologie..........................................................192 3.5 Mnoharozměrné databáze.................................................................193 3.6 Úložiště pro stromové struktury.......................................................194 3.6.1 LDAP (Lightweight Directory Access Protocol)......................194 3.6.2 Nativní XML databáze..............................................................194 3.7 Snahy o univerzální přístup..............................................................195 3.8 Zvolené řešení...................................................................................196 C.4 Uživatelské rozhraní.............................................................................199 4.1 Scénář „desktop“..............................................................................200 4.2 Scénář „z intranetu“..........................................................................201

4.3 Scénář „z Internetu“..........................................................................201 4.3.1 Vytváření dynamického obsahu................................................202 4.3.1.a Pull.....................................................................................203 4.3.1.b Push....................................................................................204 4.3.2 Formuláře..................................................................................205 4.3.3 Kontroler...................................................................................206 4.4 Scénář „mobilní“..............................................................................206 4.5 Scénář „hendikepovaní“...................................................................207 4.6 Jak to tedy vyřešíme?.......................................................................207 C.5 Neinteraktivní rozhraní........................................................................209 5.1 Sestavy zejména pro tisk..................................................................209 5.2 Netiskové výstupy, komunikace.......................................................212 5.3 Univerzální řešení.............................................................................213 5.3.1 Rizika........................................................................................213 5.3.2 Požadavek a řešení....................................................................214 C.6 Infrastruktura nasazení.........................................................................216 6.1 Nevrstvená infrastruktura.................................................................217 6.2 Dvouvrstevná infrastruktura.............................................................218 6.2.1 S mohutným klientem...............................................................218 6.2.2 S tenkým klientem.....................................................................219 6.3 Třívrstevná infrastruktura.................................................................219 6.4 Software jako služba (SaaS).............................................................220 6.5 Data jako služba (DaaS)...................................................................221 6.6 Nezávislí agenti................................................................................223 6.6.1 Inteligentní agenti......................................................................224 6.6.1.a Charakteristické rysy..........................................................224 6.6.1.b Použití................................................................................225 6.7 Infrastruktura pro navrhovaný systém..............................................226 V Příloha CD.....................................................................................................227 VI Závěr...............................................................................................................229 A Shrnutí výsledků..........................................................................................230 B Jak pokračovat.............................................................................................232

Úvod Úvod

I Úvod

1

Úvod Cíl

A Cíl Na titulním listě jste si mohli povšimnout obecného cíle práce. Ještě než se vrhne me na všechny ty zajímavé otázky okolo webových aplikací a ontologií, po třebujeme tento cíl trochu více rozvést – stanovit, o co nám vlastně jde.

Co cílem není Tak tedy, hlavním cílem není •

vytvořit učebnici pro práci s ontologiemi

•

popsat nějaký konkrétní nástroj či technologii

•

srovnávat a hodnotit technologie

•

vytvořit ucelený a vyčerpávající přehled čehokoliv – třeba internetových aplikací

To vše se ale v práci alespoň částečně objeví, ale pouze účelově, k podpoře cíle.

Co cílem je Cílem naopak je •

navrhnout univerzálně použitelnou knihovnu pro práci s ontologiemi

K tomu bude třeba •

prozkoumat souvislosti, východiska a trendy v oblasti internetových aplikací

•

trochu uspořádat typy těchto aplikací

•

probrat základní východiska ontologií, částečně i jejich současný význam a vlastnosti

•

provést několik projektových studií pro odlišné typy nasazení navrhované ho systému

•

a především, rozebrat vlastní systém z různých hledisek

•

při tom všem hledat souvislosti se současným stavem poznání v oblasti on tologií

•

a aplikovat poznatky o těch typech aplikací, v nichž by systém mohl najít uplatnění 2

Úvod Motivace

B Motivace Možná se ptáte, co mě dovedlo k námětu, který zdobí desky. Tedy, jsou to pře devším určité nepříjemné zkušenosti s různými systémy, se kterými jsem dosud pracoval nedostatky některých z nich se staly východiskem již zmíněných projektových studií.

..co se mi nelíbilo Nelíbí se mi, když musím cokoliv z jednoho programu ručně přepisovat do druhé ho. Nemám rád duplikaci a bojím se nekontrolované redundance. Považuji za ne vhodné, když data o produktech jsou jednou v produktové databázi, podruhé v účetním systému, potřetí v elektronickém obchodě dodavatele, počtvrté v nějaké recenzi na cizím webu... a nikde žádné pořádné vazby, které by hned, jedno značně a automatizovaně udávaly, že jde stále o ten samý produkt. Nelíbí se mi, že mi dokumenty leží v adresářích; adresářová struktura sice má určitý systém a logiku, ale je to pořád příliš málo. Že pokud budu potřebovat dokumenty sdílet s někým jiným, narazím na to, že on používá také nějakou or ganizační strukturu, trochu podobnou, ale přeci jinou. Že spojení těchto struktur lze provést pouze ručně. Ano mohl bych používat systém pro správu dokumentů, ale problémy s univerzálně platnou a univerzálně sdílitelnou organizací tím stejně nevyřeším. Chybí mi strojově srozumitelný slovník.

..a pak přišly ontologie Před pár lety jsem zkoumal přesně takové věci a hledal jsem řešení. A pak přišly ontologie – nebo spíše já jsem přišel k nim... Od té doby na každém kroku pozo ruji možnosti aplikace ontologií. Myslím, že je jen málo programů, které by nemohly být povýšeny v použitelnosti aplikací ontologií. Pokud by data – jakáko liv data byla lépe zachycena, tedy včetně sémantického významu, případně o tuto významovou rovinu doplněna, otevřelo by to široké možnosti, některými z nich se budu zabývat v dalším textu.

3

Úvod Motivace

..které toho umí tak moc Ano, tuším možnosti kvalitnější práce s takovými systémy, ale také obrovské možnosti zvýšení interoperability a především masivní integrace. Totiž, to je to, co podle mého názoru schází současným aplikacím především – možnost budovat z nich integritní, kompaktní celky s hodnotou společně realizované služby pro uživatele. Když ale říkám integritní, v žádném případě nemyslím monolitické, spíše poskládané z mnoha nezávislých komponent, pouze překrytých jednotící vrstvou. Masivní integrace především obchodních aplikací může být první fází in tegrace v mnohem větším měřítku, integrace odpovídající trendům ekonomiky nové doby. K tomu ale ještě dospějeme...

4

Úvod Jak číst dál

C Jak číst dál pokud spěcháte.. Pokud spěcháte celou teoretickou část možná přeskočíte – jejím smyslem je pou ze uspořádat různé souvislosti, a tak vybudovat základ pro návrh ontologického systému. Možná si prolétnete pouze nadpisy, tuším, že se zastavíte asi v částech s vizí, protože vize jsou obecně lákavé.. Pokud víte co jsou ontologie zač, asi pře skočíte celou část o nich a skončíte až u projektových studií. Z nich považuji za nejzajímavější tu poslední, o administraci serveru, vás třeba ale zaujme některá ji ná. Dál to již nechám na vás; každopádně jádrem práce je rozbor meta modelu on tologie navrhovaného systému, v závěsu podle významu jsou kapitoly o provoz ních požadavcích a konfigurovatelnosti. Část Struktura a technologie obsahuje už zase spíše spoustu přehledového a srovnávacího materiálu pro nalezení odpovědí na otázky související s architekturou aplikací na systému postavených, a tak ji můžete třeba přeskočit. Pokud toho času máte opravdu málo, asi bude nejlepší prolistovat nosné části, prohlédnout obrázky a větší nadpisy a samozřejmě přečíst závěr – tak si uděláte ucelenou představu o tom, co vlastně práce řeší a třeba se k ní vrátíte někdy poz ději...

jak se vyznat aneb formátovací konvence Základní text je na celou použitou šíři stránky, pouze ty skutečně veliké obrázky ho občas přesáhnou. O dva řádky výše vidíte styl používaný pro uvození defi novaných anebo vysvětlovaných položek, někdy sloužící také jako podnadpis nejnižší úrovně. a toto je ta vlastní definice takhle vypadá příklad, co má charakter souvislého textu a takhle zdrojový nebo pseudozdrojový kód ..a ještě tohle je poznámka na okraj, která dodává nějakou zají mavou souvislost, ale pro pochopení hlavních myšlenek je vedlejší

5

Teoretická část Teoretická část

II Teoretická část

6

Teoretická část Úvod a systematizace internetových aplikací

A Úvod a systematizace internetových aplikací A.1 Typy webových aplikací Vraťme se zpátky na zemi a pěkně od podlahy probereme, s čím se můžeme na Internetu setkat. V tuto chvíli nám nejde o vyčerpávající seznam a ani o dokonalé členění, koneckonců ani hranice nejsou pevně definovatelné. Cílem je spíše na stínit šíři typů webových aplikací, aby náš rozhled nebyl příliš zúžený, až budeme promýšlet ontologický systém, který by se mohl stát jejich jádrem. Zmiňuji zde především typy a pokud mluvím o technologiích, většinou jen obecně. Výjimku ale učiním hned v úvodu:

portálové systémy Existuje mnoho systémů, které se zabývají integrací komponent pro účely prezentace uživatelům. Komponentám se často říká portlety, jsou to taková malé okénka do dat z různých zdrojů – z místní databáze nebo třeba z nějakého zpravodajského serveru. Tvorba portálu pak znamená především výběr a vhodnou kombinaci portletů. Příkladem portálových systémů jsou například Jakarta Jetspeed, Liferay, Exo, Pluto, JASIG uPortal, Jahia, Gluecode Portal Foun dation Server, jPortlet... Vzhledem ke zvoleném námětu cítím povinnost v úvodu vymezit, co rozumím pojmem portál. Pojem je to totiž značně vágní.

portál v užším smyslu Pan Hlavenka v [BYZNETH99] píše: „Na začátku roku 1998 se v ob lasti internetových médií objevil nový pojem – portál. Představa něko lika webů, které budou sloužit jako vstupní brány do Internetu, rozcest níky k dalším službám, obchodům a médiím. Samozřejmě opět s urči tou manipulací – portály měly ukazovat jen na ty služby a obchody, které vlastníkům portálu zaplatí peníze. … Idea portálu v této podobě zahynula v rekordní době – dnes se sice pojem ze setrvačností dále po užívá, ale v jiném smyslu, spíše jako hodnotná destinace – místo kam uživatel přijde a kde najde dostatečně zajímavé a provázané nabídky,

7


které neodmítne a kde zůstane. Pokus o zmanipulování Internetu nevy šel.“ Výrok je z roku 1995 a to, že myšlenka podobně manipulativních portálů se postupně opět vrací, u nás v podobě portálů jako se znam.cz či atlas.cz, je dokladem neobyčejného tempa vývoje In ternetu. Každopádně, takovými portály se příliš zabývat nebudeme. My budeme pod pojem portál shrnovat mnohem širší paletu aplikací:

portál v pojetí práce V zásadě jakýkoliv počítačový systém, který integruje heterogenní zdroje a využívá síťovou infrastrukturu. Občas se ale nevejdeme asi ani do takto široce pojaté definice, protože cílem je, aby v dalších kapitolách navrhovaný systém byl opravdu hodně univerzální. A ještě jedna věc nebudeme se příliš zabývat těmi typy „webů“, které má na mysli většina lidí, když mluví o webové prezentaci.

webová prezentace Plní pouze roli jakési reklamní vývěsky, bezostyšně propaguje firmu nebo výrobek. Soudím, že reklamní vývěsky jsou přežitkem doby, ne vhodným přenesením starých modelů do dynamického prostředí elek tronického věku. Nezajímavost, uzavřenost, neupřímná a neobjektivní sebechvála, to jsou znaky, které na Internetu spolehlivě odradí, zejmé na když objektivní informace jsou na dva kliky daleko.

1.1 Systémy pro správu obsahu (CMS)

systémy pro správu dokumentů (DMS) Znalosti se stávají základem ekonomiky. Intelektuální kapitál může být nejsilnější zbraní v silné konkurenci. Je třeba zachytit a řídit tok infor mací v organizaci, dost možná je to důležitější než tok vlastního zboží. Systém pro správu dokumentů dělá přesně to – umožňuje řídit proces získávání, sdílení, zaznamenávání, revidování, distribuce dokumentů a informací, které obsahují. Kompletní systém správy dokumentů umožní kontrolovat všechny procesy spojené se všemi typy dokumentů v organizaci, jako s tabulkami, prezentacemi, textovými dokumenty.. 8


redakční a publikační systémy Podporují spolupráci týmu na sdíleném obsahu. Definují role jako au tor, redaktor, korektor, překladatel a podle rolí přidělují práva. Oddělují proces schvalování od vlastní publikace. Články postupně procházejí různými stavy. Většina publikačních systémů obsahuje také podporu pro definici rubrik, souvislostí, typů článků a také pro včlenění obráz ků, příloh.

blogy Blog je médium dostupné přes web. Publikace nového článku je „ blogování“, správce a autor je „blogger“. Pro blogy je také typické, že jsou tvořeny spíše krátkými články a jsou aktualizovány často, lépe pravidelně a nejlépe denně; obsahují subjektivní názor autora. Blogo vací software jsou programy, které umožní snadno a rychle zveřejňovat zprávy a blog spravovat bez nutnosti rozumět technickým aspektům – nejčastěji přímo přes webové rozhraní. Tudíž blogovat může každý kdo chce a najde dostatek času. Blogy tvoří paralelu ke klasickým zpravodajským, ale i oborovým webovým serverům a více odpovídají původní myšlence decentralizovaného Internetu.

galerie Systémy pro zveřejnění a správu kolekcí fotografií a obrázků. Většinou s pohodlným rozhraním, efektními výstupy, možnostmi řadit a prohle dávat, připojovat klíčová slova atd.

publikačně - aplikační systémy Redakční systém je speciálním typem obecnějšího systému. Systému, který umožní volně definovat datové objekty, jejich možné stavy a pře chody mezi stavy, role tvůrců a uživatelů... Na základě takového systé mu lze postavit jak redakční systém, tak třeba systém pro podporu jednání a hlasování na různých poradách, podporu různým komunitám a skupinám... V zásadě je v takovém systému možné nadefinovat i prostředí podobné blogu nebo třeba Wiki, jež bude popisován dále. Příkladem takového univerzálního systému je třeba plně objektový Plone postavený na aplikačním serveru Zope. 9


1.2 Kolaborativní systémy

P2P pro sdílení dat Nemá cenu je definovat – snad jen některá jména: Bittorent, eDonkey, Gnutella, DC++, eXeem, Soulseek

MUD (multi user dungeon) Zařadil jsem jej jako příklad kolaborativní zábavy. Je to počítačový program, typicky běžící na internetovém serveru, umožňuje mnoha uživatelům sdílet virtuální realitu obvykle smyšleného světa. Většina MUD je z větší části textově provedenou variantou RPG (roleplaying games).

webmail Vlastně jen webové rozhraní poštovní schránky, ale v důsledku usnadňuje komunikaci, tudíž jsem jej zařadil jako příklad kolabora tivního systému.

groupware Systémy pro podporu práce ve skupině. Obvykle sestává z několika softwarových komponent, jako sdílený adresář kontaktů, webmail, plánovací kalendář, řízení workflow, nástěnka, sdílené dokumenty apod. Pěkný přehled konkrétních systémů je třeba [GRPWREB].

wiki Původní definice wiki podle autora myšlenky a tvůrce prvního wiki systému p. Warda: The simplest online database that could possibly work. Wiki je kus softwaru, který umožňuje uživatelům volně tvořit a upravovat webové stránky pomocí libovolného prohlížeče. Podporuje hyperlinky a, což tyto systémy odlišuje od čehokoliv jiného, disponuje jednoduchou syntaxí pro tvorbu nových stránek a vazeb mezi nimi. Je opravdu vzrušující a dosud nepříliš běžné povolit návštěvníkům upravit kteroukoliv stránku. Musíte při tom počítat s tím, že občas se 10


objeví nějaký vandal, kterého těší, když může stránku poškodit. Na druhou stranu wiki systémy uchovávají kompletní historii úprav, a správce může stránku kdykoliv vrátit k předchozímu stavu. Wiki zna mená pro web skutečnou demokracii a otevřenost a podobně jako je tomu u blogovacích systémů umožňuje i netechnickým uživatelům pu blikovat. [WIKIDEF] Neodpustím si poznámku, že jako experiment jsme stránky [OWIKIZF] společnosti, ve které působím jako jednatel postavili právě na jenom takovém systému, konkrétně na MoinMoin.

systémy pro řízení vztahů se zákazníky (CRM) Customer Relationship Management, jinak též Customer Information Systems, Customer Interaction Software (CIS), Technology Enabled Relationship Manager (TERM). Aplikace, které pomáhají společnostem spravovat všechny aspekty vztahů se zákazníky. Pomáhají vybudovat trvalé vazby, obrátit zákaz níkovu spokojenost v loajalitu. Informace o zákaznících získané z prodejů, marketing, doprovodných služeb a podpory jsou posbírány a uloženy v centrální databázi. Systém může nabízet schopnosti dolování dat, může být také propojený s dalšími systémy, například pro účetní evidenci, výrobu... [FRDICTH] Nedávno jsem stál před potřebou zvolit kvalitní systém z této ka tegorie, porovnáním asi dvaceti kritérií jsem z dvaceti vytipo vaných projektů nakonec zvolil open source systém OpenCRX. Ten je pozoruhodný mimo jiné svou architekturou – byl vystavěn na platformě OpenMDX pro tvorbu aplikací podle zásad MDA (ModelDriven Architecture). S Davidem Klímou jsme systém lokalizovali do češtiny a p. Klíma zřídil i českou stránku projektu [OPECRXK].

znalostní systémy (KM) Mnohé podniky neznají, co znají. To vede k duplikaci činností, neefek tivním rozhodnutím a ztrátám. Bez ohledu na charakter organizace, efektivní management znalostí se zaměřuje na celý systém: organizaci, lidi a technologie.

11


Počítače a komunikační prostředky mohou být cennou pomocí při zís kávání, transformaci, distribuci a používání vysoce strukturovaných znalostí, které se mění každým okamžikem. Dobře implementovaný znalostní systém pomáhá analyzovat, plánovat, mnohdy drasticky zvýšit kvalitu rozhodování, alokace zdrojů, správy systémů, šíření knowhow a přístupu k němu a v důsledku celkovou výkonnost. [KMFAQ98][ZTECHMP02]

systémy pro řízení zdrojů (ERP) Enterprise Eesource Planning je software, který podporuje a automa tizuje obchodní procesy, obvykle je dimenzován pro střední a velké podniky. Podporovanými procesy může být výroba, distribuce, řízení lidských zdrojů, řízení projektů, finanční řízení apod. ERP mají silné vazby s účetnictvím, pomáhají plnit požadavky zákazníků a obdržet za to náležitou odměnu. [FRDICTH] Jsou také nedílnou součástí, možná dokonce jádrem aplikací, které jsou označovány jako podnikové informační systémy.

1.3 E-Commerce 1.3.1 B2C

obchodní dům To, co se vám vybaví, když se řekne elektronický obchod, eshop. Vir tualizace kamenného obchodu, většinou včetně nezbytných rekvizit, jako nákupní košík nebo pokladna. Typický eshop slouží koncovému uživateli. Může být specializovaný místně nebo sortimentem, anebo zeširoka pojatý, v tom případě ale bude vyžadovat mnoho úsilí, aby obstál v tvrdém konkurenčním boji.

1.3.2 C2C Pojem to není dokonalý, ale snad trochu vyjadřuje myšlenku, že uživatelé si mohou být vzájemně zákazníkem; stejně tak obchodníkem není jedna firma, ale může jím být každý.

12


virtuální aukční síň Každý může vrhnout nějakou věc do veřejné elektronické aukce. Elek tronický systém následně umožní ostatním uživatelům přihazovat, dů ležité jsou také různé prostředky pro ověření důvěryhodnosti účastní ků. Mezinárodně nejúspěšnější je na tomto poli eBay, u nás fungují servery jako aukce.cz a aukro.cz.

inzertní systémy Každý může nabízet co mu zbývá ve webové obdobě inzertních novin. Oproti novinám přináší elektronický inzertní systém mnohem lepší možnosti vyhledávání, pohodlnější zpětnou vazbu, dostatek prostoru pro obrázky a další informace..

1.3.3 B2B a B2G Pokud B2C obchodování přináší úspory a zvyšuje efektivitu, pak v systémech B2B je v tomto směru ještě mnohem vyšší potenciál. V oblasti B2B je zřejmá tendence k integraci všeho, co se integrovat dá. Formát elektronické výměny dokumentů (EDI) a sama technologie existuje již více než 40 let a jeho popularita (i přes některé problematické pasáže v návrhu dané právě dobou jeho vzniku) postupně spíše roste, protože koneckonců až v nedávné době Internet poskytl skutečně univerzální infrastrukturu pro masově využitelnou vlast ní výměnu. Kromě toho je zde množství novějších formátů, které jistě stojí za zmínku, v čele s rodinou jazyků okolo standardu XML. Z nich se velké oblibě těší například SOAP, odlehčený formát pro výměnu informací, za kterým stojí or ganizace W3C. Zajímavé jsou v této souvislosti také pokroky v oblasti multia gentních systémů. A samozřejmě, kromě standardů existuje mnoho různých pro prietárních řešení.

e-marketplace V principu stále jednoduchá aplikace, podobná aukční síni, s tím rozdí lem, že je určena společnostem. Pokud někdo potřebuje nakoupit služ by, zařízení, cokoliv, zadá do takového systému poptávku a stanoví kri téria hodnocení. Systém zorganizuje výběrové řízení, jednotliví účast níci zadají nabídky a zadavatel je nakonec s podporou systému vy 13


hodnotí a uzavře obchod s vítězem. Provozovatel tržiště si nechá zapla tit drobnou provizi. Také stále více veřejných zakázek je realizováno přes taková tržiště – jmenujme třeba centrade.cz nebo allytrade.cz. Organizace a celé řízení je mnohem méně pracné, proces je unifikovaný a transpa rentnější. V tomto případě můžeme hovořit o B2G.

1.4 .. a mnohé další Takto bychom mohli ještě poměrně dlouho pokračovat. Nezmínili jsme třeba elektronické bankovnictví, podatelny úřadů, meteorologické, geografické a karto grafické informační systémy a mnohé další....

A.2 Vize: Virtuální firma A už jsme zase u toho – velké plány, velké změny: Zákazníci, dodavatelé, subdo davatelé, předměty, lidé, aktivity, služby, úlohy, procesy, sklady, značky, data, služby... to vše bude propojeno. Jak konkrétně, to ještě ukáže čas. Každopádně, za nosnou myšlenkou elektronického obchodování platí právě taková integrace. Modelem silné obchodní korporace elektronického věku nebude velký moloch disponující vším od výroby po distribuci. Myslím, že budoucnost bude patřit spíše malým, dynamickým firmám, které dokáží pospojovat dodavatele pod střechou jedné značky. Taková firma vlastní jen značku (a s ní spojené zákazníky), vše ostatní nakupuje – sklady, služby, zboží, logistiku, servis. [BYZNETH99] Díky své štíhlosti se dokáže mnohem lépe přizpůsobovat extrémně rychlému vývoji in ternetového světa, než megakorporace staré doby. Stačí jeden příklad za vše: amazon.com. Navenek B2C, ale na pozadí je propracovaný stroj B2B vztahů. V této oblasti probíhá také intenzivní výzkum. Zajímavý je projekt Process In tegration for Electronic Commerce (PIEC), který usiluje o vybudování platformy, nástrojů a technik pro analýzu meziorganizačních procesů a identifikaci a mode lování transakčních služeb pro virtuální podniky. PIEC pomáhá při vývoji trans akčních služeb, ale také definuje, jak je možné zapojit do celku staré (legacy) informační systémy. Právě to autoři považují za klíčové pro úspěch počátečních fází integrace. [SERVIYHP01] Jiní autoři posouvají hranice ještě dále. Například autoři [VPRINBD01] chápou virtuální firmy jako dočasné spojení firem za účelem splnění konkrétní zakázky, 14


také označované jako rapid teaming nebo virtual teaming. Takové dynamické ob chodování, vedené hrstkou schopných analytiků a manažerů, kteří místo lidí se staví tým z celých společností. Schopnost formovat, operovat, zrušit virtuální spo jení bude klíčová. Takové krátkodobé, příležitostí zřízené společnosti mohou po skytnout stejný potenciál, jako klasické vertikálně integrované korporace, ale fle xibilita je mnohem vyšší. Přináší to ale problémy a výzvy jiného druhu – bu dování důvěry, schopnost spolupráce mezi pracovníky zúčastněných společností, a v neposlední řadě masivní nároky na informační infrastrukturu pro zvládání toků informací, znalostí, zboží, v ideálním případě justintime dodávky anebo alespoň tak, aby bylo vyráběno co je třeba, budování optimálních koalic, překo návání obav z případné konkurence současných partnerů... Nároky na informační systémy na pozadí takového spojení jsou řádově vyšší, než u všech předchozích typů aplikací. Je tady mnoho rozhraní mezi jednotlivými sys témy jednotlivých subjektů, je tady potřeba transformovat data, domlouvat se společným jazykem, to všechno rychle, efektivně, spolehlivě – za chyby v kvalitě služeb se na Internetu platí asi ještě více, než kdekoliv jinde, konkurence je totiž neobyčejně ostrá a zákazníci vybíraví...

15

Teoretická část Úvod do problematiky ontologií

B Úvod do problematiky ontologií B.1 Zachycení složité informační struktury Svět okolo nás je komplikovaný. Nejsme schopni plně ho popsat, vystihnout sku tečnost, vztahy, závislosti. Již jsme ale přišli na spoustu možností, jak tento problém prozatím obejít a alespoň určité aspekty světa nějak formalizovaně po psat – nedokonale, ale aspoň nějak. K tomu slouží rozličné hierarchie (jakákoliv alespoň částečná seřazení) nebo ještě obecněji, konceptuální struktury. [MATHBKS01]

1.1 Pojmenování a meta data Samotný přirozený jazyk poskytuje různé prostředky konceptualizace. V minulých několika stovkách let jsme vybudovali techniku (efektivní proceduru) psaného slova. Díky ní můžeme jednoduše a automaticky generovat pojmenování jakéhokoliv konceptu. Prehistorické jazyky touto, pro nás možná samozřejmou, technikou nebo technikou ekvivalentní nedisponovaly. Konvencí je, pokud chce me cosi pojmenovat, uzavřeme to do uvozovek. Pokud chceme pojmenovat ter mín dům, napíšeme „dům“. Tedy například „„dům““ je odkaz na „dům“, a ten je zase odkazem na termín dům, který odkazuje na konkrétní entitu reálného světa. Zde série odkazů končí. Prakticky cokoliv, co se objevuje v řeči nebo jiných kon ceptuálních strukturách vede k něčemu v reálném světě. Výrazem konceptua lizační schopnosti jazyka jsou třeba slovníky.

dům „„dům““ „dům“

16


Když chceme popisovat svět, potřebujeme definice. Zajímavých je např. sedm druhů definic, které zmiňuje Norman Swartz [DEFDICS97]: •

smluvní definice

•

lexikální definice

•

zpřesňující definice

•

teoretické definice

•

operační definice

•

rekurzivní definice

•

argumentační definice

Data jsou vždy nějakým odrazem, zachycením reality – data tvoří vlastní meta realitu. Meta data přidávají další rozměr datům, dodatečnou informaci, hodnotu, popisují data, jsou to data o datech. V tomto smyslu bychom ale mohli pokračovat dále – meta meta data, meta meta meta data.... Jak tedy popíšeme svět? Můžeme využít různé informační struktury, například (částečně podle [MATHBKS01]): •

množiny, pytle, sekvence, seznamy

•

funkce, relace

•

lambda kalkulus

•

grafy, mříže, stromy, herní grafy

•

propoziční logika

•

predikátová logika (firstorder)

•

axiomy, tvrzení, důkazy

•

formální gramatika

•

formální specifikace

•

teorie modelu

•

teorie množin

•

stromy, mříže a jiné hierarchie

•

Petriho sítě, Markovovy řetězce 17


Za každým uvedeným formalismem je široká teorie, spousta metod, technik, ná strojů...

1.2 Grafy Z hlediska popisné schopnosti si ze všech těch formalismů zvláštní pozornost zaslouží grafy – koneckonců, od grafů vede k ontologiím poměrně krátká cesta.

graf V diagramech je graf znázorněn jako síť uzlů spojených hranami. Konkrétní vizuální reprezentace není důležitá, nezáleží na to, zda jsou hrany krátké, dlouhé, rovné, klikaté, zda jsou uzly malé nebo velké, tečky nebo čtverečky. Jde čistě o existenci vztahu. Proto je grafické znázornění chápáno pouze jako neformální pomůcka pro zvýšení ná zornosti, vlastní graf je primárně zachycen formálním jazykem. Následující diagramy tedy znázorňují stejný graf:

Obecný graf povoluje libovolné počty rodičů a dětí, povoluje rovněž kruhy, jako např. ABCD z příkladu výše. Hierarchie obsahující kruhy je někdy také ozna čovaná jako nestrom nebo „tangled hierarchy“. Pokud se na graf podíváme z jedné strany, z pohledu jednou uzlu (třeba když si představíme, že za uzel graf pověsíme), můžeme sledovat určitou hierarchii tvo řenou rodiči a potomky. Podle povoleného počtu rodičů a možnosti nebo nemožnosti tvořit kruhy můžeme sledovat speciální případy, např:

strom Je graf, který neobsahuje kruhy. Podle počtu rodičů a dětí můžeme roz lišovat různé varianty. 18


Např. takto vypadá binární strom – každý prvek kromě nejvyššího má právě jednoho rodiče, maximální počet potomků jsou 2 – proto binární:

mříž Ta vypadá zase třeba takto:

1.3 Sémantické sítě Počítačová podoba sémantických sítí měla původně sloužit umělé inteligenci a strojovému překládání, ale již mnohem dříve byly tyto sítě používány ve filozofii, psychologii a lingvistice. Nejstarší známou sémantickou síť sestavil ve třetím století našeho letopočtu řeckým filosof Poryfyros ve svém komentáři k Aristote lovým kategoriím. Poryfyros ji použil k ilustraci Aristotelovy metody definování kategorií specifikací genu, všeobecného, základního typu a diference, která rozli 19


šuje jeho podtypy [SEMNETS02]. Mimochodem až tak hluboko a možná ještě hlouběji sahají myšlenky dědičnosti používané nejen v definičních sémantických sítích, ontologiích, ale i objektovém programování nebo třeba v relační analýze. I moderní pojetí sémantických sítí a pojem samotný sahá hluboko do počítačové prehistorie – pojem jako takový můžeme vysledovat až do r. 1968, kdy jej použil Ross Quillian's ve své disertační práci jako způsob uvažování o lidské sémantické paměti (paměti pro slovní koncepty). Sám pojem sémantické sítě je značně široký:

sémantická síť O sémantickou síť jde vždy, kdykoliv je informace zachycena v grafu (viz výše), kde uzlům a hranám jsou přiřazeny významy a topologie grafu je důležitá pro tyto významy. [SEMNETG82] Jedna trochu konkrétnější definice tvrdí, že je to graf, sestávající z uzlů reprezentujících fyzické nebo konceptuální objekty a hran, které popi sují vztahy mezi těmito objekty. Používá se mechanismů dědičnosti, čímž je možné vyhnout se potřebám data duplikovat. Smysl konceptů vyplývá vazeb na jiné koncepty a informace je uložena právě a pře devším v podobě těchto typových vazeb.[FRDICTH] Nejednotnost a vágnost definice je i důvodem, proč žádnou konkrétní neuvádím jako nějaký typický příklad spíše by zmátla než pomohla. Všem sémantickým sítím je společná deklarativní grafická reprezentace. Mohou zachycovat znalosti, podporovat automatizované systémy při rozhodování a usu zování. Některé z nich jsou vysoce neformální, jiné naopak velmi formální a pre cizně definované, pak často slouží jako systémy logiky. John F. Sowa považuje následujících šest typů sémantických sítí za nejdůležitější [SEMNETS02]. U kaž dého typu zrovna uvedeme přibližnou definici či popis.

definiční sítě Zdůrazňují vztahy dědičnosti reprezentované vazbami „isa“ (subtyp) mezi koncepty. Výsledná síť je označována jako generalizace nebo za hrnující hierarchie (subsumption hierarchy). Podporuje pravidla dě dičnosti pro přenášení vlastností definovaných u nadtypu na podtyp a všechny jeho podtypy. Protože definice jsou pravdivé z definice, infor 20


mace v těchto sítích je považována (alespoň teoreticky) za nezbytně správnou – mluvímeli o takové síti, jde vlastně o jednu velkou defini ci.

prohlašovací sítě Jsou navrženy k prohlašování tvrzení. Na rozdíl od definičních sítí informace je považována za případně pravdivou, pokud tak není expli citně označena modálním operátorem. Některé prohlašovací sítě byly navrženy jako struktury pro zachycení sémantiky přirozeného jazyka

implikační sítě Používají implikaci jako primární vztah pro spojování uzlů. Mohou být použity k reprezentaci vzorů myšlenek a představ, příčinnosti nebo k inferencím.

vykonatelné sítě Zahrnují mechanismy jako předávání značky nebo připojené procedu ry, které umožňují provádět inference, předávat zprávy nebo hledat vzory a souvislosti.

učící se sítě Vytvářejí nebo rozšiřují svou reprezentaci získáváním znalostí z příkla dů. Nové znalosti mohou změnit starou síť přidáním nebo odstraněním uzlů a vazeb nebo modifikací číselných hodnot, nazývaných váhy, při pojených k uzlům a/nebo hranám.

hybridní sítě Kombinují dvě nebo více předchozích technik, ať již v jedné síti nebo v sítích oddělených, ale silně spolupracujících. Notace sítí a lineární notace jsou obě schopny vyjádřit stejné informace (jejich vyjadřovací schopnosti jsou ekvivalentní), ale konkrétní reprezentační me chanismy lépe odpovídají jedné nebo druhé formě. Hranice mezi jednotlivými typy sítí jsou značně vágní a co víc, je prakticky nemožné přesně definovat co sé mantické sítě jsou, aby definice zahrnula vše, co je do nich obvykle počítáno a naopak vyloučila, co mezi ně počítáno spíše není. Mnoho prací se věnuje takové

21


mu rozlišování, případně porovnávání vhodnosti jednotlivých systémů reprezenta ce informací a znalostí pro konkrétní použití.

1.4 Ontologie Sémantické sítě jsou stále zajímavé i v takové obecné podobě, jak byly původně pojaty. Ovšem čím dál větší pozornost si získává jedna jejich aplikace – on tologie. Ontologie silně vycházejí z toho, co jsme označili jako definiční sítě včetně klíčového mechanismu dědičnosti. Vlastně jsou jejich aplikací a přidávají k nim další rozšíření.

ontologie (technicky) Množiny definic ve formálním jazyce, založeném na diskrétní matema tice a teorii grafů. Zachycují třídy (koncepty), vazby, instance, někdy také axiomy, pravidla a funkce. Kromě formální podoby je ale zajímavé především použití a i to by mělo být sou částí definice. Pojem ontologie nepochází z informatiky ontologie je původně odvětvím metafyziky a zabývá se podstatou bytí. Počítačové ontologie od toho nejsou daleko.

ontologie (podle použití) Sdílené konceptualizace konkrétní domény nebo rovnou celého světa. John Sowa nabízí třeba takovouto, na význam a obsah zaměřenou defi nici: „Je to takový katalog všeho, co tvoří náš svět a také toho, jak je to vše poskládáno a jak to dohromady funguje.“ Můžeme na ně pohlížet také jako na bohaté a strojově zpracovatelné významové slovníky.

1.4.1 Význam Někdo možná řekne dobrá, ale k čemu to všechno bude? Dotaz je to smysluplný a vyžaduje odpověď. Když už mluvíme o použití, je třeba mít na paměti, že vždy tady bu dou působit dvě protichůdné síly – jedna bude usilovat o co nej rychlejší aplikaci v obchodě, průmyslu, školství, kdekoliv. Druhá bude takové snahy brzdit, protože bude zdůrazňovat kvalitu návrhu

22


a z ní plynoucí telnost...

snadnou správu, rozšiřitelnost a znovupouži

Dnes vznikají dva typy ontologií – odlehčené, doménově specifické, navržené pro konkrétní oblasti lidské činnosti – pro zdravotnictví, výrobu, obchod, matematiku, včelařství, .. cokoliv. Tyto samostatné ontologie již dnes pomáhají komunikovat, spolupracovat a zejména integrovat. Díky nim se mohou mnohem lépe domlouvat nezávislé počítačové systémy, lidé, společnosti. Kromě nich vznikají tzv. toplevel ontologie, které mají ambice zmíněné v úvodu – popsat svět. Bdí nad nimi vážená konzorcia napěchovaná odborníky a na jejich tvorbě spolupracují někdy i tisíce lidí – však také obsahují třeba i milióny koncep tů. Využívají se všelijak, například v systémech pro práci s přirozeným jazykem. Především do budoucna ale mohou sloužit také jako prostředek pro spojení jednotlivých doménově specifických ontologií, a tak pomoci překlenout další ba riéry k ještě širší integraci. Jsou tady ale různé potíže. Například s tím, že nemyslíme stejně. Použití ontologií je tak omezeno – uživatelé ontologií přemýšlejí jinak než jejich tvůrci, a tak si vzájemně leckdy neporozumí. Například jedna ontologie reprezentuje červenou barvu jako vztah, druhá jako hodnotu. Zvolená reprezentace je v rámci ontologie vždy správná a pravdivá – správná je z definice, protože jde o definici. Ale zda je to pořád ještě ten náš svět, to je mnohem těžší stanovit. Podle [ONTADGL02] je význam ontologií především takovýto: •

•

•

pro komunikaci •

mezi implementovanými počítačovými systémy

•

mezi lidmi

•

mezi lidmi a implementovanými počítačovými systémy

pro automatizované usuzování •

pro vnitřní reprezentaci plánů a souvisejících informací

•

pro analýzu vnitřních struktur, algoritmů, vstupů a výstupů systémů pracujících s teoretickými a konceptuálními významy a pojmy

pro znovupoužití a organizaci znalostí

23

Teoretická část Úvod do problematiky ontologií •

pro strukturalizaci a organizaci knihoven, repozitářů, datových úložišť a doménových informací

Myslím, že především v praktické části se dotkneme i lecčeho dalšího..

1.4.2 Ontologický model a meta model Tyto pojmy si musíme trochu vyjasnit, protože dále s nimi budeme pracovat. Tak tedy

ontologie Vlastní, konkrétní slovník, obsahuje koncepty, instance, vazby... a po pisuje nějakou část našeho světa.

model ontologie Tvar konkrétní ontologie, nejde nám o detaily.

meta model ontologie Popisné a inferenční schopnosti modelu. Formální definice toho, co ontologie může obsahovat, co jsou uzly, co vazby, jaké typy vztahů připouští, jak je možné specifikovat pravidla a funkce apod. Ontologie je jedna a má svůj model. Více ontologií ale může být vystavěno podle stejného meta modelu.

1.4.3 Souvislosti s jinými formalismy Je známou pravdou, že dva lidé jiných profesí si nemusí porozumět, i když hovoří o stejném námětu. Každý totiž používá jiné vyjadřovací prostředky – specifická slova, specificky utvářené věty. Proto se často i definice, metody, techniky... v různých oborech opakují, byť třeba nikdo o souvislostech netuší. Když si nakonec takoví odborníci porozumí, dost možná se budou divit, co vše mají společného a jak hodně si mohou vzájemně prospět. Podobně, leccos ontologického můžeme pozorovat i jinde. Můžeme třeba hledat podobnosti s jinými formalismy pro zachycení nějaké struktury. Nepůjde o ko nečný výčet, spíše jen o náznaky...

24


1.4.3.a Ontologie a datové modelování

Podle [DATAONT05] je zde mnoho podobného, například v nabídce kon ceptuálních prvků, jakými je integrita, taxonomie, pravidla pro odvozování nebo možnost diagramatické reprezentace a testů kvality. Podobné je také to, že v obou případech jde o konceptualizaci reálného světa. Hlavní rozdíl typického předmětu datového a ontologického modelování je v šíři použití – datový model je vytvářen pro omezené použití v organizaci, která jej vy tváří nebo jinde, zatímco ontologie je v principu tvořena pro sdílení a znovupou žití. Tomu odpovídají i odlišné nároky na specifičnost versus univerzalitu. Od lišnosti jsou samozřejmě ve struktuře, způsobu přístupu a metodách tvorby a manipulace. Ontologie je méně účelová a více se zabývá logickými teoriemi platí cími v doméně. 1.4.3.b Ontologie a objektové modelování

Zde bych rád vyzdvihl především podobnosti meta modelů. Třídě objektového ná vrhu zhruba odpovídá ontologický koncept, instanci entita a rovněž ontologické vazby mají své protějšky v dědičnosti tříd, v asociacích objektů apod. O objektovém meta modelu lze uvažovat i jako o speciálním druhu meta modelu ontologie. V této souvislosti je zajímavý výzkum v oblastech generování objek tového modelu z ontologií a a naopak. Například podle [ONTPADE05] by bylo praktičtější pro objektové modelování používat místo běžných dosti neformálních UML modelů ontologie, především proto, že: •

jsou formálnější, a tedy snadněji automatizovatelné

•

mohou být snadno převedeny do méně formálního popisu (grafické notace) použitím stylu, opačně je to podstatně složitější

•

není žádný centrální model softwarového designu ani ústřední bod kont roly. Vizí je, že softwaroví inženýři použijí ontologie pro zachycení návr hových vzorů (design patterns) a zveřejní je na webu. S podporou inde xačních služeb, jako např. google, budou snadno dohledatelné díky kvalit ním meta informacím.

•

nabízejí možnosti inference

25


mohou být snadno rozšířeny přidáním dalších konceptů typických pro konkrétní programovací jazyky nebo jejich verze (java asserty, vnitřní tří dy, meta tagy) nebo přidáváním AOP konceptů.

•

tato rozšíření mohou být implementována jako nezávislé zdroje, které mohou být pospojovány dohromady. Výsledkem bude síť návrhových vzo rů.

Osobně si myslím, že je to rovněž perspektivní a zajímavá možnost využití on tologií. Vidím zde ještě další souvislosti, především s principy modelem řízené ar chitektury (MDA). Soudím totiž, že ontologie nabízejí dostatek prostředků nejen k popisu návrhových vzorů, ale celých vlastních programů. 1.4.3.c Ontologie a rámce

Rámce jsou dalším, dosud nezmíněným druhem formalismu.

rámce Jsou to struktury pro reprezentaci stereotypních situací a odpovídají cích stereotypních činností (scénářů). Inspirují se lidskou schopností na základě zkušeností si utvářet rámcové myšlenkové struktury. Rámce se pokoušejí reprezentovat obecné znalosti o třídách objektů, znalosti pravdivé pro většinu případů, tedy počítá se s tím, že mohou existovat objekty, které porušují některé vlastnosti popsané v obecném rámci. Rámec je tvořen jménem a množinou atributů. Atribut (rubrika, slot) může dále obsahovat položky (links, facets), jako např. aktuální hodnotu (current), implicitní hodnotu (default), rozsah možných hodnot (range). Dalšími položkami slotu mohou být speciální procedu ry, jako např. ifneeded, ifchanged, ifadded, ifdeleted, které jsou au tomaticky aktivovány, jestliže nastanou příslušné situace. Mezi rámci mohou existovat vztahy dědičnosti, díky nim lze dis tribuovat informace bez nutnosti duplikace. Rámec může být specia lizací jiného obecnějšího rámce (vztah typu specializationof) a sou časně může být zobecněním jiných rámců (vztah typu generalization of). [EXPERTD01] Dědičnost může být u rámců i vícenásobná – jeden rámec je potomkem více jiných.

26


Rámce jsou preferovaným schématem reprezentace v modelovém a případovém usuzování (modelbased reasoning, casebased reaso ning). Pro reprezentaci lze použít některý z jazyků jako KRYPTON, FRL nebo KSL. Rámce se definují třeba tak, jak je uvedeno dále příklad je inspirovaný [ON TOLED03]. Nedělám si valné iluze o smyslu definovaných rámců, ale i tak bude užitečný. Je z něj zřejmé například to, že nejdříve se obvykle nadefinují typy, a třeba až konkrétní potomek může doplnit konkrétní hodnoty. Nic takového na druhou stranu meta model rámců striktně nevyžaduje. class-def Keyword class-def Similarity slot-constraint keyword1 value-type Keyword slot-constraint keyword2 value-type Integer class-def KeywordSimilarity subclass-of Keyword subclass-of Similarity slot-constraint keyword1 has-value BlahBlah slot-constraint keyword2 has-value 10

Rámce mohou sloužit k popisu prvků ontologie a také se tak občas používají. Uzel v takovém případě bude vlastně rámcem – bude mít sloty, bude zapadat do hierarchie dědičnosti apod.

1.4.4 Ontologické inženýrství Ontologické inženýrství zahrnuje podporu v průběhu celého životního cyklu on tologie – v průběhu návrhu, ověřování, validace, správy, nasazení, mapování, in tegrace, sdílení a znovupoužití. Budování ontologií je náročné, stojí hodně času a je nákladné, zejména pokud je cílem taková ontologie, která umožní provádět au tomatizované inference. Jedním z komplikujících faktorů je to, že je třeba získat konsenzus široké komuni ty, jejíž členové mají radikálně jiné názory a pohledy na věc, na doménu, která je mapována. Konsenzu je dosahováno různě – jedním extrémem jsou malé on tologie tvořené velkou skupinou lidí, jimiž vytvořené kousky se pospojují do vý 27


sledné ontologie. Druhým extrémem jsou velké zejména toplevel ontologie, jejichž vývoj je obvykle pevně řízen zodpovídajícím konzorciem či standar dizační organizací. V prvním případě je klíčová schopnost spojovat, ve druhém efektivně vést tým ke společné práci, navrhovat a analyzovat. [ONTADGL02] Pro účinný návrh existují metody, techniky a nástroje. Základem je jazyk pro po pis ontologie a pomoc v podobě neformálního grafického zobrazení. 1.4.4.a Nástroje

formální specifikace ontologie Obvykle v textové podobě, používá se některý z mnoha jazyků pro po pis ontologií. Mezi nejznámější patří DAML+OIL, OWL, RDF a RDFS, Z, KIF (zdá se mi docela přehledný a účelný), RuleML (pro za chycení pravidel v sémantickém webu), CYCL, SUMO a našli bychom i další.

neformální vizualizace Nástrojem neformální vizualizace ontologie je graf. Tak jak jsme zmi ňovali u sémantických sítí, jde pouze o uzly a vazby mezi nimi, tedy o to, zda tam uzel je nebo není a stejně tak zda hrana je a jaké uzly spo juje. Tvar, barva a uspořádání uzlů a hran v ploše není relevantní, to vše by pouze mělo přispívat k přehlednosti. Graf může mít tvar stro mu, obvykle jde ale o spletitou (tangled) hierarchii, obsahující kruhy. Význam grafu je v jeho názornosti – z grafu obvykle snadněji pochopí me, co je třeba a stejně tak se nám graficky daří dobře formulovat myš lenky; u strojů je to přesně naopak.

aplikace pro práci s ontologiemi Existuje mnoho specializovaných nástrojů, které pomáhají tvořit, spravovat i využívat ontologie. Většina z nich podporuje několik for mátů, umí generovat grafy, mnohé z nich i prohledávat a třeba prová dět i nějaké inference. Většinou jde o samostatné aplikace. Při svém zkoumání jsem narazil například na tyto nástroje: Protége, DLworkbench, OilEd, Z/EVES, CREAM (anotace textu, zejména webových stránek), OntoWeaver, WebODE, Jena, Dspace, VOM, Kactus. Kromě Protége, který je poměrně známý mě zaujal pře 28


devším aplikační server pro sémantický web nazvaný Kaon [KAEVOH04] univerzity Karlsruhe. 1.4.4.b Činnosti

dolování ontologií Ontologie může být budována výhradně ručně, inženýr vytváří veškeré koncepty a vazby mezi nimi. Může být ale také alespoň z části na čerpána (vydolována) z nějaké jiné reprezentace. Existují nástroje na generování ontologií z textu, z databází, z dalších ontologií a z různých kombinací datových zdrojů. Podobně automaticky získaná ontologie ale samozřejmě vyžaduje dodatečnou revizi a validaci.

mapování ontologií Jde o hledání vazeb mezi ontologií a neontologickými entitami nebo naopak připojování ontologických meta informací datům. Příkladem intenzivního využívání těchto postupů je tvorba tématických map ( topic maps). 1.4.4.c Znovupoužití ontologií

spojování ontologií (merge) Výsledkem jsou stále dvě ontologie, ale s definovanými společnými místy a přesahu jícími vztahy. Vý znam má především tam, kde se očekává budoucí rozvoj a údržba spojovaných ontologií.

integrace ontologií Výsledkem je jedna nová ontologie, která zahrnuje informace z on tologií původních. Jde o nejtěsnější možné spojení. Integrovaná on tologie je již nezávislá na ontologiích původních.

29


transformace ontologií Může být přinejmenším dvojího druhu transformace meziformátová, tedy mezi jazyky pro zachycení ontologií (RDF > OIL) anebo séman tická, tedy změna vnitřní struktury podle jiného meta modelu nebo pro jiné použití.

evoluce ontologií Tedy údržba, doplňování nových konceptů, slaďování se současnými poznatky o doméně nebo o ontologiích.

1.5 Konkrétní ontologické slovníky Konkrétních slovníků existuje velké množství, možná tisíce. Několik málo z nich si stručně představíme. Zaměřil jsem se především na dvě skupiny, které v kontextu práce považuji za významné na toplevel ontologie a ontologie pro podniky a obchod.

1.5.1 Top-level ontologie 1.5.1.a WordNet

WordNet WordNet je online lexikální referenční systém, inspirovaný současný mi psycholingvistickými teoriemi lidské lexikální paměti. Anglická podstatná jména, slovesa, přídavná jména a příslovce jsou zorganizová ny do systémů množin, kde každá reprezentuje příslušný lexikální koncept. Mezi koncepty jsou různé vazby, například jsou takto zachycena synonyma. [WORDNET] Pro práci s ontologií je možné použít webové rozhraní nebo speciální klientský program. 1.5.1.b Cyc

Cyc Znalostní server Cyc je velmi rozsáhlá multikontextová znalostní báze a inferenční stroj vyvinutý společností Cycorp [CYCORP]. 30


Jejím cílem je překonat slabá místa současných aplikací jednou provždy vytvo řením základny všeobecného poznání – sémantického substrátu termínů, pravidel a vztahů, které umožní vytvářet širokou paletu znalostně orientovaných produktů a služeb. Cyc se snaží nabídnout hlubokou úroveň porozumění, které přinese programům nebývalou flexibilitu. Hlavním výsledkem jejich snažení je, jak jinak, obsáhlá a univerzální ontologie. Autory deklarované příklady možného použití jsou docela inspirativní, lze je chá pat i jako obecně široké možnosti toplevel ontologií, proto si je zde vyjmenuje me; posbíral jsem je z více míst na jejich webu: •

porozumění textu a příprava dokumentů

•

porozumění řeči

•

inteligentní strojový překlad

•

generování textu

•

expertní systémy

•

tréningové simulace

•

umělá inteligence her

•

online komerce

•

online poradenské služby

•

cílený marketing

•

čištění a integrace databází

•

čištění a integrace tabulek (spreadsheets)

•

aktivní menu a formuláře

•

praktická encyklopedie

•

odpovídání na otázky

•

vyhledávání dokumentů a fotografií

•

distribuovaná umělá inteligence

•

zprostředkování prodeje zboží a služeb

•

chytrá rozhraní

•

inteligentní simulace pro hry 31


bohatá virtuální realita

•

sémantické dolování

•

inteligentní agent – osobní poradce pro nakupování

Inspirativní je i architektura systému:

Existuje i open source verze Cyc ontologie a nástrojů pro práci s ní [OPENCYC].

1.5.1.c The Suggested Upper Merged Ontology (SUMO)

SUMO SUMO, MILO (MIdLevel Ontology) a související doménové on tologie společně tvoří největší současnou formální veřejně dostupnou ontologii, dohromady obsahují 20000 konceptů a 60000 axiomů. Ano, není to pouhá taxonomie, ale je bohatě axiomatizovaná. Všechny koncepty jsou formálně definované ve vlastním jazyce SUOKIF. Významy nejsou závislé na konkrétní implementaci inferenčního mechanismu, ovšem systém pro inferen ce a správu ontologie je k dispozici. K dispozici je také grafický nástroj KSMSA pro pohodlné prohlížení a editaci. [SUMONP01]

Toto jsou současné doménové ontologie a je pozoruhodné, o jak odlišné domény jde: •

komunikace

•

země a regiony 32


distribuované výpočetní systémy

•

ekonomie

•

finance

•

inženýrské komponenty

•

geografie

•

vláda

•

vojenství

•

severoamerický klasifi kační systém průmyslu

•

lidé

•

fyzické elementy

•

mezinárodní otázky

•

doprava

•

viry

•

světová letiště

•

terorismus

•

zbraně hromadného ni čení

Na rodině SUMO je založena spousta výzkumných projektů i funkčních aplikací z oblastí prohledávání, lingvistiky a usuzování. SUMO je také jedinou formální ontologií, která je plně namapovaná na lexikon WordNet zmíněný výše. Vlast níkem je IEEE, konzorcium ji vyvíjelo pro svobodné použití. Rozšiřující on tologie jsou zveřejněny pod GNU General Public License. Bez povšimnutí nelze nechat také to, že SUMO disponuje šablonami pro gene rování jazyka; podporována je angličtina, němčina, italština, čínština, hindština a (což nás především těší) čeština.

33


1.5.1.d Další zajímavé projekty

Dolce Popisná ontologie pro lingvistiku a kognitivní inženýrství.

OntoMap Portál pro ověřování a porovnávání upperlevel ontologií a lexikálních znalostních bází.

OntoKhoj Portál pro ontologické inženýrství.

1.5.2 Vybrané ontologie pro podniky a obchod 1.5.2.a KSL

KSL provádí výzkum v oblastech reprezentace znalostí a automatizovaného usu zování, za projektem stojí Stanfordská univerzita. Současné práce se zaměřují na sémantický web, hybridní usuzování, vysvětlování odpovědí z heterogenních aplikací, deduktivní odpovídání na otázky, reprezentace usuzování ve více kontextech, agregace znalostí, ontologické inženýrství a znalostní technologie pro analytiky. [KSLSTANF] Kromě jiného je na serveru projektu k dispozici několik jednoduchých, ale zají mavých ontologií. Pro použití v obchodu jsou použitelné především dvě z nich: •

Productontology

•

ComponentAssemblies

1.5.2.b AIAI Enterprise

Projekt štědře financovaný britskou vládou, cílem je propagovat používání zna lostních systémů v modelování obchodních aplikací, cílem je pomoci organizacím zvládat management změny. Ontologie, která je součástí projektu má být schopna popsat různé aspekty toho, jak komerční organizace funguje a jak je řízena. Smys lem je reprezentovat organizaci v takové podobě, která může být použita jako zá klad pro rozhodování. [AIAI] Pročetl jsem si různé materiály o této ontologii a na jejich základě jsem sestavil jednoduchý neformální diagram některých ústředních 34


konceptů (aktivity, aktéři, čas, cíle, zdroje, prodeje) vč. příkladů in stancí, který pomůže získat přehled o tom, co konkrétně ontologie řeší: Effect Resource performs is performed

Activity

Doer

Subactivity Time Range

Person

Machine Org.unit

šálek kávy

pít kafe

skill

Franta

hold (permission)

1.5.2.c Business Management Ontology (BMO)

Open source integrovaný informační model pro spojení informačních technologií s prostředím obchodu. Zabývá se návrhem obchodních procesů, správou a

35


řízením projektů, řízením požadavků, řízením obchodní výkonnosti (v podobě vy rovnaných výsledkových listů). Vytváří základ pro integrovanou, nezávislou znalostní bázi řízení podniku, ze kte ré mohou být generovány rozličné artefakty. Ontologie je určena především pro obchodní analytiky, může posloužit i IT expertům jako základ pro spojení definic specifických pro IT (software, web...) a konceptů obchodních. [BUSMANONT] Ontologie působí přehledně, jako nejpoužitelnější mi připadá ta část, která se za bývá definicí procesů. Má také modulární a rozšiřitelnou architekturu. Důsledně rozlišuje koncepty, těm říká „entity“ (např. „zákazník“, „dodavatel“) a instance, kterým říká pro změnu objekty („zákazník Franta“). Na stránkách projektu je pěkně ilustrovaná myšlenka využití ontologie jako cent rálního repozitáře pro návrh programu s možností generovat jiné reprezentace:

36

Teoretická část Synergie ontologií a webových aplikací

C Synergie ontologií a webových aplikací C.1 Vize: Ontologický Internet Již jsme se lehce zabývali tím, jak Internet změnil zaběhnuté pořádky. Že přinesl mnohem větší změnu, než třeba telefon, že má potenciál nahradit nejen telefon, částečně poštu, ale také televizi, rozhlas, knihovny, banky, podatelny úřadů a částečně možná i úřady samotné... Internet poskytuje především technickou infrastrukturu, propojuje celý svět. Jeho obsah ne nesmírně rozsáhlý, ale také silně decentralizovaný. To je jistě výhoda – přináší odolnost, umožňuje aplikovat principy volného trhu – můžeme říct, že ne viditelná ruka Internetu určuje, který projekt má smysl a který nikoliv. V současné době můžeme pozorovat postupný posun těžiště významu od typických desktopových aplikací k aplikacím webovým. Zatím nikoliv ve všech oborech a typech aplikací, ale především tam, kde klíčovou roli hraje komunikace a sdílení je tento trend zřejmý – podnikové informační systémy, systémy vládních a samosprávných úřadů, groupware, CRM, ale také počítačové hry a multimedi ální zábava. Tuším, že je jen otázkou času, kdy podobný vývoj bude čekat i další aplikace – především ty, kde opět jde především o spolupráci, tedy např. systémy CAD/CAM, vývojová prostředí pro budování softwaru, možná i ty kancelářské balíky, které dnes považujeme za typicky desktopové. Brzdou pro takové pojetí dosud byla rigidita tvůrců těchto systémů (ta zmizí nebo zmizí oni), ale také nedo statečné technické parametry sítí s Internetem v čele (rychlost, spolehlivost, bez pečnost) a jejich nedostatečná rozšířenost. Internet již dnes poskytuje ohromující výpočetní výkon. Z jednotlivých počítačů lze sestavit výpočetní klastry nebo gridy, kterým se především na poli úloh, které lze rozdělit a paralelizovat žádné sebedokonalejší superpočítače nemohou rovnat – viz SETI@home nebo novější a zajímavější iniciativy COINC, například pro predikce vývoje klimatu [CPREDICT]. Většina prostředků Internetu slouží lidem, tedy přímo lidem. Obrovský a z větší části stále ještě z větší části nevyužitý potenciál je naopak v autonomní komu nikaci mezi počítači, jednotlivými systémy. Takovou spoluprací by mohly vznikat další hodnoty – pro lidi. 37


Svoboda a decentralizovanost také vede k tomu, že nikoliv vždy se podaří nalézt přesně tu službu či produkt, která by vyhovovala nejvíce. Značnou moc získávají služby, které přinášejí určitou centralizaci a tak vnášejí do živelného prostředí řád – velké portály s diskuzními skupinami, zpravodajstvím, obrovské elektro nické obchody (amazon.com)... a zejména indexační a prohledávací servery s Go oglem v čele. Taková centralizace přináší nebezpečí – například vyhledávací portál může značným způsobem ovlivňovat, které projekty budou úspěšné a které nikoliv. Sta čí, když do vedení takové společnosti pronikne někdo se záměrem prosadit své myšlenky, politické cíle, názory. S růstem významu Internetu rostou i taková ne bezpečí. Je vůbec nějaká alternativa? Je možné vnést řád do aplikací a služeb nekoordi novaně vznikajících, bouřlivě se rozvíjejících a nečekaně končících? Je možné propojit Internet na úrovni obsahu a významu zdola, bez nezbytné asistence mocných společností nebo alespoň s omezením jejich moci? Je možné efektivně spolupracovat na velkých, výpočetně náročných projektech? Myslím že ano. Jak již asi tušíte, myslím, a že cesta vede přes masivní nasazení ontologií. Ontologie samy o sobě nabízejí prostředky poznání, porozumění a po chopení, umožňují propojit odlišné myšlenkové mapy, subjekty působící ve stejných i jiných konceptuálních doménách, lidi a stroje. Internet k tomu nabízí infrastrukturu. Spojením vznikne nová kvalita.

C.2 Obecné přínosy Při vývoji ontologického systému potřebujeme budeme potřebovat široký rozhled usilujeme přeci o univerzálnost. Proto se nyní zamyslíme nad obecnými efekty spojení ontologií a webu, nad sémantickým webem a také nad přínosy pro jednot livé obory lidské činnosti a pro architektury aplikaci pracujících v síťovém prostředí. Jako v celé práci, nepůjde nám o vyčerpávající přehled, ale o náznaky a ukázku směrů.

38


2.1 Přehled a zvládnutelnost

popis Ontologie dokáží velmi kvalitně a precizně popsat problém, situaci, produkt, službu nebo obecně cokoliv. Popis je vysoce strukturovaný, a tedy mnohem snáze uchopitelný, strojově zpracovatelný.

souvislosti Součástí kvalitního popisu mohou být souvislosti s dalšími koncepty. Vztahy mohou být na rozdíl od klasických hyperlinků typové a mohou být jednosměrné i obousměrné. Jednotným způsobem je možné zachy tit alternativy, doplňující informace, výhody, použité technologie, příklady použití, varianty..

porovnávání Ontologie je prostředkem domluvy. Překlene tak bariéry dané roz dílným jazykem, rozdílným způsobem vyjadřování, rozdílné jednotky, způsoby reprezentace. Umožní uživateli mnohem snáze a z velké části automatizovaně porovnávat – produkty, jejich vlastnosti, ceny..., postu py, technologie, definice... a leccos dalšího.

ovladatelnost a prohledávání Určitým rysem dnešní doby je informační zahlcení, plodící v lidech informační úzkost až averzi k informacím či apatii. Pokud potřebujete konkrétní jednoduchou informaci, vyhledávač vám nabídne několik miliónů možností. Je pravda, že výsledky jsou seřazeny podle význa mu a relevance, ale je to pořád nedostatečné. Pokud chcete mít alespoň nějakou jistotu, že nalezená informace je opravdu ta, kterou hledáte a ta nejlepší možná z nich, možná musíte projít spoustu z nich. To vás stojí čas a úsilí. S daty obohacenými o ontologií zachycenou sémantiku by bylo mnohem snazší automatizovaně posuzovat relevanci.

clustering Jednoduché fulltextové hledání dnes již nestačí. Je třeba nabídnout prostředky třídění a organizace výsledků do smysluplných kategorií, které umožně uživatelům načerpat mnohem více znalostí a vhledu do 39


problému. Díky kategorizaci výsledků si snadněji vyberou, kterým směrem dál zaměřit pozornost. Příkladem poměrně úspěšného nástroje, který něco takového prová dí s klasickým webem je Vivísimo. Technika, která běhá v pozadí dokáže kategorizovat velké objemy dat bez komplikovaného zpra cování konkrétních dokumentů. Vystačí si i bez nějaké speciální taxonomie (bavme se zrovna o ontologii), ale s ní funguje ještě pod statně lépe. Dramaticky by se účinnost této metody zvýšila, kdyby byly dokumenty explicitně doplněny alespoň o základní vazby s on tologickými koncepty. [VIVISTAXO]

2.2 Spojení

agragace, integrace, unifikace Podniky a instituce jsou prostoupené informacemi ve všemožné podo bě, struktuře a kvalitě.. Ontologie by mohly být prostředkem propojení a následné unifikace takových heterogenních zdrojů. Databáze které obsahují cenná data a již dnes jsou cenným aktivem by mohly sloužit ještě mnohem lépe v integrovaném celku. Ontologie by se staly jádrem informačního systému, prostředkem pro kompozici ne závislých webových služeb, ale také pro spojování nejen v rámci or ganizace ale i mezi organizacemi – to jsme ale již párkrát zmínili.

snížení redundance Redundance zvyšuje náklady znovu a znovu jsou vytvářeny, shro mažďovány, zpracovávány, ověřovány, porovnávány informace již mnohokrát předtím vytvořené, shromážděné, zpracované... Kromě toho, redundance vede k nekonzistenci, když si duplikovaná data vzá jemně protiřečí. S použitím ontologií by mohla být data by místo du plikace sdílena, a tak by redundance i nekonzistence mohla klesnout anebo by se alespoň stala lépe kontrolovatelnou.

40


znovupoužití Konceptualizovaná data by bylo mnohem snadnější použít, a to nejen jednou a jednoúčelově, ale mnohokrát a i doposud netušenými způso by.

2.3 Komunikace a vzájemné porozumění

propojení Ontologie by mohly vytvořit komunikační platformu pro spojení lidí vzájemně, lidí a technologií, technologií mezi sebou. Rozdíly mezi vý sledky práce lidí a strojů by se mohly postupně stírat. Pokud vám například robot v centru technické podpory dobře poro zumí a přesně a sofistikovaně poradí, je vám koneckonců jedno, že je to robot a nikoliv operátor z masa a kostí. S podporou ontologických technologií by mohlo nastat mnohem těs nější propojení informací a procesů reálného světa a informací a proce sů v elektronickém prostředí. Překlenuly by se různé bariéry dané třeba nekompatibilními jazyky ( mnohojazyčná ontologie). Otevírají se také možnosti automatického přizpůsobování nejen vzhledu, ale i obsahu webu hendikepovaným osobám.

sdílení Čím dál více popularity si získává architektura P2P systémů – ko neckonců nabízí úplnou decentralizaci tak, jak to bylo původním zá měrem tvůrců Internetu. Mnoho z nich slouží především sdílení dat – nejčastěji hudby, filmů, dokumentů, programů. Mám na mysli obecné systémy jako Direct Connect, eDonkey, ale také BitTorrent nebo specializované, jako třeba SoulSeek. Většina systémů umožňuje vyhledávat podle omezené množiny cha rakteristik dat – nejběžnější je hledání podle názvu souboru. Všechny tyto systémy by mohly postoupit na kvalitativně vyšší úroveň, kdyby umožnily uživatelům popsat a sdílet (ať je to zajímavější, vytvořme nový veselý termín D&S, describe & share) svá data pomocí ontologie. 41


S využitím ontologie by šlo hledat data podle mnoha charakteristik, šlo by ale rovněž snadno a efektivně objevovat třeba uživatele se společnými zájmy. Myslím, že k podrobnostem se dostaneme ještě v případové studii o popisu a organizaci dat a také v samotném závěru práce, která bude věnována architektuře ontologických systémů.

Kromě sdílení dat existují i zajímavé projekty sdílení meta dat v rámci komunity. Za zmínku stojí třeba různé projekty sdílení a znovupoužití odkazů na zajímavé informační zdroje, někdy spojené s hodnocením a kategorizací. [STUMBLEUP]

spolupráce P2P systémy ale nelze chápat pouze jako nástroje sdílení dat. Cítit jsou tendence zapojit uživatele do tvorby obsahu a hodnoty, chápat je niko liv pouze jako prosté konzumenty, ale jako spolupracovníky. Ať doplňují ontologii, ať popisují informace meta informacemi z on tologií, ať se cítí jako součást celku, ať v to všem vidí možnost sebe realizace. Budou z toho mít radost a my získáme zpětnou vazbu, vy tvoříme komunitu a v neposlední řadě dostaneme více či méně kvalitní obsah prakticky zadarmo. Inspirací mohou být internetové komunity, především okolo open source projektů nebo různých jiných svobodných forem spolupráce – například budování svobodných sítí [CRFREENET].

C.3 Sémantický web Sémantický web spojuje zdroje informací do podoby znalostí. Umožňuje tak provoz inteligentních služeb, jako již zmíněný clustering nebo masivní persona lizace. Pomáhá uživatelům ve správném uchopení a použití webu.

3.1 Obsah, tvorba a údržba

automatizace Představme si web, který anotuje a popisuje sám sebe – i to mohou systémy postavené na ontologiích nabídnout. Úspěch sémantického 42


webu totiž závisí na dostupnosti ontologií a také na proliferaci webových stránek anotovaných metadaty odpovídajícími ontologiím. Klíčovou otázkou je, kde vzít tato metadata. V tomto směru se rýsují slibné cesty – například v práci [ANOTCHS04] je představen systém pro automatizovaný proces ka tegorizace instancí na základě technik rozpoznávání vzorů, automa tizovaný do té míry, že nepotřebuje žádný dohled. Výsledky systému jsou ověřovány a porovnávány s anotacemi vytvořenými lidmi. Směry dalšího výzkumu jsou například: •

sémantický hypertext, konceptuální spojování, vypočítatelná hypertextová struktura (metahypertext)

•

hromadná a automatizovaná kategorizace webu

•

katalogizace služeb na webu

•

generování webu ze znalostí (ontologií)

•

sémantické dolování (semantic web mining)

agregace Informační portály či informační služby agregující mnoho zdrojů při dávají novou hodnotu tím že agregovaná data třídí, hodnotí, po rovnávají, zajišťují jednotné a přehledné rozhraní.. Ontologie by mohly jejich schopnosti podstatně zvýšit – podle ontologických metadat by mohly být agregovatelné služby vyhledávány, zařazovány do kategorií, podle kterých by si zase jednotliví uživatelé mohli vybírat, co je zají má. To vše mnohem přesněji, precizněji, s vyšší relevancí.

spravovatelnost, trvalá hodnota Klíčem k vyšší dynamičnosti, snadnější spravovatelnosti a vyšší auto matizovatelnosti je kromě jiného důsledné oddělení obsahu od formy, proces někdy nazývaný sémantizace, tedy konkrétně rozlišení •

vzhledu

•

obsahu

•

významu

43

Teoretická část Synergie ontologií a webových aplikací •

logiky

Díky tomu bude snadné stejnou myšlenku prezentovat mnoha forma mi, vzhled měnit podle aktuálních potřeb nebo přání uživatelů. Díky oddělení a kvalitnímu zachycení logiky se nestane například, že zasta ráním nějaké publikace budou zapomenuty i její stále platné nosné myšlenky.

3.2 Využití

navigace Ontologie mohou nabídnout nové možnosti navigace. Můžeme zva žovat různé úrovně ontologické podpory navigace – navigace ontologií podporovaná, na ontologii založená anebo ontologií řízená. Například ontologií podporovaná navigace může vypadat takto [ONNAVCR00]: 1. Systém načte profil uživatele – ten obsahuje cíle a omezení. 2. Automaticky vygeneruje vážené sémantické odkazy mezi dokumenty. 3. Vazbám dodá role, významy (půjde o typové vztahy). Při tom bude brát v úvahu profil a doménovou ontologii a ontologii diskuze a vyjednávání. 4. Mezi množstvím odkazů vybere nejrelevantnější vůči kontextu a záměrům uživatele. 5. Poskládá zdroje s využitím vhodných pedagogických a vy pravěčských strategií. 6. Výpočty provádí v souladu s omezeními časovými a jinými ekonomickými, jak jsou stanoveny v profilu.

hledání Přínos ontologií je zřejmý, již jsme jej zmiňovali – s jejich použitím vzroste výkonnost a přesnost. Ontologie mohou být použity pro anota ci dokumentů, ale i pro specifikaci dotazů. Pomocí může být i perso

44


nalizovaný informační asistent jako samostatný program, nejspíše s ar chitekturou inteligentního agenta – o které se ještě zmíníme v závěru. S podporou ontologií bude snadnější ohodnocovat zdroje, posuzovat jejich kvalitu a relevanci.

objevování (semantic discovery) Budouli služby vhodně popsány ontologiemi, silně to napomůže jejich dynamickému objevování a zařazování do kontextů a větších celků. V této souvislosti jsou zajímavé rovněž principy a důsledky SaaS, jak budou rozebírány ještě v závěru práce.

setkávání (matching) Snáze se setká poptávka a relevantní nabídka, požadavek a řešení, agent a služba.

C.4 Podle typu média V této části se především zamyslíme nad tím, jaké typy dat mohou být obohaceny ontologiemi.

4.1 Lexikografická data

přirozený jazyk Jednou z hlavních aplikací ontologií je právě reprezentace, přenos a sdílení jazykových konstrukcí, vazeb a významů. Obor, který se tím zabývá se nazývá ontologická sémantika. Cílem je pomoci strojům „pochopit“ text, hledat vazby mezi různými jazyky, což může být zá kladem kvalitních překladových nástrojů, výkladových slovníků apod.

text Mohli bychom ještě mluvit o extrakci významu z textu, dolování pravidel, hodnocení novosti..

45


4.2 Procesy a spolupráce

spotřební elektronika Především výrobci spotřební elektroniky (Sony..) se předhánějí ve zve řejňování vizí, kde spotřebiče budou vzájemně komunikovat a komuni kovat s lidmi a počítačovými systémy. Myslím si, že pokud má podobný systém vůbec fungovat, bez značné dávky umělé inteligence se neobejde – alespoň zatím. Ale pravděpodobně i do budoucna nelze očekávat od většiny populace, že se sníží na dostatečně technologickou úroveň, aby se s takovými stroji a přístroji bavila „v jejich jazyce“. Především formální jednoduché ontologie mohou být klíčovým po mocníkem vzájemnému porozumění i v této oblasti. Viz v textu roztroušené poznámky o informační úzkosti, infor mačním opaření apod.

procesy Ontologie jsou často využívány pro modelování, dekompozici, restruk turalizaci a simulaci procesů.

toky dokumentů Systémy pro správu dokumentů a řízení workflow (mimochodem stále častěji realizované v architektuře webových služeb) mohou rovněž díky ontologiím nabídnout vyšší komfort – lepší možnosti kategoriza ce, perzonalizace apod.

4.3 Multimédia

streamovaná multimédia Množství takového obsahu na Internetu silně roste. Nemyslím si, že by měla být multimédia reprezentována ontologiemi, ale ontologické anotace (metadata) by usnadnily setkání uživatelů, kteří požadují něja ký obsah a poskytovatelů, kteří jej nabízejí.

multimédia obecně Mnoho multimédií je v současné době anotováno primitivními prostředky – příkladem mohou být ID3 tagy MP3 dokumentů nebo 46


údaje uváděné v AVI obálce. Ontologická kategorizace by prospěla každému druhu médií a multimédií. Snadnější správa, vyhledávání, or ganizace, sdílení... vše o čem jsme již mluvili zde platí na sto procent.

4.4 Správa sítě

práva a oprávnění Pro zachycení práv a oprávnění v síťovém prostředí jsou nejčastěji po užívány stromové LDAP databáze nebo jejich obdoba. Například Active Directory ve Windows nebo třeba Netware NDS, eDirectory... Podoba mezi strukturou těchto dat a ontologiemi je zřejmá. Repre zentace v podobě ontologií by ještě více usnadnila napojení na další systémy. Pomohla by také při kooperaci subjektů (viz virtuální firma), jinak bolestivé a nákladné integraci (při fůzích a akvizicích), případně transformaci (při změnách v procesech, rolích, kompetencích, zejména jako součást reinženýringu).

plánování a správa síťové infrastruktury Pokud by byly uzly síťové infrastruktury popsány jako koncepty on tologií, usnadnilo by to plánování a optimalizaci infrastruktury. Síťové prostředky jsou obvykle spravovány s použitím standardních protokolů (zejména SNMP) a odpovídajících nástrojů. Ontologické systémy pro správu sítě by mohly pro vyšší pohodlí správců taktéž generovat SMTP zprávy. Zajímavá je myšlenka inteligentních agentů, kteří by putovali počíta čovou sítí, hledali by vadná a špatně fungující místa, chyby by sami napravovali, případně hlásili nadřazeným autoritám. Určitě by jim po mohlo, kdyby jednotlivé prvky infrastruktury byly anotovány vhodnou ontologií – agenti by pak mohli snáze učit smysl a význam prvků, spo jů, tras, procházejících dat apod.

47


C.5 Podle architektury Webové služby, podnikové informační systémy, P2P – o tom všem jsme již mluvi li. Zmíníme proto jen pár zajímavějších a méně běžných..

weboví agenti Pan Bell navrhl v práci [AGENTRB95] univerzální architekturu inte ligentního agenta, vhodného zejména pro práci v prostředí webu. Ar chitektura je tak obecná, že je prakticky jedno, v jaké oborové doméně agent pracuje – jeho jádro je stabilní a jediné, co je závislé na konkrét ní doméně a použití jsou senzory a efektory. Takoví agenti by mohli provádět cokoliv – hledat novinky v oboru, po suzovat aktivity konkurence, sledovat vývoj veřejného mínění, sloužit jako mnohem inteligentnější obdoba botů (indexačních agentů) nebo třeba fungovat jako osobní rádce.

adaptivní systémy Nejde nikoliv o konkrétní architekturu, spíše o konkrétní výraznou nebo dokonce klíčovou charakteristiku. Jsou to systémy, které reflektu jí změny v prostředí – např. ve vysoké peci, nebo třeba v legislativě a dynamicky přizpůsobují své chování, případně se učí z důsledků svých minulých akcí. Myslím že takový umělý právní nebo účetní poradce by vůbec nebyl k zahození... Současný web je pro takové systémy docela velkým oříškem – těžko mu porozumí, je vytvářený především pro lidi. V sémantickém webu by se ale cítili jako doma – ontologie by sloužila jako slovník.

znalostní systémy Velká kategorie programů pro zachycení, manipulaci, sdílení a využí vání znalostí a „korporátních vzpomínek“. Ontologie jsou nedílnou součástí nebo dokonce jádrem mnoha z nich. Stále běžnější jsou tyto systémy jako nástroj znalostního managementu ve velkých společnostech. Myslím že je zde ale ještě velký potenciál, především v oblastech, kte ré jsou těmito technologiemi zatím ještě nedotčené. Velmi by pomohly například komunitám okolo různých svobodných a neziskových 48


projektů – open source programů, svobodně budovaných a využí vaných sítí [CRFREENET]. Přílišná roztroušenost a nízká centralizace vede k tomu, že mnoho cenných znalostí je zachyceno jen v podobě diskuzí a fór, oficiální dokumentace bývá spíše podružná, leckdy neak tuální nebo neúplná. Znalostním systémem by možná nepohrdly ani různé další spolky a zájmové skupiny.

C.6 Podle oborů a činností O mnoha souvisejících věcech jsme již mluvili v jiném kontextu, tak jen stručně..

6.1 Komerční Podle [VALPRBM00] je pro úspěšné elektronické obchodování nezbytné řídit se pěti pravidly: •

Jedinou možností je dát zákazníkům na výběr, ale chytřeji než dosud – dostatečná volnost, ale nikoliv přesycení; výběr z možností, které jsou spe cificky uzpůsobené podle profilu...

•

Rychlejší je lepší, zákazníci platí za rychlost

•

Uděláte dobře, pokud nebudete dělat všechno

•

Zacházejte s partnery jako s partnery

•

Poznejte, co zákazníci potřebují aneb super služby a perfektní objednávky

Co pomůže naplnit tyto cíle? Například kvalitní popis produktů a nabízených slu žeb, sběr a analýza informací o zákaznících, unikátní zacházení s každým zákaz níkem jednotlivě, sběr a analýza informací o konkurenci, propojení systémů sub dodavatelů, zvládnutá logistika a řízení zásob... V tom všem pomohou ontologie.

B2C se sériovým zbožím Myslím že význam ontologií je zřejmý u klasických obchodů s běžným zbožím – pro snadnější hledání, porovnávání, efektivnější transakce... o tom všem jsme již mluvili.

B2C a C2C se specifickým zbožím Řekl bych ale, že ještě větším přínosem by byly ontologie obchodům se zbožím specifickým, kde každý kus je originál. U takových obchodů 49


jde především o matching, setkání konkrétní poptávky s konkrétní na bídkou. Mám na mysli umělecké nebo uměleckořemeslné produkty, ale především širokou oblast obchodů s použitým zbožím sta rožitnosti, bazary, autobazary, vrakoviště, antikvariáty, burzy sběratel ských předmětů – známek, pohlednic, mincí, pohledů.... Ve všech těchto případech je zákazník ochoten zaplatit i relativně hodně, pokud najde přesně to, co hledá. Na tom ovšem často vše ztros kotá – jak má sběratel zjistit, že konkrétní známka, kniha, komoda, ne dostatkový náhradní díl..., kterou/který usilovně shání leží na zaprá šené polici v zapadlém podniku v nějakém okresním městečku na druhém konci republiky? Ontologický systém, který by umožnil anotovat prodávané zboží a ná sledně propojil (integrace nebo brokering) zmíněné podniky, by přinesl značný užitek všem zúčastněným.

B2B a B2G O tom jsme již také mluvili, snad jen zopakuji klíčové pojmy integra ce partnerů pomocí ontologického modelu, virtuální firmy, automatiza ce procesů, reprezentace kontraktů s důrazem na řešení neobvyklých situací, ontologie pro B2B tržiště, integrace katalogů, alokace zdrojů a řízení zásob...

6.2 Nekomerční Zatím jsme se zajímali především o aplikaci v komerčních oblastech; možnosti použití ontologií a sémantického webu je ale široce přesahují, zasahují do snad všech oblastní lidské činnosti. Jen pár příkladů:

knihovny, muzea Představme si digitální knihovny s plnými texty miliónů publikací, dů sledně anotované podle vhodných ontologií, digitální muzea s ob razovým, zvukovým i multimediálním obsahem, opět důsledně anotované. Když to spojíme s možnostmi techniky blízké budoucnosti – mám na mysli extrémně ohebné displeje s vysokým kontrastem a mi nimální spotřebou nebo věrnou 3D vizualizaci – potřebujeme ještě vů bec jejich kamenné podoby? 50


mapy, GIS.. Vezměme si nějakou digitální mapu (třeba InfoMapu od PJSoft). Před stavme si, že by údaje o objektech na mapě byly popsány vhodnou on tologií. Jak snadno by se nám pak v takové mapě hledalo... A co víc, ontologický systém by mohl automatizovaně dohledávat souvislosti s dalšími externím datovými zdroji – recenzemi, turistickými průvodci, prezentacemi ubytovacích zařízení, kulturních památek.. Mohl by do plňovat provozní doby čerpacích stanic, doporučovat trasy podle mnoha kritérií..

archivy Možnosti využití ontologií jsou zde nebývalé. Prakticky celé archivní fondy (matriky, historické záznamy, výroční zprávy) by mohly být při nejmenším ontologicky anotovány nebo přímo do podoby ontologie převedeny. Třeba sestavení rodokmenu (které dnes znamená usilovnou, mra venčí, skoro detektivní práci) by bylo otázkou několika kliknutí my ší..

státní správa, místní samospráva.. Ontologie vlády, správních úřadů, místní samosprávy – interoperabili ta, efektivní komunikace: •

vertikálně i horizontálně mezi jednotlivými úřady sdílení infor mací, snížení redundance, úspory stohů papíru, pracovních ná kladů úředníků i občanů...; nadřízené úřady by mohly snáze hle dat a vyhodnocovat nejen chyby, ale i rizika a hrozby; například policie jednotlivých států a bezpečnostní a zpravodajské služby by mohly spolupracovat a sdílet konceptualizovaná data pro vy hledávání hrozeb, pátrání po nebezpečných osobách, sledování transportů zbraní, drog, chráněných zvířat a rostlin...

•

mezi úřady a občany – občan by již nebyl horkým bramborem, který si jednotliví úředníci přehazují tak dlouho, dokud nevy chladne a nepřestane ho to bavit; každý úředník by díky znalost nímu systému postavenému na ontologii věděl vše – úředník ka

51


tastrálního úřadu o daních z převodu nemovitosti, finanční úředník o sociálních dávkách..

e-Learning Význam ontologií pro elearning je myslím rovněž zřejmý...

52

Projektové studie Projektové studie

III Projektové studie Jak vyplývá z teoretické části, možností použití ontologií ve webových aplikacích je nepřeberně. Tuto rozmanitost budu mít na paměti při analýze požadavků vyví jeného systému. Smyslem práce není detailně zkoumat každé možné použití, pokusím se ale vybrat několik reprezentativních možností, kterým se budu vě novat více a ze kterých především následně odvodím požadavky na systém. Ne zapomenu ani na důležitou schopnost ontologií, totiž jejich již několikrát zmi ňovaný integrační potenciál. V rámci navazujícího návrhu budu upírat pozornost především k použitím podle případových studií, ovšem pokusím se nezapomínat ani na ostatní možnosti zmíněné v teoretické části. Při zkoumání parametrů ontologií, které by vhodně naplnily požadavky zva žovaných aplikací budu mimo jiné rozlišovat to, jaká část doménových dat je za chycena ontologií. Podle toho připadají v úvahu dva typy:

samohodnotná Ontologie hodnotná sama o sobě, obsahuje vlastní doménová data. samohodnotná ontologie

reálný svět

meta ontologie Ontologie je v v pozici metainformačního systému nad daty reprezen tovanými převážně jinak.

53

Projektové studie Projektové studie

meta ontologie reálný svět externí datová základna

Je zřejmé, že hranice mezi nimi není příliš ostrá, ale rysy jednoho nebo druhého typu obvykle převažují. Zaměřím se na to, aby byly zvažované případy pokud možno dostatečně různoro dé, a to nejen z hlediska role ontologie v architektuře, ale i v jiných parametrech. Cílem je, aby byla výsledná knihovna maximálně ohebná a aby tak pokryla co nejširší paletu možných použití, ovšem s důrazem na různá třeba i nápaditá, ale spíše „konvenční“ využití. Trochu tedy opomenu například ontologie pro repre zentaci jazyka. Netvrdím, že výsledný systém pro něco takového použít nepůjde, ale přeci jenom asi by se našly specifické (a vhodnější) knihovny a nástroje.

54

Projektové studie Evidence a organizace dat

A Evidence a organizace dat A.1 O co jde Již několik let se potýkám s problémem, jak organizovat například

informace převážně textového charakteru Mám na mysli to, co je často shrnováno pod pojmem „dokumenty“ informace v elektronické i tištěné podobě, technické i jiné (obecně li bovolné). Především vše, k čemu se buď pravidelně vracím nebo alespoň soudím, že to v budoucnu bude třeba.

programy Typicky programy pro vývojáře (různé nástroje a pomůcky, systémy pro ukládání dat, různé knihovny, editory, frameworks, apod.), ale i obecně jakýkoliv jiný program, „který by se mohl v budoucnu hodit“. Možná vám to připadá zbytečné, ale jako vývojář potřebuji řádově stovky různých programů a nástrojů a samozřejmě stále vznikají nové verze a také úplně nové produkty. Leckdy se mi stane, že pátrám po určitém nástroji opakovaně. Přitom najít optimální nástroj nemusí být vůbec triviální – možností jsou desítky a kritérií také spousta..

jakákoliv jiná data Mám na mysli především různá multimédia obraz, zvuk, hudbu, video… S dostupností digitalizačních zařízení (skenerů, digitálních fo toaparátů, videokamer, ale třeba i syntetizátorů nebo různých au torských programů) potřeba organizovat multimédia rovněž poroste, a to ani nemluvím o soukromých sbírkách hudby, filmů a dalších cizích multimédií. tak, abych vše potřebné vždy (nebo alespoň většinou) našel. A jak je zřejmé z výše uvedeného, týká se to jak dat z cizích zdrojů, tak dat vytvořených mou činností. Kdo by měl dodat znalosti nutné pro nastolení potřebného pořádku a jeho další udržování? Z větší části asi jejich správce a uživatel – sám nejlépe ví, jaké typy dat chce třídit, podle jakých kritérií je bude pravděpodobně hledat apod. Má s tím 55


také pravděpodobně dlouholetou (a nejspíše občas i bolestnou) zkušenost. Na druhou stranu by bylo praktické všechno to úsilí vložené do systematizace obecně použitelných dat sdílet – sdílet slovníky kategorií, konkrétní zařazení dat apod. Na základě průzkumu svého okolí mohu konstatovat, že prakticky každý má podobný problém, byť mu možná nepřikládá přílišný význam. Každý je ve svém systému dat svým expertem a uživatelem, ovšem prakticky nikdy příliš úspěšným, protože technické prostředky pro sofistikované řešení jsou příliš složi té (a tedy nepraktické), nákladné nebo vůbec neexistují. Zmiňovaný systém by ale mohl být užitečný nejen pro jednotlivce, ale rovněž pro společnosti či instituce. V případě takového nasazení je pouze třeba zvážit doda tečné komplikace, které pramení z vyššího stupně sdílení a kooperace. Znamená to řešit otázky jako • efektivní tok dat • bezpečnost (security) • distribuovanost uvnitř sítě • mnoho otázek spíše psychologického charakteru

A.2 Běžné řešení bez ontologií Zvažoval jsem využití některých klasických systémů pro správu dokumentů, ale nenarazil jsem na žádný, který by byl současně snadno použitelný a zároveň dostatečně flexibilní, aby splnil základní požadavek: „uspořádej cokoliv!“ V současné době vše organizuji v poměrně propracované adresářové struktuře na pevném disku a v databázovém katalogu uchovávám rozličné meta informace. Ta kový systém má velkou výhodu, že je k dispozici ihned, bez jakéhokoliv speci álního nástroje. Nedostatky jsou ovšem značné: Není možné rozumně rozmístit data (informace/programy/cokoliv jiného – viz výše) na různá média (např. CD), aby se neztratil celkový přehled a aby byly po ruce náhledy, vazby a souvislosti. A zejména adresářová struktura je prostý strom a naprosto selže při pokusu třídit v ní data podle více kritérií. Leccos je možné řešit pomocí symlinků (na systé mech s Windows zvaných zástupci), ovšem výsledek stejně působí provizorním dojmem a funguje spíše jako karikatura na systém. 56


I profesionálním systémům pro správu dokumentů a dat chybí sdílený slovník ka tegorií a možnosti propojit různé instance. To zvyšuje náklady na zavedení systé mu a ještě dlouho poté znesnadňuje komunikaci mezi subjekty, natož nějakou užší integraci.

A.3 Přínos ontologií Zatím se nebudu věnovat konkrétním parametrům ontologie, která by se dala vyu žít při budování systému pro organizaci dat, spíše vyjdu z nějaké co nejobecnější definice ontologií a zamyslím se nad stejně obecně pojatými přínosy. Tak tedy, dejme tomu že ontologie je sdílená konceptualizace světa. Například jaký prospěch by přineslo spojení systému systému evidence dat s vhodnou ontologií? Předně, půjde o obecné zvýšení efektivity a kvality vyhledávání. Takový systém by umožnil vyhledat potřebná data libovolného typu, podle mnoha obecných i specifických kritérií, omezených pouze vyjadřovacími schopnostmi použité on tologie a ontologií samotnou.

najdu co hledám Bez použití kvalitního systému pro správu dat se snadno může stát, že se vůbec nepodaří najít relevantní data. Stát se to může jednotlivci, který organizuje svá osobní data, tím spíše to hrozí v organizaci kde spolupracuje lidí více a mnozí často nemají ponětí o práci některých svých kolegů. Důsledky toho, že se nepodaří najít to, co je třeba mohou být různé, ale obecně negativní. Často to povede k dodatečným nákladům spojeným s opětovnou tvorbou již vytvořeného (redundance, duplikace)...

najdu to nejrelevantnější Uživatel při prohledávání možná často skončí u prvního trochu použi telného výsledku. Pokud by byl systém založený na ontologiích (včetně souvislostí typu synonym, příkladů, paralel, různých dalších vztahů), zvýšila by se pravděpodobnost nalezení toho nejlepšího, co je ve spravované množině dat k dispozici. Pokud se spokojíme s prvním použitelným výsledkem, pravděpodobně to přinese různé negativní důsledky:

57


Vývojář zvolí méně vhodný nástroj, který znesnadní, prodraží nebo v extrémním případě úplně zboří vývoj. Právník nenajde speciální zákon, který se vztahuje přesně k řešenému problému. Konstruktér ve svém výkresu použije méně vhodnou (třeba dražší) norma lizovanou součást.

vnější konzistence pro správu i užívání Vše by spravoval jeden systém, maximálně flexibilní. Výhoda je zřej má – není nutno instalovat, spravovat více produktů, není třeba učit se a případně školit uživatele v jejich používání apod. Objevíli se nová kategorie dat, jednoduše ji do pružného systému včleníme… Jednotné rozhraní pro správu mnoha typů dat by tedy snížilo náklady na ob sluhu, také by přispělo k tomu, aby byl systém využíván s oblibou a často.. Jednotné rozhraní pro správu firemních dokumentů i soukromé sbírky hudby, pro knihy i fotografie, pro dokumenty vlastní i cizí.

konsolidace procesů Před zavedením zvažovaného systému každý uživatel má svůj způsob práce s dokumenty. Použití systému sjednotí nejen postupy jednoho uživatele pro dosahování různých cílů, ale také doposud nezávislé a leckdy nekompatibilní, nesourodé a třeba i nepříliš kompatibilní postu py jednotlivých uživatelů. Konsolidace procesů povede k úsporám.

univerzálnost znamená širokou uživatelskou základnu Kvalitní systém, který by splňoval popsané požadavky by mohl dosáh nout hromadného rozšíření v různých odvětvích. To by byla jistě výho da, ještě znásobená, kdyby pro různá odvětví vznikly příslušné slovníky (ano, ontologie) a nejlépe také jednotné postupy popisování a třídění dat. Spojímeli to ještě s možnostmi Internetu a jeho prudkým rozvojem, výhody jsou zřejmé – snadné sdílení dat, až propojování nezávislých systémů z kompatibilních, tedy nikoliv nutně totožných, domén.

uchování cenných expertíz Znalosti, které pomáhají popsat, třídit a najít potřebná data bývají mnohdy nashromážděny mnohaletou zkušeností. Zkušenost může ode 58


jít s pracovníkem, který je jejím nositelem. Kodifikace v rámci znalost ního systému by zkušenosti zachovala, zpřístupnila, umožnila opě tovně použít.

A.4 Problémy a rizika řešení s ontologiemi Většina rizik má původ v relativní vnitřní komplikovanosti systému a také v po měrně značných nárocích na obsluhu, zejména ve fázích zavádění. Jako typické problémy případného nasazení systému jsem vybral:

špatný způsob kategorizování V případě že by se nevěnovalo dostatek pozornosti výběru evi dovaných charakteristik, sledované vlastnosti by byly irelevantní k po třebám, výsledkem by byl sofistikovaný a flexibilní systém, ve kterém by ovšem nikdo nic nenalezl. Systém musí poskytnout dostatečná vodítka (výchozí slovníky, různé příklady, klást otázky – proč? jak?, možná nějaké průvodce...), aby se toto riziko co nejvíce snížilo.

rizika přechodu – nechuť a obavy Zejména ve větší organizaci by téměř jistě nastaly potíže při přechodu. Pracovníci téměř jistě svá heterogenní data nějak spravují – ať již cent rálně, distribuovaně po odděleních, nebo každý sám, více či méně sys témově. Zažitá a do jisté míry fungující řešení by musela být postupně převáděna do systému nového. Ti uživatelé, kteří mají averzi k systé mu, ke všemu technickému, případně k novinkám a změnám jako ta kovým, se budou bránit. Systém by měl umožnit postupné zavádění, aby nedůvěřiví dostali po třebný čas.

moc práce Ať bude systém sebeinteligentnější, nezbaví nás to nutnosti přeci jenom nějaká meta data pořídit ručně. Zřejmě vzniknou otázky, jako třeba: Kdo to udělá s existujícími a již nějak zorganizovanými daty? Kdo to bude dělat do budoucna? Objeví se jistě i otázky, zda taková práce bude dostatečně vyvážena přínosy. 59


Jako klíčová se v této souvislosti jeví jednoduchost obsluhy systému.

A.5 Kostra architektury ontologického řešení 5.1 Struktura Z jakých funkčních celků by se systém mohl skládat? V diagramu je znázorněn hrubý návrh architektury včetně vazeb mezi moduly, o jejich významu se zmíním dále. Zákaznické rozhraní jádro Správa kategorií Správa produktů

Katalogizační ontologie Databáze produktů

Rozhraní do IS cizích podniků Rozhraní do IS podniku

Modul událostí

pořizovací modul Umožní lidskému operátorovi („pořizovači“) doplnit k datům informa ce, které i chytrý počítačový systém těžko zjistí.

správa ontologie doménových kategorií Přestože každá položka dat by měla být vhodně „obalena“ svou meta informací nezávisle na jiných, pro účely prohledávání bude třeba na množinu těchto informací nahlížet jako na celek.

60


Pro úspěch nasazení jde o klíčovou část systému bez důsledně promyšleného a alespoň místně jednotného přístupu k tvorbě a správě kategorií by celý systém ztroskotal, jak bylo naznačeno výše, v rozbo ru rizik.

správa rolí Důležitou vlastností by bylo omezení/přiznání úrovně přístupu k on tologii podle role uživatele. Úložiště kategorií ontologie by bylo prav děpodobně čitelné pro pořizovače, měnit by ho mohl pouze kompetent ní správce, který by znal vazby v systému, důsledky případných změn a měl by celkový přehled o doméně. Situace si jistě bude vyžadovat jejich úpravy, zejména rozrůstání, a tak by na požádání pořizovačů da tabázi upravoval (případně by autorizoval úpravy jejich). U jednou živatelského nasazení role pořizovače a správce splývají v jedinou.

modul fyzické organizace Bude zajišťovat vyšším modulům přístup k datům – uloženým v sou borovému systému, objektové databázi, XML databázi, či kdekoliv jin de.. Na zvážení je, zda by modul pouze zajišťoval spolupráci s fy zickým úložištěm, případně zda by data v rámci tohoto úložiště nějak rozumně organizoval.

dotazovací modul Brána, kterou uživatelé prahnoucí po datech použijí pro formulování dotazů. Vnitřně by se skládala z minimálně 2 co nejvíce oddělených částí – vrstvy logiky a prezentační vrstvy. Výchozí implementací pre zentační vrstvy bude asi nejspíše vhodné grafické uživatelské rozhraní. Kromě výše uvedených připadají v úvahu další, spíše rozšiřující moduly – modul bezpečnosti (security), modul zálohovací, indexační, vyrovnávací paměť, podpora práce v síti,… Při nasazení ve víceuživatelském prostředí by byly mnohé z těchto modulů rovněž důležité, ale pro jednoduchost je zatím nebudeme dále uvažovat.

5.2 Charakter Podle [ZTECHMP02] je vhodné volit znalostní čí expertní systém jako základ ar chitektury pokud 61


• problém není formálně vyjádřitelný • řešení není založeno na deterministických reproduktivních postupech • princip řešení nemá teoreticky dobré a ucelené podklady, užité znalosti nejsou formálně dobře vyjádřitelné • užívané údaje jsou vágní, nepřesné, nespolehlivé, vzhledem ke své nedo stupnosti neúplné Které moduly systému splňují uvedená kritéria? Začněme pořizovacím modulem – ten by měl být hodně flexibilní, měl by disponovat i nějakými heuristickými schopnostmi, aby uživatele navedl k zadání správných kategorií metadat. To vše ale lze řešit konvenčními prostředky, tedy v procedurálním objektově orien tovaném jazyce. Centrální správa doménových kategorií i centrální databáze meta informací mají charakter databáze – znalostní metody by byly zbytečné. Modul fyzické organizace je pouze vrstvou rozhraní pro komunikaci s úložištěm – rovněž stačí konvenční postupy a stejně tak i uživatelského rozhraní dotazovacího modulu. Zbývá logika dotazovacího modulu, což je ovšem něco docela jiného.

5.2.1 Charakter logiky dotazovacího modulu Shrňme, jaké by měl mít schopnosti. Z nich vyplynou i podrobnější požadavky na zachycená a zpracovávaná data:

maximum informací čerpat samostatně přímo z dat Lidé by při takovém čerpání dat mohli asistovat – data validovat, zpřesňovat, doplňovat apod., ale systém by je měl ušetřit maxima ru tinní práce, kdy se pouze něco odněkud někam přepisuje. Taková práce nejen že je nepříjemná, nudná, ale také přináší redundanci, a tedy riziko vzniku inkonzistence v datech. Mohl by uvažovat například takto: má příponu MP3 => je to hudba má příponu MP3 => možná obsahuje ID3 tag možná obsahuje ID3 tag => načti meta informace

Pro úlohu by možná mohl sloužit samostatný modul.

62


zpracovat nejasné, neúplné dotazy Klíčovým parametrem systému, který by jej měl odlišit od běžných systémů pro správu obsahu by měla být výjimečná vyhledávací schopnost. Uživatele nechceme nutit uvažovat podle počítače, ale naopak.

odpovídat na základě neúplných meta informací Systém by měl být rozumně použitelný i v době, kdy bude probíhat vý stavba katalogů – pokud uživatel (investor) neuvidí první známky pří nosu co nejdříve, těžko bude věnovat svůj čas, energii či finance další mu nasazování systému. Kromě toho – žádná ontologie není dokonalá, vždy jde o určitou aproximaci či odraz světa. Systém by ale měl vytěžit maximum z toho, co k dispozici má.

snadno „vstřebávat“ doménové zvyklosti pro pokládání dotazů Mám na mysli doménově specifickou terminologii, strukturu dat, vzá jemné souvislosti dat i metadat. Systém by měl být schopný zachytit doménové znalosti nezbytné pro „porozumění“ dokumentům, jejich obsahu a významu, především s cílem porozumět případným vyhle dávacím dotazům. Určitou drobnou znalostí je dejme tomu vztah: „PDF dokument=>čitelný Acrobat Readerem“

Systém by měl takovou znalost obsáhnout a také využít všude, kde to bude vhodné. Z toho vyplývá, že souběžně s naplňováním stromu společných kategorií meta informací by měla být doplňována rovněž odpovídající pravidla v logice dotazovacího modulu, o kterých bude souzeno, že z hlediska účelu nasazení mohou být praktická.

„chápat“ význam kategorií Třeba co je to program, zakázka… prvním stupněm by mohla být schopnost rozeznat synonyma, antonyma a jiné lexikální vztahy.

rozpoznávat přirozený jazyk V ideálním případě by vyhledal vhodné informace na základě dotazu typu 63


„Chci navrhnout www stránku, ale neumím moc syntax HTML jazyků“ což ale rozhodně snadné není, alespoň při současném stavu poznání v příslušných oborech. Ovšem budeli systém dobře navržen a zejména budouli data vhodně a dostatečně popsána metadaty, snad bude časem, při pokroku v rozpoznávání přirozeného jazyka, možné podobné funk ce začlenit do dotazovacího modulu.

propojit obecné znalosti se znalostmi v doméně Systém by měl být vybaven sadou obecných pojmů a vztahů tak, jak jsou například definovány v různých toplevel ontologiích, což ušetří práci jednotlivým uživatelům a také usnadní případné propojení vytvo řených databází. Na druhou stranu, primárně by měl být implementován jako prázdný, tj. bez doménově specifických kategorií dat a pravidel v dotazovacím modulu. Místo toho by vznikaly samostatné ověřené, doménově spe cifické slovníky pro specifické typy uživatelů. Kromě toho by případný uživatel (a ve svém oboru doménový expert) pravděpodobně budoval další, již silně specifické koncepty, které by nenašel v jiných slovnících. Klíčové je, aby si se všemi těmito zdroji sytém poradil, dokázal je za řadit do vzájemných kontextů a účinně je využívat při hledání.

5.3 Cíle 5.3.1 Složitost modulů Možná v tuto chvíli namítnete, že celý systém bude příliš složitý, aby mělo smysl se jím vůbec zabývat. Kus pravdy na tom je, ovšem skutečná složitost je koncent rována pouze v logice dotazovacího modulu. Dotazovací modul by byl ale pouze jednou (byť docela technicky asi nejzajímavější) částí celku a i bez něj by byl sys tém přínosný. Minimálně by umožnil již nyní data organizovat s ohledem na bu doucnost. A to by mělo být hlavním cílem jakékoliv evidence, organizace a syste matizace.

64


Úplně ideální by bylo rozčlenit dotazovací modul na část obecně použitelnou i v jiných programech a část specifickou. Tvorba univerzální knihovny pro tvorbu, manipulaci a prohledávání on tologií bude předmětem další části práce.

Zvážímeli náklady a přínosy pokročilých technologií, možnosti (technické i fi nanční) a také architekturu systému (modulární), asi bude nejrozumnější nejdříve implementovat pouze prototyp bez pokročilých schopností možná bude zvládat jen dotazy ve stylu SQL nebo ani to ne... a při tom mít uvedená specifika na paměti. Především, prototypem tvořená ontologie musí být dostatečně bohatá, aby umožnila povýšení dotazovacího modulu bez výraznějších zásahů do dat ze strany uživatele... Jak již bylo naznačeno ostatní moduly jsou principiálně triviální (pořizovací, centrální správa doménových kategorií i centrální databáze meta informací) nebo je možné dobře využít existující systémy a tak si ušetřit podstatnou část práce (modul fyzické organizace – s podporou vhodné vrstvy pro perzistenci, např. [OJB]).

5.3.2 Kritéria posouzení úspěchu Stanovme si nějaká kritéria pro posouzení výsledků. Projekt bude v pokusné implementaci úspěšný, pokud s jeho pomocí bude možné 1) připojovat takové meta informace k datům, která umožní zachytit vlastnosti, relevantní místa v kontextu kategorií domény a základní souvis losti s jinými daty z domény 2) přizpůsobovat centrální databázi kategorií 3) data automaticky, logicky (dle daných pravidel – nejspíše dle přiřazených kategorií) přeuspořádat v rámci fyzického úložiště, zpočátku zejména sou borového systému pevného disku. 4) integrovat více fyzických úložišť, v prvních fázích například „vědět“ o da tech, která právě nejsou systému fyzicky dostupná např. protože byla přenesena na CD. 5) pokládat jednoduché dotazy (dotazovací modul prozatím bez navr hovaných heuristik)

65


6) vytvořit nebo z vhodné toplevel ontologie načerpat univerzální kategorie a pravidla

5.4 Stav Již jsem vytvořil primitivní prototyp. Sice by se dal použít pro organizaci ome zeného množství dat, ale smyslem bylo spíše si ověřit některé uvedené nápady v praxi. Následovat by měl prototyp dokonalejší, který by již splnil uvedené cíle. Prototyp má následující charakteristiky:

technologie Zvolil jsem jazyk Java, především pro jeho platformní nezávislost a si lnou podporu pokročilých technologií (XML, databáze,...)

ontologický model Používá primitivní interní ontologii, kterou může uživatel z grafického prostředí programu budovat a upravovat. Použitý ontologický meta model umožňuje definovat kategorie pojmů a základní vztahy. Má ale také řadu omezení, například nelze definovat vztahy mezi kategoriemi (pouze mezi daty), vztahy nemohou mít vlastní hierarchii apod. Také chybí podpora pro pravidla.

podporované typy dat Pracuje výhradně s daty na pevném disku – se soubory a adresáři. Na druhou stranu disponuje určitou inteligencí v rozpoznávání typů dat – podle toho nabízí vhodné kategorie k zařazení, také přizpůsobuje vzhled uživatelského rozhraní (generuje náhledy dokumentů, umožňu je přehrávat audiovizuální data apod.).

úložiště pro databázi kategorií a metadat Kategorie ukládá do centrálního XML souboru na disku. Metadata ukládá do XML souborů poblíž popisovaných dat. Protože si systém zatím nečiní nároky na kompletní správu zařazených dat (pořád to jsou soubory na disku), bylo zvoleno právě toto řešení, aby příliš nehrozilo, že při běžné manipulaci (přesouvání, přejmenovávání..) budou metada ta ztracena či oddělena od jimi popisovaných entit.

66


Formát pro zachycení metadat je takovýto – použit je vlastní na XML založený jazyk: <elTree name="program"> <elDesc name="verze"/> <elDesc name="s/n"/> <elBranch name="co" necessity="required"> <elTwig name="úpravy"> <elTwig name="hromadné"/> <elBranch name="s čím"> <elTwig name="dle formátu"> <elTwig name="text"> <elTwig name="web"/>

dotazovací modul a uživatelské rozhraní Dotazovací modul pro jistotu chybí úplně. Přikládám dvě obrazovky uživatelského rozhraní, které umožňuje popisovat data, budovat on tologii a procházet tím, co již bylo zpracováno. Komponenty uživatel ského rozhraní se dynamicky přizpůsobují typu dat (jak již bylo zmíně no) a také podle příslušnosti k hlavním kategoriím.

67


68


A.6 Klíčové parametry ontologického meta modelu V první řadě, jde o typickou meta ontologii, která pouze popisuje externí data. Informace zachycené v systému budou trojího typu:

příslušnost ke kategorii v terminologii domény, ve které by byl systém nasazen. Například ke grafickému editoru pod Linux by mohly být: „program/pracuje s/grafika/bitmapy“ „program/poběží na/UNIX/Linux/Debian“ „program/vrstva/frontend aplikace“

Údaje k firemnímu dokumenty by mohly obsahovat třeba: „dokumenty/zakázky/střechy“

vztah k jiné položce v databázi „rozšiřuje (odkaz)“ „popisuje (odkaz)“ „následuje po (odkaz)“

popisné údaje Vše ostatní, co nemá charakter čí vazbu ani na centrální členění ka tegorií, ani na jinou položku v databázi. To bude vždy trochu relativní, protože bude záviset na šíři a hloubce ontologie. „Pěkně se v něm ručně retušuje, nemá ale žádné zabudované filtry.“

A.7 Významné koncepty a vztahy 7.1 Základní koncepty Několik konceptů by mělo vyjádřit základní charakter popisovaných dat, tedy zda jde o textový dokument nebo třeba o videozáznam. Vzhledem k poměrně univerzálním ambicím bude třeba zachytit materiální povahu popisovaných entit – jsou abstraktní nebo konkrétní? Existují v elektronické podobě nebo jako hmotné předměty reálného světa?

69


Určitou kategorii konceptů budou tvořit různé subjekty (fyzické osoby nebo třeba společnosti) v různých rolích (například autor). Dále nesmíme zapomínat na obecné vztahy, zejména isa, součást celku nebo alternativa, ale jistě mnohé další.

7.2 Příklad doménově specifické aplikace Prototyp jsem testoval především na dokumentech převážně textového charakte ru, multimediálních datech a také na programech. Konkrétně například u progra mů z hlediska jejich zařazení do popisovaného systému v roli dat jsem zatím skončil u sady takovýchto metadat:

kategorie •

co (= co program dělá)

•

s čím (= s jakým typem dat)

•

pro koho (je vhodný)

•

na čem (poběží – požadovaná platforma)

•

vrstva (frontend aplikace nebo třeba na pozadí běžící služba)

•

copyright (výrobce)

•

licence (ne znění, ale její charakter)

•

jméno

•

verze

•

slovní popis

popisy

vztahy k jiným datům •

závisí na (a obráceně „je nezbytný pro“)

•

následuje po (a obráceně „předchází“)

•

rozšiřuje (možnosti jiného programu a obráceně)

•

je popsáno (dokumentem)

Kategorie mohou být obecně větveny jako stromy, nejvyšší stupeň udá kategorii a další stupně jednotlivé možnosti na zařazení v rámci této kategorie. Kategorie pro evidenci programů by mohly vypadat třeba takto: 70

Projektové studie Evidence a organizace dat na čem DOS Windows 16-bit 9x 95 98 ME NT řada NT 2000 XP UNIX Linux Debian …

Některé z nich (s čím, pro koho, na čem, copyright apod.) by koncepčně odpoví daly spíše vztahům, ale takové řešení by vyžadovalo již v první fázi reálného na sazení skutečně znalostně implementovaný dotazovací modul. Proto jsou to zatím kategorie, pro další verzi prototypu ale počítám s jejich transformací ve vhodné vztahy. Jiným velmi dobrým příkladem doménově specifické aplikace by bylo využití systému jako bibliografického nástroje. V tomto oboru není nouze o teorii – exis tuje mnoho publikací, které odpovídají na otázky co je třeba evidovat, jaké výstu py generovat, jaké dotazy připadají v úvahu apod.

7.3 Důsledky ontologického modelu pro dotazování Jednoduchý dotazovací modul by již se současným provizorním ontologickým modelem mohl zvládat

dotazy na kategorie Například: „co:úpravy“

71

Projektové studie Evidence a organizace dat „s čím:dle formátu:text:neformátovaný“ „na čem:UNIX:Linux“

fulltext Sice poměrně primitivní, ale pořád přesto relativně účinný způsob pro hledávání. Minimálně v prvních verzích bude hrát klíčovou roli, časem by měl být postupně doplněn inteligentními variantami. V úvahu připa dá fulltext •

v rámci popisných položek

•

kompletními metadaty a nakonec

•

daty

Poslední jmenovaný by mohl časem sloužit i při analýze obsahu doku mentu v době zařazování do databáze a na jeho základě by mohly být pořizovači nabídnuty vhodné kategorie. Fulltext by měl být také do plněn o schopnost interpretovat regulérní výrazy, wildcards, apod.

navigace dle závislostí Na stránce či obrazovce s vyhledanou informací o položce dat budou též odkazy na jiná související data. Modul umožní tyto odkazy sle dovat.

72

Projektové studie Elektronická komerce

B Elektronická komerce Elektronický obchod má budoucnost jistou, otázkou je spíše, jak se na vzdouvají cí se vlně co nejlépe svézt – konkurence je tvrdá a počítají se milimetry. O stavu elektronického obchodování a jeho problémech jsme již mluvili. Proto si jen tro chu připomeneme o co jde a myšlenky rozvedeme více směrem k praktické aplikaci.

B.1 O co jde B2C Zákazník se bude vracet na server, který ho přesvědčí svou přehlednos tí, spolehlivostí, nízkými cenami (které pramení z úspor nákladů a velkých obratů), inteligencí, aktuálností, dodatečnými službami. Jak je zřejmé z úspěchu těch, co působí v první lize (amazon.com), klíčem je využít maximum toho, co technologie nabízí (silné stránky) k překo nání nevýhod elektronického obchodu (slabé stránky), tedy toho, že chybí osobní kontakt se zbožím, prodavači apod. Technologie umožňu je například sbírat ohromné množství informací o zákaznících – co na kupují, ale i co si pouze „osahají“ v regálech, kdy přicházejí, co je baví, jak rychle se po obchodě pohybují..

C2C Uživatel bude nakupovat tam, kde najde, co hledá a prodávat tam, kde mu bude umožněno zboží zařadit a popsat tak, aby ho našel ten, kdo ho hledá. Systém také musí umožnit sledovat důvěryhodnost a spolehlivost uživatelů.

B2B Efektivita procesů, dokonalá logistika, minimum papíru, rychlost reak ce, spolehlivost, informace.. Elektronické obchodování a vůbec elek tronizace procesů v oblasti vztahů mezi komerčními subjekty dispo nuje ještě větším potenciálem růstu než u B2C.

73


B.2 Běžné řešení bez ontologií Produkty elektronického obchodu je zvykem organizovat do tabulek relační data báze. Elektronické obchody jako samostatné znovupoužitelné produkty obvykle nabízejí jistou míru flexibility, ale ta je samozřejmě omezena datovým modelem – nejčastěji relačním, již méně běžně objektovým. Organizace produktů takového obchodu obvykle nerespektuje doménová specifika a podporuje pouze jedno duchý systém kategorií. Vazby mezi kategoriemi (natož mezi jednotlivými pro dukty), verze, kombinace – alespoň něco z toho obvykle chybí. Elektronické obchody šité na míru samozřejmě mohou toto všechno zvládat, ale při vývoji není kvalita jediným kritériem. Svou roli hrají další hlediska – cena, ná vratnost, účelnost. To je samozřejmě v pořádku, ale výsledkem jsou aplikace silně doménově specifické, které není snadné použít opakovaně. Procesy integrace a konsolidace jsou v B2B určitě podstatně dál než u B2C, ale i tak to bude ještě dlouhá cesta. Sice obvykle funguje docela dobře výměna ob chodních dokumentů (faktury, dodací listy, reklamační protokoly..), horší je to ale s integrací produktových řad. Sám jsem například v situaci, kdy bych rád nakupoval zboží od několika velkých dodavatelů, jejichž nabídka se zčásti překrývá a zčásti doplňuje. Rád bych jejich nabídky integroval do vlastního elektronického obchodu, což ale není vůbec snadné a je téměř nemožné provést to automatizovaně. Každý totiž ve svých data bázích pojmenovává zboží jinak, přiděluje mu jiná identifikační čísla.. navíc přestože se stává zvykem nabízet elektronickou výmě nu dokumentů, ceníky ve strojově snadno interpretovatelné podobě zvykem stále ještě nejsou.

B.3 Přínos ontologií integrace procesů Právě ontologie jako sdílené reprezentace světa by mohly hrát roli lepidla produktových portfólií tak, jako například EDI již dnes mnohde do určité míry sjednocuje a zefektivňuje vlastní obchodní procesy. S integrací více dodavatelů B2B pod střechou jednoho B2C obchodu by se počítalo od začátku. Produktové informace postavené na ontologiích

74


by bylo snadné integrovat, transformovat, modifikovat, vše značně au tomatizovaně.

informační jistota pro zákazníka Ontologie jako informačně i sémanticky bohaté, přesné, výstižné... by přinesly nové kvality i do obchodování B2C. Souvislosti, podrobné ka tegorie podle mnoha hledisek, jednotně zachycené parametry a vlastnosti konkrétních produktů, pro to vše by byly ontologie maxi málně vhodné. Uživatel by mohl prohledávat s mnohem vyšší relevan cí, díky sémantice automatizovaně porovnávat, a to nejen v rámci jednoho eshopu, ale i mezi nimi. Snadno by nacházel alternativy, vhodné doplňky a kombinace a další vztahy a souvislosti.

znovupoužitelnost, e-shop reflektuje skutečné rozdíly A co je klíčové pro úsporu nákladů – detaily o produktech by stačilo udržovat pouze jednou – postaral by se o to například sám výrobce a používat opakovaně, bez dodatečných nákladů. Obchody by se mohly více zaměřit na soutěž v tom, v čem jsou opravdu odlišné, tedy nikoliv v parametrech jimi nabízeného zboží (které je stejné, vždyť všechno vyrábí Čína, že?), ale spíše v dodacích podmínkách doprovodných službách, reklamaci a samozřejmě v cenách.

sdílení Podobně by bylo možné sdílet třeba i uživatelské připomínky k danému zboží – hodnocení, recenze, nápady, podněty.. Každý obchod by je umožnil doplňovat o připomínky vztahující se právě k jeho obchodu (kvalita služeb..), které by již dále nesdílel.

nový stupeň flexibility Pokud jsou produktová data zachycena ve struktuře relační databáze nebo v podobě objektů, není snadné strukturu měnit a přizpůsobovat. Objektový model oproti relačnímu sice usnadňuje vývoj, ale stále se nedá mluvit o flexibilitě za běhu – pokud zjistíte, že třída, která repre zentuje nějakou kategorii zboží by měla být doplněna o další atributy, neobejdete se bez zásahu do programového kódu (a nejspíše rekompi

75


laci). Takové zásahy by měly být doprovázeny testováním, navíc bude možná třeba zasáhnout do starých dat. Ontologický datový model by přinesl novou dimenzi flexibility umožnil by za běhu podstatně měnit obsah obchodu. V extrémně rych le se rozvíjejícím světě elektronického obchodu je to nezanedbatelný parametr.

B.4 Problémy a rizika řešení s ontologiemi Jistě hrozí i technologická rizika. Myslím ale, že silně převažují ta, jež vycházejí ze sociálních aspektů, obchodních politik a vztahů, nepružnosti organizačních struktur velkých společností a dalších záležitostí typicky lidských. Například:

apatie ze strany dodavatelů Ty největší přínosy by z využití ontologií plynuly pokud by se co nej více spolupracujících subjektů dohodlo na jejich používání. Jak mohu potvrdit z vlastní zkušenosti, jednat o čemkoliv (tím spíše o něčem tak závažném) s molochy typu Intel, HP nebo třeba Sun není snadné..

obavy obchodníků Zvýšení transparentnosti někteří obchodníci ponesou nelibě – dost možná se jim nebude líbit, že uživatel na dvě kliknutí porovná jejich nabídku s přesně odpovídající nabídkou konkurence. Internet ovšem k otevřenosti směřuje a je čím dál zřejmější, že tradiční metody utajování, těžící z asymetrické informace kupujícího a pro dávajícího zde příliš nefungují. Jakmile se navrhovaný systém sku tečně rozjede, obchodníkům, kteří zůstanou mimo nezbude než se při dat, anebo živořit někde na elektronické periférii.

nechuť ze strany uživatelů Myslím že toto riziko je minimální. Výsledek by z uživatelského hle diska měl být velmi přehledný a jednoduchý – na webech zapojených do projektu se snadno zorientuje (respektují jednotné konvence or ganizace produktů, jednotné názvy, kódy) a navíc dostane do rukou mocné zbraně umělé inteligence pro hledání a porovnávání, které bo hatě vynahradí jakékoliv nepohodlí. 76


rizika slabé vůle k dohodě Velmi přínosné by bylo sdílení doménově specifických ontologií. Pokud se ale klíčové subjekty z nějakého důvodu nedohodnou na společných postupech, nevytvoří univerzální slovníky, věc sice nebude úplně ztracena, ale promrhá se část integračního potenciálu – neshody bude třeba překlenout technologiemi mapování, propojování a trans formace ontologií.

B.5 Kostra architektury ontologického řešení 5.1 Struktura

zákaznické uživatelské rozhraní Ta část aplikace, se kterou bude uživatel přímo komunikovat. Zákla dem budou sady transformačních mechanismů pro spojení •

informací čerpaných z jádra systému a

•

šablon s vizuálním stylem

dále •

sada formulářů a jiných prvků pro zadávání dotazů

•

různí průvodci

•

a sem tam něco dalšího

rozhraní pro správu V diagramu jsou naznačena rozdílná rozhraní pro správu kategorií a produktů. V reálném systému by bylo podobných rozhraní pravdě podobně více, podle různých správcovských rolí. V reálném nasazení samozřejmě více rolí může zastat jeden člověk, jindy ale bude prak tické například ontologii vytvářet ve větším kolektivu zástupců růz ných zúčastněných stran, zatímco produkty si bude spravovat každý sám.

ontologie kategorií Nejzajímavější část systému, klíč k integraci rozdílných systémů a zvýšení informační hodnoty obchodu pro zákazníka. Bylo by zde sou 77


středěno vše obecné (obecné ontologické koncepty a vztahy, nejspíše převzaté z toplevel ontologie), ale i koncepty doménově specifické. V reálném nasazení by byla tato ontologie z větší části tvořena verifi kovanými slovníky převzatými od druhých, doplněná vybranými kon cepty, které prozatím nikdo jiný nepotřeboval, ale pro činnost konkrét ního obchodu jsou důležité. Z těch by se po ověřování a validaci moh ly časem stát další sdílené slovníky. Bude třeba vypracovat přesná pravidla tvorby, verifikace a sdílení slovníků, které by takto vznikaly.

databáze informací o produktech Sem patří vše, co není dostatečně univerzální, aby se hodilo alespoň obchodům působícím ve stejném oboru s jiným sortimentem. I tak je zde prostor pro znovupoužití – produktové katalogy navázané na ka tegorie z ontologie by sloužily případným odběratelům jako zdroj pro injektáž obsahu do jejich vlastních obchodů a informačních systémů.

modul událostí (transakční modul) Klíčový prvek pro zajištění rozšiřitelnosti, taková komunikační brána se dvěma základními úkoly: •

odesílat informace o událostech vybraným naslouchačům a naopak

•

přijímat informace o událostech ve vnějším světě, tedy zejména v jiných systémech.

Typickou událostí ve vnitřním světě by bylo třeba zařazení nového produktu nebo kategorie do ontologie, ale také třeba uživatelská žádost o načtení informací o vybraném produktu. Na další zvážení bude, zda by ostatní moduly rozhraní, především roz hraní uživatelská, neměla být rovněž alespoň zčásti podřízena modulu událostí. Tato otázka se řeší v závěru práce, v popisu architektury obecného ontologického systému postaveného na navrhované knihovně pro práci s ontologií.

78


rozhraní do IS podniku Modularitu považuji za klíčový parametr architektury, který umožní vybudovat živou, flexibilní a snadno spravovatelnou aplikaci namísto monolitického molocha. Proto nečekám, že by systém řešil vše, co ob vykle řeší podnikové informační systémy, byť zde můžeme sledovat mnohé paralely. Spíše, s podporou transakčního modulu mechanismem zasílání zpráv o událostech, budou moci vznikat rozhraní pro rozšíření funkčnosti. Mám na mysli propojení s nástroji pro řízení vztahů se zákazníky (CRM), pro evidenci zakázek, plateb, s moduly účetnictví a skla dové evidence a dalšími. Několik z mého pohledu nápaditějších možných rozšíření zmíním dále:

rozšiřující modul objednávek Je sice integritní součástí každého elektronického obchodu, tudíž by měl možná být modulem základním. Zabývám se především aplikací ontologií, proto vzniká otázka, jak by vypadalo ontologické pojetí pro cesu objednávání a nákupu. Některé ontologie se specializují vyloženě na reprezentaci podobných procesů, např. [EONUKMZ98]. V našem konkrétním případě by například při objednávání vznikla instance konceptu objednávka, s vazbami na instance ob jednávaných produktů, doplněných o různé požadované parametry (množství, různé doplňky apod.). Příslušné dynamické vlastnosti in stancí zboží (vlastně něco jako metody) spočítají celkovou cenu... Na druhou stranu je na zvážení, zda by ontologické pojetí nepři neslo spíše komplikace.

rozšiřující modul analýzy chování uživatele Znát chování uživatelů bylo dříve konkurenční výhodou, dnes je to již téměř nezbytnost. Již zmíněný mechanismus předávání událostí by příslušnému statistickému modulu naprosto postačoval. Co by se mělo sledovat? Nejen realizované nákupy a celé zakázky, ale i pohyb uživa tele po webu, a také nerealizované poptávky, nedokončené ob jednávky.. 79


rozšiřující modul kalkulace nákladů Ontologie je schopna evidovat vztahy mezi součástmi a celkem, různé podmíněnosti a další vztahy. To ji přímo předurčuje k dalšímu využití – jako základu kalkulačního modulu. K produktům již tak evidovaným v ontologii bude stačit připojit infor mace o komponentách a dalších vstupech a vhodná dynamická vlastnost (funkce zachycující mechanismus výpočtu) z nich odvodí ná klady. V ontologii by to mohlo být realizováno tak, že kategorie „nositel hodnoty“ svým potomkům předá dynamickou vlastnost cena. Ta má výchozí hodnotu nula, ale může (a měla by) být překryta konkrétní hodnotou nebo výpočetním mechanismem u konkrétních potomků. Ceny by mohly být počítány v konkrétní měně, případně v určitých systémech bodů, ze kterých by se vhodnými převodními koeficienty výsledné ceny odvodily. Dejme tomu, že vyrábíme nábytek. V ontologii je zaneseno, že židle je nositel hodnoty (něco co se dá prodat), že se skládá ze čtyř noh a jednoho sedátka, dále ceny každé komponenty a dynamická vlastnost pro stanovení ceny židle. Sedák cena: 50, Nositel ceny cena: ?

Židle cena:sedák + 4*židle Noha cena: 30,

Takže například nás sedák stojí 50 korun, nohy třeba 30 a hodnota celé židle je funkcí komponent a dalších, zde pro jednoduchost vy nechaných, vztahů. 80


Je zřejmé, že náklady jsou funkcí různých typů vstupů: •

kdo?

..cena pracovní síly

•

kde?

..cena nemovitostí, půdy

•

co?

..spotřebovaný materiál

•

čím/na čem prostředků

..cena výrobního zařízení a dalších tech.

Kombinacemi různých odpovědí na uvedené otázky (například majetkovými vztahy k výrobním prostředkům, místem výkonu prá ce..) lze definovat takové pojmy jako prodej, hosting, outsourcing. Kalkulační modul by mohl díky sémantickému porozumění složkám cen počítat i ceny variant dodávky v tomto smyslu.

rozšiřující modul stanovení cen Náklady spočítané modulem kalkulace nákladů mohou případně slou žit i jako základ mechanismu automatizovaného stanovování prodejních cen různě kombinovaných a parametrizovaných produktů. Zapomenout nesmíme na různé slevy (množstevní, slevy vybraným partnerům), provize a další obchodní a marketingové nástroje.

5.2 Charakter V této fázi nemá cenu definitivně volit konkrétní technologie, ale mohu se podělit alespoň o subjektivní dojem. Největší šance dávám technologiím okolo jazyka Java – jazyk je to mul tiplatformní, výkonný a disponuje vším potřebným pro tvorbu ro bustních serverových aplikací. Více viz poslední část práce.

5.2.1 Uživatelské rozhraní U modulů prezentačních je třeba postupovat opatrně. Nejžádanější podobou zá kaznického rozhraní bude zřejmě klasické rozhraní webové. Nelze ale opomenout prohlížeče různě atypické – například mobilní telefony a PDA. Dále musíme počítat s lidmi hendikepovanými, například slabozrakými (rozhraní s velkým písmem), barvoslepými (volby kombinací barev), úplně slepými (hla sové rozhraní). Řešením pro budoucnost by bylo postavit uživatelské rozhraní na

81


vhodném nástroji pro generování různých rozhraní z modelu, například Xermes [XERM]. U prototypu možná zvolíme snadnější cestu v podobě jednoduchého webového rozhraní. Bude to řešení provizorní, na druhou stranu, budemeli důsledně oddě lovat UI od logiky (jádra, transakčního modulu..), cesta pro výměnu rozhraní za kvalitnější podle potřeby a bez zásahů do dat zůstane otevřena. Univerzálnost ad ministračního rozhraní není tak klíčová (prozatím postačí jednoduché webové nebo dokonce klasické okenní rozhraní), ale časem by se s ní rovněž mohlo počí tat..

5.2.2 Ostatní moduly Pro datové úložiště bude nejvhodnější použít abstraktní perzistenční vrstvu typu [OJB]. Transakční modul je vlastně trochu složitější implementací návrhového vzoru naslouchač (listener viz [GHJV95] a [BMRSS96]) v čisté Javě. Vlastní rozhraní do dalších programů zkoumat nebudeme – již nepatří přímo do navr hovaného systému. V případě vzdálených aplikací bude vhodné využít některý ze standardů pro meziprogramovou komunikaci, například již zmíněný SOAP, u aplikací postavených na Javě možná RMI, u ostatních CORBA. Jak je již jistě zřejmé, základem jádra programu bude sada on tologií a podpůrných knihoven pro práci s nimi. Implementace prototypu těchto nástrojů je námětem dalších, již ryze praktických, částí práce

5.3 Cíle Pokud studie proveditelnosti neprokáže, že nemá smysl systém vyvíjet, tak dlouhodobým cílem je samozřejmě co nejšířeji akceptovaný nástroj produkční kvality. Pro nejbližší budoucnost budeme ale skromnější a spokojíme se s proto typem následujících parametrů: 1. funkční a v zásadě použitelné jádro postavené na vlastních obecnějších ná strojích pro práci s ontologiemi, ovšem bez pokročilejších schopností vy hledávání a inteligence 2. základní zákaznické webové rozhraní 3. perzistenční vrstva schopná integrovat více datových úložišť pro ukládání ontologií 82


4. spartánské administrační uživatelské rozhraní Takový prototyp bychom rádi vyzkoušeli na vybraných projektech skutečných elektronických obchodů.

5.4 Stav Zatím pouze zvažuji, zda rizika nejsou příliš značná a tedy zda se vůbec vyplatí systém vyvíjet. Souběžně provádím analýzu – zkoumám prostředí, ve kterém by byl systém případně nasazován a snažím se odvodit další klíčové charakteristiky, které by mohly promluvit do analýzy proveditelnosti, a to jak na straně nákladů, tak případných přínosů a z nich plynoucího zájmu uživatelů, investorů...

B.6 Klíčové parametry ontologického meta modelu Ontologie zde vystupuje především v roli meta systému, ale má i některé rysy samohodnotné. Zjevně musí být schopna pojmout (v podobě odkazů nebo i nějak těsněji) existující propagační materiály, obrázky, příklady, obchodní informace apod., a to zejména tam, kde by se na ontologické řešení postupně přecházelo z nějakého konvenčnějšího systému. Na druhou stranu zároveň značnou dávku informace obsahuje ontologie sama o sobě a lze si představit i elektronický obchod plně vybudovaný na ontologii, který by se bez externích materiálů obešel. Pokud by ontologie obsahovala opravdu vše podstatné, bylo by možné všemožné přehledové i produktově specifické propa gační materiály, emaily, tiskové zprávy, ale i různé formuláře nebo třeba ankety vhodnými transformacemi naopak generovat. Základem by byly výsledky vhodně položených dotazů v kombinaci se šablonami vizuálního stylu. V takovém přípa dě již půjde o ontologii čistě samohodnotnou. Z požadovaných vlastností vyplývají také další nezbytné charakteristiky ontolo gického meta modelu:

skládání na různých úrovních Jeden produkt může být složeninou jiných, a to obecně, na úrovni kon ceptu anebo u instancí, s udáním konkrétních verzí.

83


násobnost vazeb Zejména u vztahů „součástí“ mezi instancemi produktů vynikla potře ba stanovení jeho kardinality. Mám na mysli možnost definovat to, že židle zahrnuje čtyři nohy, aniž by bylo nutné v systému evidovat opravdu čtyři instance kon ceptu noha a čtyři související vazby – tedy nebudeli takové řešení v konkrétním případě vhodné z jiného důvodu. U židle by ještě problém nebyl tak palčivý, větší potíže by nastaly tam, kde je třeba materiál (látku) odvažovat či odměřovat, případně kde stejných komponent není pár, ale třeba tisíce.

události Ontologický systém musí generovat hlášení o probíhajícím dění (udá losti) a rozesílat je přihlášeným naslouchačům. Je to klíčová schopnost zejména pro funkci transakčního modulu, bude se ale asi hodit i při implementaci uživatelského rozhraní. Transakční systém by měl disponovat poměrně bohatou hierarchií růz ných typů událostí, aby pokryly veškeré zajímavé dění, nejen úpravy, ale i čtení. Naslouchači musí dostat možnost registrovat se k vybraným událostem, aniž by byli obtěžováni událostmi pro ně nezajímavými.

sledování času Zejména v souvislosti s procesy poptávek, objednávek, nákupů apod. bude třeba evidovat okamžik jejich vzniku. Sledování platnosti určité informace bude mít svůj význam třeba i u definic produktů – aby bylo zřejmé, kdy byla která vlastnost zveřejněna, jak dlouho zůstala, kdy se změnila apod. Takové informace budou hodnotné pro zákazníky (bude je třeba zají mat vývoj nějakého produktu aby odhadli, co se s ním bude dít dále), také pro provozovatele – jako podpůrná informace při vyřizování re klamací, obnovování smluv... Shrnuto, hodila by se obecná podpora sledování změn v čase nejlépe s možností návratu k předchozím verzím.

84


Inspirací mohou být schopnosti databáze ZoDB aplikačního serveru [ZOPE] nebo třeba systémy Wiki.

dynamické vlastnosti, možná dokonce metody Například pro cenové kalkulace bude velmi praktické, pokud budou in stance ontologií disponovat vlastnostmi, jejichž hodnota bude dána nikoliv výslovně, ale vhodným funkčním vztahem či pravidlem. Konkrétní hodnota takové vlastnosti (například číselná) bude na dotaz zjišťována aplikací funkčního vztahu na vhodné hodnoty té samé in stance nebo instancí souvisejících. Například pokud cena židle bude dána jako součet cen zahrnutých komponent. Při dotazu na cenu židle systém projde graf, vyhledá komponenty, jich se zeptá na cenu a zjištěné hodnoty dosadí do funkce, která vrátí výsledek... Vyšším stupněm jisté „objektovosti“ instancí v ontologiích by byla podpora metod – nějakých obecnějších předpisů, které by již ne sloužily výhradně počítání hodnot dynamických vlastností, ale na příklad by nějak ontologií manipulovaly. Zatím nechám na zvá žení, zda jejich přínos převáží potíže plynoucí z vyšší složitosti.

základní sémantické souvislosti Ontologie by měla umožnit definici synonym, antonym, komplementů a antagonismů... Pokud zákazník zatouží po pramenité minerální vodě, měla by mu být nabídnuta třeba praktická sada sklenic.. Pokud bude hledat housky, které zrovna došly, můžeme mu navrhnout rohlíky. Také je zřejmé, že pokud hledá „hosting s podporou JSP“, je to to samé jako „hosting s podporou Java Server Pages“ nebo možná i „hosting s podporou Javy“.

vlastnosti Velký důraz bude kladen na možnost precizně popsat vlastnosti. To nás vrací k myšlence kombinovat ontologii s rámci.

85


internacionalizace V našem stále se zmenšujícím světě stále roste potřeba vyjít vstříc zá kazníkům ze všech možných zemí, mluvících rozličnými jazyky, zvyk lých na různá prostředí, prostě všemožně jiných. Systém by jim měl nabídnout popisy, charakteristiky, souvislosti, to vše v jejich jazyce. Kromě přímých překladů je dále třeba pamatovat na různé měrné sou stavy, časová pásma a další komplikace. Ontologický model s tím vším musí počítat.

verze Tento bod možná trochu souvisí se schopností zachycovat čas. O co jde? Konkrétní produkt prochází svou vlastní historií – od prototypů a testovacích modelů, pokračuje v různých verzích, končí jako výbě hový typ. Celou dobu ho tvůrci udržují v konkurenceschopném stavu neustálým doplňováním, vylepšováním. Podpora verzí je pro aplikaci ontologie v elektronickém obhodě po měrně důležitá, zároveň ale přináší některé komplikace, které si vyžá dají ošetření. Jak například naložit se vztahy, které novější verze „zdě dí“ od starší? Asi nic zvláštního – prostě ji zdědí. Přidat novou vazbu u novější verze také půjde snadno. Co ale když novější verze nebude mít nějakou starou vazbu obsahovat? Bude tedy třeba vypracovat vhodný mechanismus nedědění nežádaných vazeb, případně rušení vazeb již zděděných.

vazby ven Poměrně běžnou potřebou jistě bude zapojit do ontologií konvenční data – elektronické podoby propagačních letáků, prezentací, fotografií, url... Ontologie musí být také dostatečně otevřená, aby se snadno propojila s ontologií jiného systému, a také s například podnikového informační ho, adres

86


dilema instance a probublávání vlastností Nejsem si úplně jistý, zda má praktický význam explicitně rozlišovat koncepty a instance. Jak to? Instance je z jiného úhlu pohledu může být konceptem. Například, uvažujili hierarchii skriptyJSP, mohu JSP považovat za instanci (vždyť jde o konkrétní skriptovací jazyk). Na druhou stranu mohu JSP považovat za koncept a až konkrétní verzi specifikace za instanci. Anebo mohu i verzi specifikace pova žovat za koncept, a jako instanci chápat až konkrétní implementaci (třeba Apache Tomcat) nebo třeba konkrétní využití (zakázku, webovou stránku v JSP apod.). Jaký je vlastně rozdíl mezi vztahem dědičnosti (isa) a vztahem imple mentace v říši ontologií? Nebylo by univerzálním řešením něco, co nazvu a budu dále nazývat „probubláváním vlastností“? Mám na mysli takový mechanismus, že dokud není vlastnosti v hierarchii přidělena hodnota, je hodnota „pa sivní“ a celý koncept abstraktní (skript:[model:string]) a až po doplně ní všech pasivních hodnot (jsp:[model:push]) se z konceptu stává in stance. K těmto otázkám se jistě ještě vrátíme.

Nastínil jsem, myslím, docela zajímavý meta model ontologií, který možná za slouží i své vlastní označení. Říkejme mu v dalším textu charakterizační sítě.

B.7 Významné koncepty a vztahy 7.1 Základní koncepty Klíčovým konceptem bude zřejmě produkt a rodina konceptů souvisejících – ta kových, které umožní produkt popsat, zařadit ho do kontextu jiných produktů, stanovit jeho parametry apod. Další koncepty, jako třeba zákazník, dodavatel, správce, případně cena, nositel hodnoty, zakázka, objednávka, poptávka souvisejí s procesy, které by systém mohl ale na druhou stranu zejména v prvních verzích nemusel podporovat formou rozšiřujících modulů.

87


Důležitou skupinou vazeb budou různá skládání (židle integruje nohy), dále al ternativy (houska – rohlík), komplementarity (ke kávě cukr), antagonismy.. Spousta vazeb přichází v úvahu s již zmíněnými procesy poptávání, objednávání, administrace apod.

7.2 Příklad doménově specifické aplikace Nebudu zabíhat do zbytečných detailů, ale zmíním pár bodů specifičtější přípa dové studie obchodu se službami webového a poštovního hostingu. Dejme tomu, že by bylo cílem poskytovat produkty, které byly zhruba shrnuty takto:

7.2.1 Produkty

obecné a základní služby monitorování a servis zálohování dat

služby spojené s doménovým jménem doména druhého řádu subdoména alias k doméně

služby elektronické pošty poštovní schránka (umožní cizím SMTP serverům umístit zprávu) přístup k poštovním schránkám prostřednictvím IMAP přístup k poštovním schránkám prostřednictvím POP webové rozhraní pro poštu alias k emailu automatický odpovídač přesměrování pošty na email přesměrování pošty na mobil

základní webhostinové služby SSH přístup pro upload (SCP/SFTP) 88


upload přes prohlížeč ankety kniha návštěv modifikace chyby 404 statistiky přístupů odesílání formulářů obchod WAP

aktivní technologie pro webhosting PHP CGI JSP a servlety Perl PHP řešení založené na xml obsahu prezentační framework dynamické xml řešení (Apache Cocoon)

relační databáze PostgreSQL MySQL HSQLDB Firebird

jiné databáze objektová databáze XML databáze

89


7.2.2 Tvorba ontologie Jak by vypadalo ontologické pojetí takového portfolia? Zkusím na zkoumaném příkladě naznačit postup tvorby ontologie. Postup by šlo jistě zpřesnit a zobecnit a vytvořit příslušnou metodiku. Tak tedy:

virtuální produkty Pokud bychom požadovali, aby systém rozuměl vztahům mezi produk ty (aby například mohly fungovat kvalitní cenové kalkulace), bylo by v první řadě třeba doplnit virtuální produkty, které vhodně vyjádří (s)po třebu zdrojů. Produkt hosting místa by vyjadřoval kolik prostoru na disku serveru je třeba pro data zákazníka. Hosting konektivity by zase vyjadřoval kapacitu Internetového připojení. Podobně by bylo možné vyjádřit třeba spotřebu výpočetní kapacity serveru.

závislosti (kompozice) Dále bychom museli stanovit kompozice jednotlivých produktů – vaz by, kdy jeden produkt vyžaduje produkt jiný. Například dynamické technologie nemají smysl bez obecného web hostingu. Webhosting nelze poskytovat bez hostingu místa na disku a konektivity. Místo na disku budou vyžadovat rovněž produkty da tabázové...

konceptualizace Dalším krokem by bylo logické rozlišení konceptů a instancí – byť není zatím jisté, zda má smysl rozlišovat je na technologické úrovni, pro pochopení vztahů je to při návrhu praktické – a vyhledání vztahů dědičnosti mezi nimi. Tedy například podtypem konceptu databáze by byl koncept relační databáze (a stejně tak objektová databáze a XML databáze). Instancí nebo dalším podtypem relační databáze by byly konkrétní podpo rované systémy – PostgreSQL, MySQL apod. Webové rozhraní, IMAP a POP jsou všechno podtypy konceptu přístup k poště...

90


další vztahy Dále by bylo vhodné explicitně stanovit takové další zajímavé vztahy, které přímo nevyplývají z charakteru konceptu a dědičností. Je třeba zřejmé, že PHP a JSP jsou alternativy, protože obě techno logie by byly subkonceptem aktivní technologie. Šlo by především o alternativy, komplementarity apod.

cenové předpisy Jednotlivé produkty by bylo třeba ohodnotit, aby kalkulační model mohl počítat ceny. Některé produkty by dostaly ohodnocení paušálem (konstantou), jiné funkčním vztahem. Hosting místa v závislosti na počtu obsazených megabajtů, poštovní služby podle počtu schránek apod. Pro opravdu robustní cenové modely by přibyla ještě část on tologie definující jednotlivé zdroje a jejich ceny, ze které by cenotvorné funkce u produktů vycházely.

detaily o produktech Samozřejmě nelze zapomenout na vlastní charakteristiky produktů – jak se jmenují, v jaké verzi jsou nabízeny, kdo je vytvořil (čí je techno logie a čí konkrétní realizace), nějaké recenze, popisy, hodnocení.. ale také nápady, postřehy, vazby na diskuze uživatelů apod., tedy všechno to, co je zvykem o produktech uvádět i u konvenčně řešených obcho dů. Na následujícím obrázku je znázorněn kousek ontologie. Šipky vy jadřují dědičnost, kolečka nezbytnost (závislost, kompozici) – kon cept s kolečkem musí být přítomen (prodán, zahrnut do nabídky apod.), aby koncept na druhé straně vztahu mohl existovat.

91


email

alias schránky

web

aktivní technologie

konektivita JSP

místo databáze

relační databáze

92

PHP

Projektové studie Administrace serveru

C Administrace serveru C.1 O co jde Představte si Linuxový server pro poskytování mnoha služeb. Je to server složený z velkého množství vzájemně nezávislých softwarových komponent. Nemyslím si totiž, že je dobré, když jeden program umí všechno – kromě toho, že pak většinou sice dělá všechno, ale nic pořádně, přináší to často také řadu dalších problémů. Například problémy bezpečnostní – pokud je kompromitována jedna služba, jsou auto maticky kompromitovány i ostatní. Tvůrci monolitů mají také ten dence obcházet standardy a nahrazovat je svými proprietárními řešeními, čímž zákazníka napevno k ke svému produktu – to je z pohledu dodavatele pozitivum, ale uživatel trpí – stává se závis lým.

Nuže, máme server z komponent – komponent otevřených, respektujících stan dardy, bezpečných, schopných dobře plnit své poslání. Oproti řešením monoli tickým má ale taková „skládačka“ také nevýhody. Prakticky všechny podstatné lze shrnout pod pojem komplikovaná správa.

C.2 Běžné řešení bez ontologií Jak jsme již zmínili, zvažujeme využití nezávislých komponent. To, že jsou ne závislé obvykle znamená, že je vytvářeli různí vývojáři, podle různých zásad. Každá taková komponenta vypadá jinak, chová se jinak a především se jinak konfiguruje a spravuje.

2.1 Výchozí stav V prostředí Linuxu je zvykem konfiguraci koncentrovat do snadno čitelných tex tových souborů na jednotné místo v adresářové struktuře. Každý takový konfigu rační soubor je ale jiný – některé mají tvar dlouhé řady voleb (Postfix), jiné jsou vystavěny na XML (aplikační server Apache Tomcat), další sice XML na první pohled připomínají, ale jeho standardem se neřídí (HTTP server Apache). Pokud je třeba zprovoznit prostředí třeba i se základní sadou služeb novému kli entu, vyžaduje to různé zásahy do mnoha takových souborů. Kromě toho je možná třeba vytvořit nějaké adresáře, založit databáze, poštovní schránky... Ještě 93


komplikovanější může být zprovoznění nové služby většímu množství stávajících zákazníků. To vše lze zvládnout ručně, ale je to otravná práce, náchylná k chybám. Navíc, a to považuji za ještě závažnější, v případě budoucích změn (například zákazník odejde nebo požaduje kompletně jinou sadu služeb) je třeba vrátit všechny úpravy provedené při zakládání. Jednoduše řečeno – ruční administrace je pracná, časově náročná, není škálovatelná, nepružná – je prostě špatná Pak tady existují různé pokusy, jak správu zjednodušit. Například můžete použít jednu z mnoha grafických nadstaveb, třeba Webmin. Ty ale obvykle nejsou ničím jiným než právě takovou nadstavbou – jejich prostřednictvím lze provádět úpravy v jednotlivých konfiguračních souborech služeb. To ale neřeší náš problém – po třebu integrovat správu tak, aby jeden úkon (přidání zákazníka, odstranění zákaz níka, povolení virtuální služby „pošta“...) byl automaticky, bezpečně (s různými validacemi) promítnut do konfigurace více služeb.

2.2 Běžná řešení Spousta administrátorů se nakonec uchýlí k tomu, že si vytvoří systém jedno duchých, ale účinných skriptů, které potřebné úkony provádějí za ně, a na který jsou pak náležitě pyšní. To je v současné době asi nejlepší řešení, ale stále je špatné. Především, je plýtváním pracovní silou vytvářet něco obecně použitelného pouze pro sebe. Dále, takový racionálně uvažující autor zvažuje svůj čas vynaložený na tvorbu skriptů a porovnává ho s přínosem, který mu skripty přinesou. Je proto lo gické, že neimplementuje dokonale automatizovaný systém, ale spokojí se s auto matizací toho nejvíce se opakujícího, případně toho, v čem dělá nejvíce chyb. Například já jsem si na serveru který spravuji vytvořil sadu skriptů pro přidávání zákazníků, protože to se děje docela často, ale změny a odstraňování konfigurace provádím ručně. Pokud by tady byl systém, který by sloužil spoustě administrátorů, celkové nákla dy a přínosy by se vyrovnaly někde u mnohem dokonalejšího řešení. Proč tedy ta kový systém již neexistuje? Potíž je v tom, že když skládáte server z nezávislých otevřených komponent, máte neskutečně mnoho možností, jak to udělat – máte na výběr řekněme ze třech SMTP serverů, čtyř POP a IMAP serverů, třech webových serverů, pěti doménových serverů, dvou SSH serverů, snad několika 94


desítek relačních a jiných databází...., spousty různých modulů a rozšíření, to vše v mnoha verzích a modifikacích.. Posoudíte parametry a vyberete to pro vás nej vhodnější. Nakonec napíšete hrst jednoduchých ale účinných skriptů, přesně pro tu vaši kombinaci – jednoduše proto, že se vám to vyplatí. Nevyplatí se vám ale vytvářet skripty univerzální, protože to by byla již řádově složitější úloha.

C.3 Přínos ontologií Myslím že ontologie by byla vhodným základem maximálně flexibilního systému pro správu nezávislých softwarových komponent. Veškeré klíčové informace o zákaznících a jimi požadovaných službách a jejich parametrech by mohly být pri márně zachyceny ontologicky a až od tohoto základu by byly odvozovány konfigurace jednotlivých služeb. Přineslo by to například takové výhody:

přirozená integrace Integrace by nebyla realizována jako dodatečné „slepení“ nesourodých konfigurací, ale byla by pojata vnitřně integrovaně. Jeden pohled na ontologii by vybral vše, co se týká zákazníka. Jiný pohled by zase sle doval konkrétní službu. Celek by byl vnitřně provázaný.

abstrakce Administrátor by byl „odstíněn“ od konkrétní technologické realizace jím spravovaných služeb. Nemusel by tolik řešit technologické detaily, ale soustředil by se více na to, co je skutečně důležité – správu poža davků, funkcí, vztahů, definici toho kdo a co a nikoliv jak. Rozhraní by mohlo vypadat prakticky stejně, i kdyby na pozadí obsluhovalo úplně jiné programy.

snadný přechod Jakmile zahlédnu závislost na konkrétní technologii, řešení, pro duktu, firmě apod., tak zbystřím – závislostem je třeba se vyhýbat, protože přinášejí rizika. Co se stane, když dodavatelská firma zkrachuje? Když vývoj bude ukončen? Když program přestane sta čit?

Pokud budou klíčová data v nezávislém formátu (v ontologii) a konfigurace konkrétních nástrojů bude pouze projekcí těchto dat do specifických šablon, záměnou šablon bude možné bezbolestně, tedy 95


bez zásahů do dat, přejít na jiný systém. Zatím neznám žádný adminis trační nástroj, který by něco takového obecně umožňoval. Na následujícím obrázku je naznačena integrace jednotlivých služeb – nejprve zo becnění konkrétního serveru (Posftix..) jako implementace nějaké technologie (SMTP). Pak shrnutí technologií v rámci určitých rodin – mezi jejich členy bude mno dat sdílených. A jako finální integrační vrstva rozhraní, které překlene barié ry i mezi rodinami a umožní sdílet i tak univerzální údaje, jako třeba doménové jméno.

konkrétní nástroj

Postfix

protokol

SMTP

kategorie služby

Courier

POP3

IMAP

Pošta

Apache

OpenLDAP

...

HTTP

LDAP

...

Web

Data

...

Rozhraní pro správu

C.4 Problémy a rizika řešení s ontologiemi nevhodnost ontologií Univerzální, nezávislý nástroj pro správu serveru by byl užitečný – to je myslím mimo jakoukoliv diskuzi. Je tady ale určité riziko, že ontologie nejsou tím nejvhodnějším způsobem reprezentace dat. Možné to je, ale dovolím si tvrdit, že jsou pro toto užití přinejmenším vhodné.

nevhodnost technologií Mohlo by se stát, že některá použitá technologie nebude vyhovovat prostředí serverů – svými závislostmi na jiném softwaru, svou nedosta tečnou otevřeností, platformní závislostí apod. 96


Toto riziko je třeba mít na paměti při návrhu systému a stále si poklá dat vhodné otázky..

komplikace přechodu Nebude snadné převést nastavení stovek či tisíců účtů různých služeb do podoby ontologie.

psychologické zábrany Jak mohu soudit z komunikace s některými zkušenými správci UNI Xových serverů, jsou to obvykle lidé nadprůměrně inteligentní a také dosti sebevědomí. Jsou pyšní na své znalosti technologií se kterými pracují a mají obecně odpor ke grafickým rozhraním, konfiguračním pomáhátkům a dalším kusům softwaru, o kterých s oblibou prohlašují, že je pro neschopné.. Mnohdy také, co si nenaprogramují sami, tomu často nedůvěřují. A za roky své praxe si již vytvořili obstojná, ale nikoliv univerzální prostře dí pro správu. Svému systému dokonale rozumí, ale nerozumí mu prakticky nikdo jiný, díky čemuž jsou skoro nenahraditelní – což je dobrá pozice. Dovedu si představit, že podstatné procento správců by se docela zdráhalo navrhovaný systém nasadit.

C.5 Kostra architektury ontologického řešení V té nejjednodušší a nejobecnější podobě by mohla vypadat architektura systému zhruba takto: Postfix Ontologie

Apache Tomcat

Generování konfigurace Šablony konfigurací

SSH

97


5.1 Základní komponenty Základních komponent je vcelku málo:

uživatelské rozhraní V prvních verzích bude stačit primitivní rozhraní v příkazové řádce. Časem by pro vyšší pohodlí mohlo vzniknout webové administrační rozhraní tvořené třídami, které by vhodně vizualizovaly obsah on tologie formou tabulek a přehledů a také by zahrnovalo třídy pro gene rování formulářů na zadávání údajů a manipulaci ontologií.

ontologie Jádrem by byla pro změnu opět oborová ontologie. V ní by byly uchovány všechny informace o zákaznících a jimi požadovaných služ bách. To vše na abstraktní úrovni – bez vazeb na konkrétní programové balíky, které by požadované služby realizovaly.

šablony V šablonách konfigurací by byla naopak data závislá na konkrétních použitých technologiích, ale nezávislá na zákaznických datech – na informacích o zákaznících, jejich požadavcích apod. U většiny služeb je třeba v konfiguračních souborech definovat obecné funkční parametry týkající se celé aplikace a také informace specifické podle uživatelů. Pro tyto typy informací by byly definovány dílčí šab lony. Části závislé na doménových datech by byly naplněny daty z on tologie a následně spojeny se zbytkem konfigurace. Konkrétně by ve velké šabloně (se základem konfigurace, tedy definicí obecných parametrů, nezávislých na konkrétních zákaznících) mohl být nějaký symbol či značka, na jejíž místo by se doplnily doménově specifické šablony vyplněné konkrétními daty. Kromě toho by některá z doménově specifických proměnných mohla sloužit jako identifikátor začátku a konce oblasti, aby v případě odstranění záznamu z ontologie bylo možné dohledat příslušná místa v konfiguraci. Mohlo by to vypadat třeba takto: …

98

Projektové studie Administrace serveru #mark_start aaa.cz mark_start … #mark_end aaa.cz mark_end #mark_appendhere

Určitou komplikací pro proces spojování ontologie a šablon budou obecně vícehodnotové položky – například mailové nebo doménové aliasy. Je třeba na ně pamatovat při volbě či návrhu šablonového jazyka.

modul generování konfigurace V implementačně nejjednodušší variantě systému by šlo prostě o na plnění šablon daty z ontologie, případně ověření toho, zda existují po třebné databáze, adresáře apod. a jejich vytvoření. Po každé změně v ontologii by bylo třeba takto zaktualizovat konfigu raci dotčených služeb. Trochu hloupé u takového řešení by bylo to, že i při nepatrné změně by bylo vše generováno znovu. Při velkém počtu uživatelů, případně v nasazení, kde ke změnám dochází často, by asi náročnost opakovaných procesů překročila únosnou míru. Dokonalejším řešením by bylo, kdyby systém prováděl pouze chirurgické zásahy do konfigurace. Architektura by v takovém případě byla o něco komplikovanější. Bylo by třeba nadefinovat úlohy jako „přidání zákazníka“ nebo „zrušení zákaz níka“ a pro jednotlivé podporované technologie (konkrétní konfigurované aplika ce) vytvořit řetězce úkolů, které je třeba provést třeba nějak takto: přidej zákazníka zruš zákazníka Potom, například pří vkládání nového zákaz níka do systému by bylo třeba stanovit, které služby mu mají být zprovozněny a systém by provedl všechny úko ly úlohy „přidání zákaz níka“ související s poža dovanými službami.

povol příjem pro doménu

zakaž příjem pro doménu

vytvoř schránky

zruš schránky

nastav hosting

zruš hosting

připrav adresář pro hosting

smaž adresář pro hosting

Postfix

Apache

99


5.2 Některé podstatné podrobnosti

kontext Bavímeli se o správě, veškeré úpravy budou probíhat v kontextu zá kazníka (hostitele) a taktéž instance v ontologii budou ke konkrétnímu účtu patřit. Při výběru kontextu bude pak jasné, které části ontologie mají být zpřístupněny a které skryty. Takové rozlišení především otevře cestu pro dělbu rolí – různí správci budou moci mít na starosti různé zákazníky, ale především mnoho věcí si budou moci zákazníci přes webové rozhraní spravovat sami. I takové běžné věci jako zapomenuté heslo k ně které mailové schránce nebo zřízení dalšího mailového aliasu často řeší hlavní správce. Je to plýtvání jeho časem, navíc možná by bylo i pro zákazníka pohodlnější, kdyby měl nad svým účtem přehled a mohl jej snadno spravovat.

transakce Veškeré prováděné úkoly by měly být propojeny transakčním návra tovým mechanismem pro případ chyby. Pokud se nezdaří dílčí úkol, měl by být systém navrácen do stavu před spuštěním úlohy, tedy všechny úspěšně provedené zásahy by měly být znegovány. Třeba v případě úlohy „přidávání zákazníka“ pravděpodobně vo láním příslušných úkolů úlohy „zruš zákazníka“.

sanity check Pro zvýšení spolehlivosti systému by každý skončený úkol měl provést explicitní kontrolu úspěšného splnění (např zda vytvářený adresář opravdu existuje) a v případě negativního výsledku nahlásit chybu, která by spustila řetěz navracení.

obsah úkolů Vlastní úkoly by mohly mít podobu nezávislých skriptů, v rámci kte rých by bylo možné používat předem dohodnuté proměnné systému. Některé skripty by generovaly dokumentaci, jiné by vytvářely adresá ře, další by volaly nějaké externí programy pro manipulaci poštovními schránkami apod. 100


řetězce závislostí Mezi úkoly bude také třeba definovat závislosti. Například že nelze spouštět úkol nastavení webhostingu pokud ještě nebyl vytvořen adresář pro budoucí prezentaci s provizorní stránkou, která o tom informuje. Vlastní proces přidání zákazníka do ontologie by mohl spustit pří slušný řetěz úkolů. Jak již bylo naznačeno, pokud kdekoliv dojde k chybě, bude třeba vrátit se do stavu na začátku.

5.3 Spolupráce 5.3.1 Základní model spolupráce Spolupráce jednotlivých komponent by mohla vypadat třeba tak, jak je znázorně no na stylizovaném diagramu sekvencí: Ontologie

Řídící jádro

přidej

Konfigurační úloha

přidej konfigurace služeb

dílčí úkol

souv. úkol

OK chyba vrať změny

informuj o chybě

odstraň

V odpověď na modifikaci ontologie je spuštěna konfigurační úloha. Ta volá první úkol z řetězce. Úkol potřebuje, aby byl nejdříve 101


splněn jiný úkol, na němž závisí, tak ho tedy zavolá. Druhý úkol proběhne úspěšně a vrátí řízení úkolu prvnímu. Ten ale z nějaké vnější příčiny selže. Proto bude třeba vrátit řízení závislému úkolu, aby po sobě odčinil vše, co vykonal a nakonec bude upravena on tologie (aby byla stále zachována konzistence mezi konfigurací a ontologií) a o neúspěchu informován uživatel. Ve skutečnosti jsou v nastíněném postupu určitá zjednodušení. Například úkoly rekonstruující stav před prováděním nebudou totožné s úkoly samotnými. Dílčích úkolů bude podstatně více a vzájemné závislosti budou komplikovanější. Pro zvýšením robustnosti by také před každým úkolem a po něm měly být prováděny kontroly, takže celý proces provedení dílčího úkolu by měl podobu sekvence činností: nastav prostředí pro úkol zkontroluj současný stav proveď všechny závislé předběžné úkoly proveď úkol proveď navazující úkoly zkontroluj stav

Komplikovanější by byl rovněž dialog mezi řídícím jádrem a uživatelem. Mohl by probíhat třeba takto: uživatel: chci přidat zákazníka jádro: musíš vyplnit jméno a příjmení, doménu... uživatel: tady to je – Franta Novák, franta.cz... (ověří dostupnost domény, provede pár dalších kontrol) jádro: vyber, jaké služby bude požadovat uživatel: poštu a web jádro: dobrá, přidávám ho do ontologie, spouštím úlohy přidání pro web a poštu.. (dopočítává další proměnné podle potřeb úlohy, spouští jednotlivé úlohy, provádí kontroly..)

102


5.3.2 Architektura založená na naslouchačích Trochu jiná a možná flexibilnější architektura by spoléhala na naslouchače. Každá podporovaná služba by se zaregistrovala v ontologii k odebírání konkrétních hlá šení o změnách. Jakmile by změna nastala, automaticky by spustila příslušné úlo hy (skládající se z dílčích úkolů). Výhoda takového řešení by spočívala především v maximálním oddělení ob služného a řídícího jádra s ontologií od adaptérů pro jednotlivé služby. Přidávání dalších služeb by bylo snazší, jádro by mohlo zůstat nedotčené.

C.6 Klíčové parametry ontologického metamodelu Každopádně jde o typickou samohodnotnou ontologii – veškerá doménová data jsou přímo její součástí. Mnoho parametrů je shodných s těmi, které již byly iden tifikovány u předchozích příkladů. Proto se zmíním jen o těch nejzásadnějších, nesamozřejmých anebo zatím nepříliš zdůrazňovaných parametrech.

čas a změny Pro účely fakturací by bylo praktické evidovat od kdy je která služba poskytována, možná i od kdy do kdy je zaplacena. To přináší potřebu evidovat změny v čase a také čas samotný.

naslouchači Nezbytným parametrem u naznačené flexibilnější varianty bude pod pora naslouchačů pro vybrané části ontologie. Například když se změní cokoliv v konkrétním kontextu, dozví se to naslouchač, který shromažďuje údaje pro fakturace. Pokud se změní něco v libovolném kontextu, ale v kategorii poštovních služeb, do zví se to zase příslušný adaptér, který provede aktualizaci nastavení. Ke každému prvku ontologie (koncept, vazba..) by mělo být možno při dat takový naslouchač. Ten bude sledovat buďto co se děje přímo s konceptem, anebo jeho instancemi (potomky) kdekoliv v podřízené hi erarchii.

103


závislosti Celým systémem se prolíná potřeba stanovovat závislosti – které mo duly se vzájemně potřebují pro správnou funkci, které úlohy před cházejí dané úloze, jaké musí být pořadí dílčích úkolů apod. Například pro web a poštu je třeba nejprve zřídit a evidovat doménu (byť třeba ne námi spravovanou). Při zřízení webu bude jako dopo ručená (ale již nikoliv nezbytná) navazující služba nabídnuto zřízení SSH účtu pro přístup a nahrávání stránek apod.

uživatelské datové typy Praktická by byla podpora nepříliš běžných datových typů, jako email, domain nebo domainentry. Myslím, že pokud bude možné definovat aplikačně specifické typy, nezanedbatelně to zvýší robustnost progra mu, jeho odolnost proti chybně zadaným hodnotám a mnohdy to také zvýší pohodlí. Například datový typ domainentry bude obsahovat položky jako: www

A

194.195.157.141

Ve webovém rozhraní by místo jednoduchého rámečku pro zadání textu mohla být zvláštní komponenta obsluhující speciálně tento da tový typ, sestávající ze sady rozbalovacích menu a speciálních for mátovaných textových polí. Uživatel by tak byl naváděn k zadání správných nebo alespoň syntakticky validních hodnot.

C.7 Významné koncepty a vztahy Kromě konceptů vyjadřujících elementární pojmy a vztahy se zde objevují:

služby Jako kategorie toho, co lze nabízet. Například: •

pošta – SMTP, IMAP, POP3..

•

web – HTTP, aktivní technologie

•

databáze – relační, objektové... 104


komponenty služeb Kromě služeb samotných bude třeba nadefinovat obecné elementární kategorie, které se v konfiguraci mohou vyskytovat – doména, poš tovní schránka.. Komponenty budou mít například takové atributy (naznačeny jsou datové typy a jejich kardinalita): MAIL: address

email

1..1

heslo

pwd

1..1

mailbox

dir

1..1

jmeno

jmeno:text, prijmeni:text

1..1

alias

email

0..n

address

domain

1..1

entry

domainentry

0..n

address

domain

1..1

alias

domain

0..n

DOMENA:

WEB:

… Jak si můžete povšimnout, jsou zde použity nepříliš běžné datové typy, jak byly zmíněny výše.

technologie Jako implementace služeb, tedy konkrétní nástroje, které je třeba provozovat, spravovat, konfigurovat. •

Apache

•

Postfix

•

Courier IMAP

•

...apod.

105


Technologicky specifické adaptéry by zahrnovaly šablony konfigurací a také specifické konfigurační postupy (skripty). Každý adaptér také ponese seznam jím vyžadovaných dat, zejména těch trvale uložených v ontologii v podobě konceptů komponent služeb.

komponenty technologií Konkrétní, technologicky specifické realizace obecných konceptů komponent služeb. •

poštovní schránka v Postfixu

•

poštovní schránka v Courieru

•

doménový záznam v NSD

•

...apod. Koncept

Technologie (realizace)

Služba

pošta

Courier

Postfix

Konfigurační komponenta

pošt. box

Courier box

Postfix box

hostitel (zákazník) Ten, v jehož prospěch jsou služby provozovány. V jeho kontextu bu dou prováděny úpravy. Vazbami, nejčastěji s kardinalitou n, bude na pojen na koncepty jím využívaných služeb.

106


Tedy nějak takto – v obrázku jsou čtverečkem naznačeny násobné kardinality: alias webu

alias pošty

web

databaze

poštovní schránka

107

domenovy zaznam domena

Projektové studie Další možnosti praktické integrace

D Další možnosti praktické integrace Je jasné, že systémy s ontologickým jádrem lze integrovat snadněji. Postupy ma pování, spojování a znovupoužití ontologií (zmíněné v teoretické části) jsou dobře formalizované, popsané známa jsou úskalí i jejich řešení, existují i vhodné manipulační nástroje. Mnohé integrační možnosti jsem již zmínil výše, nebudu proto zabíhat do detailů. Toto krátké zamyšlení jsem si ale neodpustil, protože považuji ontologie pře devším za vhodné a univerzální lepidlo pro integraci, proto zde shrneme možnosti, které jsme již zmínili a možná naznačíme pár dalších. Tak tedy krátce se zamyslím nad perspektivami integrace jednotlivých typů aplikací. Všechny uváděné systémy by mohly těžit z bohatství informací, které ontologie zachycují, a tak by mohly nabídnout vyšší stupeň inteligence, než je běžné. Od drobností opět dospějeme až k vrcholu – k ontologií podpořené virtu ální firmě.

systém fakturace Vhodným propojením systému pro správu serveru a ekonomického informačního systému by mohl vzniknout automatizovaný systém pro fakturace na základě skutečně odebíraných služeb.

CRM Jak jsme již zmiňovali, pojem nemá jednoznačně definovaný význam, ale obecně se jím rozumí evidence zákazníků, jejich potřeb, jednání s nimi, evidence a správa uzavřených kontraktů, podpora pro marke tingové aktivity a pro další činnosti. Jako základ systému CRM by mohl sloužit adresář informací o zákaz nících potřebný již jinde. Nadprůměrná inteligence systému plynoucí z kvalitních údajů v ontologii by se mohla projevit třeba tak, že by sys tém doporučoval vhodné kampaně na základě statistických dat o zá kaznících, jejich činnosti a nákupních zvyklostech. Těsné vazby může me hledat také směrem k systémům znalostním – viz níže

108


sklad a logistika Informace o zboží z webového obchodu by byly navázány na logistiku a skladové hospodářství. Skladové hospodářství by třeba samo doporu čovalo objednání zásob podle vhodného modelu zásob.

správa dokumentů Ontologie by zde byla v typické meta roli – pouze by popisovala data uložená v jiné podobě. Oproti klasickým systémům pro správu doku mentů by mohla opět nabídnout zajímavé vazby na produkty, zákaz níky apod.

řízení workflow, groupware Ontologie by zahrnovala především adresář kontaktů a pak spoustu konceptů jako „proces“, „úkol“, „cíl“ nebo „schůzka“, „telefonát“. Při vhodném spojení se systémem obchodu by mohly být konkrétní úkoly přidělovány a realizovány zároveň v kontextu zákazníků a kontextu produktů.

systém znalostní Význam znalostí v konkurenčním prostředí roste. Cílem organizací myslících na budoucnost je uchovat cenné znalosti svých kvalitních pracovníků. Propojením znalostního systému s CRM by i běžní operátoři na horkých linkách mohli zodpovídat složité dotazy. S kvalitním roz hraním do elektronického znalostního systému by mohl obchodník rychle vyzdvihnout přednosti produktu. Účetní by snadno zjistila, jak má účtovat složitý, ale občas se vyskytující případ... Nabízí se propojení se systémem správy dokumentů, elektronickým obchodem nebo třeba informačním systémem pro podporu servisu a vyřizování reklamací. Všude by vazby dobře zprostředkovaly on tologie.

podnikový informační systém jako integrovaný portál To je myslím velkou výzvou v oblasti aplikace možností aplikace on tologií. Tak jako nejlepší server pro poskytování síťových služeb se 109


stává z mnoha otevřených, vzájemně nezávislých komponent, tak by mohl vzniknout podobně komplexní, provázaný a integrovaný infor mační systém z původně nezávislých kusů. V oblasti opensource existuje mnoho systémů, které řeší dílčí úlo hy klasických informačních systémů. Patří mezi ně například Compiere (CRM a ERP systém) nebo OpenCRX (CRM systém profesionální kvality). Existuje také mnoho účetních programů, programů pro vedení skladové evidence, groupware (OpenGroup Ware..) apod. Neznám ale ani jediný, který by byl flexibilní, ale zá roveň dostatečně komplexní.

Komunitní způsob vývoje příliš nepřeje podobně rozsáhlým projek tům. Výjimkou z tohoto pravidla je třeba monolitický kancelářský ba lík OpenOffice.org – za ním ale stojí silná společnost (Sun Micro systems), která jeho vývoj podporuje a koordinuje. Mnohem běžnější jsou kvalitně pojaté drobnější projekty. Myslím že ontologie by dost možná mohly posloužit jako společný jazyk a umožnit nezávislým týmům propojit svá díla. Výsledkem by mohl být univerzální a komplexní, flexibilní a integrovaný celek.

integrace subjektů Zajímavou oblastí jsou možnosti integrace různých subjektů – dodava telů a odběratelů nebo obecněji spolupracovníků podílejících se na společném velkém díle (zakázce, projektu..). Ontologie by mohly pod pořit již existující svazky nebo pomoci při formování nových. Jak vy plývá z úvodu práce a především z části o virtuální firmě, vše to jsou směry, jimiž se obchod téměř jistě bude ubírat. Zároveň je to bitevní pole, kde konkurence je neobvykle intenzivní – kdo nevyužije maximum technologického potenciálu doby (a on tologie, byť zatím možná ještě v této oblasti nedoceněné do něj jistě patří), neuspěje.

110

Projekt ontologického systému Projekt ontologického systému

IV Projekt ontologického systému Na základě poznatků načerpaných z případů použití ontologií v různých prostře dích nyní stanovíme obecné požadavky dále navrhovaného systému. Pokusím se je vyjádřit stručně a výstižně, aby bylo snadné udržet je v mysli, až se ponoříme do větších detailů. Při stanovování požadavků čerpám kromě předchozího textu také z práce [ASMZEJ03].

univerzálnost, přizpůsobitelnost Systém musí umět poskytnout cenné služby výše zkoumaným typům aplikací, ale i aplikacím jiným, které jsme podrobně nezkoumali. Na druhou stranu nesmí pro dané použití vnucovat nevhodné a zbytečné funkce. Klíčem k řešení bude konfigurovatelnost.

použitelnost Již tuším, že systém bude velmi komplexní. Nesmí to ale být na úkor použitelnosti. 1. Uživatelská přívětivost: Systém by měl pomáhat uživateli kde to jen půjde a nevyžadovat od něj víc než je nezbytné. V tomto směru bude klíčová opět konfigurovatelnost spolu s me chanismy skrývání. 2. Snadnost správy: Instalace a konfigurace včetně propojování s dalšími systémy uživatelským rozhraním, databází a systémy aplikačními musí být rozumně snadná. Klíčem bude otevřenost, respektování standardů, kvalitní dokumentace. 3. Snadný vývoj: Při vývoji by měly být používány dostupné prostředky pro udržení přehledu nad projektem, pro a zajištění spravovatelnosti i do budoucna. Důležitá bude kvalitní analýza a návrh, v rámci implementace pak API dokumentace a jednot kové testy. Nesmíme opomenout také volbu vhodné techno logie.

111


nezávislost Systém musí běžet na všech běžných operačních systémech Windows, Linux, MacOS… Nesmí být závislý na žádné knihovně nebo aplikaci s restriktivní licencí, která by omezovala jeho další pou žití. Nesmí být pevně svázaný s žádnou konkrétní databází, aplikačním serverem...

rozšiřitelnost a flexibilita Musí být otevřený ke změnám a vývoji. Musí být také otevřený pro uživatelské modifikace a doplňky. Kromě toho musí definovat jasná a dobře použitelná rozhraní a mechanismy komunikace, včetně me chanismů hlášení změn v ontologii. Nebudu se snažit vytvořit jeden překomplikovaný meta model, který by šlo použít všude (ale všude by zároveň překážela spousta nevyuži tých funkcí). Spíše systém pojmu jako konfigurovatelný – meta model půjde vybudovat konfigurací pro konkrétní užití.

robustnost Jakmile bude jednou nakonfigurovaný, měl by kontrolovat a vynu covat validitu ontologie na něm postavené. Nemělo by být snadné po rušit integritu ontologie nevhodnou entitou nebo vazbou. Systém by měl kontrolovat veškeré změny a vynucovat dodržování integritních pravidel.

výkon Výkonové požadavky jsem zařadil až na poslední místo, protože upřednostňuji čistotu návrhu a jsem toho názoru, že výkon je lépe řešit, až když systém funguje správně. Na druhou stranu je třeba mít na paměti, že v reálném nasazení půjde i o výkon, rychlost, spotřebu paměti a podobné parametry.

Ve fázi budování prototypu se ale spokojíme s tím, když budou nároky v zásadě „rozumné“. Hned od začátku ale budeme pamatovat na budoucí potřebu škálova telnosti – především co se týče možností ukládat data do více databází,

112


replikovat apod. Prozatím ale ponecháme stranou clustering a rozklá dání výpočetní zátěže. Teď nám již nic nebrání ponořit se do vlastního návrhu. Začneme meta modelem ontologie, časem přejdeme k provozním požadavkům a návrh uzavřeme de kompozicí modulů a vypátráním vhodných technologií. Pak bude následovat již jen implementace prototypu. Pokud práci dočtete až dokonce, myslím že vám bude jasné, že na finální verzi systému si bude třeba ještě chvíli počkat....

113

Projekt ontologického systému Meta model ontologie

A Meta model ontologie Předchozí část zkoumala možnosti nasazení ontologií především tam, kde to do sud není příliš běžné. Předkládala doklady toho, proč jsou ontologie pro dané po užití vhodné, jak by systém s jejich využitím mohl fungovat, jak by mohl vypa dat. V neposlední řadě jsme dospěli k různým zásadním parametrům ontologické ho meta modelu právě pro trochu tato atypická využití. Teď nám půjde právě a především, jak je zřejmé i z nadpisu, o meta model on tologie. Jednoduchou definici tohoto pojmu jsme již uvedli v úvodu práce, slouži la především k odlišení ontologie, jejího modelu a meta modelu. Teď je čas na de finici podrobnější:

meta model ontologie Ontologickým meta modelem rozumím souhrn toho, co ontologie dokáže popsat a jak může fungovat. Tedy její vyjadřovací schopnosti, bez ohledu na konkrétní obsah. Třeba to, jaké datové typy podporuje v roli atributů, jaké typy vztahů zná, zda umí pracovat s pravidly a jak jsou pravidla definovaná, jaké typy dědičnosti podporuje a tak dále. Jde tedy v zásadě o souhrn para metrů struktury. Kromě parametrů struktury nás budou zajímat také různá funkční a procesní hlediska – jakým způsobem lze ontologii utvářet, mo difikovat, jak se dozvídat o změnách v ní prováděných apod. To bude ale námětem další části.

Je možné, že některé parametry vyvolají spory, zda ještě vůbec jde o ontologii. To ale nepovažuji za důležité – vede mě účelnost. Ať již to pořád ještě jsou ontologie nebo ne, rád bych položil základ flexibilní, univerzálně použitelné knihovny pro práci právě s takovými daty – ať již to ontologie je nebo není. Z klasických meta modelů ontologií přinejmenším vycházím.

A.1 Koncepty a instance Začněme klíčovou položkou struktury – koncepty a instancemi. Co je to koncept?

114


koncept Podle [HMC00] je to všeobecná myšlenka nebo pojem, odvozená ze specifických příkladů nebo výskytů. Něco zformulovaného v mysli, myšlenka nebo představa. V souvislosti s ontologiemi tato definice docela dobře odpovídá. Mohli bychom ji možná pouze lehce pozměnit a to tak, že jde o formální vy jádření všeobecné myšlenky nebo pojmu. Koncept je také docela blízký pojmu třída ze slovníku objektově orientovaného návrhu a programování.

instance Podle stejného slovníku je to případ, příklad nebo výskyt. U ontologií jde opět o formalizaci informace o takovém výskytu v re álném světě. A opět můžeme sledovat podobnost s pojmem z objektově orien tovaného programování, ten je pro jednoduchost opět instance nebo též objekt.

1.1 Dilema instance V případě objektově orientovaného programování technologie jednoznačně vyža duje takové jasné a jednoznačné rozlišení. Nelze mít objekt, který je zároveň tří dou a pokud se to někomu nelíbí, musel by kompletně změnit programovací jazyky a související nástroje. U ontologií je rovněž běžné takové rozlišení. Podobný je i postup budování on tologie – nejprve se stanoví koncepty, vztahy dědičnosti mezi nimi, pak další vztahy (agregace, ale také třeba synonyma nebo podobnosti – podle možností konkrétního ontologického meta modelu a potřeb řešeného případu). Až poté je čas pro zakládání instancí. Uvedená struktura i postup mají určitý reálný základ v charakteru světa – pouze postup poznávání je spíše opačný. Okolo nás jsou instance. Pokud ty shrneme do určitých kategorií podle podobnosti, vlastně nadefinujeme koncepty.

115


1.1.1 Problémy rozlišení konceptů a instancí Jak jsem ale uvažoval nad možnostmi aplikace ontologií do prostředí elektronické komerce, postupně ve mně začalo hlodat podezření, že takové jednoznačné a ostré rozlišení může být spíše kontraproduktivní. Vezměme si zboží v elektronickém obchodě, třeba televizi. Je zřej mé že televize je koncept, je subkonceptem „bílé elektroniky“, ta je subkonceptem elektroniky a tak dále. Televize může mít další hie rarchii konceptů pod sebou – digitální televize, nebo třeba podle typu obrazovky (CRT, plazma..) Dejme tomu že TV Oravan je konkrétní model klasické televize. Nuže, zaveďme ji jako instanci. Jako příklad, se kterým budu i dále pracovat jsem si půjčil slavný model Tesly, vyráběný v letech 196062: Dvanáctikanálový televiz ní přijímač superhet s mezinosným zpracováním zvuku dle normy OIRT (6,5 MHz). Obrazovka s úhlopříčkou 35 cm, na přední stěně vlevo knoflíky pro ovládání hlasitosti s vypínačem sítě, tónová clo na, vpravo přepínač kanálů a dolaďování. Pod spodní hranou regulátor kontrastu, řádkového a snímkového kmitočtu, jasu. Na zadní stěně přípojka pro dálkové ovládání jasu a hlasitosti, regulátor zaostření, vyjasňovač, výška obrazu a linearita. Přijímač vyšel z předchozího typu 4102U Mánes, jedná se o první televizor z Tesly Orava vlastní koncepce. První provedení mělo ochranné sklo před obrazovkou s šípovitým tvarem směrem dolů, u poslední série bylo sklo již obdélníkového tvaru a bylo možno ho jedno duchým způsobem vyjmout při čistění od prachu. Přijímač ve své době patřil k nejlevnějším na trhu, stál 2600, Kčs, pro porovnání televizor Lotos z Tesly Pardubice s úhlopříčkou 53 cm, moderní konstrukcí s plošnými spoji, vychylovacím úhlem 110 stupňů a dál kovým ovládáním stál v téže době přes 4000, Kčs. [ORAVAN]

U objektového návrhu by nám ani mnoho jiných možností nezbylo. Téměř jistě by se nám nechtělo definovat a udržovat třídy pro jednotlivé nabízené modely – vytvoření nové třídy znamená zásah do programového kódu a určitě není dobrým nápadem běžně takto program upravovat, co víc, mnohdy ani nemáme k dispozici zdrojové kódy. Jak již bylo naznačeno, u ontologií bychom možná postupovali stejně – vytvořili bychom instanci TV Oravan. Vše by fungovalo k plné spokojenosti. Až najednou... 116


Výrobce uvede nepatrně modifikovanou verzi TV Oravan+. Jak se s tím vyrovnáme? Bude třeba ručně přenést veškeré údaje o TV Oravan do této inovované instance a těch pár detailů změnit. Co hůř, pokud výrob ce změní nějaký parametr u celé řady Oravan, bude třeba provést dvojí zásah – upravit jak původní, tak i novou instanci. To je špatné – je to důsledek nepodchyceného vztahu dědičnosti mezi původní a plusovou verzí. Zdálo by se, že řešením v takovém případě je vytvořit nějakou su binstanci instance TV Oravan. To ale nelze – do vztahů dědičnosti mohou vstupovat pouze třídy (koncepty). U objektového návrhu bychom se s tím museli smířit. V případě on tologií by byl problém menší – přeci jenom tvorba ontologického konceptu není takový zásah do vlastního programu jako vytvoření nové třídy... ...takže bychom možná povýšili Oravan na koncept a přidali bychom instance původních modelů a od subkonceptu Oravan+ bychom odvodily instance modelů novějších. TV Oravan je totiž spíše koncept – množina televizorů charakteris tických rysů.

Oravan

Oravan+

Nebo trochu jiný problém. Například konkrétní konkrétní Oravan Oravan+ jedna konkrétní televize je v něčem výjimečná – má nedopatřením neob vyklou barvu, je trochu kazová, prostě jiná, ale jinak stále ten stejný Oravan. V takovém případě by se nám asi nechtělo vyvářet specifický koncept a pak instanci, asi bychom věc vyřešili nějak provizorně. Nevím, zda se mi to úplně podařilo, ale snažím se naznačit, že dělící linie mezi konceptem a instancí (stejně jako třídou a instancí) nemusí být úplně ostrá. Pokud bychom postupovali cestou maximální návrhové čistoty, instancemi by byly vždy 117


až konkrétní kusy. Na druhou stranu, takové řešení může v reálných aplikacích působit trochu těžkopádně a udržování příliš mnoha konceptů leckoho odradí – a tak se skončí opět u řešení, kdy za instanci bude považováno něco, co je spíše konceptem. V praxi se spíše vychází z potřeb konkrétní aplikace. Aplikace udává konkrétní měřítko pohledu; pokud se podíváme blíž (v důsledku situace, která byla při návr hu opomenuta), možná to, co jsme donedávna považovali za instanci budeme muset prohlásit za koncept. Záměrně jsem vybral příklad z reálného hmotného světa, kde se obecně má za to, že je jasné, co je instance a co koncept. V jiných případech, při definování abs traktnějších pojmů by mohla být situace podstatně složitější: Třeba v prostředí hostingových služeb co je instance? Služba, standard či protokol? Jeho verze? Konkrétní program, který rea lizuje službu? Konkrétní instalace tohoto programu? Nasazení pro konkrétního zákazníka? Všechno? Nebo nic? A je to vůbec důležité? Odpověď, myslím, nemůže být jednoznačná. Prostě jako lupa – záleží na podrobnosti pohledu.

1.1.2 Řešení těchto problémů Je možné úplně se nějak vyhnout naznačeným komplikacím? O objektového programování nelze jinak než postupovat jak bylo popsáno, prostě není na výběr. Ontologický meta model ale není tak striktně omezen, abychom se nemohli za myslet nad vhodným řešením. Vlastně se jej snažíme navrhnout, tudíž na výběr máme – můžeme striktně a napevno oddělit koncepty a instance tak jako je to v objektovém meta modelu, anebo to nedělat. Jak by vypadalo řešení bez takového důsledného rozlišení? Vraťme se k příkladu s televizi. Půjdemeli po stopách dědičnosti, zjistíme, že subkoncepty se od rodičů vyhraňují několika způsoby: 1. přidávají nové sledovatelné vlastnosti U elektroniky můžeme sledovat třeba spotřebu

118


2. nově stanovují nebo upřesňují hodnotu nějaké vlastnosti zavedené dříve v hierarchii dědičnosti (a to je v objektovém programování mnohem méně reflektovaná skutečnost) Dokonce můžou některé vlastnosti či vztahy rušit, což ovšem při nese spoustu dalších problémů. K tomu se ještě vrátíme.

Například pokud všechny televize v našem sortimentu mají záruku 2 roky, můžeme naplnit hodnotu vlastnosti záruka (kterou s sebou koncept nese již od nadřazeného konceptu zboží) konkrétním údajem. 1.1.2.a Odvozené rozlišení konceptů a instancí

Dejme tomu, že nebudeme explicitně rozlišovat koncepty a instance. Čím se bu dou technicky lišit jejich formální odrazy v ontologii? Myslím že tím, zda konkrétní odraz (entita v ontologii) má anebo spíše zda může mít vyplněny všech ny hodnoty, pokud jsou u ní sledovatelné. U konkrétní instance totiž můžeme o každé vlastnosti prohlásit jedno z následují cího: •

jakou má vlastnost konkrétní hodnotu

•

případně že nevíme, ale v principu můžeme zjistit

•

že taková hodnota nelze sledovat (třeba barva očí u televize – je to spíše známka chybného návrhu)

Možná vám to připadá stále jako nepříliš jasné rozlišení – u konceptů přeci také víme nebo nevíme. Ale u nich připadá v úvahu ještě čtvrtá možnost: •

hodnotu sice lze teoreticky sledovat, ale nejsme v principu schopni jedno značně ji stanovit

Je to sice na první pohled drobná nuance, ale pokud přidáme možnost stanovit, jakým způsobem je hodnota neznámá, bude možné podle uvedených pravidel au tomatizovaně usuzovat, zda je entita konceptem nebo instancí na dané úrovni po drobností. Klíčovým přínosem takového řešení bude zjednodušení návrhu ontologie – nebu de třeba zkoumat, co je koncept a co instance a řešit naznačená dilemata mezi jednoduchostí návrhu a konceptuální čistotou. Pokud se časem zjistí, že něco, co 119


bylo doposud považováno za instanci je z nového pohledu vlastně spíše koncept, bude stačit doplnit pouze příslušné atributy nebo jejich hodnoty a... to bude vše. Takové odlehčené řešení zvýší flexibilitu návrhu. Za zmínku stojí i to, že ne všechny běžné ontologie podporují instance – vystačí si pouze s koncepty. Možnost explicitně rozlišit koncepty a instance bych se ale neodvažoval úplně za tratit. Zabudoval bych ji do systému pouze jako jednu variantu meta modelu. Tak bych tedy prozatím uzavřel dilema instance.

1.2 Entity Koncepty a instance budu dál víceméně shrnovat pojmem entity.

entita Slovník [HMC00] definuje jako „něco, co existuje jako určitá a dis krétní jednotka, fakt existence, bytí, existence něčeho, zvažována oddě leně od jeho vlastností“. V našem meta modelu ontologie je jejím zá kladním stavebním prvkem. Shrnuje obvykle rozlišované koncepty a instance.

primitiv Slovník definuje jako „neodvozený od ničeho jiného, základní, výchozí nebo původní“. Typickým primitivem v geometrickém významu je bod. Opět, ontologický význam docela odpovídá – jsou to ty entity, které jsou na vrcholech hierarchií, nejsou definovány jinými entitami.

agregovaná entita Je entita v konkrétním těsném vztahu k jiné entitě – je její součástí. Agregovaná entita nemůže existovat samostatně bez entity, se kterou je svázána. V případě profilu s explicitním rozlišením konceptů a instancí můžeme rozlišovat ještě:

120


konkrétní koncept Koncept, od kterého mohou být odvozovány instance.

abstraktní koncept Koncept, od kterého nemohou být odvozovány instance, pouze subka tegorie. Ať již bude meta model jakýkoliv, s budováním slovníku se může začít kdekoliv; případné nezávisle vznikající jednotlivé stromy se postupně pospojují, a tak dají vzniknout výsledné ontologii.

1.3 Hodnotnost, umístění, externí zdroje Již dříve jsme rozlišovali ontologie podle toho, zda je v nich zachycena vlastní doménová informace anebo zda pouze popisují nebo nějak organizují informace uložené v jiné podobě.

1.3.1 Samohodnotná ontologie Zvolil jsem takové trochu podivné slovo, protože jsem neobjevil žádné známé, které by dostatečně vyjadřovalo potřebnou myšlenku. Samohodnotná ontologie má hodnotu sama o sobě. Samozřejmě nemám na mysli, že by musela mít hodno tu bez systému vybudovaného okolo ní nebo dokonce bez uživatelů. Obejde se ale bez vazeb na nějaké externí informace. Sice odráží reálný svět, ale nemá vazby na jiný meta svět – svět dat, informací, dokumentů, databází, médií... Anebo pokud takové vazby má, nejsou klíčové, obraz pouze doplňují.

1.3.2 Meta ontologie Jsou ty ontologie, které byly vybudovány nad jinou datovou základnou – sadami dokumentů, multimédií, textů.. Bez jimi popsané základny nemají téměř žádnou hodnotu. Tato základna je primární. Pokud ji odstraníte, můžete s klidným svě domím zlikvidovat i celou ontologii. Meta ontologie popisuje, charakterizuje, ka tegorizuje, katalogizuje nebo jinak uspořádává externí data. Typickým příkladem jsou tématické mapy (topic maps). Je zřejmé, že hranice mezi těmito typy ontologií není ostrá a nejběžnějším přípa dem bude kombinace – ontologie ponese část samohodnotného obsahu a z části se bude odkazovat na externí zdroje. Každopádně meta model musí počítat s 121


možností takového napojení. Musí umožnit definici vazeb na celé dokumenty (nebo jiné datové zdroje), ale také na jejich části – konkrétní odstavce, obrázky, položky v databázích apod.

1.3.3 Parametry řešení Bude jistě vhodné zvážit možnosti jazyka XML, především standard [XPATH], případně novější [XLINK] nebo některý jiný. Při implementaci bude rovněž vhodné čerpat inspiraci z široké oblasti téma tických map. Vážně pojatou specifikaci tématických map vypracovalo konzorci um TopicMaps.Org [XTMSPEC]. Jako úvod do problematiky je asi nejlepší článek [PEPP02], který sepsal spolutvůrce již zmíněné specifikace Steve Pepper a možná také článek [GARS02].

externí entita Tak nazveme externí datový zdroj, který byl propojen s ontologií. Zdroje mohou být mnoha různých typů, například: •

textové dokumenty všech možných formátů (HTML, RTF, PDF, XML, neformátovaný text...), to vše v různých kódováních a znakových sadách)

•

obrázky

•

zvukové záznamy

•

videosekvence

•

databáze (relační, objektové, XML..)

kvalifikované vazby Ať již bude uznán za vhodný kterýkoliv standard (což by měl být vždy upřednostňovaný postup), řešení které bude nakonec vybráno musí především podporovat kvalifikované vazby.

122


I u odkazů na externí zdroje musí být možné stanovit, v jaké roli je ex terní zdroj vůči ontologii, z níž je odkazováno, nebo lépe přímo vůči konkrétní její entitě. Tedy, zda ontologickou informaci pouze doplňuje, rozšiřuje, přidává nějakou alternativu anebo naopak, zda jde o zdroj primární a ontologie jej pouze popisuje, obohacuje o další souvislosti apod.

celek i části Vazby mohou propojovat ontologii s celým dokumentem, databází, videosekvencí.. anebo pouze s konkrétním odstavcem, vloženou tabulkou, databázovým záznamem, časovým výsekem videa apod. Takové propojení bude vyžadovat určité porozumění struktuře pod porovaných externí dat.

1.4 Hierarchie Hierarchizace v ontologii může být postavena na dvou paralelně využívaných principech.

1.4.1 Kategorizace Umožní volnější definici hierarchie. Definují příslušnost entit k hierarchickém systému kategorií. Kategorizace je realizována vztahy kompozice. Vhodným příkladem kategorií jsou rubriky v časopise nebo na něja kém publicistickém webu. Články jsou si více méně podobné, parametry, které u nich můžeme sledovat určují, že jsou součástí stejné třídy entit. Bavímeli se o hi erarchii, jde pouze o to, do jaké přihrádky je redaktor přiřadil. Příslušnost ke kategorii tedy nezpřesňuje atributy kategorizované entity a ani ne definuje nové. Ani nevymezuje hodnoty atributů stanovených u předků v hierar chii dědičnosti. Kategorie toho mnoho neumí. Ale mají podstatnou výhodu – jsou jednoduché; na rozdíl od dědičnosti nepřinášejí žádné zásadní komplikace, a to ani když jednu entitu zařadíme do více kategorií.

kontext Kategorie mohou pěkně definovat kontext. 123


Pěkným příkladem může být zařazení různých entit ontologie pro poskytování hostingových služeb do kontextu hostitele a zároveň do kontextu služby. Každá taková zaškatulkovaná entita bude patřit jak ke službě, tak k hostiteli, byť nebude ani samotnou službou a ani hostitelem. V této souvislosti je zřejmé, že pro kategorii by mělo být možné de finovat, do kolika kategorií jednoho typu (třeba typ hostitel) může jedna entita patřit.

kruhy Když uvažujeme o kategoriích jako o analogii přihrádek, je zřejmé, že jejich hierarchie bude mít rysy stromu – kategorie může mít subka tegorie a tak až do v zásadě libovolné hloubky. Vzniká otázka, zda nás taková analogie zbytečně neomezuje – mohly by být ve vztazích virtuálních přihrádek kruhy? Tedy že by jedna kra bička byla zároveň v první i ve druhé zásuvce? Přemýšlel jsem nad tím a žádný zásadní problém nevidím – zkusme tedy povolit i kruhy.

identita Jako praktická se jeví možnost definovat mechanismy jednoznačné identifikace entity v rámci kategorie. Podobně by bylo praktické umožnit definovat pravidla identifikace entity v rámci hierarchie dědičnosti.

1.4.2 Dynamická kategorizace Kromě explicitního zařazení do kategorie bude praktické podporovat automatické zařazení na základě kategorizačního pravidla. Vyhodnocením pravidla budou za běhu entity přiřazeny do kategorií a poplynou z toho pro ně a pro kategorii stejné důsledky, jako kdyby bylo přiřazení explicitní. Při navrhování této funkce jsem se inspiroval především zpětnými kategoriemi v systémech wiki. V úvahu připadají například tyto varianty:

podle výskytu Každá entita, která disponuje zvoleným atributem nebo kombinací atributů, bez ohledu na jeho hodnotu, patří do vybrané kategorie. 124


Například cokoliv s vlastností „výhřevnost“ může být automaticky zařazeno do kategorie „palivo“.

podle hodnoty Každá entita, jejíž konkrétní vlastnost má konkrétní hodnotu patří do vybrané kategorie. Cokoliv s vlastností „vyžaduje elektřinu“ a hodnotou „ano“ může být považováno za „elektrický spotřebič“. Dále bychom mohli zmínit kategorizaci na základě vazeb s jinými entitami, na zá kladě postavení v hierarchii dědičnosti... a samozřejmě kombinace všeho uve deného.

1.4.3 Dědičnost, nejprve obecně Zachycuje těsnější a ve svých důsledcích mnohem komplikovanější vztah než kategorizace. Článek je druhem publikace. Stejně tak je dokumentem. Vztahem dědičnosti entita nabývá anebo může nabývat atributy entity, od které dědí. Nejprve stručně shrnu, co je pro nás teď podstatné a zamyslím se především nad dalšími důsledky a dilematy, které dědičnost přinese.

třída, rodič Je entita, která ve vztahu k jiným entitám vystupuje nebo může vystu povat jako nadřazená ve vztazích dědičnosti. Vztahy třídapotomek realizují dědičnost.

přejímání atributů V objektově orientovaného návrhu je běžným zvykem, že potomek zdědí veškeré vlastnosti předka. Podobný mechanismus by měl podpo rovat navrhovaný meta model. Pokud entita zboží definovala atribut záruka, pak odvozená entita elektronika jej přejala.

přejímání hodnot atributů U objektů trochu méně řešený efekt dědičnosti. 125


Pokud všechny naše televize mají záruku dva roky, není nic systé movějšího než vyplnit hodnotu atributu záruka u entity televize a nikoliv třeba až u jednotlivých modelů. Konkrétně by přejímání mělo fungovat tak, že za hodnotu atributu spe cifické entity bude považována první nalezená hodnota tohoto atributu při procházení hierarchií nahoru směrem k obecnějšímu maximálně až k entitě, která atribut zavedla. Je zřejmé, že pokud entita explicitně definuje hodnotu atributu, hledání se zastaví u ní. Pokud naopak nebude hodnota nalezena až k definující entitě (k té, u které se atribut poprvé objevil), atribut bude mít nedefi novanou hodnotu.

televize záruka: 2r napájení: ano sériové číslo: ? spotřeba: ? obrazovka: ? digitální: ?

elektronika záruka: ? napájení: ano sériové číslo: ? spotřeba: ?

TV Oravan záruka: 2r napájení: ano sériové číslo: ? spotřeba: 20W obrazovka: 35 digitální: ne

126

zboží záruka: ? napájení: ?

TV Oravan e.č.154 záruka: 2r napájení: ano sériové číslo: as4-45 spotřeba: 20W obrazovka: 35 digitální: ne


1.4.4 Dědičnost vícenásobná

násobnost dědičnosti Násobnost dědičnosti vyjadřuje, kolik přímých předků může mít jedna entita. Jednoduchá násobnost povoluje maximálně jednoho přímého předka, vícenásobná jich povoluje více. Zda povolit i násobné vazby, to je docela složitá otázka. Odpověď záleží na váze, jakou přiřadíme jednotlivým kritériím – především flexibilitě plynoucí z ná sobnosti a jednoduchosti a přehlednosti návrhu v případě jejího zakázání. 1.4.4.a Potřebujeme ji?

Ve světě OOP také není odpověď jednoznačná. Například jazyk C++ podporuje vícenásobnou dědičnost, zatímco novější Java pro třídy nikoliv. Osobně zastávám názor, že zde převažují spíše negativa násobnosti (vyšší složitost a také některé z problémů naznačených níže), k čemuž mě vedou i zkušenosti s uvedenými jazyky, z poslední doby především zkušenosti s návrhem pro jazyk Java. Je prav da, že občas jsem skončil s trochu nečekaným návrhem, ale vždy jsem se bez ná sobných vztahů dědičnosti obešel a výsledný program je díky tomu i snáze spravovatelný. U ontologie si zbytečností vícenásobných vztahů dědičnosti zdaleka tak jistý nejsem. Ontologie vidím jako velice flexibilní datovou strukturu, jako prostředek zachycení vztahů a souvislostí světa. Jako takovým by jim, myslím, absence možnosti násobné dědičnosti docela uškodila. Okolo sebe totiž vidíme příklady takového vztahu na každém kroku. S podporou vícenásobné dědičnosti bude také mnohem snadnější ontologie propojovat. Vyhneme se také některým zjednodu šením, která musíme přijímat při objektovém návrhu: Vraťme se třeba k příkladu s televizí. Definovali jsme hierarchii zbožíelektronikatelevize. Vztah elektronikatelevize je v pořádku, televize je elektronika. Taktéž zbožíelektronika – prodáváme elektroniku, tak elektronika je pro nás zboží. Pokud ale opustíme omezené prostředí našeho elektronického ob chodu a budeme chtít využít ontologii jako slovník pro domluvu s cizími partnery anebo obecně s kýmkoliv, narazíme na problém. 127


Z jejich pohledu televize zbožím být nemusí. V ta nelze univerzálně sdílet žádnou část kovém případě nebudou souhlasit s naší ontologií zboží elektronika jako sdíleným komuni televize kačním jazykem, protože vazba zbožítelevize by na rušila vnímání světa jejich TV Oravan informačním systémem.

Jaký z toho plyne závěr? Ve sdílené ontologii by měly být zachyceny pouze takové vztahy, které platí dosta tečně univerzálně. Vztahy subjektivní musí být odděleny. Pokud nepovolíme vícenásobnou dědičnost, těžko vyřešíme náš problém ke všeo becné spokojenosti. Řešení nabízí vícenásobná dědičnost. Hierarchii díky ní bu deme moci přetransformovat tak, aby univerzálně platné entity nedědily nic od entit subjektivních. Takový stav je totiž jasnou známkou neuniverzálního návrhu. Řešení s vícenásobnou dědičností:

univerzální definice => lze sdílet elektronika televize

zboží TV Oravan

128


1.4.4.b Komplikace vícenásobné dědičnosti

Takové řešení vypadá komplikovaně (a komplikovanější skutečně o trochu je), ale umožní sdílet ontologii s kýmkoliv, což za to myslím stojí. Koneckonců zboží a televize jsou jiná hlediska charakteru entity TV Oravan, a tak by měly patřit do různých hierarchií. Vícenásobná dědičnost ale přináší i potíže – kdyby tomu tak nebylo, asi by např. v návrhu jazyka Java nechyběla. Některé z těch, které souvisí s již prozkoumaný mi tématy zmíníme, o dalších se zmíníme na patřičných místech:

potíže při přejímání atributů V hierarchii se vyskytne více atributů stejného jména, ale jiného typu. Vzniká otázka, jak situaci řešit. Jedna možnost je povolit stejně pojmenované atributy a následně podle vkládané nebo žádané hodnoty (jejího datového typu) určovat, o kte rým atribut je právě zájem. Atributy by byly jednoznačně identifiková ny nejen svým jménem, ale kombinací jména a typu. Navržený postup můžeme nazvat přetěžování atributů. Potíže ovšem nastanou, pokud průnik hodnot přípustných pro použité datové typy nebude prázdný. Je zřejmé, že přetěžování atributů takovou situaci nevyřeší. Dalším možným postupem by bylo nadefinovat pravidla pro pře krývání atributů. Na základě postavení v hierarchii, příslušnosti konkrétní ontologii nebo datového typu určovat, který atribut má mít přednost a který má být u potomků ignorován (nezděděn). Je tady ještě jedna možnost. Jde o mechanismus, který přinutí vývojáře (návrháře ontologie) situaci v každém konkrétním konfliktním případě explicitně vyřešit – stanovit, co se zdědí a co ne. Obě poslední řešení jsou sice univerzálnější než řešení první, ale situa ci komplikují zase jiným způsobem. Pokud se totiž pro jedno z nich rozhodneme, zaplatíme za to cenu v podobě ztráty jistoty. Nebudeme totiž moci prakticky nic s jistotou prohlásit o jen trochu vzdálenějších potomcích. Veškeré zděděné atributy se totiž mohou v další hierarchii poztrácet.

129


potíže při přejímání hodnot Přestavme si situaci, kdy jeden atribut nabude v hierarchii různých hodnot. V případě jednoduché dědičnosti to není problém – způsob stanovení aktuální hodnoty je jednoznačný a byl popsán výše. Násobná dědičnost ale věci komplikuje. Problém si můžeme přiblížit, když se zmíníme o tom, k čemu může taková dědičnost vést u jazyků OOP, konkrétně v jazyce jako C++. Tady je třeba zbystřit kdykoliv dojde k uzavření kruhu v hierarchii. Proměnné třídy na nejvyšší úrovni hierarchie v kruhu jsou pak tří dou nejnižší zděděny vícekrát, u jednoduchého kruhu konkrétně dvakrát, a to pod stejnými jmény. Více o problému se dozvíte třeba v kurzu C++ [CPPKURP00] v časopise Progres.

U navrhované ontologie můžeme vytvořit mechanismus, který se vy rovná s takovým kruhem, kdy v kritické části (na obrázku zvýrazněné) nedojde k redefinici atributů a jejich hodnot. V takovém případě je v rámci celého kruhu sdílena hodnota z nejvyšší části kruhu a její redefi nice v nejnižší části problémy také nezpůsobí. Pokud ale dojde v kri tické části ke změně, nelze použít žádný obecný postup pro zjištění hodnoty vespod kruhu – můžeme volit kteroukoliv cestu vedoucí kri tickou částí kruhu a cesty jsou rovnocenné. Při jednoduché dědičnosti není žádný problém: a:? a:5 a:[5]

směr hledání hodnoty

Ale tady nevíme, zda vybrat pětku nebo sedmičku:

130


a:5

a:? a:7

a:nelze zjistit

směr hledání hodnoty

Žádné zázračné řešení asi neobjevíme. Některá z řešení naznačených v předchozí části, mírně upravená můžeme uplatnit i zde – asi nelze zva žovat přetěžování, protože už z definice problému jde o atributy stejných typů. Můžeme ale stanovit pravidla pro automatický jedno značný výběr cesty, anebo zajistit, aby návrhář taková pravidla nadefi noval, případně vždy cestu explicitně zvolil. Oproti přejímání atributů zde nehrozí, že bychom se některým z řešení připravili o jistotu, že potomci budou disponovat zděděnými atributy. Nejistota zde ale také je – nevíme, zda potomci budou mít stejné hodnoty zděděných atributů. Obecně se ale s možností redefinice počí tá i u hodnot jednoduché hierarchie, ale pokud by náš zvolený model podporoval finální atributy (s hodnotami neměnnými v rámci hierar chie), potíže by zjevně nastaly. Vícenásobná dědičnost, stejně jako v OOP, i v ontologiích přináší vyšší složitost a potíže. Na druhou stranu výrazně zvyšuje jejich vyjadřovací schopnosti. Proto by měla být v různých variantách podporována jako jedna volba nastavení meta modelu, nikoliv povinně. Podle konkrétní aplikace bude třeba posoudit, zda převáží spíše výhody anebo komplikace...

131


A.2 Atributy V předchozí části jsme již zkoumali, jaký vliv na vlastnosti (atributy) entit bude mít hierarchizace, především dědičnost. Ještě jsme se ale příliš nezamýšleli, co jsou atributy vlastně zač..

koncept atributu Primitivní, ale plnohodnotná komponenta ontologie. Skládá se z povinných komponent názvu a datového typu a volitelně může být doplněn o vysvětlující popisek. Od jednoho konceptu může být odvozeno libovolně mnoho instancí atributu.

hodnota atributu Konkrétní hodnota (datová položka) či předpis pro její odvození, při řazená konkrétní instanci atributu.

instance atributu Potomek konceptu atributu, tvoří ji především trojice komponent: ná zev, datový typ a hodnota, volitelně popiska. Je přiřazena konkrétní en titě, vazba mezi entitou a atributem není rovnocenná – instance atribu tu entitě patří. Jedna instance atributu patří právě jedné entitě.

název atributu Název atributu nelze nikde v hierarchii měnit, protože slouží jako identifikátor. Povoleny jsou pouze znaky anglické abecedy, čísla, po mlčky a podtržítka.

popiska atributu Nepovinný údaj, umožňuje uživatelsky srozumitelnějším způsobem popsat význam atributu. Může být delší, obsahovat znaky národních abeced a může být také lokalizovaný do více jazyků (viz literál níže).

identifikátor atributu Atribut je jednoznačně identifikován názvem, v případě přetěžování názvem a datovým typem.

132


atribut

hmotnost :kilogramy :0

PDA Zaurus entita

instance atributu

hmotnost:0,17

V dalším textu pokud budu mluvit o atributu, budu mít na mysli koncept atributu, případně instanci atributu.

2.1 Doména Doména určuje, jaké datové položky jsou přípustné v roli hodnot atributu a také význam těchto hodnot.

2.1.1 Datový typ I zde je to, co je pod tímto pojmem běžně chápáno – určitý způsob definice množiny přípustných hodnot. Definice může být provedena výčtem všech možných prvků anebo předpisem, který nějak omezuje množinu nadřazenou. Část hierarchie předpisem definovatelných typů neboli množin povolených hodnot může vypadat třeba takto: string numeric integer real ...

133


Způsob definice podtypů nelze stanovit univerzálně – podtypy číselných hodnot budou dány matematickým předpisem (třeba sudá čísla jako dělitelná dvěma), podtypy v řetězcové hierarchii zase regulérními výrazy. Pouze stanovení výčtem je dostatečně univerzální z hlediska typů, na něž je lze aplikovat. Navrhovaný systém by měl obsahovat kvalitní, univerzálně použitelnou hierarchii typů. Vedle toho by mohly vznikat ontologie oborových typů. Konečně, úplně specifické typy si navrhne sám uživatel / tvůrce ontologie. Smysl je jasný – typ by měl být schopný pojmout veškerá omezení povolených hodnot, aby nebylo třeba vymýšlet další omezující mechanismy.

uživatelský typ Například takto by mohla vypadat definice specifických typů z ob lasti webhostingu; upozorňuji že jde jen o příklad, opravdové defini ce by měly být deklarovány specifičtěji a měly by to být skutečné regulérní výrazy a ne tyto napodobeniny: domain

a-zA-Z0-9.a-zA-Z

email

a-zA-Z0-9@{domain}

ipaddress

0-255.0-255.0-255.0-255

dnsrecord

a-zA-Z0-9 'CNAME'|'A' {ipaddress}

Za zmínku stojí druhý a poslední příklad – ukazuje možnosti kompozice typů. Přesné mechanismy kompozice budou specifické pro jednotlivé hierarchie typů, zatím se jimi více zabývat nebudeme. Podotýkám rovněž, že kompozice datových typů je něco jiného než komplexní datové typy popsané dále.

jednoduchý typ Hodnota má maximálně jednu datovou položku. Datová položka odpo vídá typu. Příklad: typ domain: www.evidence.cz

komplexní typ Je datový typ složený z dalších typů. Odpovídající atribut má maxi málně tolik datových položek, kolik dílčích typů zahrnuje jeho komplexní datový typ a každá datová položka odpovídá příslušnému 134


dílčímu datovému typu. Každá položka je kvalifikovaná identifikáto rem dílčího typu. Dílčí datové typy se mohou lišit. Mohou být jedno duché, násobné, komplexní i komplexní násobné. Příklad: typ osobnijmeno (jmeno:string, prijmeni:string): jmeno Jan prijmeni Novák

násobný typ Kterýkoliv typ, jednoduchý i komplexní, může být použit na místě uži tí jako násobný nebo může sloužit jako základ pro definici explicitně násobného typu – např. typu emails. Hodnota má minimálně m a maximálně n datových položek. Pokud není stanoveno jinak, číslo m je rovno nule a n nekonečnu a je tedy přípustný jakýkoliv počet položek. Všechny datové položky odpovídají typu atributu. Příklad: typ email: [email protected], [email protected] V úvahu připadají též speciálnější možnosti omezení kardinality, obecně dané předpisem. Díky tomu by bylo možno povolit například pouze sudé počty datových položek (třeba seznam účastníků soutěže manželských párů). U násobného typu navíc může být anebo nemusí být důležité pořadí.

množina synonym Speciální typ, umožňuje zachytit více položek, ale položky jsou pova žovány pouze za jiná vyjádření téhož. Vychází z jiného datového typu, v praxi asi nejspíše řetězcového.

mapa Speciální typ, seznam dvojic klíč a hodnota, obdoba hashovacích tabulek známých například z jazyka Java. Jednotlivé položky lze vklá dat pouze v kombinaci s klíčem a přístup k nim bude opět přes klíč.

135


statická mapa Je taková mapa, jejíž klíče jsou definovány jednou provždy a od defi nice nemohou být měněny. Měnit se mohou pouze hodnoty ke klíčům přiřazené.

dynamická mapa Taková mapa, která může měnit nejen hodnoty, ale i své klíče, pří padně při definici mohou být klíče opomenuty úplně a naplní se až po užíváním.

literál V zásadě pouze speciální případ mapy, typu string a s klíči v podobě kódů jazyků. Umožní vytvářet lokalizované verze textových údajů.

kořenový typ Veškeré typy budou vycházet z univerzálního kořenového typu. Díky tomu bude snadné implementovat například netypové atributy – jejich typem bude právě tento kořenový typ.

2.1.2 Relevance Zatímco datové typy jsou běžné i u konvenčních programovacích jazyků, relevan ce domény je nový pojem. Relevance přidává k datovému typu konceptuální roz měr – udává význam zachycených hodnot. V případě běžných jazyků je třeba význam dodat jiným způsobem, nejspíše programovým kódem. Takové řešení funguje, ale nijak nepomáhá vzájemnému porozumění. Význam datům je přiřazován pokaždé jinak, a tak někdy sám programátor je zmaten a neví, zda vlastnost pojmenovat delka nebo centimetry. Není snadné takové aplikace propojovat. Vždy musí být doplněna vrstva, která zajistí vzájemné porozumění datům, aby se z nich staly alespoň informace. U čí selných údajů musí být doplněno, jaké jednotky jsou používány, u údajů řetěz cových třeba kódování, jindy zase použité šifrovací mechanismy. Taková práce není příjemná. Jsem toho názoru, že ontologie, která má být maximálně věrnou konceptualizací světa, která má podporovat porozumění, a má být sdíleným slovníkem, musí dis 136


ponovat odpovídajícími prostředky. Relevance domény pomůže porozumět da tům. Typickým využitím relevance je definice jednotek centimetrů, kilogramů. Hodnoty atributu s vyplněnou relevancí tak již nebudou anonymní bezrozměrná čísla. Univerzálnost a flexibilita návrhu s využitím relevance bude možná trochu zřejmější, když si uvědomíme, že třeba i běžný datový typ datum lze snadno za chytit jako datový typ číslo s relevancí dny (ve významu počet dní řekněme od 1.1.1900). Relevance je údaj nepovinný – ne vždy má smysl jej udávat.

2.2 Prostředky pro zvýšení robustnosti 2.2.1 Mechanismy vyžádání

volitelné (optional) Výchozí mechanismus, entita i její potomci mohou a nemusí specifi kovat hodnoty.

doporučené (suggested) Do možností ontologie nevnáší žádná pevná pravidla, vyplnění hodnot v celé hierarchii entit je pouze doporučeno. To se projeví například při návrhu varovnými hláškami, pokud není doporučení respektováno. Je věcí konkrétní aplikace, jak bude s nerespektovanými doporučeními zacházet.

požadované (required) Nejvyšší stupeň vyžádání. Každá entita s atributem v nedefinovaném stavu je považována za nevalidní. Doplnění hodnoty je vynuceno. V rámci hierarchie dědičnosti lze mechanismy vyžádání zpřísňovat. Potomek s volitelným atributem může změnit stav vyžádání na doporučení nebo požadavek. Žádný z jeho potomků se již ale nebude moci vrátit ke stavu výchozímu.

137


2.2.2 Mechanismy podsouvání

výchozí hodnoty (default) Pokud je konkrétní hodnota uvedena již při definici konceptu atributu, dostává roli výchozí hodnoty. Odvozené instance ji zdědí místo hodno ty nedefinované. Mohou ji ale explicitně překrýt.

doporučené hodnoty Seznam běžných hodnost atributu, může být sestaven a modifikován kdekoliv v hierarchii (u konceptu i instance), slouží pouze jako po mocné vodítko pro uživatele.

nemodifikovatelné (immutable) Pokud je instance atributu označena jako nemodifikovatelná, nemůže být její hodnota v další hierarchii změněna.

2.3 Odvozený atribut Zatím jsme zvažovali pouze možnost, že instance atributu explicitně specifikuje konkrétní hodnotu anebo je atribut nedefinovaný. Bylo by chybou explicitně evi dovat vlastnosti, které přímo vyplývají ze vztahů a vlastností jiných, již evi dovaných. O důsledcích pro konzistenci takového počínání se dočtete dále v části věnované pravidlům.

Princip je jednoduchý – tvůrce ontologie sestaví na dané úrovni hierarchie místo explicitní hodnoty předpis, na základě něhož bude možné hodnotu odvodit. Opět inspirativní je v tomto směru oddíl o pravidlech, je pouze třeba mít na mysli, že odvozený atribut nebude definovaný pouze na základě predikátů (výrazů o nichž lze prohlásit zda platí nebo neplatí) ale na základě konkrétních hodnot.

V předpise bude možno čerpat informace z vlastností dané entity a jejich hodnot, z vlastností a hodnot entit okolních, z vazeb a jejich účastníků.. Příklad: obsah čtverce: obsah = strana*strana

138


A.3 Vazby Nejjednodušší možné vazby mezi dvěma entitami nedefinují charakter vztahu jsou netypové a neorientované. Přestože i takovými primitivními vazbami by bylo možno vyjádřit mnohem více informací než bez nich, k blízkému konceptuálnímu popisu světa by měla taková ontologie daleko. Přesto – jednou z možností meta modelu by mělo být povolení netypových vazeb – asi bychom nalezli případy, kdy je naprosto klíčová snadnost použití a typy vazeb by znamenaly zbytečnou komplikaci. V dalším textu se budeme zabývat vazbami typovými a zejména orientovanými typovými. Nadefinujeme kostru hierarchie typů vazeb, zamyslíme se nad ná sobností a také třeba nad komplikacemi, které vazbám přináší dědičnost entit.

koncept vazby Je to typ vazby, myšlenka vyjadřující druh a charakter vztahu, nikoliv nějaký konkrétní vztah mezi konkrétními entitami. Existuje jako samo statný prvek ontologie, jednotlivé instance vazeb jsou od něj odvozeny.

jméno vazby Identifikátor typu vazby. Při jeho stanovení si návrhář musí vystačit s písmeny anglické abecedy, čísly, podtržítkem a pomlčkou. V hierarchii instancí vazeb je neměnný.

popiska vazby Pro srozumitelné vyjádření významu vazby, vhodné pro požití v GUI. Mohou být použity znaky národních sad, podpora lokalizace (datový typ literál).

instance vazby Konkrétní vztah mezi konkrétními entitami. Je odvozen od konceptu (typu) vazby. Nemůže existovat samostatně bez zúčastněných entit.

139


účastník vazby Pokud vazbu znázorníme jako hranu grafu, pak účastníky vazby jsou uzly, které vazba spojuje. V ontologii jím může být především li bovolná entita, obecněji ale každý prvek, tedy například i atribut nebo jiná vazba.

atribut vazby Ty informace, které nedokážeme zachytit pomocí prostředků spe cifických pro vazby (jméno, popiska, účastník, role – ta bude popsána dále) můžeme k vazbě připojit v podobě atributů. Atributy mají stejný význam a možnosti jako u entit.

3.1 Orientace a navigabilita 3.1.1 Neorientované Z hlediska orientovanosti jsou zjevně nejjednodušší vazby neorientované. Ty mohou sloužit k zachycení symetrických vztahů, kde všichni účastníci vystupují ve stejné roli. Typickým příkladem neorientované vazby je bratrství – bratři jsou si rovni, každý je bratrem druhému.

3.1.2 Orientované

jednosměrné Mají význam pouze v jednom směru. Myslím že v případě ontologií nemá smysl takové vazby uvažovat.

obousměrné Mají význam v obou směrech, byť podle směru pohledu se jejich cha rakter ve většině případů bude lišit. Obousměrné vazby jsou tvořeny dvojicí inverzních vztahů, kde žádný z nich není nadřazený. Dvojice je vzájemně nerozlučná – pokud existuje jeden vztah, existuje k němu i vztah inverzní. Pokud toto neplatí, nejde o obousměrný vztah. Příklad: rodič – potomek, vlastní – je vlastněno, částí – zahrnuje

140


Neorientované vazby lze implementovat jako orientované, jsou speciální pouze v tom, že jsou tvořeny vazbou, která je inverzní sama sobě.

role Má význam v případě orientovaných vazeb. Je to postavení účastníka v rámci vztahu. Například ve vztahu otcovství vystupuje pan Novák v roli otce a malý Franta v roli potomka. Nebo třeba ve vztahu dědičnosti je je den účastník v roli nadypu a druhý v roli podtypu.

3.1.3 Navigabilita Jde o něco jiného než orientovanost v pravém smyslu. Orientovanost platí na kon ceptuální úrovni – svázané prvky prostě mají nějaký vztah. Navigabilita definuje nebo omezuje možnost tento vztah sledovat. Podle hodnoty navigability zejména bude nebo nebude uživatelské rozhraní nabízet souvislosti při práci s ontologií. Podpora takové funkčnosti není v principu nezbytná, ale zpřehlední ontologii z uživatelského hlediska – uživatel nebude obtěžován nezajímavými souvislostmi, byť budou tyto v ontologii zachyceny pro účely odvozování jiných, již zají mavějších skutečností.

3.2 Hierarchie vazeb Zatím jsme se zamýšleli nad vazbami obecně – nad jejich definicí, parametry apod. Nyní je čas věnovat se trochu specifickým typům vazeb a jejich významu pro ontologii. Rozdělme nejprve možné vazby takto:

3.2.1 Vztahy meta modelu Zahrnují souvislosti mezi parametry meta modelu ontologie. Umožňují zachytit nastavení ontologie, podstatně ovlivňují její vyjadřovací schopnosti. Konkrétní podoba bude předmětem budoucích úvah o meta modelu. Zatím bych zmínil především to, že považuji za užitečné maximum meta mode lových vazeb přenést do modelu samotného, a tak zvýšit jeho univerzálnost a fle xibilitu. Proto v další části najdete i takové typy vazeb, jako isa pro definici dě dičnosti a tvorbu instancí nebo vazbu „je vlastností“ pro připojování atributů, kte ré jsou obvykle vyčleňovány mimo základní hierarchii modelu. 141


3.2.2 Vztahy modelu Do této kategorie patří ty typy vztahů, o které jsme se doposud zajímali pře devším – vztahy použitelné ve vlastní univerzální potažmo i v doménově spe cifické ontologii. Vsadíme je do širší hierarchie, která odhalí zajímavé souvislosti. Když zmiňuji hi erarchii, mám na mysli hierarchii dědičnosti, tedy vztahů isa mezi jednotlivými typy vztahů – ano můžeme sledovat vztah mezi dvěma dalšími vztahy. Zasazení do hierarchie umožní pokládat jak specifické, tak všeobecnější dotazy, obsahující univerzální, všeobecné typy vztahů. Například pokud rodič je nadtyp otec, pak když je někdo otec, je to zároveň rodič atp. Hierarchii nebudu rozvádět do široka – vlastně jde o samostatnou ontologii vztahů a pro něco takového zde není prostor. Naznačím pouze pár vztahů opravdu univerzálních: /vztah / fyzická souvislost / má popis / má vlastnost / má (sou)část / kontext / je (sou)částí (e) / je agregováno (◊) / logická souvislost / isa (^) ~je instancí, je podtypem /je verzí / asociace (→) / alternativa / je implementací (o)

Návrh je třeba chápat pouze jako pracovní a měl by být podroben hlubší analýze, především v souvislosti se vztahovými koncepty de finovanými v uznávaných toplevel ontologiích (SUMO apod.).

Zajímavé bude hledat vztahy inverznosti. I v takto malé hierarchii je v tomto smě ru několik souvislostí, které si zaslouží komentář. Tak předně, vztahy je (sou)částí a má (sou)část jsou vzájemně inverzní. Dále třeba alternativa je 142


typickým příkladem neorientované vazby. Vidíme také, že orientovanost se může v rámci hierarchie vztahů měnit.

3.3 Vazby více prvků Zatím jsme vždy uvažovali vztah dvou prvků (entit, atributu a entity, dvou vazeb). Mohou připadat v úvahu komplikovanější vazby buďto mezi více účastníky kde každý může vystupovat obecně v jiné roli, případně mezi většími počty účastníků, jejichž role jsou totožné?

3.3.1 Multilaterální V reálném světě takové souvislosti jistě existují. Časté a zřejmé je to například u smluv. Smlouva vlastně vyjadřuje vztah mezi subjekty – vzájemné povinnosti a práva, vztah na kterém se smluvní strany dohodly. Smlouva může mít dva účastníky, ale může jich mít i více.

kupní smlouva s ručením

prodávající

kupující

ručitel

Vzniká otázka, jak takové vztahy zachytit. Jsou obecně dvě možnosti, buďto re álnému světu podřídit meta model ontologie a povolit multilaterální vazby:

143


vztahy mezi subjekty explicitní

Jirka prodávající

Tonda kupující ručitel

Franta

Anebo vztah dekomponovat na více vztahů jednoduchých a přímé vztahy mezi účastníky odvozovat na základě pravidel:

Jirka Tonda smlouva

vztahy mezi subjekty odvozeny pravidlem

Franta

Účastníky jsme nahradili jejich konceptuálním odrazem, smlouva je zachycena v podobě trojité vazby nebo zvláštní entity.

Klíčové je, že obě řešení jsou co do schopnosti zachytit vazbu ekvivalentní, pře devším díky schopnosti vazeb pojímat atributy, jak byla naznačena výše. Máme tedy na výběr. Druhé řešení se zdá od pohledu komplikovanější – je tam spousta vazeb navíc a zdá se že primární vazby ke smlouvě jsou trochu zlomené přes ko leno – jde přeci o vztah mezi subjekty a nikoliv o tři nezávislé vztahy ke smlouvě. Na druhou stranu multilaterální vazby vnášejí do návrhu další technologické komplikace a co víc, u ontologií zdaleka nejsou běžné.

144


Myslím, že vhodným řešením by bylo tyto vazby povolit, ale pouze volitelně – kdo je využije, nechť mu to systém umožní, kdo ne, zbytečně by mu kompli kovaly život.

3.3.2 Násobné Násobnost vazby je jiný pojem. Násobná vazba může být i bilaterální, ale mi nimálně jeden její účastník je násobný, tedy vystupuje v ní v nějakém počtu či množství. Typickou vazbou, která by se mohla často objevit v násobné variantě je agregace či kompozice. Myslím že nejlepší bude příklad. Dejme tomu, že pro dáváme máslo po celých krabi cích. V jedné krabici je dejme tomu 40 kusů. Nadefinovali jsme si koncept máslo a kon cept krabice.

Čerstvé máslo

Čerstvé máslo

Čerstvé máslo

Čerstvé máslo

x10

Jak zachytíme naznačený vztah? Řekněme že jde o orientovanou ty povou vazbu je umístěno/obsahuje. Ve směru máslokrabice je vše v pořádku, máslo je v jedné krabici. Obráceně to tak jednoduché není. Pokud bychom nepodporovali násobné vazby, bylo by třeba vytvořit 40 instancí másla a všechny spojit s krabicí nějak takto: máslo krabice máslo

máslo

máslo

..a dalších 36

Představa, že by to měl člověk ručně provádět není nijak příjemná, u másla by se to zvládnout ale ještě dalo. Horší by bylo, kdybychom měli dávat do krabiček špendlíky nebo sypat písek do pytlů – jak by

145


bylo možné bez násobnosti vyjádřit množství (hmotnost, délku..) nějaké entity? Proto potřebujeme vhodnější řešení, třeba takovéto:

máslo 40

je umístěno v obsahuje

1

krabice

Myšlenka je zřejmá – vazba je v systému pouze jedna, ale účastník je násobný. Úplně se zde nabízí využít mechanismů násobnosti definovaných u atributů a myslím že to přesně tímto způsobem také zrealizujeme. Zbývá určit, kde vlastně má být násobnost stanovena. Asi nejflexibilnější bude spolehnout se na mechanismus dědičnosti. Výchozí násobnost u konceptů vazeb bude u všech rolí 1, tedy do vztahu bude moci vstoupit pouze jeden účastník za každou roli. Pokud bude násobnost u konceptu výslovně specifikována (např. 40), bude tato přenesena do všech odvozených vazeb. Obecně bude připadat v úvahu redefinice kdekoliv v hierarchii, pokud nebude redefinice zakázána pomocí prostředků pro zvýšení robustnosti popsaných níže.

3.4 Prostředky zvýšení robustnosti 3.4.1 Rozhodovací řetězce Vzniká otázka, jak je možné určit například to, zda je konkrétní vazba přípustná například pro konkrétní kombinaci prvků ontologie v rolích účastníků. Navrhuji mechanismus rozhodovacích řetězců inspirovaný konfigurací firewallů. Roz hodovací řetězce mají jednoduchou strukturu, jsou přehledné a snadno pochopi telné a umožňují poměrně přesně specifikovat, co je povoleno a co nikoliv.

rozhodovací řetězec (decisive chainlink) Je posloupnost testů a rozhodnutí, která mají být přijata v případě platnosti testu. Na základě rozhodnutí může být provedena určitá akce nebo posouzena přípustnost situace. Pravidla jsou vyhodnocována pod le jednoznačně daného pořadí.

146


test rozhodovacího řetězce (rule) Skládá se z řady dílčích testů, spojených logickými operátory. V přípa dě testování přípustnosti vazeb pro konkrétní prvky ontologie bude tře ba posuzovat jejich parametry – postavení v rámci hierarchie dě dičnosti, atributy nebo vazby s jinými prvky (třeba příslušnost ke ka tegorii).

rozhodnutí (decision) V úvahu připadá především rozhodnutí o povolení nebo zakázání konkrétní vazby. Přidejme ještě rozhodnutí o změně parametrů vazby – zejména kardinality (násobnosti) na stranách účastníků.

ukončující rozhodnutí (terminal decision) Ta rozhodnutí, která ukončí další provádění řetězce.

pomocné rozhodnutí (supplementary decision) Jak asi tušíte, ta rozhodnutí, která neukončí další provádění řetězce, pouze provedou určité akce – třeba změny v nastavení parametrů vaz by. Budou vykonána pokud finální ukončující rozhodnutí dopadne kladně.

politka (policy) Ukončující rozhodnutí, které bude aplikováno pokud žádný test s ukončujícím rozhodnutím neuspěje. Výchozí naložení se situací. Pro každou situaci (kombinaci vazby a účastníků) musí existovat výchozí politika.

3.4.2 Struktura rozhodovacích řetězců Jak bude takový řetězec vypadat? Půjde o posloupnost testů a rozhodnutí shrnutých do velkého seznamu. Například pro vazbu je částí/obsahuje v prostředí publikačního serveru může část tohoto řetězce vypadat takto: vazba

prvek=

celek=

decis. částí/obs.

{have} schválený=ne

{isa} rubrika

deny

částí/obs.

{isa} článek

{isa} rubrika

allow

částí/obs.

…

…

…

147

Projekt ontologického systému Meta model ontologie částí/obs.

default

deny

Jak vidíte, pravidlo, které vyřadí neschválené články je vykonáno dříve než to, které povolí zařazení článků obecně. Celé to bude fungovat tak, že bude povoleno zařadit článek do rubriky pouze pokud je schválen redaktorem. Poslední řádek řetězce obsahuje vý chozí politku, která zamítne vazby, které nebyly výslovně povoleny. Možná se zeptáte, jak budou vypadat rozhodovací řetězce u vztahů dostupných obecně všem prvkům, například u vazby isa. Jednoduše: vazba

test

decision

isa

default

allow

3.4.3 Rozhodnutí v rozhodovacích řetězcích Co se testů týče, lze se inspirovat v kapitole věnované pravidlům, konkrétně v části o predikátech. Dále se proto budeme zabývat již jen jednotlivými typy roz hodnutí:

zakázáno (deny) Ukončující rozhodnutí, vazba je zakázána.

povoleno (allow) Ukončující rozhodnutí, vazba je povolena.

doporučeno (suggest) Ukončující rozhodnutí, vazba je povolena (allow) a k tomu navíc do poručena. Konkrétní aplikace může tuto skutečnost reflektovat v grafickém rozhraní – doporučenými vazbami naplní seznam pro snadné ustavení, který zobrazí a zaktualizuje pro každou entitu, pokud je s ontologie otevřena v režimu úprav.

vyžadováno (require) Vazba je nejen povolena, ale dokonce vyžadována – bez ní bude on tologie invalidní. Konkrétní aplikace na to může upozornit uživatele. Pokud je vazba jednoznačně daná testovým pravidlem, možná ji sama vytvoří, jinak si asi vyžádá doplnění dalších podrobností od uživatele.

148


změnit kardinalitu (change_cardinalty) Změní nastavení násobnosti pro jednu nebo více rolí v konkrétní kom binaci účastníků, dané testovým kritériem. Násobnost může být za kázána (změněna na 1), stanovena jednoznačně (40 ks másla do krabi ce) nebo obecně povolena (uživatel bude asi vyzván k doplnění konkrétního počtu nebo množství).

změnit účastníka (modify_counterpart) Změní atributy nebo jiné vazby účastníků.

3.4.4 Mechanismus aplikace pravidel V zásadě je to jednoduché. Pokaždé, kdy se objeví požadavek na změnu ontologie (nová vazba, nová entita..), budou z tabulky pravidel vybrána ta z nich, která by se mohla v dané situaci hodit – v rozhodovacím testu se objevuje prvek nadřazený zařazovanému prvku, jeho předek, případně situace odpovídá na základě jiné sho dy. Tento redukovaný řetězec bude třeba projít od začátku do prvního ukončujícího rozhodnutí, případně až do konce, k definici politiky. Všechna pomocná roz hodnutí po cestě k ukončujícímu rozhodnutí budou vykonána v případě, že ukon čující rozhodnutí bude kladné.

3.4.5 Automatický typ vazby Trochu zvláštní skupinu pravidel tvoří pravidla pro automatické určení typu vaz by. Umožní stanovit jednoznačně typ vazby podle parametrů účastníků tam, kde to lze. Například je zřejmé, že pokud někdo bude chtít definovat vztah mezi tech nologií a implementací, půjde téměř jistě o vztah implementuje. Takové pravidlo můžete zachytit třeba takto: vazba

prvek=

celek=

decision

? mentuje

{isa} technologie

{isa} implementace

s_type=imple-

Je na konkrétní aplikaci, jak si s výsledkem takového pravidla po radí. Pravděpodobně ale asi ochotně nabídne doporučený typ vaz by.

149


doporučit typ (suggest_type) Pro situaci splňující podmínky testu bude při jejím zřizování navržen konkrétní typ vazby.

doplnit typ (auto_type) Pro situaci splňující podmínky testu bude automaticky vybrán konkrét ní typ vazby. S tímto typem rozhodnutí je třeba zacházet opatrně.

3.5 Důsledky dědičnosti účastníků 3.5.1 Dědictví vazeb Jeli jeden prvek potomkem druhého, vzniká otázka, zda má zdědit i vazby. Ve většině případů bude odpověď znít ano, potomek možnosti předka spíše rozšíří než že by schopnosti rušil. Na druhou stranu si lze představit i situaci, kdy poto mek nedědí vazby předka. Třeba nová verze programu již nepodporuje zastaralý protokol, kte rý podporovala verze předchozí. hosting

hosting v.1

JSP

podporuje

JSP v.1

ruší hosting v.2

podporuje

JSP v.2

Na druhou stranu, pokud umožníme rušit již ustavené vazby, přijdeme o pod statný díl jistoty – již nebudeme moci prohlásit, že všechny domy mají vstupní dveře – kterýkoliv dům bude moci vazbu na dveře zrušit. Kromě toho, rušení vazeb přinese i další komplikace v podobě složitější práce s ontologií. Můžeme rozlišovat tři přístupy k nakládání s vazbami v rámci dědičnosti:

150


zaručené dědictví Potomek zdědí všechny vazby předka. Nikde v hierarchii se vazby nemohou ztratit.

selektivní dědictví Potomek zdědí ty vazby, které určí tvůrce ontologie. V úvahu připadají drobné nuance – explicitní dědění a explicitní rušení. Rozdíl je v tom, zda je třeba vyjmenovat ty vazby, které mají být zděděny nebo naopak ty, které zděděny být nemají.

odmítnuté dědictví V rámci hierarchie se vazby nepřenášejí vůbec. Napadá mě veselá analogie s dědictvím v občanskoprávním smys lu – dědic jak známo může volit, že dědictví přijímá nebo odmítá, vždy ale jako celek. Tyto možnosti odpovídají první a třetí varian tě. Druhá varianta je ze zákona nepřípustná.

Rušení zděděných vazeb je mechanismus, který nelze jednoznačně odsoudit ani schválit, proto jej necháme na volbě tvůrce ontologie – on nejlépe ví, co bude po třebovat a podle toho si nakonfiguruje meta model a tedy vybere, která z těchto třech možností mu vyhovuje nejvíce.

3.5.2 Další automatické manipulace vazbami Kromě dědičnosti by bylo možné zkoumat i další použitelné mechanismy rušení anebo naopak vyžádání vazeb. Například automatické zrušení či vyžádání jedné vazby v důsledku vzniku vazby nové. Dejme tomu, že máme dva typy vztahů (A a B) a mezi entitami, které označíme n1 a n2. Obecný mechanismus by se dal shrnout třeba takto:

vyloučení specifické n1 –A– n2 => ruší n1 –B– n2

vyloučení generální n1 –A– n2 => ruší cokoliv –B– n2

151


vyžádání specifické n1 A n2 => musí být/implikuje n1 B n2

vyžádání obecné n1 A n2 => musí být/implikuje n1 B cokoliv a obráceně

režim vyžádání stanoven... hmotnost:? required

PDA

...hodnota musí být doplněna hmotnost:0,17 required

PDA Zaurus

Situace, kdy vazba dvou prvků má za následek vznik nebo zánik vazby úplně ji ných prvků už raději rozvádět nebudu..

A.4 Pravidla K čemu jsou pravidla dobrá? Mohou sloužit k odvozování zajímavých důsledků již zachycených vztahů, které pak není třeba explicitně deklarovat. Díky tomu še tří čas při návrhu ontologie a zároveň pomáhají zajistit její konzistenci a jsou tak prostředkem zvýšení robustnosti. Pokud je totiž jedna informace zachycena více krát, hrozí, že si informace budou vzájemně protiřečit, což je typický příklad inkonzistence. Proto, pokud z kombinace zachycených informací vyplývají další informace, bylo by chybou explicitně je vetkávat do podoby konkrétních explicit ních vazeb nebo atributů. Mnohem lepším řešením je nadefinovat pravidla, která umožní požadované informace odvodit automaticky. Při procházení ontologie, prohledávání, dotazování bude systém čerpat paralelně jak z explicitních vztahů, tak ze vztahů odvozených na základě pravidel. Z tohoto pohledu půjde o integrovaný celek. Rozdíl bude pouze ve způsobu zadávání a ve vnitřní reprezentaci. 152


Pravidla lze kromě definice vlastní ontologie také vhodně použít jako prostředek dotazování v rámci interaktivní práce s ní.

4.1 Struktura pravidel Pravidlo je předpis, který se skládá ze dvou hlavních částí:

predikát, výrok Takové vyjádření, o němž je možno v souvislosti s konkrétní entitou jednoznačně prohlásit, zda platí. Příklad: worksfor :person Franta :company OpenIT

efekt Důsledek platnosti predikátu. Ta část pravidla, která definuje nový po znatek, vztah apod..

4.2 Predikát Například systém JADE zná pojem „identifikující referenční vyjádření“, v origi nále „identifying referential expression“, IRE. [CAIR02] Je to vlastně odkaz na všechny prvky ontologie vyhovující predikátu a používá se především v dotazech a silně se podobá mechanismům intenzivně využívaným v logických programova cích jazycích (Prolog apod.). Příklad: worksfor :person ?x :company OpenIT Zamyslímeli se nad predikátem, zjistíme, že je třeba vymezit minimálně dvě věci: •

co můžeme zjišťovat, hodnotit, posuzovat a

•

u čeho, tedy u jakých prvků ontologie.

Odpověď na druhou otázku je poměrně snadná – u entit, vazeb a atributů, další podrobnosti musíme ale rozebrat trochu více..

4.2.1 Báze Na základě čeho mohou být predikáty, potažmo IRE definovány? Za klíčové po važuji následující možnosti:

153


atribut entity Platí, pokud entita disponuje uvedeným atributem. Jeho hodnota není pro platnost rozhodující. Příklad: {have} hmotnost

hodnota atributu entity Platí, pokud entita disponuje uvedeným atributem a jeho hodnota od povídá podmínce. Podmínkou může být rovnost, ale také >, <, >=, <=. Je zřejmé, že jiné podmínky než rovnost lze použít pouze u atributů ta kových datových typů, které porovnání umožní a u nichž je mechanis mus porovnání definován. Příklad: {have} hmotnost > 5kg

vazba entity Platí, pokud entita disponuje uvedenou vazbou a přitom nezáleží na tom, jaké entita je jí ve vazbě partnerem. Příklad: {have} bratr

partner ve vazbě entity Platí, pokud entita disponuje uvedenou vazbou a partner splňuje další podmínku. Příklad: {have} bratr Jan Stejný mechanismus bude možné použít pro hledání všech členů ka tegorie: Příklad: {have} kategorie Recenze

předek entity Platí, pokud je entita předkem dané entity. Možno specifikovat hloubku hledání – zda je zájem pouze o rodiče nebo i o vzdálenější předky. Příklad: {ancestor} televize … nalezne „elektronika“.

154


potomek entity Platí, pokud je entita potomkem dané entity. Možno specifikovat hloubku hledání – zda je zájem pouze o děti nebo i o vzdálenější poto mky. Příklad: {isa} elektronika … nalezne „televize“.

4.3 Efekty pravidel V případě použití pravidel při interaktivní práci s ontologií si vystačíme s pre dikátem – interpretaci a využití nalezené množiny prvků ontologie provede uživa tel. Pokud ale požadujeme pravidla, která nějak doplní ontologické informace o nový pohled nebo rozměr, potřebujeme efekty. Ty nám umožní stanovit, k čemu je vlastně získaná množina dobrá. Již jsme minimálně na jeden typ efektu narazili, když jsme se zabývali dynamickou kategorizací. Stručně ji připomeneme a navrh neme některé další:

dynamická kategorizace Je to postup, který prvky splňující podmínky predikátu dynamicky za řadí do kategorie. Příklad: ?x {have} cena => ?x belongs Zboží

dynamické vztahy Jde o mechanismus odvozování vztahů na základě podmínek v pre dikátu pravidla. Příklad: (?x vztah1 ?y) & (?y vztah2 ?z) => ?x vztah3 ?z Dynamické vztahy umožní třeba definovat tranzitivitu: Příklad: (?x tranzitivni_vztah ?y) & (?y tranzitivni_vztah ?z) => ?x tranzitivni_vztah ?z Příklad: „pokud má technologie stejného předka z větve „techno logie“, je to alternativa“ JSP1 –> JSP –> webtechnologie <– PHP <– PHP4 => PHP4 alternativa JSP1

155


pravidla validity Splnění podmínek predikátu může být také vyžadováno jako podmínka validity ontologie – pokud nová entita či vazba nesplňuje podmínky pravidla validity, nebude povoleno její zařazení, případně modifikace. Tato pravidla zvýší odolnost ontologie proti chybám uživatele. Příkladem aplikace pravidel validity může být vyžádání/omezení pří slušnosti k jedné kategorii na základě příslušnosti k jiné. Pokud je enti ta produkt, nesmí být zároveň technologie: Příklad: {isa} produkt => ! {isa} technologie Za zmínku stojí, že dynamické atributy, přestože jsou jim charakte rem blízké, mezi pravidla nepatří, protože místo s hodnotami lo gickými (pravda/nepravda) mohou pracovat i s jinými, v zásadě li bovolnými datovými typy – s konkrétními hodnotami atributů, z nichž dopočítávají hodnoty jiné.

4.4 Operátory Je zřejmé, že pouze s výše uvedenými podmínkami by nebylo možné definovat i jen trochu komplikovanější predikáty. Pomohou operátory, především

logický součin & Platí obě podmínky. Příklad: ({have} bratr ?x) & (?x {have} barva_oci = „červená“)

logický součet | Platí alespoň jedna alternativa. Příklad: ({have} bratr) | ({have} dcera)

negace ! Unární operátor negující výsledek jiného testu. Příklad: ! ({have} hmotnost) Operátory naleznou uplatnění nejen v části predikátu, ale i u efektu. Trochu problematické by bylo pojetí efektu logického součtu – nebylo by jasné, který efekt zvolit. Proto je logický součet aplikovatelný pouze u predikátu.

156

Projekt ontologického systému Provozní požadavky

B Provozní požadavky Zatím jsme se zabývali především meta modelem ontologie, tedy jejími vyjad řovacími schopnostmi. Snažili jsme se respektovat cíl, totiž navrhnout takový kus softwaru, který by byl univerzálně použitelný pro definici ontologického jádra ši roké palety aplikací, z nichž o některých jsme se již zmínili. Cíl zůstává stejný, pouze úkol je teď trochu jiný – zamyslíme se nad ostatními pa rametry systému, které již tak těsně nesouvisí s meta modelem, ale rovněž značnou měrou ovlivní, zda výsledek bude anebo nebude použitelný.

B.1 Sledování provozu S provozem systému souvisí kromě zajištění perzistence také to, zda a jak budou evidovány prováděné změny, kdo a co se o změnách bude průběžně dozvídat a také to, co se bude dít se souvisejícími prvky, když bude například smazána něja ká entita. To vše prozkoumáme v tomto oddíle.

1.1 Správa změn a událostí Asi to znáte – váš oblíbený textový procesor si pamatuje, jakým úpravám jste dokument podrobili umožní vracet se nazpět v historii změn. Je to velmi praktická funkce a vnímáme ji jako samozřejmost. Podobné schopnosti mají i některé data báze, například objektová databáze ZoDB, která je součástí aplikačního serveru Zope. Veškeré úpravy v ní uložených objektů eviduje a v případě potřeby je doká že zvrátit. Náš ontologický systém musí umět totéž. Musí zaznamenávat veškeré změny on tologie, tedy nové entity, nové typy vazeb, nové vazby, nové atributy, změny hodnot atributů a v neposlední řadě výmazy. Možná to dá určitou práci, ale přínos za to stojí. Evidence půjde využít minimálně takto:

1.1.1 Statistika Pokud bude zaznamenáván kromě změny samotné také přesný čas, kdy nastala a nejlépe také kdo ji provedl (jaký uživatel), bude možné generovat sestavy zpráv o vývoji ontologie. Takové sestavy pomohou administrátorům při správě,

157


stanovování práv, omezení, obecně zpřístupňování ontologie na jedné a při jejím zabezpečování na druhé straně. Pokud se kromě změn budou evidovat i požadavky čtení a prohledávání, možnosti využití se ještě zvětší. Sestavy budou moci sloužit pro analýzy zátěže systému podle času nebo jiných kritérií. V případě ontologií sdílených více subjekty pro stanovování podílů využívání – ty mohou zase sloužit ke spravedlivému rozdě lování nákladů. Manažeři budou moci vyhodnocovat aktivitu zaměstnanců pracu jících s ontologií...

1.1.2 Návrat Asi ještě cennější bude pocit klidu při úpravách ontologie. Žádná změna totiž ne bude nevratná. Nestane se, že byste smazali informace o důležité zakázce a o dvě vteřiny později vám už bylo jasné, že v téhle práci nadobro končíte.. Nevím, zda se někdo pokoušel vyčíslit škody způsobené zbrklými uživateli, ale tuším že urči tě nebudou zanedbatelné.

1.1.3 Zachycení faktoru času Čas každopádně plyne a informační systémy s ním musí umět pracovat. Tuším, že mnoho údajů sledovaných a evidovaných v reálném čase – měřené hodnoty v provozech, čas strávený na projektu, „píchačky“.. by mohlo být realizováno prostředky automatické evidence a archivace změn snadněji a přirozeněji. Příklad: Pokud zaměstnanec Franta přijde do práce, řekněme do hlavní slévárny, svou magnetickou identifikační kartu prožene čteč kou ve dveřích a informační systém někde v mozku podniku prostě vytvoří vazbu Franta–je v–slévárna a o víc se nestará. Čas přícho du je zaznamenán automaticky.

1.2 Události – naslouchači Při práci s ontologií budou nastávat události. Událostí je založení nové entity. Nová vazba. Změna hodnoty atributu. Události mohu být ale také neinvazivní – načtení entity, sledování vazby (navigace), prohledávání. Informace o všem tomto dění bude zveřejňována v podobě oborově a místně členěných zpráv. Jádrem řešení bude..

158


naslouchač (listener, observer design pattern) Návrhový vzor, definuje vztah jedenkumnoha mezi objektemsubjek tem a libovolným množstvím objektůnaslouchačů tak, že vždy když se změní stav subjektu, všechny naslouchající objekty jsou automa ticky informovány a mohou na změnu reagovat. [OBSRLAM98] V našem případě budeme pro účely definice mechanismu naslou chání změnou stavu objektu rozumět i to, že je například čten, jak bylo naznačeno výše.

Bude třeba věnovat péči vyladění systému zpráv tak, aby byl opravdu použitelný. Naslouchači se budou moci registrovat k jednotlivým typům událostí (základními jsou vznik, čtení, modifikce, likvidace) u jednotlivých entit. Kromě typu události bude muset určit, zda jej zajímá pouze to, co se děje entitě samotné anebo i to, co se děje jejím potomkům (přímým či vzdáleným).

1.2.1 Probublávání zpráv Aby mohla entita garantovat informace o svém potomstvu, musí zde existovat podpůrný systém „probublávání“ zpráv dolů po hierarchii dědičnosti. Při vzniku každého prvku entity jsou registrováni příslušní naslouchači – všichni přímí před kové. Ti budou informováni o všech událostech. Kromě nich se mohou navíc registrovat jiné partie ontologického systému, případně i adaptéry zprostřed kovávající spojení s vnějším světem.

registrován jako naslouchač

nová vazba

informace o nové vazbě

159


1.2.2 Využití pro RSS O využití tohoto systému jsme již mluvili, když jsme hledali možnosti využití on tologií v případových studiích. Mluvili jsme například o tom, že tento mechanis mus bude základem pro integraci systémů stejného subjektu i systémů externích. Kromě toho bych se rád zmínil ještě o dalším moc pěkném využití hlášení bu dou moci sloužit jako základ velmi snadno implementovatelného systému RSS.

RSS RSS asi znáte. Používá se pro sledování změn na vybraných webech, případně pro agregaci a syndikaci, tedy další zveřejňování těchto změn. Pokud napojíme ontologii na systém RSS, kdokoliv se pak bude moci zaregis trovat k odběru pro něj zajímavého kanálu. Šéf bude sledovat nové zakázky, zákazník nové produkty ve vy braných kategoriích a změny stavů svých objednávek a reklamací... A co je ze všeho nejhezčí, to vše bude fungovat automaticky, bez jakéhokoliv programování. Postačí definice kanálů a práv k nim – v naprosté většině případů půjde o hrst pravidel v rozsahu maximálně několika řádků...

1.3 Strategie vývoje Zabýváme se provozními otázkami. Už jsme řešili, jak se mají evidovat a hlásit změny, ještě jsme se ale nedotkli toho, co se má dít, když je smazána například entita, která disponuje košatou hierarchií potomků. Co s takovými sirotky provést? Předat do péče prarodičům? Osamostatnit? Nebo je snad dokonce zničit? Při sestavování této části jsem se inspiroval [KAEVOH04].

1.3.1 Strategie likvidace Problém se týká především odstraněných předků jak již bylo naznačeno. Již v menší míře budeme požadovat připojení atributů odstra ňované entity nějaké jiné entitě – většinou již potřeba nebudou, ale pro úplnost se o nich zmiňuji také.

160


1.3.1.a Nakládání s potomky

smazat Pokud smažete prvek, který má potomka, smazán bude automaticky i tento potomek. Postup může být aplikován v rámci celé subhierarchie.

připojit Přímí potomci smazaného prvku budou připojeny vazbou isa přímému předkovi smazaného prvku.

osamostatnit Pokud smažete prvek, který má potomka, potomek bude považován za nejvyšší koncept nově vzniklé hierarchie. Technicky bude připojen ke kořenovému konceptu. Zbytek hierarchie může zůstat beze změny.

dotázat se Neřešit situaci automaticky, vždy se dotázat uživatele. 1.3.1.b Nakládání s instancemi atributů

smazat Pokud smažete prvek, který má definované instance atributů, smazány budou i tyto atributy.

připojit Instance atributů budou připojeny přímému potomkovi, pokud tento nemá již vlastní instance. Pokud je přímých potomků více, instance bude nakopírována pro každého z nich.

dotázat se Neřešit situaci automaticky, vždy se dotázat uživatele. 1.3.1.c Nakládání s vazbami

smazat Pokud smažete prvek, který má definované vazby, smazány budou i tyto vazby. 161


připojit Vazby budou připojeny přímému potomkovi, pokud je tento doposud dědil a nerušil. Pokud je přímých potomků více, instance vazeb budou nakopírovány pro každého z nich.

dotázat se Neřešit situaci automaticky, vždy se dotázat uživatele. Aby likvidace prvku proběhla úspěšně, musí být po jejím dokončení prověřeny podmínky validity.

1.3.2 Strategie duplicity Jak se má systém zachovat, pokud se uživatel snaží založit vztah dědičnosti, která již existuje, byť cesta třeba vede přes jiné prvky například tako: Pravděpodobně jde o chybu – taková hierar chie nemá valný smysl. Proto je tady možnost na stavit, co se má v takové situaci stát:

nová vazba

nic specíálního Nově vytvářená cesta bude přijata jako platná, stará zůstane beze změ ny.

kratší smazat Kratší hierarchie vyjadřuje méně informací, proto bude odstraněna.

dotázat se Neřešit situaci automaticky, vždy se dotázat uživatele.

B.2 Konfigurovatelnost meta modelu Na mnoha místech jsme zmiňovali, že to či ono půjde v meta modelu nastavit a tak jej přizpůsobit konkrétním potřebám. Tvrdím, že taková flexibilita je ne zbytná, pokud chceme pokrýt širokou paletu aplikací, jak jsme naznačili. Co obecně může být v meta modelu konfigurováno?

162


konfigurace meta modelu Nastavením meta modelu rozumím definici toho, co je v něm •

povoleno

•

zakázáno

•

vyžadováno

2.1 Důvody pro konfigurovatelnost Někdo bude možná oponovat, proč jednoduše neumožnit naráz používat všechny ty vymoženosti – kdo je použije, použije, kdo ne, nebude si jich všímat. Souhla sím, že by to bylo řešení, minimálně v případech kdy nejsou jednotlivá nastavení vzájemně konfliktní. Přineslo by ale problémy:

jak zažít informační opaření Dejme tomu, že potřebuji řešit nějaký průměrně složitý problém. Pokud k jeho vyřešení dostanu do ruky něco pro mě neznámého, ve svých schopnostech ale velmi mocného a složitého, nějakou dobu se budu snažit pochopit, jak by to mohlo posloužit k vyřešení problé mu. Dost možná ale po čase usoudím, že úsilí věnované do zvládnutí nástroje bude větší, než přímá pomoc nástroje. Pokud bych nástroji věnoval více pozornosti, časem bych možná zjistil, že mi pomůže řešit i úplně jiné a třeba i komplikovanější problémy. Kvůli prvotní negativní zkušenosti dané složitostí i při jednoduchém použití jsem se o to připravil. Systém by neměl působit jako kanón, v případě že je třeba sestřelit vrabce. Nasta vení a profily v kombinaci s maskovacími dekorátory [PATTGOF95] základních tříd systému by měly společnou silou přispět k rychlému zvládnutí základů. Uživatel poté, co úspěšně sestřelí vrabce, možná začne více bádat a odhalí další, doposud jeho pozornosti skryté funkce a zažije při tom již nikoliv informační opaření, ale příjemné informační dobrodružství. Za ještě zásadnější argument pro konfigurovatelnost meta modelu považuji toto:

robustnost, logická integrita Je zřejmé, že ve světě okolo nás jsou složité vztahy. Ontologie je jejich konceptuálním odrazem. Na jedné straně je musí odrážet co nejvěrněji 163


a na druhé straně musí být práce s ní co nejsnazší. K tomu patří i to, že by měla maximálně odolná proti nevhodným zásahům uživatele, li dově řečeno „blbuvzdorná“. Uživatel sice musí myslet, ale není tady pouze od toho, aby po sobě neustále něco kontroloval – co zvládne zkontrolovat počítač, to by taky zkontrolovat měl. Vhodně nastavený meta model nedokáže odfiltrovat úplně všechny chyby, ale téměř všechny syntaktické a mnohé konceptuální a sémantické.

2.2 Mechanismus vynucené integrity Autorizovaný uživatel či program bude moci vytvořit v zásadě libovolný prvek ontologie (entitu, vazbu..) nebo sestavu takových prvků. Před vlastním zařazením do ontologie (do kontextu dalších prvků..) musí být ověřena validita. Součástí de finice validity je i splnění podmínek nastavení meta modelu. Invalidní změny bu dou odmítnuty. Systém bude podle nastavení meta modelu vynucovat takový tvar ontologie, který odpovídá doméně i aplikaci, která s ontologií pracuje. Nedovolí změny, které by s nastavením kolidovaly. Pokud se uživatel pokusí o něco nevhodného, sešle na něj výjimku, která skončí třeba v okně s chybovým hlášením. Výjimka by měla nést dostatek informací, aby bylo možné říci •

co se nepovedlo, nestalo

•

co je špatně

•

proč je to špatně

•

a jak je možno situaci řešit

2.3 Konfigurovatelné vlastnosti meta modelu Téměř jistě zde nezmíním všechno, na mnohé další možnosti pravděpodobně na razíme až časem, při implementaci nebo používání. Myslím že další konfigurova telné vlastnosti by vyplynuly i z důkladného studia toho, co již bylo napsáno vý še. Zaměřím se hlavně na to, jaké oblasti mohou spadat do konfigurace meta modelu.

164


2.3.1 Provozní nastavení Především, zda mají fungovat mechanismy sledování času a změn v čase včetně možnosti vracet změny. Také, zda mají být generovány událostí pro registrované naslouchače a vůbec, zda se někdo jako naslouchač může registrovat.

2.3.2 Dědičnost Dědičnost může být podporována v různém stupni: •

vůbec

•

jednoduchá

•

vícenásobná

A toto nastavení může být jiné pro jednotlivé typy prvků, tedy zejména pro: •

entity (koncepty a instance)

•

koncepty atributů

•

koncepty vazeb

Kromě toho můžeme vysledovat další parametry související s dědičností, na příklad, zda mohou existovat:

finální prvky Ty prvky ontologie, od nichž je zakázáno odvozovat jakékoliv poto mky. Nebo zda je povoleno nedědění vazeb a jakým způsobem – více viz oddíl o dě dičnosti.

2.3.3 Atributy Půjde především o to, zda jsou povoleny atributy •

odvozené

•

finální

•

uživatelské

A zda mají fungovat mechanismy •

vyžádání 165

Projekt ontologického systému Provozní požadavky •

podsouvání

Tak jak je vše definováno v kapitole o atributech. Kromě toho mohou být selek tivně povoleny složitější datové typy jako mapy nebo literály (pro lokalizaci).

2.3.4 Vazby Důležité bude stanovit, zda mohou být v ontologii vazby: •

multilaterální

•

násobné

•

vazby na externí data

Rozhodovací řetězce mohou být podporovány v různém stupni: •

vůbec

•

pouze ukončující rozhodnutí

•

ukončující i pomocná rozhodnutí

Dále půjde povolit nebo zakázat mechanismy •

vyloučení

•

vyžádání

2.4 Profily nastavení meta modelu Bude jistě pěkné, pokud bude možné nakonfigurovat si meta model přesně podle potřeb. Na druhou stranu, i to bude činnost, která by mohla vést k informačnímu opaření – uživatel by byl zpočátku jistě zmaten tím, co znamená mechanismus vyžádání nebo co jsou rozhodovací řetězce.

2.4.1 Smysl a charakter profilů Pomocí mu budou profily, zejména ty přiložené do distribučního archivu systému. Prakticky kdokoliv bude moci shrnout své nastavení, nějak jej pojmenovat a vy exportovat, a tak dát k dispozici ostatním.

profil meta modelu Je souhrn nastavení meta modelu, uložený do přenositelné a sdílitelné podoby. 166


Kromě prevence informačního opaření, časové úspory a šetření nákladů při zavá dění ontologického systému mají profily ještě jeden význam. Použití kompatibi lních profilů usnadní integraci. Pokud se partneři dohodnou, že oba použijí například profil charak terizační sítě, nebudou muset řešit potíže plynoucí z rozdílných stupňů podpory dědičnosti, z rozdílné podpory násobných vazeb apod. A pokud se nedohodnou, informace o tom, jaký profil používá partner jim alespoň pomůže možné problémy identifikovat a využít řešení, která pro kombinace profilů vymyslel třeba už někdo před nimi... Výběrem profilu se provede základní konfigurace, uživatel bude moci detaily do nastavit. V této souvislosti je vhodné definovat co je to

šíře profilu Profil může shrnovat veškerá možná nastavení – na každou otázku v souvislosti s meta modelem s určitostí odpoví, to je úplný profil. Pokud mnohá nastavení, je to široký profil. Pokud jenom několik málo, je to úzký profil.

síla profilu Profil k jednotlivým volbám připojuje příznak, zda je o nastavení ne měnné nebo pouze výchozí. Jednoznačný profil vynucuje vše, silný profil vynucuje mnoho, slabý profil málo a bezmocný profil nic. Kromě nastavení je možné k jednotlivým profilům doplnit dekorá tory tříd API, které skryjí nepodporované funkce.

167


2.4.2 Vybrané profily

základní ontologie Úplný a bezmocný profil, po kterém by měl sáhnout začínající uživa tel. Podporuje pouze to, co je skutečně nezbytné i pro pokusy. Dě dičnost jednoduchá, vazby jednoduché, žádné mechanismy vyžádání, podsouvání.. Více méně na všechny otázky z části o konfigurova telných vlastnostech meta modelu odpoví ne, neumím, snad s vý jimkou generování událostí. Každopádně by k němu měly být připoje ny odpovídající dekorátory.

meta ontologie Úzký a jednoznačný, stanovuje pouze podporu vnějších zdrojů, jak byly popisovány v části s případovými studiemi.

samohodnotná ontologie (self-valuable) Úzký a jednoznačný, vnější zdroje jsou zakázány, opak meta ontologie.

charakterizační síť Široký a silný profil odvozený v rámci případové studie využití on tologií v elektronické komerci. Podpora externích vazeb, lokalizace, selektivní dědictví...

tématická mapa (topic map) Profil odpovídající definici jak je uvedena třeba v [GARS02] nebo v [XTMSPEC].

terminologická ontologie Profil pro budování jednoduchých ontologií, s důrazem na entity a vaz by, každopádně bez podpory pravidel.

axiomatická (formální) ontologie Umožňuje vše, co umí terminologická a přidává pravidla navíc. Pro budování ontologií s důrazem na pravidla a dynamičnost. O terminolo gických versus axiomatických ontologiích více třeba [ONTOSOW00].

168


2.4.3 Znovupoužití profilů Z příkladů profilů je zřejmé, že jejich šíře je různá – od definice jediného para metru až po kompletní nastavení. Zjevně by bylo praktické umožnit a) skládat úzké profily b) od univerzálních profilů odvozovat profily speciální Oba mechanismy mají své opodstatnění a oba je třeba podporovat.

kompozice profilů Je mechanismus, který umožní definovat profil jako sloučení profilů ji ných. Je třeba respektovat omezení jednotlivých profilů a záleží na pořadí kompozice. S jednotlivými parametry bude naloženo takto: profil A

profil B

profil AB

výchozí

výchozí

A

výchozí

neměnný

B

neměnný

výchozí

A

neměnný

neměnný

nelze

specializace profilů Je mechanismus dědičnosti, který umožní definovat profil jako speci ální případ profilu jiného. Je třeba respektovat omezení předka. S jednotlivými parametry bude naloženo takto: předek

profil 1

výsledné nastavení

výchozí

nedefinuje

zděděno

výchozí

definuje

předefinováno

neměnný

nedefinuje

zděděno

neměnný

definuje

nelze

Místo násobné dědičnosti, která podporována nebude lze využít kombinaci kompozice a dědičnosti jednoduché.

169


2.5 Režimy a módy Nastavení meta modelu a profily řeší trvalé a univerzální parametry a chování, zejména s ohledem na použitelnost ontologie. Smyslem režimů a módů je dále zjednodušit práci s ontologií a především předcházet nežádoucím zásahům ze strany uživatelů.

režim Zpřístupňuje funkce podle fáze životnosti ontologie a systému vůbec.

mód Zpřístupňuje ty funkce, které odpovídají oprávnění a záměrům konkrétního uživatele.

2.5.1 Základní režimy

návrhu V tomto režimu bude možno využít veškerých možností API, jak jsou definovány nastavením meta modelu.

provozu Přestože to nastavení meta modelu umožňuje, v klasickém režimu provozu nebude například možné vytvářet nebo měnit kořenové kon cepty, případně provádět jiné podobné úpravy, které spadají spíše do fáze návrhu.

2.5.2 Základní módy

čtení API povoluje všechno

vytváření Uživatel může vytvářet nové prvky, zejména entity a vazby, ale nemů že měnit prvky stávající.

úpravy Uživatel může měnit stávající prvky. 170


mazání Uživatel může odstraňovat prvky. Zejména v souvislosti s potřebou rozdělovat role a spravovat oprávnění jednot livých uživatelů bude třeba tyto mechanismy rozvést podrobněji, umožnit defi novat různé režimy a zejména módy podle oblasti v ontologii.

171

Projekt ontologického systému Struktura a technologie

C Struktura a technologie Nyní je čas zamyslet se nad případnou aplikací využívající navrhovaný systémem jako nad celkem, nasazeným v reálném prostředí, komunikujícím s reálnými uživateli a systémy, pracující s konkrétními daty a nastaveními. Budem především hledat vhodné technologie, které splní jak kvalitativní požadavky definované v úvodu praktické části, tak zároveň funkční a procesní požadavky, které jsme defi novali o něco později. Pokud vás zajímají bližší podrobnosti, případně byste si rádi přečetli něco o tom, jak části zapadají do celkové architektury aplikace a jaké má to všechno důsledky pro snadnost její údržby, rozšiřitelnost a další parametry, můžete se podívat do [ASMZEJ03]. Celá tato část je vlastně aplikací zásad a pravidel Architektury pod řízené modelu, včetně důsledků pro volbu technologií. Za klíčové pro další návrh a implementaci považuji to, aby byly jasně stanoveny hranice vyvíjeného systému. Musí být zřejmé, co je integritní součástí, a co je nadstavba nebo úplně cizí systém. Jsem toho názoru, že je mnohem lepší, když se samotný systém soustředí skutečně na jádro své činnosti, tj. zpracování ontologií a vše ostatní přenechá dalším, jasně odděleným modulům a systémům.

C.1 Systém jako celek 1.1 Základní a rozšiřující části Za základní v tomto smyslu považuji: •

Ontologické jádro, které dokáže zachytit ontologii v operační paměti počí tače, v rámci běžícího procesu aplikace, která jej využívá.

•

API rozhraní tohoto jádra, umožňující pracovat s ontologií – klást dotazy, sledovat vazby, provádět modifikace apod.

•

Systém řízení zpráv, který umožní registrovat naslouchače a tyto bude informovat o veškerém dění v ontologii.

172


Na obrázku jsou tyto základní komponenty systému zachyceny černou barvou:

registrovaní naslouchači statistiky

cizí IS

RSS

CRM

sestavy

interaktivní rozhraní

dotazovací modul

externí entity

API

...

toplevel ontologie doménová ontologie

perzistenční vrstva

řízení událostí export/import

nastavení meta modelu

Vše ostatní je rozšiřující, a jako takové není přímou součástí vyvíjeného systému a tedy ani není předmětem vývoje prvního prototypu. Těmito moduly jsme se do posud téměř vůbec nezabývali, přestože pro použitelnost aplikace jsou rovněž podstatné – zkuste vytvořit aplikaci, jejíž data a nastavení nelze ukládat a která nemá uživatelské rozhraní. Myslím že moc nepochodíte. Aby se ale někdo necítil ochuzen, zamyslíme se alespoň nad technologiemi, které by mohly sehrát úlohu v implementaci těchto částí. Přeci jenom i při vývoji jádra je třeba počítat s budou cími nadstavbami – zejména s tím, co budou od jádra vyžadovat a jaké techno logie mohou být použity při jejich budování.

1.2 Příklad komunikace Jak bude probíhat komunikace mezi moduly? Vezměme si jeden takový příklad – vyhledávací dotaz. 173

DB


Pokud uživatel odešle nějaký požadavek, řekněme dotaz, povede to k řetězu akcí. Uživatelské rozhraní zformuluje dotaz v podpo rovaném dotazovacím jazyce (o něm se stručně zmíníme dále) a odešle ho dotazovacímu modulu. Dotazovací modul jej přeloží do volání API a v této podobě jej předá dále, samotnému jádru. Jádro prověří práva a validitu, zjistí že je vše v pořádku u dotazu ko neckonců nehrozí poškození integrity. Zjistí, že objekty, které repre zentují požadované entity nemá momentálně v paměti, tak o ně požádá perzistenční jádro, ještě předtím ale informuje příslušné na slouchače o zahájení zpracování dotazu. Perzistenční jádro zfor muluje příslušný SQL dotaz, který odešle do databáze. Databáze od poví, perzistnční jádro přeloží relační data do podoby objektů a ty předá ontologickému jádru. Ontologické jádro je zařadí do pří slušných kontextů a odkazy na ně předá dotazovacímu modulu a opět informuje naslouchače o vyřízení požadavku hledání. Do tazovací modul sestaví odpověď ve svém jazyce a tu předá uživatel skému rozhraní. Uživatelské rozhraní data převede do podoby HTML stránky a uživatel je naštvaný, že to trvalo celé dvě sekundy.

uživatelské rozhraní

vyplněný formulář (HTML)

dotazovací modul

ontologické jádro

perz. rozhr.

databáze

nasl. XML

volání API

volání API

174

SQL


Je zřejmé, že komunikace nebude triviální, a to jsme vůbec nezmínili další sys témy a protokoly, které se jí účastní – prostředky síťové komunikace (protokoly TCP/IP, HTTP), databází prováděné čtení z úložiště někde na disku nebo třeba vykreslování komponent HTML stránky prohlížečem. A opět, vlastní navrhovaný systém je pouze uprostřed.

1.3 Původ jednotlivých komponent Za zamyšlení stojí i to, co bude natolik univerzální, že to bude součástí dodávky systému, co bude k dispozici jako doplněk a co vznikne v průběhu instalace a po užívání. Nuže, univerzální bude například: •

prázdný ontologický systém

•

základní entity, vztahy, datové typy.. čerpající z vhodné toplevel ontologie (isa, part_of...)

•

prázdná perzistenční vrstva

•

možná i dotazovací jazyk postavený nad API

Jako dodatek či rozšíření bude k dispozci: •

uživatelská rozhraní (HTML, Swing..)

•

generátory a analyzátory sestav

•

konektory pro jednotlivá úložiště

•

doménové a jiné speciální ontologie

Naopak v průběhu života projektu využívajícího náš systém vznikne především: •

vlastní ontologie entity, vztahy...

•

nastavení a profily

•

specifické doplňky

175


C.2 Jádro a API Nejprve vymezíme co vlastně máme na mysli, když mluvíme o jádru. Následně se budeme trochu detailněji zabývat tím, jaké základní technologie použijeme pro jeho implementaci.

jádro Nemá cenu detailně představovat, protože o něm je prakticky celá prá ce. Je to hrst provázaných objektů reprezentujících ontologii. Patří do něho také API pro manipulaci s ní a API pro konfiguraci. Poslední ne dílnou komponentou je systém pro řízení a hlášení událostí.

API Jak již bylo několikrát opatrně naznačeno, vše potřebné definice kon ceptů entit a vazeb, instancí entit a vazeb, modifikace, základní prohle dávání podle entit i atributů (Kdo všechno sídlí v ulici Škroupova?), počítání diferencí (rozdílů entit)... lze provádět voláním metod objektů jádra. Inspirací může být API již zmiňované knihovny OJB.

externí entity Jsou to data a dokumenty uložené jinde než v ontologii – články, obráz ky... Již jsme zkoumali, proč je třeba umožnit jejich zasazení do kontextu ontologie. Do jádra sice přímo samy o sobě nepatří, a nepatří do něj ani adaptéry pro různé typy dokumentů a dat. Jádro pouze musí poskytnout obecné rozhraní těmto adaptérům.

2.1 Model Asi jste si již všimli, že když mluvím o jádru, občas zmiňuji nějaké objekty, ob jektové návrhové vzory a podobné věci. V této části se pokusím obhájit volbu právě takového typu modelu a rovněž dospěji ke konkrétnímu jazyku, který pova žuji pro realizaci za vhodný. Nuže, jak by mohl model vypadat? Podle ASM „je potřeba zvolit model, který má dostatečné vyjadřovací schopnosti a tak umožní vytvoření flexibilní aplikace“. Přidejme k tomu ještě robustnost a širokou použitelnost a uvidíme, že mnoho možností nezbude. 176


2.1.1 Relační model Datový model navržený pomocí metodologie zvané strukturální analýza má něko lik nesporných výhod, které jeho stále ještě přežívající skalní příznivci jistě ne zapomenou zdůraznit. Například: •

Existuje solidně propracovaná teorie strukturální analýzy.

•

Databáze jsou podepřeny kvalitní relační teorií. Mocný jazyk SQL je i přes implementační odlišnosti standardní.

•

Existují silné CASE nástroje podporující tvorbu datového modelu.

•

Z kterékoliv části programu je možné vidět celý systém najednou, „z ptačí perspektivy“ data jsou všude přístupná, díky tomu nový požadavek zapa dající do modelu je „pouze jeden SELECT navíc“.

Ovšem systémy založené na relačním modelu trpí podobnou chybou jakou trpí i strukturální programování a kvůli které možná i někteří příznivci raději poslední „výhodu“ nezmíní: Zásahy v modelu značně ovlivní program a znesnadňují tak údržbu a vývoj celé aplikace. Co se stane, když máme bohatou košatou databázi a v jedné tabulce změním jednu definici sloupce, anebo dokonce když změním na zá kladě změny požadavků celou vazbu? Co když požadavky na sys tém natolik narostou, že počty tabulek začínají přerůstat rozumnou mez a jdou do počtu až několika stovek a poté provedu změnu v několika z nich? Je to jednoduché procesy začnou „padat“. Systém se stane neudržitelným a jaký koliv zásah do něj způsobí neustálé problémy pracovníkům z jiných částí týmu, kteří nic netuší a všichni se jenom rozčilují, proč databáze najednou nefunguje. Navíc, a to je horší, nelze mnohdy ani určit, kterých procesů se změny dotknou. Musíte, ať už s podporou programovacího prostředku anebo čistě ručně, projít všechny příkazy SQL databáze, které tabulky, vazby atd. používají, a měnit, mě nit, měnit... A protože máte vytvořit systém dost složitý, zákonitě se dostane do kruhu oprava jedné skupiny tabulek s sebou přináší další opravy jiných tabulek a procesů atd. a systém se stane krajně nestabilním. [ZOOPKR98] A proč to všechno nastane? Může za to „výhoda veřejnosti“ procesy počítají s datovou strukturou tabulek, kterou jste publikovali všem. Takové řešení by jistě nebylo příliš robustní a snadno spravovatelné, proto musíme pátrat dále.. 177


Prosím ale pozor nezavrhuji zde relační databáze jako takové ani mohutnou re lační teorii, pouze nedoporučuji chápat relační model jako jádro aplikace a zá roveň nedoporučuji kombinovat SQL s programovým kódem. I přes to jsou RD BMS ověřeným a široce podporovaným standardem pro úložiště, jak prozkoumá me dále. Na závěr ještě připojím podnětné vzkazy pana Amblera pro návrháře datových modelů. Pokud ale spěcháte, můžete jej přeskočit, o relačním modelu jsem toho, myslím, napsal již až dost. [AMBL]

návrháři logických modelů Ve skutečnosti již nebude třeba logických datových modelů, pouze tam, kde se ještě nezačalo pracovat v souladu se současným trendem a tedy podle zásad OO, a to jen dočasně. Návrháři logických modelů se proto budou muset naučit navrhovat objektové a/nebo fyzické datové modely. Dobrou zprávou je, že mnohé zkušenosti, které jako návrháři logických modelů získali, budou moci využít schopnost nadhledu, schopnost modelovat, schopnost dodržovat doporučení. Špatnou zprávou ovšem je, že jejich oblíbený modelovací mechanizmus a datové modely již ne stačí a byly překonány objektově orientovaným modelováním. Toto do poručení možná není lehké přijmout, ale čím dříve začnete, tím lépe pro vás.

návrháři fyzických modelů Ať samozvaní OO guruové říkají co chtějí, fyzické modely jsou stále potřeba. Budete se ale muset naučit navíc mapovat objekty do re 178


lačních databází. Dobrou zprávou pro vás je, že po lidech, kteří to dokáží je silná poptávka.

2.1.2 Model založený na XML Má své opodstatnění ve speciálních případech, ale spíše jako pomocný model pro zachycení jednotlivých dokumentů, třeba v rámci systémů pro správu dokumentů (documentmanagement). V čistém XML modelu není snadné realizovat dyna mičnost – data jsou pouze data a samo o sobě nic neumí. Navíc hrozí podobná ne bezpečí jako u relačních modelů, způsobená přílišnou veřejností dat i jejich sché mat. Opět těžko bychom mohli dostát požadavkům robustnosti a rozšiřitelnosti. Na druhou stranu je zda spousta prostředků pro manipulaci s XML, samotný jazyk dokáže ontologii zachytit docela účelně a pro tyto účely se také hojně vyu žívá. Proto jej rozhodně nemůžeme jednoznačně zatratit a budeme uvažovat o vhodné kombinaci s jiným modelem.

2.1.3 Objektový model Myslím že platí univerzální poučka „pokud nemáte závažný důvod pro jiný pří stup, jakýkoliv informační systém založte na objektovém modelu“. Takovou vol bou se zúží volba programovacího jazyka na ty objektově orientované.

Samotný objektový model sám o sobě samozřejmě žádnou flexibilitu či ro bustnost nezajistí, pouze nabízí prostředky, kterými je možné „udělat to dobře“ a průběžně vás k relativně dobrým řešením směruje. Nijak tím ale není snížen vý znam analýzy a návrhu – koneckonců o nich je celá tato práce a stále to ještě ne bude stačit.

179


Pro dokreslení uvádím diagram pokroku v oblasti architektur. Půj čil jsem si jej z [METADIB00]. Ukazuje postupný odklon od re lačních modelů a strukturovaného programování.

2.1.4 Logické, deklarativní, pravidlové apod. Jde o různé specifické modely vhodné především pro zachycení znalostí a různé obory umělé inteligence, například dolování informací, rozpoznávání tvarů, práce s lidskou řečí, zpracovávání nejasných a neúplných údajů. Zdá se, že jsou to obo ry dosti blízké námi navrhovanému systému.

LISP LISP (LISt Processing, zpracování seznamů) je interpretovaný, plně strukturovaný jazyk, v zásadě se skládá pouze ze seznamů volání funk cí. To mu dodává neobvyklou flexibilitu.

Scheme Scheme je mnohaúčelový programovací jazyk vyšší úrovně, podporuje operace se strukturovanými daty (řetězci, seznamy, vektory) stejně jako s primitivními typy. Často je spojován se symbolickým 180


programováním, ale jeho bohatá nabídka datových typů a flexibilní struktury pro práci s nimi z něj dělá skutečně univerzální jazyk. Dů kazem je, že existují textové editory, kompilátory, operační systémy, grafické knihovny, expertní systémy, výpočetní aplikace, aplikace pro finanční analýzy a snad každý další představitelný typ aplikace. A začít se Scheme není nijak obtížné! [SCHEMED96]

Prolog Prolog je jazyk pro programování symbolických výpočtů. Jeho název, odvozený ze slov PROgramování v LOGice, naznačuje, že jazyk vy chází z principů matematické logiky. Od počátku byl Prolog využíván při zpracování přirozeného jazyka (francouštiny) a pro symbolické vý počty v různých oblastech umělé inteligence. Používá se v data bázových a expertních systémech, při počítačové podpoře specia lizovaných činností, např. při projektování (CAD) nebo výuce (CAI), i v klasických úlohách symbolických výpočtů, jako je návrh a konstruk ce překladačů, a to nejen jako prostředek vhodný pro reprezentaci a zpracování znalostí, ale i jako nástroj pro řešení úloh.

CLIPS CLIPS je nástroj pro tvorbu expertních systémů vyvinutý skupinou Software Technology Branch (STB) v NASA. Nyní je používán mnoha tisíci lidmi na celém světě. V CLIPSu existují 3 způsoby, jak reprezen tovat poznatky: pravidly jsou určena k heuristickým poznatkům za loženým na zkušenostech, definování funkcí (deffunctions) a generic function jsou primárně určeny pro procedurální poznatky, objektově orientované programování také je určeno primárně pro procedurální poznatky. Program lze sestavit použitím jen pravidel, jen objektů nebo kombinací objektů a pravidel. CLIPS byl také navržen pro plnou in tegraci s jinými jazyky. [CLIPSMI99] Sice vše, co dokáží, lze ekvivalentně vyřešit i v čistě objektovém jazyce, ale právě díky specializaci mnoho věcí jde s těmito jazyky snáze, rychleji a přirozeněji. Tam, kde objekty působí těžkopádně a je třeba mnoho kódu možná postačí jedno či dvě krátká pravidla v Prologu. Využití některého takového modelu bych každo pádně úplně nezavrhoval, pravděpodobně v kombinaci s modelem objektovým. Bude ale třeba ještě důkladně prověřit dostupnost, platformní nezávislost, licenční 181


podmínky konkrétních nástrojů a další parametry. Oproti objektovým nástrojům a modelům jsou totiž kvůli své specifičnosti tyto nástroje mnohem méně rozšířené a používané.

2.2 Platforma Čím je dána platforma, na které vaše aplikace poběží? Zejména použitým programovacím jazykem, konkrétně dostupností kompilátoru či interpreteru na různých platformách, ale i dostupností použitých knihoven, závislostí na propri etárních systémech (třeba databázi, uživatelském rozhraní, souborovém systému apod.). Většina současných programů je vytvářena s pevně stanovenou třídou počítačů a pevně stanoveným operačním systémem nebo třídou operačních systémů, na kte rých budou fungovat. Takové řešení je zejména z dlouhodobého hlediska ne šťastné dáváte tím budoucnost aplikace do rukou dodavatele používané platfor my. Opět připojím citát od pana Amblera, tentokrát jeho filozofii návrhu (Scott’s General Design Philosophy) Proprietární řešení vás vždy poškodí: Stále zdůrazňuji: Opravdu přemýšlejte, než přijmete proprietární technologii. Ano, vždy jsou nějaké výkonnostní důvody, a často hraje roli snadnost vývoje, ale nikdy nezapomeňte, že vás musí zajímat rovněž „drobnosti“ jako přenositelnost, spolehlivost, škálovatelnost, rozšiři telnost a spravovatelnost. Už jsem viděl mnoho společností, které se dostaly do vážných problémů, když použily proprietární vlastnosti, které je svázaly s techno logiemi, které se v budoucnu prokázaly jako nedostatečné. [AMBL] Co když dodavatel operačního systému zkrachuje? Co když vybraná platforma postupně přestane vyhovovat rostoucím nárokům provozovatele aplikace, na příklad z hlediska výkonu či bezpečnosti, zatímco jiná (nová, lepší, rychlejší, bez pečnější...) by vyhovovala? A proč by měl být uživatel vaší aplikace nucen učit se pracovat s jiným operačním systémem, případně za něj platit, pokud jediné, co potřebuje, je fungující aplikace? Navíc, my nenavrhujeme běžnou obchodní aplikaci, ale univerzální knihovnu, která by měla mít široké použití v mnoha různých prostředích. Určitě by měla fungovat na kterékoliv platformě. Změnou hardwaru či operačního systému kte réhokoliv z počítačů by funkčnost aplikace měla zůstat nedotčena.

182


Zmiňme nyní krátce některé běžně používané objektově orientované programova cí jazyky, abychom následně zlehka prozkoumali, jaký vliv bude mít jejich použi tí na platformní závislost:

C++ Kompilovaný, hojně využívaný v praxi, vyvinul se ze strukturovaného předchůdce jazyka C zejména přidáním objektové orientovanosti.

Object Pascal Object Pascal se vyvinul ze strukturovaného předchůdce, jazyka Pascal zejména přidáním objektové orientovanosti. Stejně jako C je kompi lovaný. Podporuje jej především firma Borland, která prodává odpoví dající vývojová prostředí Delphi a Kylix.

Smalltalk Smalltalk považuji za velmi zajímavý jazyk. Je možná jako jediný plně objektový, v zásadě interpretovatelný (ale se současnými rozšířeními již nikoliv na 100%). Převzal rovněž dost z myšlenek neméně zají mavého LISPu. Pěkným úvodem do práce s ním je třeba [SMALTHU95].

Java Java je další silně (byť nikoliv čistě) objektově orientovaný programovací jazyk založený na interpretaci bytekódu. Má silnou pod poru ze strany firem, standardizačních skupin, open source skupin i samostatných vývojářů, k dispozici je ohromné množství technologií, nástrojů a pomůcek, které řeší mnoho běžných i méně běžných programátorských úkolů. Interpreter Javy se jmenuje Java Virtual Machine (JVM) a existuje skutečně pro cokoliv PC s jakýmkoliv operačním systémem, handheld, mobilní telefon. Zakladatelem Javy a jejím silným podpo rovatelem je firma Sun Microsystems. Ale kromě standardní imple mentace JVM firmou Sun je možné použít i jiné například IBM JVM nebo některou z open source, svými funkcemi se ale s oficiálním JVM nemohou příliš měřit. Na druhou stranu, pokud by Sun z nějakého dů

183


vodu přestal Javu podporovat, je dostatečně otevřená na to, aby se jí ujal kdokoliv jiný – ať již společnost nebo komunita.

Python Python je interpretovaný, interaktivní, objektově orientovaný jazyk. Obsahuje velké množství modulů, které podstatně usnadňují práci. In terpret je k dispozici v mnoha systémech: Unix, Windows, DOS, OS/2, Mac, Amiga... Je sice rovněž opatřený Copyrightem, ale je volně pou žitelný a šiřitelný i pro komerční využiti. Příslušná licence je svo bodnější než u konkurenční Javy

2.2.1 Přenositelnost Důležitým pojmem zde je přenositelnost. Tu můžeme sledovat na různých úrovních: 1. přenositelnost zdrojových kódů 2. přenositelnost bytekódu 3. přenositelnost nativního kódu 4. přenositelnost používaných knihoven Kromě toho můžeme zkoumat přenositelnost uživatelského rozhraní, dat apod., ale o tom se ještě zmíníme dále. Pro zodpovězení otázky jaký vyšší programovací jazyk je dostatečně přenositelný je třeba poukázat na principiální rozdíly mezi jazyky z hlediska jejich schopnosti odstínit operační systém, a to ani ne tak v průběhu programování (to je spíše věc procesu vývoje než užití, o které nám jde především), ale zejména při běhu.

184


2.2.2 Jazyky kompilované Nejdelší historii mají jazyky kompilované. Jejich výhodou je rychlost výsledných programů relativně časově náročná kompilace ze zdrojového do nativního kódu, kterému rozumí přímo operační systém proběhne pouze jednou, při běhu se pouze spustí na obrázcích jsem to znázornil překrývajícími se ovály. Proces vytvoření a spuštění kompilovaného programu vypadá takto:

Výsledný program je nativní, tedy nutně nepřenositelný. Řešením by mohlo být (a bývá) použití specifických kompilátorů a skutečně, kompilátory například jazyka C++ jsou dostupné prakticky pro všechny běžné platformy. V čem je tedy problém, když pomineme „drobnost“, že náš systém by musel být distribuován v různých vydáních pro jednotlivé platformy? Zejména v knihovnách, které vaše aplikace použije, protože ty musí být také k dispozici pro každou podporovanou platformu. A dokonce ani mnohé standardní knihovny například již zmíněného jazyka C++ se nechovají všude stejně. Z těchto důvodů je zajištění přenositelnosti buď nepříjemné, nebo hodně nepříjemné, nebo (a bohužel velice často) nemožné. Proto, kompilovaných jazyků se vyvarujeme.

185


2.2.3 Jazyky interpretované O něco novější jazyky interpretované přinášejí zásadní změnu vlastní kompilace probíhá až při spuštění programu a nazývá se interpretace. Do této skupiny patří LISP, Scheme, Prolog, ale i většina jazyků označovaných jako skriptovací jazyky, tedy PHP, Perl, Python, Tcl, JavaScript a v neposlední řadě Python. Proces vytvoření a spuštění interpretovaného programu vypadá takto:

Z hlediska přenositelnosti je to dobré řešení stačí aby existoval interpret pro každou platformu, která má být podporována. Pokud použijete výhradně přenosi telné knihovny (např. v tom samém jazyce), je vše v pořádku. Nebezpečí se skrývá ve schopnosti využívat knihoven neinterpretovaných (a tedy nepřenosi telných) jazyků, která je vlastní mnoha interpretovaným jazykům. Použijemeli nativní knihovnu, přenositelnost se rázem zboří. Před volbou interpretovaného jazyka budeme muset prověřit, zda jsou k dispozici přenositelné knihovny ke vše mu, co budeme využívat. Nevýhody jsou dvě: 1. Dáme veřejně k dispozici svůj zdrojový kód, i kdybychom náhodou nechtěli a především by to nemuseli chtít případní uživatelé naší knihovny. 2. A dále, program je pomalý časově náročná kompilace se provádí při kaž dém spuštění. Tento problém již dnes ale tolik nepálí – kvalita interperterů je mnohem vyšší než dříve a hardware také pokročil..

186


2.2.4 Jazyky interpretované s bytekompilací Jazyky interpretované s bytekompilací jsou další generací jazyků interpre tovaných. Rozdělují proces kompilace do dvou fází. Bytekompilátor převede zdrojový kód do tzv. bytekódu, což je operace časově srovnatelná s kompilací do nativní podoby, ale bytekód je platformně nezávislý . Interpretr bytekódu je již nutně platformně závislý, a proto musí existovat pro každou podporovanou platformu. Proces vytvoření a spuštění bytekompilovaného programu je takovýto:

Z hlediska přenositelnosti je to řešení stejně dobré, jako čistá interpretace. Navíc přináší výhodu v podobě vyšší rychlosti běžících aplikací a odpadá nutnost zve řejnit zdrojový kód. Ovšem i zde musíme dbát na to, že využijeme pouze přenosi telné knihovny. Věřím ale, že cesta vede nejspíše právě tudy.

187


2.2.5 Volba jazyka Otázkou je, který jazyk konkrétně je nejvhodnější? Odpověď nemůže být na prosto jednoznačná protože záleží na konkrétních parametrech navrhované aplikace. Hledaný jazyk musí být široce rozšířený, široce podporovaný, dostupné nástroje musí být schopny zajistit vše potřebné bez pevné vazby na cokoliv na tivního. Co třeba Smalltalk? Je dobře navržený, výkonný, čistě objektově orientovaný, in terpretovaný s bytekompilací, interprety existují pro mnoho platforem... Ovšem trpí právě nedostatkem kvalitních, dostupných knihoven a tento hendikep řeší možností využívat nativní knihovny C a dalších jazyků. Zbývají dva kandidáti Java a Python. Možná mají ve srovnání se Smalltalkem nějaké drobné chyby v základní specifikaci, ale u Javy jistě a u Pythonu téměř jis tě nehrozí, že bychom museli použít cokoliv nativního proto, že nenajdeme vhodný nativní ekvivalent. Interpretery rovněž existují a jsou svobodně k dispozi ci. K řešení postaveném na Pythonu se přikláním, zejména když si vzpomenu na stu dii využití v prostředí správy serveru. Java například na Linuxech k dispozici je, ale příliš velké oblibě se netěší kvůli svému korporátnímu pozadí, stále relativně restriktivní licenci a monolitické architektuře JVM. Mnozí správci systémů Javu považují pořád za příliš podezřelou, aby jí svěřili své bohatství. Java je zase jasnou volbou pro ebusiness – šéfové velkých firem naopak neu znávají nic, za čím nestojí společnost dostatečného jména, tedy ani Python, byť by šlo o technicky nejvhodnější řešení. Java má přeci jenom o něco vyšší výkon a rovněž je pro ni k dispozici i více knihoven a nástrojů. Pro implementaci prototypu zvolme Javu a uvidíme...

188


C.3 Zajištění perzistence Umožnit datům přežít konec běhu programu, to patří mezi základní požadavky. Pokud bude chybět možnost ontologii, ale rovněž nastavení systému uchovat, těžko se najde pro systém nějaké reálné využití. Zdálo by se možná, že jde o samozřejmost nebo trivialitu, ale ukládání komplikovaných dat, když jsou tady požadavky výkonové a také požadavky stability a robustnosti, není nic snadného. Bylo by ale chybou snažit se perzistenci řešit úplně po svém, když existuje nepře berné množství různých databází, všech možných typů a parametrů. Chybou by rovněž bylo vybrat jedno z té záplavy možných úložišť a systém na něm udělat závislým. To by byl prohřešek proti snaze o maximálně univerzální použití – je zřejmé, že jiné úložiště bude používat domácí uživatel pro organizaci rodinných fotografií a úplně jiné úložiště zvolí nadnárodní korporace pro ukládání informací o svých produktech (a ještě jiné pro evidenci přijatých a vydaných úplatků – má dátidal :). Musíme najít nebo vytvořit univerzální perzistenční vrstvu, konkrétní úložiště bude využíváno s pomocí pro něj specifických adaptérů do této vrstvy. Existuje nepřeberně možností, jak ukládat data z aplikace. Data můžeme ukládat jako soubory uvnitř souborového systému, můžeme vytvořit nějaký proprietární atypický ukládací systém, můžeme využít relačních databází, objektových data bází, XML databází, LDAP struktur nebo třeba něčeho úplně jiného. V dalším textu se zaměřím především na možnosti pro jazyk Java.

3.1 Soubory 3.1.1 Serializace Serializace je nástroj standardní knihovny Javy, tedy je ihned k dispozici. Princip je stručně řečeno takový, že objekt je převeden do binárního datového proudu a nástroje pro zpracování datových proudů ho pak můžou uložit například do sou boru. Ze souboru je možné objekt „zrekonstruovat“ do původní podoby. Pokud nechceme promíchat kód specifický pro tento typ ukládání s vlastní apli kační logikou, musíme vytvořit nějakou vrstvu, která bude ukládání řídit... což znamená vytvořit v zásadě celý databázový systém. Ano, serializace je použitelná pro jednoduché nebo specifické úlohy. 189


3.1.2 XML mapování O řešení některých nedostatků standardní serializace se pokouší různé nástroje, které uloží objekt nikoliv v binární podobě, ale do XML a z XML ho umí zpětně zrekonstruovat, tedy provádějí XML mapování. Produktů v této kategorii je více.

JOX JOX je skupina Java knihoven, které usnadňují přenos dat mezi XML dokumentem a objektem odpovídajícím JavaBeans specifikaci. Můžete chápat JOX jako speciální formu serializace, kde použitým formátem je XML. JOX je tak snadno použitelný, jako samotná serializace. Vý stupní XML soubor má ovšem poměrně plochý formát a nejde příliš (téměř vůbec) přizpůsobovat. Pro naše účely není vhodný. Více viz [JOX].

KBML - The Koala Bean Markup Language KBML přístup zvládne mnohem více typů objektů než JOX, ale musíte se uvázat k použití jejich speciálního XML formátu. Koala XML seria lizace je nadstavbou standardní serializace. Proces je rozdělen do dvou fází: Všechny objekty jsou serializovány do java.io.ObjectOutput Stream a následně převedeny do KOML dokumentu. Deserializace probíhá obráceně. Pro naše účely se jeví použitelnější, ale téměř jistě bychom narazili na problémy s výkonem u větších ontologií. Více viz [KBML].

JAXB Sun si je rovněž vědom potřeby XML reprezentace objektů. Vybrali si širší řešení, nazvané „data binding“ (JAXB). Toto řešení je mnohem více řízeno daty, protože využívá XML schémata přímo pro generování tříd schopných XML data zpracovávat. Serializace má být nabízena spíše jako vedlejší efekt. Hlavní nevýhoda tohoto využití spočívá v nutnosti opatřit objekty specifickými serializačními a deserializčními metodami (nazvané marshal/unmarshal). Kromě proprietárnosti a přesahů do designu tříd bychom asi opět narazili na problémy s výko nem. [JAXB]

190


Každý ze zmiňovaných nástrojů má své výhody i nevýhody. Ovšem všechny ná stroje řeší opět jenom mechanizmus převodu objektu do nějaké uložitelné formy a nikoliv pokročilejší funkce, které bychom potřebovali.

3.2 Objektově orientované databázové systémy Objektově orientované systémy (OODBMS) umožňují ukládat objektová data ve tvaru, který je jim přirozený [SICO99] a jsou tak řešením, které se tak říkajíc na první pohled nabízí, máli aplikace propracovaný objektový návrh.

ODMG Již několik let starý standard vytvořený sdružením Object Database Management Group (ODMG). S ODMG je možné vytvářet transakce, přistupovat do databáze více vlákny, znovupoužívat připojení (connection pooling). Definuje komponenty: •

objektový model

•

specifikační jazyky

•

dotazovací jazyk

•

vazby do programovacích jazyků

Avšak volně nabízené a otevřené OODBMS jsou stále (již několik let) v experi mentální fázi vývoje a tak či onak nestabilní, zatímco komerční systémy ohromí svými cenami. Co je ale nejhorší, kromě ODMG existuje hned několik dalších dotazovacích jazyků a žádný není široce podporovaný.

3.3 Objektově-relační mapování Na rozdíl od objektově orientovaných, kde jsou data silně strukturovaná a logicky propojená, jediné co relační databáze (RDBMS) nabízejí, jsou tabulky propojené relacemi. Relační databázové technologie jsou vyspělé jedny z nejstarších, při tom používané a stále nejpopulárnější ze všech. Přispívá k tomu jejich jedno duchost, efektivita, obecně nižší nákladnost. Existuje i mnoho poměrně pokroči lých RDBMS úplně zdarma, například PostgreSQL. Objektový přístup k tvorbě aplikací pracuje s objekty strukturami, kombinující mi data a chování, zatímco relační přístup je zaměřený čistě na ukládání dat.

191


impedanční nesoulad (impedance mismatch) Takzvaný impedanční nesoulad vyplyne na povrch, když porovnáme upřednostňované řešení přístupu. U objektového řešení je zvykem ob jekty procházet tak, jak jsou vystavěny příslušné závislosti, zatímco re lační přístup duplikuje data při spojování řádků tabulek. Tento základní rozdíl znesnadňuje kombinaci obou přístupů, ale, přiznejme si, kdy jste naposled použili dvě různé, primárně nesouvisející věci, aniž by to vyža dovalo pár triků? Jedním z tajemství úspěchu při objektově relačním mapování je porozumět oběma přístupům, jejich odlišnostem a na základě tohoto poznání je přimět ke spolupráci. Tyto postupy jsou již dnes docela dobře propracované a dobrým úvodem je [AMBL]. V současné době jsou také k dispozici použitelné nástroje, které značně usnadní mapování. Jsou to řešení proprietární, liší se funkcemi, podporovanými formáty popisu mapování, programátorským rozhraním, podporovanými RDBMS a mnoha dalšími vlastnostmi. Na Internetu je k dispozici celá řada srovnání. Pan Ambler vzkazuje: „Již před lety samozvaní objektoví guruové nabádali, abychom nechodili cestou nesouladu. Ano, objektový přístup je jiný než relační, ale v 99% případů, kdy vývojové prostředí je objektově orientované, úložištěm bude relační databáze. Prosím, smiřte se s tím.“ [AMBL] Ano, zdá se, že nejvhodnějším úložištěm ontologie bude relační databáze.

3.4 Objektově-relační technologie Mnoho výrobců databází, např. Oracle používá technologie, které zachovávají přednosti relačních databází a zároveň umožňují podle standardu SQL 99 specifi kovat uživatelské datové typy (UDT), které logicky odpovídají objektům. Datový model je přímo v databázovém systému objektový a na jeho základě se tvoří jednotlivé tabulky. Toto řešení se principiálně neliší od O2R mapování popsaného výše, rozdíl je pouze v přímé podpoře ze strany databáze.

192


3.5 Mnoharozměrné databáze

OLAP (On-Line Analytical Processing) Je technologie, která umožňuje pohlížet na data tradiční relační data báze jako na mnoharozměrnou strukturu. Příklad inspirovaný [SICO99]: Tradiční tabulka vypadá takto:

Příklad pohledu podél jiného rozměru:

Tento model včetně implementace a nezbytných nástrojů umožňuje rychlé, přiro zené zpracovávání dat podél všech rozměrů. Má význam zejména pro velké data báze, kde jsou potřeba postupy označované jako data mining. Součástí mnoharoz měrného pohledu mohou být hierarchie a mnoharozměrná aritmetika. OLAP ana lýza může být implementována nad tradičními (zejména relačními) databázemi,

193


anebo nad speciálním optimalizovaným úložištěm mnoharozměrnou databází (MDBMS). Jejich cena odpovídá typickému nasazení. Možná by byly schopny zachytit ontologii, ale spíše se mi zdá, že jsou určeny pro jiné typy nasazení. Každopádně nemůžeme systém postavit na nich už pro jejich vysokou cenu.

3.6 Úložiště pro stromové struktury Stromová datová forma je velmi vhodná pro některá silně strukturovaná data, např. pro dokumenty, hierarchie objektů (třeba uživatelů), reprezentaci plánů apod. Příslušné technologie jsou například:

3.6.1 LDAP (Lightweight Directory Access Protocol)

LDAP LDAP je specifická databáze určená pro ukládání stromových da tových struktur. Používá se především pro administraci v prostředí po čítačových sítí, ale může slouží pro ukládání v podstatě čehokoliv, co má smysl ukládat na síť a co potřebujeme častěji číst než zapisovat. Od databáze uživatelů až po televizní program... Rozlišuje služby autorizované a neautorizované, globální a lokální, jak můžou být aktualizované záznamy a kým, co položky mohou obsahovat a mnoho dalších vě cí. Je velice rychlá při čtení a vyhledávání, a to jsou operace prováděné mnohem častěji než zápis. Technologie je to zavedená a stabilní, existují otevřené imple mentace (OpenLDAP). [HEPP03]

3.6.2 Nativní XML databáze

Nativní XML databáze Jsou databáze specializované na ukládání XML dokumentů, místo tabulek pracují s kolekcemi XML dokumentů. Dokumenty v kolekci obvykle mohou, ale nemusí odpovídat určitému schématu. Poskytují také prostředky pro manipulaci (výběr, změna, smazání, přidání) s li bovolnou částí XML dokumentů. Někdo možná namítne, že to vše lze obvykle provádět i bez specializované data báze s využitím rozhraní DOM. XML databáze k tomu přidávají možnost doku 194


menty indexovat a sofistikovaně prohledávat. K databázi lze obvykle přistupovat příkazovým řádkem, různými API nebo přes síť (nejčastěji protokol HTTP). Příklady: Tamino, Xindice, eXist, Xhive. [XMLKOSE00] Kromě relačních databází v kombinaci s prostředky O2R mapování považuji právě tato úložiště za vhodná. LDAP zejména ve specifických nasazeních – např. pro systém pro správu serveru apod. a XML databázi i pro použití běžné.

3.7 Snahy o univerzální přístup Sami vidíte různorodost existujících řešení perzistence aplikací, z nichž každé má své výhody a nevýhody a to jsem se o mnoha možnostech vůbec nezmínil. Potře ba zastřešit takto různorodé zdroje dat nějakým jednotným rozhraním vyústila v definování konkrétních standardů. Kromě příkladů specifických pro jazyk Java (níže) stojí za zmínku ještě jednou ODMG. Tento standard měl původně sloužit jako jednotné rozhraní objektových databází, ale teoreticky (díky svému poměrně univerzálnímu návrhu) by mohl splnit stejnou funkci. Je potřeba mít ovšem na mysli, že použitelný bude ten stan dard, jemuž se dostane podpory ze strany dodavatelů řešení úložišť.

JDO (Java Data Objects) Standard JDO byl definován jako standardní rozhraní mezi objekty Java aplikací a úložišti persistentních dat, nejčastěji relačními data bázemi. Snahou bylo oddělit vlastní logiku aplikací od konkrétního způsobu uložení dat, tedy od konkrétní databáze, ať relační či objek tové. Použití JDO rozhraní usnadní programátorům práci tím, že se ne musí přímo zabývat konkrétním datovým modelem na úrovni databáze a mohou se plně soustředit na logiku aplikace. V současné době je nej silnější podpora relačních databází. Od roku 2002, kdy byla zveřejněna specifikace a referenční implementace je standard již poměrně vyspělý a jeho podpora poměrně dobrá. Nevýhodou JDO je to, že spoléhá na modifikaci bytekódu tříd.

EJB CMP Enterprise JavaBeans Container Managed Persistence EJB je komponentní architektura pro distribuované aplikace, která může být využita spolu s JDO. Komponenty EJB nabízejí svůj me chanismus pro ukládání dat, a to CMP. Na rozdíl od JDO je použití 195


CMP omezeno pouze na komponenty EJB, ale zase umožňuje dis tribuované transakce, přístup k distribuovaným objektům a rovněž na bízí bezpečnostní služby. JDO zase operuje s bohatším, ale zase s lokálním objektovým modelem. Např. objekty CMP musí být z balíků java.util.Set nebo java.util.Collection. Ukazuje se tedy, že JDO a EJB se vhodně doplnují zejména při distribuovaném zpracování. Když komponenty EJB zapouzdří třídy JDO, tak bude možné přistupovat k instancím tříd JDO vzdáleně a přímo. Použití CMP u navrhovaného systému vidím jako problematické – má příliš velké požadavky na objektový model systému, navíc nelze očekávat že každý bude in stalovat J2EE aplikační server. JDO se jeví jako použitelnější. Uvidíme v co vy ústí snahy spojit výhody JDO a CMP v návrhu JDO 2.0.

3.8 Zvolené řešení Jaký typ úložiště zvolit? Otázka to mnohdy není jednoduchá a její zodpovězení běžně (často negativně) ovlivní celou aplikaci včetně jejího objektového návrhu. Co je horší, v mnoha případech není vůbec jednoznačné, které řešení je to pravé, dokonce ani který druh úložiště. Navíc, pokud je něco „tím pravým“ nyní, nemusí tomu tak být natrvalo. Opět, hledímeli do budoucnosti, derou se nám do mysli otázky podobné, jaké jsme si již kladli v části o platformní nezávislosti: Co se stane, když výrobce pou žité databáze zbankrotuje? Co když databázový systém přestane vyhovovat, ale jiný by by byl lepší.. V našem konkrétním případě je problém ještě komplikovanější, protože pracuje me v heterogenním prostředí, které musí integrovat data z různých zdrojů – on tologie mají sloužit jako prostředek spojení a dorozumění. Stojíme před otázkami jak provázat systémy, aniž by to bylo za cenu kompromisů v čistotě návrhu? Jak si „nezavřít vrátka“ k jiným, modernějším možnostem ukládání, jakmile bude možné starý systém odstavit? Komplikovanost takových přechodů je zřejmá z ná vrhových vzorů a dalších informací z [MERGKELL]. Většina vyvíjených aplikací je silně svázána s konkrétním úložištěm. A to je chy ba. Architektura podřízená modelu [ASMZEJ03] naopak doporučuje: •

Výběr úložiště nesmí ovlivnit objektový návrh

196

Projekt ontologického systému Struktura a technologie •

Aplikace nesmí být pevně svázána s žádným konkrétním úložištěm a dokonce s žádnou konkrétní třídou úložišť.

•

Změna úložiště musí být proveditelná pouhou rekonfigurací či doplněním části podpůrného nástroje, který zajistí perzistenci objektovému modelu aniž by se to dotklo kterékoliv jiné části aplikace (zejména objektového modelu nebo uživatelského rozhraní)

•

Aplikace by měla být schopna integrovat data z různých úložišť a dokonce z různých tříd úložišť

•

Zajištění perzistence by mělo být z hlediska programátorů a vývojářů co nejsnadnější

První vývojovou fází většiny nástrojů je čisté objektověrelační mapování ná stroje zastřešují různé (ideálně všechny dostupné) RDBMS tak, aby se případná záměna nedotkla vlastní aplikace. Takových řešení je poměrně mnoho (možná de sítky). Druhá generace se snaží o skutečně univerzální přístup, jak byl popsán výše, tedy kromě RDBMS umožňují jednotně pracovat též s OODBMS, LDAP, souborovým systémem a většinou po doprogramování příslušného modulu obecně se vším. I těchto nástrojů existuje poměrně dost, populární je například Hibernate. Jeden systém ovšem vybočuje svým vysoce kvalitním návrhem a snahou jít cestou stan dardů všude, kde je to možné.

Jakarta OJB Jakarta OJB (původně ObjectRelationalBridge, po kompletním přepra cování a zuniverzálnění dále už jen OJB) je knihovna pro jazyk Java, která zpřístupňuje nejen relační databáze, ale teoreticky všechny běžné typy úložiště. Aplikace může přistupovat k úložišti přímo jedno duchým, ale proprietárním rozhraním nazvaným PersistenceBroker. OJB ale přidává další vrstvu abstrakce i směrem „dovnitř“, tedy k aplikaci a té tak umožňuje pracovat dle nejznámějších standardů ODMG či JDO. Tato architektura je dobře vidět z obrázku, který jsem si půjčil z [OJB]. Můžete si všimnout toho, že v návrhu se počítá se všemi typy úložišť, které pro naše použití připadají v úvahu – RDBMS, OODBMS, XMLDBMS a LDAP.

197


OJB dokáže pracovat jak ve vícevrstevné architektuře uvnitř EJB aplikačního serveru, tak u nevrstvené aplikace. Je, ostatně jako všechny jiné projekty Apache Jakarta, dobře dokumentována. Její novější verze se i docela snadno nastavují i používají. A je zadarmo, dokonce opensource. Sám jsem nepatrně jsem i přispěl k jejímu vývoji a její funkčnost odzkoušel na jednoduchých aplikacích. OJB je ale nasazena i v silně zatížených podmínkách.

198


C.4 Uživatelské rozhraní Tato část je možná trochu rozsáhlejší, proto hned v úvodu zmíním, o co půjde. Uživatelské rozhraní budu chápat pouze jako slupku okolo vlastního API. Budu se zamýšlet nad možnostmi kombinovat uživatelské rozhraní ručně vyprojektované s částmi automatizovaně generovanými z ontologického modelu. Důraz budu klást na rozhraní typické pro web, ale zároveň budu doporučovat univerzální zob razovací řešení se snadnou záměnou konkrétních uživatelských rozhraní. Opět si ukážeme, co znamená zásada „volná vazba – snadná změna“. Zmíníme se i o roz hraní pro hendikepované nebo pro intenzivní cestovatele... Než se do toho pustíme, tak si neodpustím ještě jednu odbočku, která s tématem přeci jenom trochu souvisí – zmíníme co zahrnuji pod pojem dotazovací modul, aby bylo jasno, až na něj dále narazíme.

dotazovací modul Co se dotazování a prohledávání týče, v systému zatím uvažujeme pře devším klasické objektové řešení – dotazy bude možno klást formou volání metod objektů, reprezentujících prvky ontologie. Na jejich zá kladě bude možné v případě potřeby vybudovat abstraktnější neobjek tový dotazovací modul pracující s jazykem blízkým přirozenému ve stylu typu SQL nebo OQL. A právě tento modul bude tvořit dotazovací systém. Případné uživatelské rozhraní tak bude moci využívat jak přímých volání API, tak služeb dotazovacího modulu. Zdaleka nejběžnějším typem uživatelského rozhraní je grafické uživatelské roz hraní (GUI). Jeho vytváření obvykle probíhá jako manuální skládání jednotlivých obrazovek z primitivních komponent, jakými jsou například vstupní pole, zaškr távací políčka, výběrové seznamy ap. a následné propojení s modelem pomocí tzv. událostí. Komponenty uživatelského rozhraní bývají označovány též jako „widgety“. Každý programovací jazyk má svou sadu takových komponent, podobně i na příklad jazyk HTML má odpovídající sady formulářových tagů (Forms, XForms, XUL..). V následujících oddílech shrnu možné scénáře ui na příkladech konkrét ních technologií. Pokud jsou implementace konkrétních scénářů závislé na konkrétním programovacím jazyce, použiji příklad z Javy.

199


4.1 Scénář „desktop“ Z grafických uživatelských rozhraní dosud drtivě převažuje právě tento typ. Vzhled je včleněn do „oken“, ta se skládají z běžných i méně běžných widgetů, převzatých z programovacího jazyka či vývojového prostředí, ve kterém je aplikace tvořena a z jejich derivátů. Je to typický vzhled aplikací vytvořených pro Windows, MacOS nebo třeba X Window. Aplikace postavené na těchto prostřed cích pro budování uživatelského rozhraní se obvykle vyznačují například těmito přednostmi: •

jednoduchost použití

•

bohaté možnosti

•

stabilita, vyspělost, spolehlivost

V Javě byl takovou sadou komponent AWT, tento balík je ovšem zastaralý, nahra dil ho nověji JFC, jehož současné verze jsou známy pod kódovým jménem Swing.

Swing Tato knihovna je svým návrhem, funkcemi a použitelností podle mého názoru jednou z nejlepších vůbec, byť je občas kritizována za svou komplikovanost. Přiblížíme některé její části a schopnosti, jak jsou uvedeny ve specifikaci [J2SDK150] a můžeme je považovat za etalon schopností widgetového systému: •

Komponenty zahrnují vše od tlačítek až k rozdělovačům ob razovky a tabulkám.

•

Výměnný vzhled a chování Každý program, který využívá Swing komponenty, si může vybrat, jak mají vypadat a jak se mají chovat. Například stejný program může jednou vypadat jako klasická MS Windows aplikace, podruhé jako Gnome a nakonec kovově („Metal“ l&f je výchozí). Kdokoliv může vytvořit balíček vzhledu a chování, pokud si z existujících nevybere v úvahu připadá třeba i využití zvuku místo obrazu.

•

Usnadnění API pro zapojení technologií jako např. čtečky ob razu, Braillovy panely 200


Java2D API Možnost zahrnout 2D grafiku, text a obrázky

•

Drag and Drop Schopnost přetahovat informace mezi Swing rozhraním a nativním prostředím

4.2 Scénář „z intranetu“

X Window Systém X Window, dodávající grafické uživatelské rozhraní UNIXům předběhl dobu už od svých počátků nabízel i přes „desktop“charakter aplikací možnost pracovat distribuovaně. Tento systém může běžet v režimu na způsob Windows, ale stejně snadno může server zobrazovat programy na dálku, tedy u klienta. Nevýhodou jsou značné nároky na server a přenosový kanál a také ne zbytné softwarové vybavení klienta, proto je použitelný prakticky vý hradně na intranetech. Časem, s rozvojem Internetu, se to ale možná změní.

Java applety Technologie, která umožňuje včlenit aplikaci se Swing uživatelským rozhraním (pouze některé funkce jsou omezené či zakázané) do HTML stránky a výsledek, pokud se zveřejní na internetu, je možné spustit prakticky odkudkoliv. Zdálo by se, že applety jsou dokonalým řešením, jeho nevýhody ale nejsou zanedbatelné: Například vyžaduje stažení poměrně velikého programu před jeho spuštěním, prohlížeč musí být vybaven správnou verzí JVM a správně nakonfigurován, výsledný applet přeci jenom všechno neumí. Dámeli vše výše uvedené dohromady, nepřekvapí nás, že tato technologie si udělala špatné jméno svou nespolehlivostí a ne stabilitou a proto se používá téměř výhradně v rámci intranetů, kde tyto nevýhody nejsou až tak moc citelné.

4.3 Scénář „z Internetu“ Různé aplikace na Internetu jsou (a budou) čím dál významnější, prostředky pro jejich vytváření proto přibývají jako houby po dešti a jsou velice různorodé. Stručné a přehledné srovnání přístupů (nikoliv konkrétních nástrojů) jsem nikde 201


nenašel, proto jsem se tomuto námětu věnoval o trošičku více – koneckonců zají má nás především použití ontologií v prostředí Internetu. I tak jde ale spíše o pouhý rozcestník.. Populárním termínem v této oblasti je MVC, tedy modelviewcontroller archi tektura. I přes svou značnou popularitu toho MVC příliš mnoho neříká a prak ticky cokoliv o sobě může prohlašovat, že je implementuje MVC přístup.

MVC Klíčová myšlenka MVC by se mohla shrnout slovem „oddělenost“. Jednotlivé komponenty aplikace, tedy •

model

•

view (vzhled)

•

controller (kontroler)

musí být maximálně oddělené jeden od druhého a komunikovat přes co nejužší, jasně vymezené rozhraní. Tato zásada je všeobecně přijímána jako důležitý předpoklad dosažení flexibility a snadné spravovatelnosti. V dalších částech se zamyslíme nad konkrétními typy MVC technologií pro prostředí webu. Termín „model“ se poměrně dobře kryje s tím, jak zde chápeme „jádro“ – o něm jsme toho napsali už dost, tak jej dále zkoumat nebudeme. Z lo gického celku „view“ probereme postupy vytváření dynamického obsahu a poté se dotkneme standardů pro vlastní formulářové prvky. O části „controller“ se zmí ním na závěr, hodně stručně.

4.3.1 Vytváření dynamického obsahu Aplikace na webu, to je vlastně hrst běžných HTML stránek doplněných o dyna miku. Takové stránky musí na jedné straně určitým způsobem prezentovat model (jádro) a na straně druhé zpracovávat uživatelské vstupy. Je možné odlišit dva principiálně odlišné přístupy, jak toho dosahovat někdy označované jako „push“a „pull“.

202


4.3.1.a Pull

pull Historicky starší je pull přístup a funguje tak, že do jinak statické stránky „dotáhne“ dynamický obsah. Důležitým momentem je zde to, že tento proces je inici ován a řízen „z pohledu“ statické stránky.

Klasickým příkladem pull technologie jsou skripty včleněné do HTML stránky (ASP, PHP, JSP, ..). Výzkumy i zkušenosti čím dál tím jasněji ukazují, že tento přístup nevede k vytvoření snadno spravovatelné, flexibilní webové aplikace. Zá kladní příčinou je jednoduchý fakt, že není technicky zaručeno, aby obsah, vzhled a logika byly maximálně odděleny a naopak jsou nabízeny prostředky k imple mentaci koncepčně špatných řešení, která jsou u push technologií technicky ne proveditelná. Silná stránka skriptovacích jazyků („moc“ a značné schopnosti) je v důsledku slabinou. O trochu méně výrazný, ale pořád ještě dostatečně nepříjemný je tento problém u „template engines“ (Velocity, WebMacro, FreeMarker, Tea,...), které jsou principi álně ekvivalentní skriptování. Jejich výhodou je, že to nejsou plnohodnotné programovací jazyky, a tak nabízejí o něco méně možností k prohřeškům. Více v tomto směru např [XMLCJSY02]. Technologie umožňující obojí přístup existují od samého začátku dynamických stránek. Mám na mysli CGI skripty, tedy samostatně spustitelné programy, jejichž jediným úkolem je generovat výsledný kód stránky. V zásadě shodné s CGI jsou servlety (vlastně CGI napsané v Javě). Jakým způsobem si výsledek sestaví, je jejich soukromou věcí mohou kombinovat kód programu se statickým obsahem (pull) anebo načíst šablonu stránky a vhodně ji doplnit (push). V zásadě všechny výše uvedené technologie oddělit vzhled, logiku a obsah umožňují, ale žádná z výše uvedených to nemůže zaručit.

203


4.3.1.b Push

Push technologie jsou naopak k takové záruce o dost blíže. Musíte se opravdu snažit, abyste princip oddělenosti porušili, a i to se vám podaří jen částečně.

push Zásadní, ale velice praktické omezení spočívá v tom, že šablona, zdrojová stránka (nejspíše XHTML) prostě je statická a není žádný způsob, jak to změnit. Program načte ve vhodné podobě tuto čistě sta tickou stránku a „vtlačí“ do ní na požadovaná místa dynamický ob sah. Statická stránka je zde ja kýmsi „substrátem“ na kterém program dodávající dynamický obsah pracuje. Příkladem produktu, který implementuje push přístup je opensource projekt Enhydra XMLC. Návrhář stránek použije svůj oblíbený editor a pouze místa, kde má stránka obsahovat dynamický obsah, označí id atributem a o logiku „dotla čení“ dat se nestará. XMLC kompilátor z takové stránky sestaví specifickou DOM (stromovou) reprezentaci, a usnadní programátorovi přístup k označeným místům, určeným pro dynamický obsah. Programátor doplní postup získání dyna mického obsahu a snadno ho včlení do stránky se zachováním jednotného vzhle du. Tento postup schema ticky znázorňuje obrázek, který jsem si půjčil z [XMLCJSY02]:

204


4.3.2 Formuláře Obdobou desktopových „widgetů“ jsou pro webové vývojáře tzv. formulářové tagy.

HTML forms Klasickým řešením jsou HTML forms, tedy HTML formuláře, součást specifikace HTML jazyka. Jsou široce rozšířené a široce podporované. Snadno se kombinují s jinými prvky HTML jazyka, takže výsledná aplikace vypadá v mnoha případech „moderněji“ a „lehčeji“ než její monoliticky působící desktopový dvojník. Trpí ovšem některými chybami: příliš zjednodušující, míchá obsah a vzhled nežádoucím (správu znesnadňujícím) způsobem, na rozdíl od desktop řešení mají značně omezenou množinou použitelných grafických prvků... Kandidátem na místo formulářových značek je kromě jiných zejména standard XForms.

XForms •

Podpora všech typů prohlížečů včetně handheldů, televizí, po čítačů, tiskáren a skenerů

•

Bohatší uživatelské rozhraní

•

Oddělení dat, logiky a vzhledu

•

Snadnější podpora více jazyků

•

Strukturovaná data

•

Pokročilá formulářová logika

•

• •

Více formulářů na stránce a více stránek tvořících jeden for mulář Pozastavení a obnova Integrace s dalšími XML znač kovacími jazkyky 205


Zdá se, že XForms nemají chybu. Ano, je to dobrý standard, ale stejně jako HTML Forms má jedno podstatné funkční omezení, které způsobuje, že trochu pokulhává za desktop řešeními: vše co zná jsou formuláře. Formuláře je možné pouze vyplnit a odeslat, což je ve srovnání s komfortem desktop řešení docela málo. Více o nich viz [XFORMS]. S formuláři si vystačíme pro dotazovací rozhraní, ale pro další interaktivní práci s ontologií její procházení, sledování vazeb, operativní úpravy apod. již nejsou příliš pohodlné. Další (a prozatím kritickou) nevýhodou je stále ještě nedostatečná podpora ze strany prohlížečů a vývojových nástrojů. Jsou zde i další možnosti, například XUL prosazovaný Mozilla Foundation. XForms jsou ale nejdále a vznikly jednáním širokého vývojového týmu, tudíž lze alespoň do budoucna očekávat i jejich silnější podporu.

4.3.3 Kontroler Existuje mnoho systémů, jejichž hlavním posláním je usnadnit navigaci uživatele po dynamicky generovaných stránkách, sledovat sezení apod. Většina těchto sys témů řeší navíc další běžné úkoly související s vytvářením aplikací pro tak hete rogenní prostředí, jakým je Internet např. lokalizace či bezpečnost (security). Spolupracují se systémy pro generování dynamických stránek, z nichž některé jsme zmínili výše. Patří sem Tapestry, Barracuda, Struts, Turbine a další. Pěkné srovnání je například na stránkách [WAFEREW] a navíc uživatelské rozhraní jako takové nepatří do jádra navrhované aplikace, proto se tímto námětem nebudu blíže zabývat.

4.4 Scénář „mobilní“ I s mobilními telefony a různými PDA zařízeními je nutno počítat „mobilní aplikace“ budou pravděpodobně jedním z nosných směrů blízké budoucnosti. Existuje obdoba jazyka HTML (WML), dále speciálně upravený virtuální stroj Javy včetně nejnutnějších knihoven (J2ME) a různé další pomůcky, nástroje, stan dardy a technologie. Nebudu zabíhat do podrobností, pouze připomenu, že uživatelské rozhraní na podobných zařízení má svá specifika, především si musí poradit s velikostí disple je zařízení, nesmí také vyžadovat nadbytečné datové přenosy nebo „myšově ori 206


entovanou“ výraznou interaktivitu... Každopádně je jasné, že i s mobilními za řízeními při vývoji uživatelského rozhraní bude třeba počítat. Určité ambice v tomto směru má již zmíněný standard XForms.

4.5 Scénář „hendikepovaní“ Kromě grafických výstupů má význam uvažovat též rozhraní pro slabozraké a ne vidomé, např. systémy s Braillovým písmem a zejména zvukové. Rozhraní pro hendikepované vyžadují mnohdy kompletně odlišný přístup. Nové možnosti se otvírají v souvislosti s pokrokem systémů umělé inteligence z oblasti rozpoznávání mluvené řeči. Vytvoření podobného rozhraní pro složitější aplikace je zatím velice pracné a nevím o žádné běžně použitelné „knihovně zvu kových widgetů“. Je pravda, že takováto rozhraní nemají tu nejvyšší prioritu, ale výslovně odmítnout hendikepované lidi by bylo diskriminující a koneckonců asi i obchodně neprozíravé, zejména pokud by řešení příliš nezkomplikovalo návrh jádra. Například Swing teoreticky umožňuje vytvořit zvukový l&f. Potíž je v tom, že widgety jsou navrženy zejména pro grafická rozhraní, a tak obsahují mnoho informací o tom, jak mají vypadat, kde mají být ve formuláři apod., ale chybí jim specifické informace pro snadnou implementaci zásadně odlišných scénářů. Řešením by byla nějaká mezivrstva, která by obsahovala maximum informací o modelu a ty byla schopna převést či předat jak do specificky grafické reprezentace (např. Swingu), tak do jakékoliv jiné...

4.6 Jak to tedy vyřešíme? Jaké sady widgetů či tagů využít? Tato otázka je poměrně komplikovaná, zejména když je nutné počítat s různými typy klientů. Klasický vzhled má nesporné výho dy, ale uživatelé potřebují svá data odkudkoliv, třeba i z internetové kavárny nebo mobilního telefonu. Situace je ještě více komplikovaná tím, že současný stav na poli technologií uživatelského rozhraní není jistě definitivní. Co když bude potře ba v budoucnosti podporovat nějaký další typ klienta? Co když klienti pro námi zvolený typ uživatelského rozhraní přejdou na jiný standard? Tvrdím, že:

207


Navrhovaná knihovna by neměla nijak zužovat možnosti volby uživatelského roz hraní. S tím, že API bude sloužit i uživatelskému rozhraní a dotazovacímu modulu je třeba počítat, ale nesmí to snížit kvalitu objektového návrhu. Aplikace nesmí být závislá na použitém uživatelském rozhraní, naopak musí být snadno přizpůso bitelná jakémukoliv uživatelskému rozhraní pouhou rekonfigurací pomůcky, která vytvoří prezenční vrstvu, aniž by se to jakkoliv dotklo jakékoliv jiné části aplikace (objektového modelu, ontologie, jiných podporovaných uživatelských rozhraní či dokonce perzistenční vrstvy). Uživatelské rozhraní musí být odvozeno od objek tového modelu, dynamicky se mu přizpůsobovat pokud možno co nejvíce automa tizovaně, ale zároveň umožnit „doladění“ podle potřeb uživatelů. Jak jsem již naznačil, konkrétní uživatelské rozhraní není předmětem našeho nej bližšího zájmu, ale neodpustím si zmínit nástroj, na kterém jsem pracoval a který by mohl pro jeho tvorbu posloužit nebo by mohl být alespoň inspirací. Nástroj dostal název Xermes.

Xermes Serverová část generuje formuláře uživatelského rozhraní ve formátu nezávislém na konkrétním scénáři uživatelského rozhraní. Tyto for muláře jsou interpretovány klientskou částí Xermesu a přetvořeny do konkrétní podoby komponent uživatelského rozhraní. Veškerá komu nikace mezi klientem a serverem probíhá v XML. Prozatím je vytvořen klientský modul využívající primitivní kompo nenty knihovny Swing, počítá se ale s klientem pro prostředí Internetu, využívající nejspíše HTML formuláře a XMLC pro snadné včlenění do konkrétních stránek. Podstatné ovšem je, že architektura systému umožňuje doplnit klientskou část pro prakticky každý jmenovaný scé nář. Více informací o projektu najdete na jeho stránkách [XERMES], ty jsou ovšem trochu zastaralé, proto je berte s rezervou.

208


C.5 Neinteraktivní rozhraní Pod tento pojem shrnuji několik na první pohled nesouvisejících rozhraní, které spojuje jedno – pokud vůbec vyžadují interakci uživatele, vystačí si s jedno duchým pokynem a jinak spoustu práce vykonají samostatně. Neprobíhá žádný skutečný dialog.

export / import ontologie Tento modul zajistí interoperabilitu vytvořené ontologie s jinými ná stroji pro práci s ontologiemi. Jednotlivé adaptéry budou rozumět konkrétním jazykům reprezentace ontologií (RDF, OIL, KAON...). Bude třeba více rozebrat, jak si má systém poradit s takovými situacemi, kdy meta model importované / exportované ontologie bude nekompatibilní. Vzhledem k univerzálnosti navrhovaného systému takové situace asi budou nastávat často především při ex portech do ontologií s nižší vyjadřovací schopnosti.

sestavy Tím myslím především statistiky, různé informace o činnosti, součty, porovnání, analýzy, doporučení, všemožné přehledové tiskové sestavy... prostě různé informace vydolované z ontologie, požadované v konkrétním formátu buď pro další zpracování nebo pro tisk.

komunikace Ostatní typy komunikace, jiné než o kterých jsme doposud mluvili – tedy nikoliv dialog s uživatelem, export nebo import ontologií, hlášení událostí naslouchačům ani sestavy navržené výše. Příkladem může být třeba výměna nastavení a profilů. Tuším, že dospějeme k řešení, které bude alespoň z pohledu jádra a jeho nejbližší ho okolí všechny tyto výstupy integrovat do jednoho univerzálního řešení neinter aktivního rozhraní.

5.1 Sestavy zejména pro tisk Začněme běžnou věcí – tiskovými sestavami. Ty je možné řešit proprietárním způsobem (jako vše) nebo využít některého ze standardních formátů pro popsání 209


textové informace s přihlédnutím k její grafické podobě. Uvedu některé zástupce a v další části se pak krátce zamyslím nad výstupy, které nesměřují na papír. Když mluvím o grafické podobě výstupů, nemám na mysli pouze uspořádání tex tu na stránce, ale i skutečné grafické informace buďto načerpané z externích entit anebo vygenerované – číselné grafy, grafická zachycení struktury částí ontologie apod.

Rich Text Format (RTF) RTF je formát pro zachycení textu včetně formátování, struktury, dalších vlastností s použitím tisknutelných znakových sad. Me chanizmus „kontrolních příkazů“ nabízí jmenný prostor, který může být využit k definování speciálních znaků, ale také různých vložených objektů, maker apod. [FFORMENM] Jeho výjimečnost spočívá v tom, že je na rozdíl od silně proprietárních formátů (DOC, WLS, ...) je celkem dobře popsán. Díky tomu může sloužit jako výměnný formát mezi různými textovými editory a kance lářskými balíky, jejichž nativní formáty jsou vzájemně nekompatibilní, ale i jako výstup IS.

OOo 2.0 Nový formát balíku OpenOffice.org byl přijat jako standard sdružením OASIS OPEN a jedná se o jeho přijetí jako ISO standardu. Pravdě podobně se stane formátem výměny dokumentů mezi evropskými vlá dami a orgány Evropské unie. Vnitřní struktura je velmi přehledná, tak jak tomu bylo již u formátu předchozího – je to sada XML souborů a použitých objektů zabalená do ZIP archivu – a tak je formát vhodný i pro různé dodatečné trans formace.

PostScript (PS) a Portable Document Format (PDF) PostScript je jazyk určený pro popis stránek dokumentu nezávisle na výstupním zařízení respektive na jeho rozlišení. Tvůrcem tohoto jazyka je firma Adobe. Mnoho laserových tiskáren ho přímo zná, proto stačí dokument na tuto tiskárnu přímo poslat. Pokud tiskárna Post

210


Script nedokáže interpretovat, je k tomu potřeba softwarový interpretr, např. GhostScript. Základní elementy v PostScriptu jsou Bézierova křivka, úsečka, text lze popsat přímo jako text avšak ve výsledku se písmena kreslí z ob louků. [PSCRPTM97] Rozdíl oproti RTF spočívá ve schopnosti stránku popsat přesně a precizně, tedy tak jak je to třeba pro profesio nálnější tiskový vzhled. PDF vychází z PS, je vnitřně komprimovaný, se zvýšenou přenosi telností, podporou Unicode a mnoha jinými výhodami, princip i pri mární použití je ovšem stejné.

TeX Viz TeX je fenomén pocházející původně z UNIXů. Pod touto zkratkou se skrývá jak vlastní formát, tak množina programových ná strojů pro sazbu. V současnosti existují různé implementace pro všech ny myslitelné platformy. Principiálně zhruba odpovídá PDF, jeho vyjadřovací schopnosti jsou ale ještě o trochu lepší..

SVG (Scalable Vector Graphic) Jazyk pro popis dvourozměrné grafiky, založený na XML. SVG zná tři typy grafických objektů: •

vektorové grafické tvary (např. cesty skládající se z rovných li nií a křivek)

•

bitmapové obrázky

•

text.

Grafické objekty mohou být seskupovány, dolaďovány použitím stylů, transformovány, komponovány do předrenderovaných objektů. Mezi interní funkce patří vnořené transformace, ořezové cesty, alfa masky, efekty a šablony. [SVG] Ano, SVG je především standardní grafický formát schopnost uchovávat textové informace je až na druhém místě. Je to patrné i z toho, že MIME typ pro SVG je „image/svg+xml“. 211


Uvedené formáty se liší tím, jaký důraz kladou na textovou a nebo spíše grafickou podobu informací, které zachycují, pro to mají všechny své opod statnění a všechny se více či méně používají.

Zmiňujeme je všechny proto, že ani jeden z nich nelze zavrhnout a ideální formát se bude lišit podle charakteru a použití sestavy. Systém by je měl svým způsobem podporovat všechny. Klíčem k řešení je dekompozice vrstvy rozhraní na část obecnou, která bude produkovat pouze holá data pro zařazení do sestavy a na část specifickou. Vlastní formát sestaví specifický formátový adaptér. Než se zamyslí me nad detaily, vrhneme se na další kapitolu z kategorie neinteraktivních výstu pů..

5.2 Netiskové výstupy, komunikace Již jsme o tom na mnoha místech mluvili, proto pro oživení jen pár příkladů:

prezentace (XHTML) Elektronický obchod postavený na ontologii bude za běhu generovat XHTML obsah – katalog produktů.

cizí klasický systém (SQL) Výstupem z ontologie může být být také například SQL INSERT příkaz, který doplní záznam v nějaké cizí databázi. Mám na mysli například nějaké logy, statistická data, informace pro prezentaci, ob jednávku, reklamaci...

cizí ontologický systém (RDF...) Na ontologii postavený elektronický obchod našeho distributora průběžně (třeba každou) automaticky aktualizuje svoje data do tazem, který odešle našemu systému. Čeká nová data ve formátu RDF a ta také pokaždé dostane.

212


klient pro sledování stavu sítě (SNMP) Administrátor chce mít vždy přehled o tom, co se děje v jeho síti. Systém pro správu je tvořený především několika propojenými on tologiemi. Je zvyklý používat nástroje pro sledování stavu aktivních síťových prvků využívající standardní protokol SNMP. Velmi se mu zamlouvá, že ontologický systém dokáže hlásit změny rovněž v podobě tohoto protokolu – pro sledování nemusí instalovat a zkou mat žádný další nástroj...

elektronické podání (XML) Je libo daňové přiznání v elektronické podobě, ve formátu za loženém na XML?

5.3 Univerzální řešení 5.3.1 Rizika Základní nevýhoda formátů pro tiskový výstup spočívá v tom, že jsou nevhodné pro jiné použití informace „chápou graficky“ a neznají význam informací. Dejme tomu, že pro tiskové výstupy programu použijeme RTF. Ale co když si pořídíme PostScriptovou tiskárnu a budeme chtít využít její schopnosti pro zvýšení kvality výstupů? Tak je převedeme, možná řeknete a s jistými obtížemi se vám to podaří. Ano, tak jiná otázka: Co když podobné výstupy, jaké tisknete, budete posílat ke zpracování „cizímu“ informačnímu systému, spravovaného na příklad ministerstvem financí. A co když požadovaný formát bude vyžadovat VÍCE informací, než kolik jich je v RTF, takže automatizovaný převod bude znamenat spoustu práce při psaní nějakého převodního programu či schématu a nebo bude principiálně neproveditelný. Ano, přijde to nejhorší zásah do vlastní aplikace (do metod uvnitř tříd modelu). Shrnemeli výše uvedený příklad: Pouze graficky formátované informace jsou takřka nepoužitelné jinak, zejména strojově. Podobné otázky si můžeme klást i u netiskových výstupů: 213


Dejme tomu že náš systém bude produkovat SQL příkazy. Ale co když po čase zjistíme, že potřebujeme nikoliv SQL výstup, ale vý stup například v nějakém proprietární textovém formátu? Bude to znamenat úpravu informačního systému? A co když budeme chtít ještě části výstupů tisknout? Tady není situace tak kritická, protože SQL, byť je pro výše uvedené použití nevhodný, obsahuje poměrně dost metainformací o charakteru posílaných dat jsou skryty v pou žitých názvech tabulek a sloupců.

5.3.2 Požadavek a řešení Změna konkrétního výstupního formátu možná a maximálně snadná a nesmí vyža dovat zásahy do modelu. Nezbytným předpokladem úspěšného řešení je zachování co největšího množství informací a meta informací v primárním výstupu. Budeli primární výstup dosta tečně informačně bohatý, finálního výstupu docílíme poměrně snadno sestavením transformačního schématu, které ovšem nijak neovlivní vlastní ontologický sys tém. Transformace proběhne „vně“. Přiložený obrázek [XMLKOSE00] demon struje snadnost transformace z informačně bohatšího zdroje do informačně chudšího formátu.

Jaký formát dokáže zachytit v zásadě libovolné informace, aniž by je nějak „okleštil“? Už nebudu dále chodit kolem horké kaše a řeknu to na rovinu: pro pri mární výstup použijeme XML s vhodným schématem, a ten transformujte dle XSLT šablony do výsledného výstupu. 214


Co je XML, XSLT, schéma a podobné věci vysvětlovat nebudu – o tom již byly popsány napsány mnohé stohy papíru. Pouze zmíním jeden nástroj, který by mohl usnadnit a zpřehlednit generování různých výstupů z různých XML zdrojů, pokud by se situace ve vašich výstupech stala nepřehlednou.

Apache Cocoon Systém pro pro usnadnění provádění hromadných transformací. Je vhodný především pro generování stránek pro WWW prezentace z všemožných datových zdrojů především z XML. Je ale navržený natolik univerzálně, že by mohl výhodně posloužit i jako vrstva ontologického systému zodpovědná za vytváření ko nečných neinteraktivních výstupů, ovšem toto použití jsem zatím neověřil v praxi.

Jak bude vypadat architektura navrženého neinteraktivního rozhraní? Trochu jsem pozměnil původní návrh architektury a znázornil jsem pouze na ty části systému, které mají přímou souvislost: RDF

e/i

šablona

XML

neinteraktivní rozhraní

print PDF

API db

tiskové sestavy

volání API

naslouchání událostem

SQL ontologie

cizí IS

A co bude finálním výstupem? Cokoliv, pro co bude napsán adaptér. Jak jsme již zmiňovali, každý formát má svá pro a proti a zejména svá vhodná a nevhodná po užití. Při implementaci pluginů budu sám dávat přednost formátům standardním před proprietárními, ale každý nechť sestaví adaptér pro to, co je mu milé. 215


C.6 Infrastruktura nasazení Jádrem každé aplikace je její •

vnitřní logika

•

struktura dat

•

a procesů nad nimi

To zde označuji jako model, v našem případě ontologický model. Modelu „slouží“ •

nějaké úložiště, které dodává datům trvalost

•

a dále uživatelské rozhraní.

Tyto funkční celky můžeme chápat v ideálním případě jako uzavřené subsystémy, které navenek komunikují pouze přes konkrétní veřejná rozhraní. Vzájemné vztahy mezi těmito subsystémy definují architekturu systému, tak jak jsme ji do posud chápali.

infrastruktura Nasazení na konkrétních počítačích nebo počítačových systémech. U každého programového subsystému nás zajímá, ve spojení s kterým dalším programovým subsystémem je umístěn na společném počíta čovém systému. Ještě zmíníme nějaké ty standardy, vhodné pro realizaci komunikace mezi komponentami:

SOAP SOAP definuje mechanismy pro výměnu strukturovaných a typových dat ve formátu XML mezi účastníky v decentralizovaném, dis tribuovaném prostředí. Specifikuje formální podobu zpráv (XML Infoset) včetně abstraktního popisu obsahu. Je bezstavový, vybudovaný podle paradigmatu jednosměrné výměny a je až na konkrétních aplikacích, zda jej obohatí o složitější vzor inter akce – požadavek/odpověď, požadavek/mnoho odpovědí atp. SOAP nedefinuje jaká data mohou být přenášena zabývá se zejména smě rováním, garancí doručení, průchodem firewally.. Aplikacím pouze do 216


poručuje, jak má být zpráva zpracována a jak mohou být vhodně repre zentována data. [SOAP12] Použití ontologických dat uvnitř SOAP obálky se úplně nabízí..

RPC, XML-RPC, CORBA, RMI Různé metody vzdáleného volání procedur a metod a využívání vzdá lených komponent. Nosnou myšlenkou všech uvedených metod je in tegrace systémů v zásadě běžících v různém prostředí, na vzdálených počítačích, pod jinými systémy a kromě RMI i napsaných v rozdílných jazycích.. Připadá v úvahu několik typických infrastruktur. Na okraj poznamenávám, že obrázky jsou UML diagramy na sazení, krabice v nich znamená hardwarový prostředek, nejspíše počítač.

6.1 Nevrstvená infrastruktura Nejběžnějším řešením v jednouživatelském prostředí je nevrstvená infrastruktura. Obvykle všechny části aplikace běží na jednom stroji, výhodou je jednoduchost ve všech směrech jednoduchá výroba, jednoduché testování, jednoduché na sazení. Implementačně jde o první řešení, které by nás asi napadlo, kdybychom se infrastrukturou vůbec nezabývali. Není použitelná v distribuovaném prostředí, kde například s jednou ontologií pracuje více lidí.

217


Z užití, kterými jsme se podrobně zabývali takto bude typicky vypa dat třeba aplikace pro organizaci dat, provozovaná jediným uživate lem, který si v ní uspořádá třeba svou sbírku písniček a fotografií.

6.2 Dvouvrstevná infrastruktura Základní způsob jak umožnit více uživatelům pracovat se sdílenými prostředky (v našem případě ontologií), je vytvořit server, který bude tyto prostředky posky tovat klientům, kteří je budou naopak využívat. V oblasti kritických aplikací je tato infrastruktura spíše na ústupu ve prospěch modernějších struktur, které popí šeme dále, přesto ji ale nemůžeme opomenout. Data je nutné sdílet prakticky ve všech případech, ale z hlediska umístění apli kační logiky připadají v úvahu dvě varianty:

6.2.1 S mohutným klientem Pokud klient obsahuje kromě uživatelského rozhraní i aplikační logiku, je to mohutný klient (thick client). Pro nás by to nejspíše znamenalo pouze oddělení databáze od ontologického systému jinak nasazeného na jediném stroji. Z hledis ka implementace je to řešení snadné, pouze v nastavení databázového konektoru bude třeba udat adresu počítače s databází a tím veškeré rozdíly oproti celodesk topovému řešení končí.

Tento model by se uplatnil třeba v situaci, kdyby bylo třeba ke stejné ontologii přistupovat z více míst, ale bez složitější spolupráce mezi uživateli – například správce sítě chce mít přehled i doma, tak vždy než odejde z práce ukončí ontologickou aplikaci a když přijde domů spustí si ji na svém soukromém počítači. Aplikace se připojí 218


na vzdálenou databázi a administrátor má dále přehled a může on tologii třeba i upravovat.

6.2.2 S tenkým klientem Klient, který neumí nic jiného, než zprostředkovat uživateli přístup k datům a programové logice tím, že se spojí se serverem je tenký (thin). Takovým klientem může být například prohlížeč internetových stránek („browser“), který žádnou logiku konkrétní aplikace už ze své podstaty obsahovat nemůže.

Typickým užitím je třeba elektronický obchod postavený na on tologii.

6.3 Třívrstevná infrastruktura Jeli každý popisovaný systém maximálně autonomní, je to třívrstevná infrastruk tura (threetier, multilayered)

219


Tato varianta je každopádně nejsložitější, ale přináší mnohé výhody například: [TRILAYCH] •

snadná zaměnitelnost úložiště nebo prezentační vrstvy

•

snadnější škálovatelnost a z toho plynoucí nižší nároky na hardware

•

snadnější integrace starých systémů

•

lepší odolnost a výkon Tyto výhody ji předurčují pro použití ve složitých podnikových sys témech, obchodních aplikacích, tam kde k jedné ontologii bude při stupovat spousta uživatelů, půjde o bezpečnost, výkon...

Tím jsme prozkoumali konvenční a klasické infrastruktury, teď přidáme pár méně běžných, o to ale zajímavějších a možná i perspektivnějších...

6.4 Software jako služba (SaaS) Nejde přímo o typ infrastruktury, ale úzce s tím souvicí. SaaS je někdy popisována jako hlavní výzva pro komunitu výzkumníků v oblasti systémového inženýrství. Jde o souhrn technologií a metod pro rychlý a efektivní vývoj a evoluci (a to i ve smyslu dlouhodobé správy) počítačových systémů. Jádrem je premisa, že uživatel považuje software nikoliv za produkt, ale za služ bu. Když pořizuje software, nejde mu o krabici, ale o to, co mu přinese. [SAASL BM04] Aplikace vystavěné podle zásad SaaS mají infrastrukturu, která přímo směřuje k dynamické integraci. Výhody takového pojetí jsou zřejmé – částečně čerpám z [SAASWHC04]. •

Jedna aplikace nabízí funkčnost, kterou potřebují mnozí. Díky tomu, že je pojímána jako služba je univerzálnější – neliší se v různých nasazeních.

•

Umožňuje nastavení a parametrizaci, ale SaaS model na druhou stranu brání klientům, aby si vymýšleli zbytečnosti. Vynucuje dobré mravy při vývoji i při používání. Brání znovuvynalézání kola. Šetří peníze a čas.

•

SaaS informační služba přináší informace agregované z mnoha zdrojů, prezentuje je unifikovaně, v příjemném webovém rozhraní. To je vlastně i původní myšlenka portálů.

220


Typickým modelem provozu SaaS software je hosting; hostované služby je snadnější provozovat. Částečně kvůli limitovaným možnostem paramet rizace, částečně proto, že nemusíte kupovat hardware ani software, in stalovat atp.

•

O to vše se postará poskytovatel – vám jde o službu. Vy nemusíte nic spravovat, opravovat, upgradovat, udržovat, kontrolovat – za to vše ručí on. Dostanete vyzkoušenou aplikaci sestavenou z komponent (služeb) a nemusíte najímat vývojáře a správce.

•

Ceny SaaS jsou predikovatelné (reprodukované) a typicky odvoditelné od intenzity používání.

•

Nezávislost. Pokud dodavatel neplní očekávání, je neobyčejně snadné se „přepnout“ na jiného. Toto vědomí udrží dodavatele bdělé a ochotné pomá hat a spolupracovat.

Do našeho ontologického pojetí to vše zapadá velmi dobře – rovněž usilujeme o integraci, nezávislost, flexibilitu.

6.5 Data jako služba (DaaS) Architektura, která má mnohé rysy společné se SaaS, zejména schopnost dyna micky vázat služby a protože jsou službami vlastně komplexní data, jde o Data as Service (DaaS). Ano, přímým cílem je integrace heterogenních datových zdrojů.

221


V centru dění je broker (zprostředkovatel), který agreguje informace z různých systémů, transformuje je a zprostředkovává pro další použití. Takovou integraci velmi usnadní sdílený slovník, na kterém se třeba ve spolupráci s nějakou ne závislou autoritou dohodnou zúčastněné subjekty. Zajímavý projekt architektury service brokeru v prostředí nemocnic a zdravotní péče dostal název IBHIS. Jeho cílem je poskytnout kon covým uživatelům unifikovaný pohled na data z mnoha zdravotnických zařízení a institucí. Autoři navrhli Architekturu in

tegrace dat orientovanou na služby (SODIA). Na rozdíl od SaaS jejich systém nevyhledává poskytovatele služeb na základě funkcio nality, ale spíše na poskytovaných dat. [IBROKER04] Jak do tohoto scénáře zapadají ontologie? •

mohou být těmi daty, která jsou agregována

•

mohou sloužit jako zprostředkovatel, jako společný slovník

•

mohou doplnit jiná data (relační, dokumenty..) o jejich význam – viz meta ontologie a třeba tématické mapy.

222


6.6 Nezávislí agenti Další perspektivní a bouřlivě se vyvíjející typ infrastruktury. Systémy jsou občas popisovány v analogiích s přírodou – v pojmech jako ekosystém, společenstvo, symbióza. Základní myšlenka je prostá na rozdíl od všech předchozích modelů zde není žádné centrum, žádný nadřazený kus softwaru, který by ostatním dik toval co mají dělat. Místo toho vedle sebe působí předem neurčený počet nezávis lých programových instancí, ty se vzájemně vyhledávají, dorozumívají, poskytují a využívají služby. agent

agent

agent

agent

Jaké to přináší výhody?

výhody architektury nezávislých agentů •

Vyšší odolnost – nejsou zde žádná zranitelná centra. Živelná po hroma, útok konkurence, vládní agentura (ani všemocná RIAA), válka – nic z toho neohrozí systém samotný.

•

Vyšší výkon a škálovatelnost – nejsou zde úzká místa, výkon celku je teoreticky neomezený. Extrémní škálovatelnost předur čuje agentní systémy třeba pro využití pro budování výpočet ních klastrů nebo technologie grid computingu.

Pro komunikaci mezi agenty je zřejmě ideální Internet. Takové distribuované po jetí Internetu mnohem více odpovídá záměrům původních jeho tvůrců, než sou časný systém službami napěchovaných, mnohdy mohutných a zranitelných serve rů. Web je vlastně krok zpět k určité míře centralismu. Kromě úplně decentralizovaných řešení existují různá přechodová stádia – někte ré spíše podpůrné služby může poskytovat jeden nebo více k tomu určených 223


serverů. Nejde ale o řízení, ale spíše podporu – pomoc při objevování ostatních agentů, překládání komunikace mezi nimi apod. Častým řešením je, že sice exis tují servery, ale těch je předem neurčený počet. Seznamy aktuálně dostupných serverů jsou neustále dynamicky aktualizovány s přispěním klientů – ti se vzá jemně o serverech informují, informace předávají serverům samotným a ty je opět šíří dále... Ve všech těchto případech se přímo nabízí použití ontologie při komunikaci – pro sdělování požadavků, odpovědí, pro popisy nabízených dat a služeb.. Ve sku tečnosti různé platformy pro budování agentních systémů s využitím ontologií po čítají. Takovou infrastrukturu mají dnes tolik oblíbené P2P systémy pro sdílení dat nové generace. Agenty a P2P systémy lze ale samozřej mě využít i ke skutečně seriózním účelům, například k budování samoučících se repozitářů, viz [P2PLTDN].

6.6.1 Inteligentní agenti 6.6.1.a Charakteristické rysy

Inteligentní informační agent je opět autonomní a adaptabilní počítačový program, pracuje obvykle v prostředí počítačových sítí, spolupracuje s různými systémy a databázemi. Technologie kombinuje umělou inteligenci (uvažování, plánování, práce s přirozeným jazykem atd.) s technikami vývoje inteligentních systémů (objektově zaměřené plánování apod.). Inteligentní agent má tyto typické rysy [INTAGEM04]:

autonomní působnost Schopnost provádět uživatelem definované úlohy nezávisle na uživate li a často i bez přítomnosti nebo vedení uživatele. Uživatel jednou spe cifikuje co, kde a kdy má agent vykonávat, a ten provádí daný úkol pouze tehdy, když nastanou vhodné podmínky.

přizpůsobivé chování Schopnost napodobovat jednotlivé uživatelovy kroky během provádění úlohy. Například si agent může uložit do paměti různé reakce uživatele na dané situace a podle toho potom sám provádět rozhodnutí apod.

224


mobilnost Schopnost volně procházet počítačovými sítěmi a vykonávat úlohy na vzdálených místech. Agenti jsou většinou tvořeni přeložitelným scriptem, který napomáhá bezproblémovému pohybu přes různé archi tektury sítí. Například komunikačně orientovaný script jako Telescript může ulehčit vzájemnou komunikaci mezi jinými agenty, kteří jsou uloženi na odlišných procesorech.

kooperativní chování Schopnost dvousměrné komunikace mezi agenty, kteří pak mohou společně provádět větší a komplexnější úlohy. Například pan X pošle panu Y elektronický dopis, který musí být neprodleně doručen. Agent nesoucí dopis od pana X se spojí s agentem pana Y a ten mu sdělí, že pan Y je na dovolené, tudíž je lepší zprávu odfaxovat sekretářce pana Y. 6.6.1.b Použití

Agent může provádět takové věci, jako •

filtrování elektronické pošty

•

organizování schůzek

•

lokalizování požadovaných informací

•

upozorňování na vhodnou možnost investice

•

zjištění nejvhodnějšího dopravního spojení.

Uživatelé jsou v současné době zahlceni obrovským množstvím informací, které se na ně ze všech stran valí – vede to k informační zahlcenosti, možná až úzkosti či apatii. Proto potřebují získat žádané informace v co nejkratší době, bez zbytečné ho šumu. Agenti mohou pomoci roztřídit a profiltrovat data do lehce manipulova telného a přehledného množství relevantních informací, přesně podle požadavků a potřeb uživatele. Čím dál více lidí intenzivně cestuje, ale zároveň musí být stále k zastižení. Elek tronické zprávy je třeba inteligentně směrovat a filtrovat.

225


A obecně, jak se tempo života zrychluje, je třeba minimalizovat čas strávený nad rutinními úkoly, aby se člověk vůbec také někdy dostal k odpočinku, zábavě, ke svým koníčkům apod.

6.7 Infrastruktura pro navrhovaný systém Při tvorbě konkrétní aplikace je zde dilema – funkce a komplexnost versus jedno duchost. Distribuované systémy na jedné straně umožňují dostat funkce a data tam, kde jsou potřeba, ale na druhé straně zvyšují složitost. Klient/server systémy mají tendenci být mnohem komplexnější než konvenční desktop architektury. Zmiňme jen pár zdrojů této složitosti: GUI, vrstva aplikačního serveru, hete rogenní platformy. Je zřejmé, že je často nutné volit mnoho kompromisů v zájmu snížení složitosti na zvládnutelnou úroveň. [CLSERRK97] Jinými slovy někdy je chybou zvolit nevrstevnou architekturu, jindy je zase chybou distribuovat. Ontologický systém proto nesmí infrastrukturu jej využívající aplikace v žádném případě diktovat. Musí být snadno škálovatelný, a to nejlépe z jednoduché desktop aplikace, přes různé klient server modifikace, až po třívrstevný model s aplikačním serverem uprostřed. Celé jádro musí být navrženo co nejlépe, bez specifik pro nějaké konkrétní finální nasazení. Přechod mezi různými typy infrastruktury by měl být realizovatelný pouhou rekonfigurací podpůrných nástrojů, které „obalují“ ontologický model.

226

Příloha CD Příloha CD

V Příloha - CD Přílohou práce je CD. Najdete na něm především:

první prototyp knihovny ELONT (ELastic ONTtology) Tak jsem nazval knihovnu pro práci s široce konfigurovatelnými ontologiemi jejíž analýza a návrh byla předmětem značné části dokumentu. Na CD najdete především: UML diagramy knihovny, především dia gramy tříd, ve formátech

•

•

ZARGO – Formát open source modelovacího nástroje ArgoUML.

•

XMI – výměnný formát pro UML modely

•

Zdrojový kód v jazyce Java.

•

Jednotkové testy v jazyce Java pro ověření funkčnosti jednot livých klíčových částí knihovny a zajištění kvality a konzistence i v případě budoucích úprav a rozšiřování.

•

API dokumentace popis rozhraní pro programátory, kteří by knihovnu rádi vyzkoušeli. •

HTML, podle zvyklostí JavaDoc Binární podoba knihovny

• •

JAR archiv pro použití v aplikacích Všechny cizí knihovny, které jsou pro běh prototypu nezbytné

•

První prototyp aplikace (pro změnu nazvané) ELORD (ELastic ORDer) Je to ta aplikace pro organizaci dat, kterou jsem zmiňoval v pří slušné případové studii UML diagramy knihovny, především diagramy tříd, opět ve for mátech

•

•

ZARGO 227

Příloha CD Příloha CD •

XMI

•

Zdrojový kód v jazyce Java.

•

Binární podoba aplikace včetně cizích knihoven, které jsou pro běh nezbytné

A v neposlední řadě...

Tento text Celá tahle práce v elektronické podobě, a co víc, krásně barevně, a k tomu ještě hned v několika formátech najednou: •

OpenOffice.org – zdrojový formát, práci jsem vytvářel v tex tovém procesoru tohoto kancelářského balíku.

•

PDF – vyexportovaný z formátu zdrojového, je vhodný pře devším pro tisk.

•

HTML – vyexportovaný z formátu zdrojového, je vhodný pře devším pro prohlížení v elektronické podobě.

228

Závěr Závěr

VI Závěr

229

Závěr Shrnutí výsledků

A Shrnutí výsledků internetové aplikace Prozkoumali jsme souvislosti, východiska internetových aplikací a tro chu jsme je systematizovali. Také jsme prozkoumali trendy v této ob lasti a pokusili jsme se predikovat budoucí vývoj. Za klíčový považu jeme trend stále vyššího propojování až integrace, a to na mnoha úrovních u aplikací, lidí i celých společností. Společnost budoucnosti bude virtuální.

ontologie Probrali jsme také základní východiska ontologií a částečně i jiných formalismů. Zamysleli jsme se nad jejich současným významem a po užitím a navrhli jsme mnohé další aplikace, z nichž některé jsou zatím na okraji zájmu a jiné zatím nebyly vůbec zvažovány. Provedli jsme několik projektových studií, abychom vybrané aplikace prozkoumali blíže, zejména s ohledem na navrhovanou knihovnu.

univerzální meta model Především jsme rozebrali vlastní parametry této knihovny – meta model, provozní a konfigurační požadavky. Dospěli jsme při tom k za jímavým skutečnostem a návrhům. Za všechny jmenujme třeba: •

dilema instance

•

výhody a nevýhody různých typů dědičnosti a jejich důsledky pro jednotlivé partie ontologie

•

dva obecné způsoby zachycení hierarchie (kategorizace a dě dičnost)

•

doména atributů tvořená datovým typem a relevancí (inspirace rámci)

•

mnohé prostředky zvýšení robustnosti: •

vyžádání a podsouvání

•

rozhodovací řetězce jako aplikace myšlenek z oblasti firewal lů 230

Závěr Shrnutí výsledků •

celý mechanismus vynucené integrity

•

odvozené atributy, automatické vazby, vícenásobné a multilate rální vazby

•

přesun hierarchie vazeb z meta modelu na úroveň modelu

•

transakční modul jako důsledná aplikace návrhového vzoru na slouchače použitelný třeba pro

•

•

zachycení faktoru času a statistiky

•

návraty v historii úprav

•

informování zájemců protokolem RSS pokročilé možnosti konfigurace, především režimy, módy a profily

analýza a návrh knihovny Myslím že se nám tak nakonec podařilo splnit hlavní cíl, totiž navrh nout univerzálně použitelnou knihovnu pro práci s ontologiemi. Při ná vrhu jsme měli stále na paměti současný stav poznání v oblasti on tologií a zejména potřeby aplikací, které by na knihovně mohly být vy stavěny. Nakonec jsme se zmínili o technologiích a možných architek turách těchto aplikací, abychom podchytili další důležité důsledky pro knihovnu samotnou. Po celou dobu jsme hledali možnosti spojení až integrace, lepší komunikace, a to zároveň s požadavky flexibility a ne závislosti, jako základem pro snadnou správu a možnost budoucího rozvoje.

prototyp Myšlenky teoreticky odvozené jsme si částečně ověřili na prototypu. Jak již vyplývá i z jeho označení, ten sice není zatím použitelný v pro dukčním prostředí, ale poskytuje základ pro další zkoumání, zpřes ňování návrhu, a především budování dalšího prototypu a snad časem i skutečně použitelné knihovny...

231

Závěr Jak pokračovat

B Jak pokračovat Myslím, že je mnoho cest, kterými by se mohl ubírat další výzkum námětu práce. Zejména: 1. Podrobněji zkoumat důsledky integračních procesů 2. Rozpracovat další nastíněné aplikace ontologií do podoby projektových studií 3. Projektové studie rozvést do analýzy a návrhu konkrétních aplikací 4. Zkoumat další vlastnosti a důsledky meta modelu, jak byl v práci předsta ven 5. Shrnout a podrobněji rozpracovat mechanismy vynucené integrity 6. Rozpracovat a přesně specifikovat prozatím neformálně uváděné jazyky pro definici různých parametrů meta modelu a tvorbu ontologie samotné anebo nalézt vhodné specifikace existující 7. Pokračovat v práci na knihovně pro reprezentaci ontologií, která je zatím pouze ve fázi prvního prototypu 8. S funkční knihovnou v ruce obohatit mnohé aplikace, o nichž byla řeč

232

Abecední rejstřík A

C

agent.................................. inteligentní.....................32, 45, 48, 224 webový..........................48 AIAI...................................34 API.....................................111, 167, 170, 172, 174176, 195, 199 201, 208, 227 ArgoUML..........................227 architektura........................ modelem řízená.............26 modelu podřízená..........172 asistent............................... informační.....................45 ASM..................................111, 172 atribut................................. doporučený....................137 finální ...........................131 konfigurace....................165 nemodifikovatelný.........138 odvozený.......................138 požadovaný...................137 vazby.............................140 volitelný.........................137 výchozí..........................138

C++....................................127, 130, 183, 185 C2C....................................12, 49, 73 CGI....................................89, 203 CLIPS................................181 clustering...........................39, 42, 113, 223 CMP...................................195, 196 Cocoon...............................89, 215 Compiere...........................110 CORBA.............................82, 217 CREAM.............................28 CRFreeNet.........................42 Cyc.....................................3032 CYCL................................28 chainlink............................ decisive .........................146

B B2B....................................13, 14, 50, 73, 74 B2C....................................1214, 49, 7375 B2G....................................13, 14, 50 báze....................................153 BitTorrent...........................41 blog....................................9, 11 BMO..................................35 bot......................................48 brokering............................50

D D&S...................................41 DAML...............................28 dědictví.............................. odmítnuté.......................151 selektivní.......................151, 168 zaručené.........................151 dekorátor............................163, 167, 168 dilema instance..................87, 115, 120 Direct Connect...................41 discovery............................ semantic.........................45 DLworkbench...................28 Dolce..................................34 dolování.............................11, 29, 32, 43, 45, 180 Dspace...............................28

E emarketplace....................13 eshop................................12, 75 EDI....................................13, 74 eDonkey.............................10, 41 efekt...................................153 ELONT..............................227 ELORD..............................227 entita.................................. externí............................176 eXist...................................195

F firma.................................. virtuální.........................14, 47 FreeMarker........................203 fulltext................................39, 72

G galerie................................9 graf.....................................9, 14, 17, 18, 20, 22, 25, 28, 85, 97, 140 grid computing...................223 groupware..........................10, 37, 109, 110

instance.............................. atributu..........................132, 138 vazby.............................139 Internet...............................13, 37, 38, 76, 206, 223 inženýrství......................... ontologické....................27, 34 IRE.....................................153

J J2ME..................................206 JADE.................................153 JAR....................................227 Java....................................66, 81, 85, 127, 129, 135, 183, 186, 188 190, 195, 197, 201, 227, 228 Java applet.........................201 JavaDoc.............................227 JAXB.................................190 JDO....................................195197 Jena....................................28 jméno................................. vazby.............................139 JOX....................................190

H

K

hendikepovaní....................81 Hibernate...........................197 hodnota.............................. atributu..........................132, 154 hyperlink............................39

Kactus................................28 Kaon..................................29 kategorizace.......................43, 46, 47, 123125 dynamická.....................124, 155 KBML................................190 KIF.....................................28, 32 klient.................................. mohutný.........................218 tenký..............................219 kompozice profilů..............169 komunikace........................23, 46, 202 komunita............................27, 42 koncept.............................. atributu..........................132, 133 vazby.............................139 konceptualizace.................16, 22,

I ID3.....................................46, 62 identifikátor....................... atributu..........................132 identita...............................124 inference............................21, 25, 27, 28, 32 infrastruktura..................... nevrstvená.....................217 s mohutným klientem....218 s tenkým klientem.........219 třívrstevná......................219

57, 90 kruh....................................18, 28, 124 KSL....................................27, 34

L LDAP.................................47, 189, 194, 195, 197 LISP...................................180, 186 listener...............................82, 159

M map.................................... topic...............................29, 121 mapa.................................. tématická.......................29, 121, 122, 222 mapování...........................27, 29, 77, 108, 190192, 195, 197 matching............................45, 50 MDA..................................11, 26 mechanismus..................... podsouvání....................138 vyžádání........................137, 168 MILO.................................32 mining................................193 mód....................................170, 171 mříž....................................17, 19 MUD..................................10 MVC..................................202

N naslouchač.........................78, 82, 84, 103, 158, 159, 165, 172, 174, 209 navigabilita........................140, 141 název.................................. atributu..........................132 negace................................156 nekonzistence....................40 nesoulad............................. impedanční ..................192

O Object Pascal.....................183 ODMG...............................191, 195, 197 OIL....................................28, 30, 209 OilEd..................................28 OJB....................................176, 197, 198 OLAP.................................193 OntoKhoj...........................34 ontologie............................ doménově specifické.....23, 64, 70, 71, 74, 78, 88, 98, 142 evoluce..........................30 meta...............................53 mnohojazyčná...............41 oborových typů..............134 pro podniky a obchod....30, 34 samohodnotná...............53, 83, 103 spojování.......................29 toplevel.........................23, 28, 30, 66, 78, 175 transformace..................30, 77 znovupoužití..................29, 108 OntoMap............................34 OntoWeaver.......................28 OODBMS..........................191, 197 opaření............................... informační.....................46, 163 OpenCRX..........................11, 110 OpenLDAP........................194 OWL..................................28

P PDF....................................63, 122, 210, 211, 228 personalizace.....................42 Plone..................................9 popiska............................... atributu..........................132 vazby.............................139 portál..................................7, 8, 34, 38, 43, 109, 220

portlet.................................7 PostgreSQL........................89, 90, 191 predikát..............................17, 138, 148, 153, 155, 156 probublávání......................87, 159 profil..................................44, 49, 120, 163, 166170, 175, 209, 225 profil.................................. bezmocný......................167, 168 jednoznačný...................167 silný...............................167, 168 slabý..............................167 široký.............................167 úplný..............................167 úzký...............................167 prohledávání......................39 Prolog................................153, 181, 186 Protége...............................28 přejímání............................ atributů..........................125, 129, 131 hodnot............................125, 130 přenositelnost.....................182, 184187, 211 přetěžování........................ atributů..........................129 PS.......................................210, 211 pull.....................................202, 203 push....................................87, 202 204 Python................................184, 186, 188

R rámec.................................26, 27 RDBMS.............................178, 191, 192, 197 RDF...................................28, 30, 209, 212

RDFS.................................28 redundance.........................3, 40, 51, 57 relevance domény..............136 režim..................................148, 170, 171 RMI....................................82, 217 robustnost..........................102, 137, 146, 179, 189 rozhodnutí.......................... pomocné .......................147 ukončující......................147, 149 RPC....................................217 RSS....................................160 RTF....................................122, 210, 211, 213 RuleML..............................28

S SaaS...................................45, 220 222 samohodnotnost.................53, 121, 168 sanity..................................100 sémantika........................... ontologická....................45 sémantizace........................43 serializace..........................189, 190 servlet................................89, 203 Scheme..............................180, 181, 186 síla profilu..........................167 síť....................................... charakterizační..............87, 167 definiční.........................20, 22 hybridní.........................21 implikační......................21 prohlašovací..................21 sémantická.....................1922 učící se...........................21 vykonatelná...................21 Smalltalk............................183, 188 SNMP................................47, 213

SOAP.................................13, 82, 216, 217 součet................................. logický...........................156 součin................................. logický...........................156 SoulSeek............................41 specializace profilů............169 strategie.............................. duplicity.........................162 likvidace........................160 vývoje............................160 strom..................................1719, 28, 47, 56, 63, 70, 121, 124, 194, 204 SUMO................................28, 32, 33, 142 SVG...................................211 Swing.................................175, 200, 201, 207, 208 symlink..............................56 systém................................ adaptivní........................48 aukční............................13 CRM..............................11, 37, 79, 108110 ERP...............................12, 110 inzertní...........................13 P2P................................10, 41, 42, 48, 224 pro správu dokumentů...3, 8, 46, 56, 57, 109, 179 publikačně aplikační...9 publikační......................9, 147 redakční.........................9 wiki................................911, 85, 124 znalostní........................11, 12, 48

T Tamino...............................195 tangled...............................18, 28 Telescript...........................225 testy.................................... jednotkové.....................111,

227 TeX....................................211 transakce............................100, 191, 196 typ...................................... datový ...........................104, 132, 133, 135, 137, 139 jednoduchý....................134 komplexní......................135 kořenový........................136 literál.............................136 mapa..............................135 násobný.........................135 uživatelský.....................134

U událost................................78, 79, 84, 157159, 165, 168, 176, 199, 209 UML..................................25, 217, 227

V váhy...................................21 vazba.................................. dynamická ....................155 jednosměrná..................39, 140, 216 konfigurace....................166 meta modelu..................141 modelu...........................142 multilaterální.................143, 144, 166 násobná..........................145 neorientovaná................139 141, 143 netypová........................136, 139 obousměrná...................39, 140 orientovaná....................62, 115, 125, 139141, 179, 181, 183, 191, 192 Velocity..............................203 vize....................................14, 37 VOM..................................28 vrstva................................. perzistenční...................82, 189

vyloučení........................... generální........................151 specifické.......................151 výraz.................................. regulérní........................72, 134 vyžádání............................. obecné...........................152 specifické.......................152

W web.................................... samoanotovaný..............42 sémantický.....................29, 34, 42 WebMacro.........................203 webmail.............................10 Webmin..............................94 WebODE............................28 widget................................199, 200, 205, 207 wildcard.............................72 WML.................................206 WordNet.............................30, 33 workflow............................10, 46, 109

Xindice..............................195 XML..................................13, 61, 66, 67, 89, 90, 93, 122, 179, 189, 190, 194, 195, 205, 208, 210, 211, 213217 XML databáze...................89, 90, 194 XMLC................................204, 208 XSLT.................................214, 215

Z Z/EVES..............................28 ZARGO.............................227 znovupoužití......................23, 25, 27, 41, 42, 78, 108, 169 ZoDB.................................85, 157 Zope...................................9, 157

Ř řetězec................................ rozhodovací ..................146, 148, 166

Š

X

šíře profilu.........................167

X Window..........................200, 201 Xermes...............................82, 208 XForms..............................199, 205207 Xhive.................................195

ú účastník.............................. vazby.............................140 úzkost................................. informační.....................46, 225

Seznam použité literatury BYZNETH99

Delejte byznys na Internetu Jirí Hlavenka, 1999 Computer Press 8072261827

GRPWREB

Collaborative Groupware Software Grant Bowman, (http://www.svpal.org/~grantbow/groupware.html)

WIKIDEF

What Is Wiki kol., (http://wiki.org/wiki.cgi?WhatIsWiki)

OWIKIZF

OpenWiki Zejda David, Faust Michal, (http://www.o it.info/) OpenIT cz, s.r.o.

FRDICTH

The Free On-line Dictionary of Computing Denis Howe, (http://www.foldoc.org/)

OPECRXK

OpenCRX - CZ stránka projektu David Klíma, (http://www.dknet.cz/Default.aspx?alias=www.dknet.cz/ope ncrx)

KMFAQ98

Answers to Frequently Asked Questions About Knowledge Management kol., (http://www.mccombs.utexas.edu/kman/answers.htm) 1998 Graduate School of Business, University of Texas at Austin

ZTECHMP02

Znalostní technologie - ucební texty Peter Mikulecký, Daniela Ponce, (https://oliva.uhk.cz/public/ZT2/index.html) 2002

SERVIYHP01

Service Deployment for Virtual Enterprises J. Yang, W. J. van den Heuvel, M. R. Papazoglou, (http://portal.acm.org/ft_gateway.cfm?id=545634&type=pdf ) 2001 IEEE, University of Tilburg, Infolab

VPRINBD01

Virtual Enterprises - Building Blocks for Dynamic eBusiness Nitin Nayak, Kumar Bhaskaran, Raja Das, (http://doi.ieeecomputersociety.org/10.1109/ITVE.2001.904 491) 2001 IEEE, IBM

MATHBKS01

Mathematical Background John F. Sowa, (http://www.jfsowa.com/logic/math.htm) 2001

DEFDICS97

Definitions, Dictionaries, and Meanings Norman Swartz, (http://www.sfu.ca/philosophy/swartz/definitions.htm) 1997 Simon Fraser University

SEMNETS02

Semantic Networks John F. Sowa, (http://www.jfsowa.com/pubs/semnet.htm) 2002

SEMNETG82

Three Principles of Representation for Semantic Networks Robert L. Griffith, (http://www.sfu.ca/philosophy/swartz/definitions.htm) 1982 IBM

ONTADGL02

Ontology Applications and Design Michael Gruninger, Jintae Lee, (http://portal.acm.org/citation.cfm?id=503124.503145) 2002

DATAONT05

Data Modeling vs. Ontology Engineering Peter Spyns, Robert Meersman, Mustafa Jarrar, (http://www scf.usc.edu/~csci586/ppt2005/modeling.ppt) 2005

ONTPADE05

The Web of Patterns Project - Object-Oriented Software Design Ontology ODOL Jens Dietrich, Chris Elgar, (http://wwwist.massey.ac.nz/wop/) 2005

EXPERTD01

Nepravidlové a hybridní expertní systémy Jirí Dvorák, (http://www.uai.fme.vutbr.cz/jdvorak/vyuka/es/NonRuleES. ppt) 2001 VUTBR

ONTOLED03

Seminar Ontology Learning Ying Ding, (http://www.deri.at/teaching/archive/docs/summer03/nextw ebgen/seminar2.ppt) 2003 Next Generation Web Group, University of Innsbruck

KAEVOH04

Kaon: Szenario_1 - Creating ontologies, Evolution hora, (http://kaon.semanticweb.org/Members/hora/S1/Szenario_1. txt) 2004

WORDNET

WordNet - a lexical database for the English language George A. Miller, Christiane Fellbaum, Randee Tengi, Susanne Wolff, Pamela Wakefield, Helen Langone, Benjamin Haskell, (http://wordnet.princeton.edu/) Princeton University

CYCORP

Cycorp home kol., (http://www.cyc.com/cyc)

OPENCYC

OpenCyc: The Project kol., (http://www.opencyc.org/)

SUMONP01

Origins of the Standard Upper Merged Ontology: A Proposal for the IEEE Standard Upper Ontology Working Notes of the IJCAI-2001 Workshop on the

IEEE Standard Upper Ontology Niles, I., and Pease, A, (http://ontology.teknowledge.com/#FOIS) 2001 KSLSTANF

Knowledge Systems, AI Laboratory (KSL) of Stanford University kol., (http://www ksl.stanford.edu/)

AIAI

AIAI Enterprise kol., (http://www.aiai.ed.ac.uk/project/enterprise/)

BUSMANONT

The Open Source Business Management Ontology (BMO) kol., (http://www.jenzundpartner.de/Resources/RE_OSSOnt/re_o ssont.htm)

CPREDICT

climateprediction.net - project page kol., (http://www.climateprediction.net) BOINC, NERC, DTI

VIVISTAXO

Vivisimo Clustering and Taxonomies - A Marriage Made.. Where? kol., (http://vivisimo.com/docs/taxonomies.pdf) 2003 Vivisimo, Inc.

STUMBLEUP

StumbleUpon - network of people and pages kol., (http://www.stumbleupon.com/)

CRFREENET

CRFreeNet - projekt neziskové broadband telekomunikacní síte v Ceské Republice kol., (http://www.czfree.net/)

ANOTCHS04

Towards the Self Annotating Web Philipp Cimiano, Siegfried Handschuh, Steffen Staab, (http://www.www2004.org/proceedings/docs/1p462.pdf) 2004 Institute AIFB, University of Karlsruhe

ONNAVCR00

Ontology-Supported and Ontology-Driven Conceptual Navigation on the World Wide Web Michel Crampes and Sylvie Ranwez, (http://portal.acm.org/citation.cfm?id=336361) 2000 Laboratoire de Génie Informatique et d'Ingénierie de Production

AGENTRB95

A Planning Theory of Practical Rationality Proceedings of AAAI'95 Fall Symposium on RationalAgency. 1-4. Bell, J., (http://www.dcs.qmw.ac.uk/~jb/ratio/ptra.ps) 1995

VALPRBM00

Value Propositions David Bovet and Joseph Martha, (http://www.fastcompany.com/magazine/37/ideazone.html)

2000 FastCompany OJB

Apache OJB - project page kol., (http://jakarta.apache.org/ojb) Apache Software Foundation

EONUKMZ98

The Enterprise Ontology The Knowledge Engineering Review - Vol. 13, Special Issue on Putting Ontologies to Use Mike Uschold, Martin King, Stuart Moralee, Yannis Zorgios, (http://www.aiai.ed.ac.uk/project/pub/documents/1998/98 kerentontology.ps) 1998

XERM

Xermes - nástroj pro generování uživatelského rozhraní , (xermes.sourceforge.net)

GHJV95

Design Patterns: Elements of Reusable ObjectOriented Software. Reading Mass. E. Gamma, R. Helm, R. Johnson, J. Vlissides, 1995 Addison Wesley 0201633612

BMRSS96

A System of Patterns: Pattern-Oriented Software Architecture F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, 1996 John Wiley & Sons. 0471958697

ZOPE

ZOPE - aplikacní server zalozený na jazyce Python , (http://www.zope.org)

ASMZEJ03

Architektura podrizena modelu David Zejda, (http://www.oit.info/asm/) 2003 UHK

HMC00

The American Heritage® Dictionary of the English Language Fourth Edition kol., 2000 Houghton Mifflin Company 0395825172

ORAVAN

Tesla 4110U "Oravan" Martin Hájek, (http://www.oldradio.cz/ts4110.htm)

XPATH

XML Path Language (XPath) James Clark, Steve DeRose, (http://www.w3.org/TR/xpath) 1999 W3C

XLINK

XML Linking Language (XLink) Version 1.0 Steve DeRose, Eve Maler, David Orchard, (http://www.w3.org/TR/xlink/) 2001 W3C

XTMSPEC

XML Topic Maps (XTM) Version 1.0 Steve Pepper, Graham Moore, (http://www.topicmaps.org/xtm/1.0/) 2001 TopicMaps.Org

PEPP02

The TAO of Topic Maps - Finding the Way in the Age of Infoglut Steve Pepper,

(http://www.ontopia.net/topicmaps/materials/tao.html) 2002 Ontopia GARS02

What Are Topic Maps? Lars Marius Garshol, (http://www.xml.com/pub/a/2002/09/11/topicmaps.html) 2002 O'Reilly

CPPKURP00

Kurz C++, díl 31. Radek Pavienský, (http://www.eternal.cz/article.php?nID=261) 2000 Progres

CAIR02

Jade Tutorial: Application-defined content languages and ontologies Giovanni Caire, (http://agentcities.cs.bath.ac.uk/docs/jade/CLOntoSupport.p df) 2002 TILAB

OBSRLAM98

SENG 609.04 Design Pattern"Observer Design Pattern" Stephen Lam, (http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/o bserverLib.html) 1998

PATTGOF95

Design Patterns Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1995 AddisonWesley Professional 0201633612

ONTOSOW00

Ontology, Metadata, and Semiotics - Presented at ICCS'2000 in Darmstadt, Germany John F. Sowa, (http://www.bestweb.net/~sowa/peirce/ontometa.htm) 2000 SpringerVerlag

ZOOPKR98

Základy objektove orientovaného programování Ilja Kraval, 1998 Computer Press 8072260472

AMBL

Mapping Objects To Relational Databases Scott W. Ambler, (http://www.AmbySoft.com/mappingObjects.pdf) Ronin International

METADIB00

Metadata Integration using UML, MOF and XMI Sridhar Iyengar, Steve Brodsky, (http://www.omg.org/news/meetings/workshops/presentatio ns/uml_presentations/Tutorial%2041%20 %20UML_Lecture4_R2.pdf) 2000 OMG and Tutorial Contributors

SCHEMED96

The Scheme Programming Language, Second Edition Kent R. Dybvig, (http://www.scheme.com/) 1996 Electronically reproduced by permission of Prentice Hall

CLIPSMI99

Úvod do prostredí CLIPS Peter Mikulecký, 1999 FIM UHK

SMALTHU95

Skolicka Smalltalku Jan Hubicka, (http://www.ucw.cz/~hubicka/skolicky/skolicka12.html) 1995

JOX

JOX, Linking Java Beans and XML With Ease project page Mark Wutka, (http://www.wutka.com/jox.html.)

KBML

KBML - The Koala Bean Markup Language project page kol., (http://koala.ilog.fr/) Dyade

JAXB

Java Architecture for XML Binding (JAXB) project page kol., (http://java.sun.com/xml/jaxb/) Sun Microsystems

SICO99

Cluster Profiling Project, phase 1 Stéphane Simon, Michel Courson, (http://www.itl.nist.gov/div895/cmr/cluster/phase1/intro.ht ml) 1999 National Institute of Standards and Technology

HEPP03

LDAP (Lightweight Directory Access Protocol) referát Michal Heppler, (http://www.fi.muni.cz/~kas/p090/referaty/2003 podzim/skupina10/ldap.html) 2003 MUNI

XMLKOSE00

XML pro kazdého Jirí Kosek, 2000 8071698601

MERGKELL

A Few Patterns for Managing Large Application Portfolios Wolfgang Keller, (http://www.objectarchitects.de/ObjectArchitects/.) Generali Office Service Consulting AG, Austria

J2SDK150

Java(TM) 2 SDK, Standard Edition Documentation Version 1.5.0 kol., (http://java.sun.com) Sun Microsystems

XMLCJSY02

A friendly game of tug of war: XMLC vs. JSP David H. Young, (http://www.theserverside.com/articles/article.tss?l=XMLC vsJSP) 2002 The Server Side

XFORMS

XForms - The Next Generation of Web Forms project page kol., (http://www.w3.org/MarkUp/Forms/) W3C

WAFEREW

Wafer project Anthony Eden, Thomas Wheeler, (http://www.waferproject.org/index.html) SourceForge

XERMES

Xermes - interim project page David Zejda, (http://xermes.sourceforge.org) 2002

FFORMENM

File Format Encyclopedia 2.0 Michael Metz, (http://pipin.tmd.ns.ac.yu/extra/fileformat/)

PSCRPTM97

First Guide to PostScript E. Weingar, (http://www.cs.indiana.edu/docproject/programming/postscr ipt/postscript.html) 1997 Indiana University

SVG

Scalable Vector Graphics (SVG) 1.1 Specification kol., (http://www.w3.org/TR/SVG/) 2003 W3C

SOAP12

SOAP Version 1.2 Part 0: Primer kol., (http://www.w3.org/TR/soap/) 2003 W3C

TRILAYCH

Trívrstvová architektura klient-server Petr Cerha, Roman Hladký, (http://www.fi.muni.cz/~mara/odbc/3u_a/3t_a.html.iso 88591)

SAASLBM04

Service-Based Software: The Future for Flexible Software - Asia-Pacific Software Engineering Conference, Singapore P. J. Layzell, K. H. Bennett, D. Budgen, O. P. Brereton, L. A. Macaulay, M. Munro, (http://www.service oriented.com/publications/APSEC2000.pdf) 2000 Universities of Durham, Keele and UMIST

SAASWHC04

Why Software-as-a-Service? (blog) David Coursey, (http://blog.ziffdavis.com/coursey/archive/2004/12/17/5112. aspx) 2004

IBROKER04

Using Web Service Technologies to create an InformationBroker: An Experience Report Proceedings of the 26th International Conference on Software Engineering (ICSE'04) Mark Turnera, Fujun Zhub, Ioannis Kotsiopoulosc, Michelle Russelld, David Budgena, KeithBennettb, Pearl Breretona, John Keanec, Paul Layzellc and Michael Rigbyd, (http://www.icseconferences.org/2004/index.html) 2004 IEEE

P2PLTDN

Using a P2P architecture to provide interoperability between LearningObjects Stefaan Ternier, Erik Duval, Filip Neven, (http://www.cs.kuleuven.ac.be/~hmdb/publications/files/pdf version/41251.pdf) Dept. Computerwetenschappen

INTAGEM04

Inteligentní agenti Václav Matousek, (http://lucifer.fav.zcu.cz/uir/predn/P8/Folie_IntAg.pdf) 2004 ZCU

CLSERRK97

Client/Server Architectures for Business Information Systems A Pattern Language Klaus Renzel, Wolfgang Keller, (http://www.sdm.de/g/arcus) 1997 EA Generali, Austria

Ontologický model pro portály

Recommend Documents