Ontologický model pro portály

Podtitul práce: Využití ontologií pro tvorbu funkčně bohatých, flexibilních a především snadno integrovatelných e-business 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 ontologického jádra aplikací, s důrazem na otevřenost použitých technologií, nástrojů a standardů.

Práce v úvodních částech systematizuje současný stav na poli webových portálů, e-business 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í struktury, 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 architektury 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.

Introductory parts of the work systematizes current state of web portals, e-business and similar applications, traces the trends and predicts the incoming advancement. Following sections consist of the selective summary of formalisms for a tangled information structure representation, with emphasis on semantic networks, ontologies and their potentialities. Especially on the sequent case studies of applications for data organisation and management, e-shop and server administration – applications which are not enriched by ontologies commonly – demonstrates 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 requirements 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.

Moje poděkování si zaslouží vedoucí práce, Mgr. Daniela Ponce za podnětné připomínky a především za to, že mě před asi třemi lety vůbec přivedla na stopu ontologií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...

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

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 poskytnout 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 E-Commerce 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 Top-level 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

I Úvod

A Cíl

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

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

B Motivace

Možná se ptáte, co mě dovedlo k námětu, který zdobí desky. Tedy, jsou to předevší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í.

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 nevhodné, 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, jednoznač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 organizač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.

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 pozoruji 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ákoliv 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.

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í integrace v mnohem větším měřítku, integrace odpovídající trendům ekonomiky nové doby. K tomu ale ještě dospějeme...

C Jak číst dál

Pokud spěcháte celou teoretickou část možná přeskočíte – jejím smyslem je pouze 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řeskočí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á jiná.

Dál to již nechám na vás; každopádně jádrem práce je rozbor meta modelu ontologie navrhovaného systému, v závěsu podle významu jsou kapitoly o provozní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 později...

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í definovaných anebo vysvětlovaných položek, někdy sloužící také jako podnadpis nejnižší úrovně.

..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ší

II Teoretická část

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 nastí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:

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, JA-SIG uPortal, Jahia, Gluecode Portal Foundation 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í.

Pan Hlavenka v [BYZNETH99] píše: „Na začátku roku 1998 se v oblasti internetových médií objevil nový pojem – portál. Představa několika webů, které budou sloužit jako vstupní brány do Internetu, rozcestníky k dalším službám, obchodům a médiím. Samozřejmě opět s určitou 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 použí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, 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 seznam.cz či atlas.cz, je dokladem neobyčejného tempa vývoje Internetu. Každopádně, takovými portály se příliš zabývat nebudeme.

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.

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, nevhodným přenesením starých modelů do dynamického prostředí elektronické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)

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 informací 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..

Podporují spolupráci týmu na sdíleném obsahu. Definují role jako autor, 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ázků, příloh.

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. Blogovací 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.

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 prohledávat, připojovat klíčová slova atd.

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řechody 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.

1.2 Kolaborativní systémy

Nemá cenu je definovat – snad jen některá jména: Bittorent, eDonkey, Gnutella, DC++, eXeem, Soulseek

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 (role-playing games).

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

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ůvodní definice wiki podle autora myšlenky a tvůrce prvního wiki systému p. Warda:

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 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 znamená 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 publikovat. [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.

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ákazní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 kategorie, porovnáním asi dvaceti kritérií jsem z dvaceti vytipovaný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 (Model-Driven Architecture). S Davidem Klímou jsme systém lokalizovali do češtiny a p. Klíma zřídil i českou stránku projektu [OPECRXK].

Mnohé podniky neznají, co znají. To vede k duplikaci činností, neefektivní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.

Počítače a komunikační prostředky mohou být cennou pomocí při získá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í know-how a přístupu k němu a v důsledku celkovou výkonnost. [KMFAQ98][ZTECHMP02]

Enterprise Eesource Planning je software, který podporuje a automatizuje 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

To, co se vám vybaví, když se řekne elektronický obchod, e-shop. Virtualizace kamenného obchodu, většinou včetně nezbytných rekvizit, jako nákupní košík nebo pokladna. Typický e-shop 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ý.

Každý může vrhnout nějakou věc do veřejné elektronické aukce. Elektronický 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.

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 vlastní 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í organizace W3C. Zajímavé jsou v této souvislosti také pokroky v oblasti multiagentních systémů. A samozřejmě, kromě standardů existuje mnoho různých proprietárních řešení.

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í kritéria hodnocení. Systém zorganizuje výběrové řízení, jednotliví účastníci zadají nabídky a zadavatel je nakonec s podporou systému vyhodnotí a uzavře obchod s vítězem. Provozovatel tržiště si nechá zaplatit 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 transparentně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 kartografické 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é, subdodavatelé, 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 internetové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 Integration for Electronic Commerce (PIEC), který usiluje o vybudování platformy, nástrojů a technik pro analýzu meziorganizačních procesů a identifikaci a modelování transakčních služeb pro virtuální podniky. PIEC pomáhá při vývoji transakč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, také označované jako rapid teaming nebo virtual teaming. Takové dynamické obchodování, vedené hrstkou schopných analytiků a manažerů, kteří místo lidí sestaví tým z celých společností. Schopnost formovat, operovat, zrušit virtuální spojení bude klíčová. Takové krátkodobé, příležitostí zřízené společnosti mohou poskytnout stejný potenciál, jako klasické vertikálně integrované korporace, ale flexibilita je mnohem vyšší. Přináší to ale problémy a výzvy jiného druhu – budová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ě just-in-time dodávky anebo alespoň tak, aby bylo vyráběno co je třeba, budování optimálních koalic, překoná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 systé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í...

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 skuteč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ě popsat – 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

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 chceme cosi pojmenovat, uzavřeme to do uvozovek. Pokud chceme pojmenovat termí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 konceptuálních strukturách vede k něčemu v reálném světě. Výrazem konceptualizační schopnosti jazyka jsou třeba slovníky.

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

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]):

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.

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.

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ř:

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

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í:

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 Aristotelový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š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).

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é popisují 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ředevší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 usuzování. Některé z nich jsou vysoce neformální, jiné naopak velmi formální a precizně 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.

Zdůrazňují vztahy dědičnosti reprezentované vazbami „is-a“ (subtyp) mezi koncepty. Výsledná síť je označována jako generalizace nebo zahrnují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, informace v těchto sítích je považována (alespoň teoreticky) za nezbytně správnou – mluvíme-li o takové síti, jde vlastně o jednu velkou definici.

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í explicitně 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

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.

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

Vytvářejí nebo rozšiřují svou reprezentaci získáváním znalostí z příkladů. 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řipojených k uzlům a/nebo hranám.

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í mechanismy 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ému rozlišování, případně porovnávání vhodnosti jednotlivých systémů reprezentace 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 – ontologie. 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í.

Množiny definic ve formálním jazyce, založeném na diskrétní matematice 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.

John Sowa nabízí třeba takovouto, na význam a obsah zaměřenou definici: „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 budou působit dvě protichůdné síly – jedna bude usilovat o co nejrychlejší aplikaci v obchodě, průmyslu, školství, kdekoliv. Druhá bude takové snahy brzdit, protože bude zdůrazňovat kvalitu návrhu a z ní plynoucí snadnou správu, rozšiřitelnost a znovupoužitelnost...

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. top-level 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 konceptů. 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ší barié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.

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

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

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 konečný výčet, spíše jen o náznaky...

1.4.3.a Ontologie a datové modelování

Podle [DATAONT05] je zde mnoho podobného, například v nabídce konceptuá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 vytváří 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. Odliš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í objektové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:

Osobně si myslím, že je to rovněž perspektivní a zajímavá možnost využití ontologií. Vidím zde ještě další souvislosti, především s principy modelem řízené architektury (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

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í procedury, jako např. if-needed, if-changed, if-added, if-deleted, které jsou automaticky aktivovány, jestliže nastanou příslušné situace.

Mezi rámci mohou existovat vztahy dědičnosti, díky nim lze distribuovat informace bez nutnosti duplikace. Rámec může být specializací jiného obecnějšího rámce (vztah typu specialization-of) 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.

Rámce jsou preferovaným schématem reprezentace v modelovém a případovém usuzování (model-based reasoning, case-based reasoning). 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ý [ONTOLED03]. 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.

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 ontologie – v průběhu návrhu, ověřování, validace, správy, nasazení, mapování, integrace, 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 automatizované inference.

Jedním z komplikujících faktorů je to, že je třeba získat konsenzus široké komunity, 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é ontologie tvořené velkou skupinou lidí, jimiž vytvořené kousky se pospojují do výsledné ontologie. Druhým extrémem jsou velké zejména top-level ontologie, jejichž vývoj je obvykle pevně řízen zodpovídajícím konzorciem či standardizač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 popis ontologie a pomoc v podobě neformálního grafického zobrazení.

1.4.4.a Nástroje

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

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 spojuje. 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 stromu, 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.

Existuje mnoho specializovaných nástrojů, které pomáhají tvořit, spravovat i využívat ontologie. Většina z nich podporuje několik formá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, DL-workbench, 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ředevším aplikační server pro sémantický web nazvaný Kaon [KAEVOH04] univerzity Karlsruhe.

1.4.4.b Činnosti

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.

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í

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

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

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

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 top-level ontologie a ontologie pro podniky a obchod.

1.5.1 Top-level ontologie

1.5.1.a 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

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

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 top-level ontologií, proto si je zde vyjmenujeme; posbíral jsem je z více míst na jejich webu:

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, MILO (MId-Level Ontology) a související doménové ontologie 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 SUO-KIF. Významy nejsou závislé na konkrétní implementaci inferenčního mechanismu, ovšem systém pro inference 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:

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. Vlastníkem je IEEE, konzorcium ji vyvíjelo pro svobodné použití. Rozšiřující ontologie jsou zveřejněny pod GNU General Public License.

Bez povšimnutí nelze nechat také to, že SUMO disponuje šablonami pro generová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.

1.5.1.d Další zajímavé projekty

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

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 usuzová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:

1.5.2.b AIAI Enterprise

Projekt štědře financovaný britskou vládou, cílem je propagovat používání znalostní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. Smyslem 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 konceptů (aktivity, aktéři, čas, cíle, zdroje, prodeje) vč. příkladů instancí, který pomůže získat přehled o tom, co konkrétně ontologie řeší:

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 řízením projektů, řízením požadavků, řízením obchodní výkonnosti (v podobě vyrovnaných výsledkových listů).

Vytváří základ pro integrovanou, nezávislou znalostní bázi řízení podniku, ze které 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 zabý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 centrálního repozitáře pro návrh programu s možností generovat jiné reprezentace:

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 neviditelná 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é nedostatečné technické parametry sítí s Internetem v čele (rychlost, spolehlivost, bezpeč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í komunikaci mezi počítači, jednotlivými systémy. Takovou spoluprací by mohly vznikat další hodnoty – pro lidi.

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é elektronické obchody (amazon.com)... a zejména indexační a prohledávací servery s Googlem 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á nebezpečí.

Je vůbec nějaká alternativa? Je možné vnést řád do aplikací a služeb nekoordinovaně 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 pochopení, 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 jednotlivé 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ů.

2.1 Přehled a zvládnutelnost

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ý.

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é zachytit alternativy, doplňující informace, výhody, použité technologie, příklady použití, varianty..

Ontologie je prostředkem domluvy. Překlene tak bariéry dané rozdí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..., postupy, technologie, definice... a leccos dalšího.

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ýznamu 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.

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 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 zpracová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ě podstatně lépe. Dramaticky by se účinnost této metody zvýšila, kdyby byly dokumenty explicitně doplněny alespoň o základní vazby s ontologickými koncepty. [VIVISTAXO]

2.2 Spojení

Podniky a instituce jsou prostoupené informacemi ve všemožné podobě, 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 nezávislých webových služeb, ale také pro spojování nejen v rámci organizace ale i mezi organizacemi – to jsme ale již párkrát zmínili.

Redundance zvyšuje náklady - znovu a znovu jsou vytvářeny, shromažď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 duplikace sdílena, a tak by redundance i nekonzistence mohla klesnout anebo by se alespoň stala lépe kontrolovatelnou.

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ůsoby.

2.3 Komunikace a vzájemné porozumění

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 porozumí 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ěsnější propojení informací a procesů reálného světa a informací a procesů 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.

Čím dál více popularity si získává architektura P2P systémů – koneckonců 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 charakteristik 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. 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]

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 nikoliv pouze jako prosté konzumenty, ale jako spolupracovníky.

Ať doplňují ontologii, ať popisují informace meta informacemi z ontologií, ať se cítí jako součást celku, ať v to všem vidí možnost seberealizace. Budou z toho mít radost a my získáme zpětnou vazbu, vytvoří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í personalizace. Pomáhá uživatelům ve správném uchopení a použití webu.

3.1 Obsah, tvorba a údržba

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 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 kategorizace instancí na základě technik rozpoznávání vzorů, automatizovaný 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.

Informační portály či informační služby agregující mnoho zdrojů přidávají novou hodnotu tím že agregovaná data třídí, hodnotí, porovná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í.

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

Díky tomu bude snadné stejnou myšlenku prezentovat mnoha formami, 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 zastaráním nějaké publikace budou zapomenuty i její stále platné nosné myšlenky.

3.2 Využití

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á.

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 anotaci dokumentů, ale i pro specifikaci dotazů. Pomocí může být i personalizovaný informační asistent jako samostatný program, nejspíše s architekturou 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.

Budou-li 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.

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

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.

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

4.2 Procesy a spolupráce

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 komunikovat 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 pomocníkem vzájemnému porozumění i v této oblasti.

Viz v textu roztroušené poznámky o informační úzkosti, informačním opaření apod.

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

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 kategorizace, perzonalizace apod.

4.3 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ějaký obsah a poskytovatelů, kteří jej nabízejí.

Mnoho multimédií je v současné době anotováno primitivními prostředky – příkladem mohou být ID3 tagy MP3 dokumentů nebo ú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í, organizace, sdílení... vše o čem jsme již mluvili zde platí na sto procent.

4.4 Správa sítě

Pro zachycení práv a oprávnění v síťovém prostředí jsou nejčastěji používány stromové LDAP databáze nebo jejich obdoba.

Podoba mezi strukturou těchto dat a ontologiemi je zřejmá. Reprezentace 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).

Pokud by byly uzly síťové infrastruktury popsány jako koncepty ontologií, 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 pomohlo, kdyby jednotlivé prvky infrastruktury byly anotovány vhodnou ontologií – agenti by pak mohli snáze učit smysl a význam prvků, spojů, tras, procházejících dat apod.

C.5 Podle architektury

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

Pan Bell navrhl v práci [AGENTRB95] univerzální architekturu inteligentního agenta, vhodného zejména pro práci v prostředí webu. Architektura 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étní doméně a použití jsou senzory a efektory.

Takoví agenti by mohli provádět cokoliv – hledat novinky v oboru, posuzovat 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.

Nejde nikoliv o konkrétní architekturu, spíše o konkrétní výraznou nebo dokonce klíčovou charakteristiku. Jsou to systémy, které reflektují 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.

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, které 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 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 neaktuá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:

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ákazníkem jednotlivě, sběr a analýza informací o konkurenci, propojení systémů subdodavatelů, zvládnutá logistika a řízení zásob... V tom všem pomohou ontologie.

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.

Ř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ů jde především o matching, setkání konkrétní poptávky s konkrétní nabí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 - starožitnosti, bazary, autobazary, vrakoviště, antikvariáty, burzy sběratelský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 ztroskotá – jak má sběratel zjistit, že konkrétní známka, kniha, komoda, nedostatkový 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.

O tom jsme již také mluvili, snad jen zopakuji klíčové pojmy - integrace partnerů pomocí ontologického modelu, virtuální firmy, automatizace 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ů:

Představme si digitální knihovny s plnými texty miliónů publikací, důsledně anotované podle vhodných ontologií, digitální muzea s obrazový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 minimální spotřebou nebo věrnou 3D vizualizaci – potřebujeme ještě vůbec jejich kamenné podoby?

Vezměme si nějakou digitální mapu (třeba InfoMapu od PJSoft). Představme si, že by údaje o objektech na mapě byly popsány vhodnou ontologií. 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 doplňovat provozní doby čerpacích stanic, doporučovat trasy podle mnoha kritérií..

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řinejmenším ontologicky anotovány nebo přímo do podoby ontologie převedeny.

Třeba sestavení rodokmenu (které dnes znamená usilovnou, mravenčí, skoro detektivní práci) by bylo otázkou několika kliknutí myší..

Ontologie vlády, správních úřadů, místní samosprávy – interoperabilita, efektivní komunikace:

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. Nezapomenu 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 zachycena ontologií. Podle toho připadají v úvahu dva typy:

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

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ůznorodé, 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 reprezentaci 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.

A Evidence a organizace dat

A.1 O co jde

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ě libovolné). Především vše, k čemu se buď pravidelně vracím nebo alespoň soudím, že to v budoucnu bude třeba.

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..

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 fotoaparátů, videokamer, ale třeba i syntetizátorů nebo různých autorský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 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žité (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 dodatečné komplikace, které pramení z vyššího stupně sdílení a kooperace. Znamená to řešit otázky jako

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. Takový 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.

I profesionálním systémům pro správu dokumentů a dat chybí sdílený slovník kategorií 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é ontologie a ontologií samotnou.

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)...

Uživatel při prohledávání možná často skončí u prvního trochu použitelné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:

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žší) normalizovanou součást.

Vše by spravoval jeden systém, maximálně flexibilní. Výhoda je zřejmá – 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 obsluhu, 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í.

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í postupy jednotlivých uživatelů. Konsolidace procesů povede k úsporám.

Kvalitní systém, který by splňoval popsané požadavky by mohl dosáhnout hromadného rozšíření v různých odvětvích. To by byla jistě výhoda, 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íme-li 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.

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 odejít s pracovníkem, který je jejím nositelem. Kodifikace v rámci znalostní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 pomě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:

V případě že by se nevěnovalo dostatek pozornosti výběru evidovaných charakteristik, sledované vlastnosti by byly irelevantní k potř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.

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ž centrálně, distribuovaně po odděleních, nebo každý sám, více či méně systé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 takovým, se budou bránit.

Systém by měl umožnit postupné zavádění, aby nedůvěřiví dostali potřebný čas.

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.

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.

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

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.

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 rozboru rizik.

Důležitou vlastností by bylo omezení/přiznání úrovně přístupu k ontologii podle role uživatele. Úložiště kategorií ontologie by bylo pravděpodobně čitelné pro pořizovače, měnit by ho mohl pouze kompetentní 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čů databázi upravoval (případně by autorizoval úpravy jejich). U jednouživatelského nasazení role pořizovače a správce splývají v jedinou.

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

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í prezentač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 architektury pokud

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ě orientované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.

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:

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 rutinní 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.

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.

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á.

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 vyhledávacím dotazům.

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á.

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.

což ale rozhodně snadné není, alespoň při současném stavu poznání v příslušných oborech. Ovšem bude-li systém dobře navržen a zejména budou-li 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é funkce začlenit do dotazovacího modulu.

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 top-level 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ě specifické 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 koncentrová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 systém přínosný. Minimálně by umožnil již nyní data organizovat s ohledem na budoucnost. A to by mělo být hlavním cílem jakékoliv evidence, organizace a systematizace.

Ú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í ontologií bude předmětem další části práce.

Zvážíme-li náklady a přínosy pokročilých technologií, možnosti (technické i finanč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é

5.4 Stav

Již jsem vytvořil primitivní prototyp. Sice by se dal použít pro organizaci omezené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:

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

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.

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žňuje přehrávat audiovizuální data apod.).

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 metadata ztracena či oddělena od jimi popisovaných entit.

Formát pro zachycení metadat je takovýto – použit je vlastní na XML založený jazyk:

Dotazovací modul pro jistotu chybí úplně. Přikládám dvě obrazovky uživatelského rozhraní, které umožňuje popisovat data, budovat ontologii a procházet tím, co již bylo zpracováno. Komponenty uživatelské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.

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:

Vše ostatní, co nemá charakter čí vazbu ani na centrální členění kategorií, 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?

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 charakteru, multimediálních datech a také na programech. Konkrétně například u programů z hlediska jejich zařazení do popisovaného systému v roli dat jsem zatím skončil u sady takovýchto metadat:

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:

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 nasazení 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 – existuje mnoho publikací, které odpovídají na otázky co je třeba evidovat, jaké výstupy 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

Sice poměrně primitivní, ale pořád přesto relativně účinný způsob prohledá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řipadá fulltext

Poslední jmenovaný by mohl časem sloužit i při analýze obsahu dokumentu 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é doplněn o schopnost interpretovat regulérní výrazy, wildcards, apod.

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 sledovat.

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 trochu připomeneme o co jde a myšlenky rozvedeme více směrem k praktické aplikaci.

B.1 O co jde

Zákazník se bude vracet na server, který ho přesvědčí svou přehledností, 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řekonání nevýhod elektronického obchodu (slabé stránky), tedy toho, že chybí osobní kontakt se zbožím, prodavači apod. Technologie umožňuje například sbírat ohromné množství informací o zákaznících – co nakupují, ale i co si pouze „osahají“ v regálech, kdy přicházejí, co je baví, jak rychle se po obchodě pohybují..

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ů.

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

B.2 Běžné řešení bez ontologií

Produkty elektronického obchodu je zvykem organizovat do tabulek relační databá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 jednoduchý systém kategorií. Vazby mezi kategoriemi (natož mezi jednotlivými produkty), 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 obchodní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 databá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í

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 by bylo snadné integrovat, transformovat, modifikovat, vše značně automatizovaně.

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é kategorie podle mnoha hledisek, jednotně zachycené parametry a vlastnosti konkrétních produktů, pro to vše by byly ontologie maximálně vhodné. Uživatel by mohl prohledávat s mnohem vyšší relevancí, díky sémantice automatizovaně porovnávat, a to nejen v rámci jednoho e-shopu, ale i mezi nimi. Snadno by nacházel alternativy, vhodné doplňky a kombinace a další vztahy a souvislosti.

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.

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.

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á reprezentuje 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 rekompilaci). 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ě rychle 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:

Ty největší přínosy by z využití ontologií plynuly pokud by se co nejví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é..

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 prodávajícího zde příliš nefungují. Jakmile se navrhovaný systém skutečně rozjede, obchodníkům, kteří zůstanou mimo nezbude než se přidat, anebo živořit někde na elektronické periférii.

Myslím že toto riziko je minimální. Výsledek by z uživatelského hlediska měl být velmi přehledný a jednoduchý – na webech zapojených do projektu se snadno zorientuje (respektují jednotné konvence organizace 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é bohatě vynahradí jakékoliv nepohodlí.

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 transformace ontologií.

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

5.1 Struktura

Ta část aplikace, se kterou bude uživatel přímo komunikovat. Základem budou sady transformačních mechanismů pro spojení

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 praktické například ontologii vytvářet ve větším kolektivu zástupců různých zúčastněných stran, zatímco produkty si bude spravovat každý sám.

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 soustředěno vše obecné (obecné ontologické koncepty a vztahy, nejspíše převzaté z top-level ontologie), ale i koncepty doménově specifické.

V reálném nasazení by byla tato ontologie z větší části tvořena verifikovanými slovníky převzatými od druhých, doplněná vybranými koncepty, které prozatím nikdo jiný nepotřeboval, ale pro činnost konkrétního obchodu jsou důležité. Z těch by se po ověřování a validaci mohly č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.

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 kategorie 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ů.

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

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 rozhraní 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í.

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 obvykle ř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 skladové evidence a dalšími.

Několik z mého pohledu nápaditějších možných rozšíření zmíním dále:

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í procesu 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 objednávaných produktů, doplněných o různé požadované parametry (množství, různé doplňky apod.). Příslušné dynamické vlastnosti instancí zboží (vlastně něco jako metody) spočítají celkovou cenu...

Na druhou stranu je na zvážení, zda by ontologické pojetí nepřineslo spíše komplikace.

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živatele po webu, a také nerealizované poptávky, nedokončené objednávky..

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 informace 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.

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 vynechaných, vztahů.

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.

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 multiplatformní, výkonný a disponuje vším potřebným pro tvorbu robustní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 (hlasové rozhraní). Řešením pro budoucnost by bylo postavit uživatelské rozhraní na 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, budeme-li 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 administrač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 navrhované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 ontologií 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 prototypem následujících parametrů:

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é propagační materiály, e-maily, 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řípadě již půjde o ontologii čistě samohodnotnou.

Z požadovaných vlastností vyplývají také další nezbytné charakteristiky ontologického meta modelu:

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

Zejména u vztahů „součástí“ mezi instancemi produktů vynikla potřeba 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 konceptu noha a čtyři související vazby – tedy nebude-li 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.

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ůzný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.

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í reklamací, 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.

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

Například pro cenové kalkulace bude velmi praktické, pokud budou instance 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é instance 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ž nesloužily výhradně počítání hodnot dynamických vlastností, ale napří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.

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“.

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, zvyklý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é soustavy, časová pásma a další komplikace. Ontologický model s tím vším musí počítat.

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ě pomě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.

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

Nejsem si úplně jistý, zda má praktický význam explicitně rozlišovat koncepty a instance.

Například, uvažuji-li hierarchii skripty-JSP, 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 implementace 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 „pasivní“ 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á instance.

Nastínil jsem, myslím, docela zajímavý meta model ontologií, který možná zaslouží 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 – takový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ů.

Důležitou skupinou vazeb budou různá skládání (židle integruje nohy), dále alternativy (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řípadové 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

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:

Pokud bychom požadovali, aby systém rozuměl vztahům mezi produkty (aby například mohly fungovat kvalitní cenové kalkulace), bylo by v první řadě třeba doplnit virtuální produkty, které vhodně vyjádří (s)potř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.

Dále bychom museli stanovit kompozice jednotlivých produktů – vazby, kdy jeden produkt vyžaduje produkt jiný.

Například dynamické technologie nemají smysl bez obecného webhostingu. Webhosting nelze poskytovat bez hostingu místa na disku a konektivity. Místo na disku budou vyžadovat rovněž produkty databázové...

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í podporované systémy – PostgreSQL, MySQL apod. Webové rozhraní, IMAP a POP jsou všechno podtypy konceptu přístup k poště...

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ě technologie by byly subkonceptem aktivní technologie.

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 ontologie definující jednotlivé zdroje a jejich ceny, ze které by cenotvorné funkce u produktů vycházely.

Samozřejmě nelze zapomenout na vlastní charakteristiky produktů – jak se jmenují, v jaké verzi jsou nabízeny, kdo je vytvořil (čí je technologie 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 obchodů.

Na následujícím obrázku je znázorněn kousek ontologie. Šipky vyjadřují dědičnost, kolečka nezbytnost (závislost, kompozici) – koncept s kolečkem musí být přítomen (prodán, zahrnut do nabídky apod.), aby koncept na druhé straně vztahu mohl existovat.

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 automaticky kompromitovány i ostatní. Tvůrci monolitů mají také tendence 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ávislým.

Nuže, máme server z komponent – komponent otevřených, respektujících standardy, bezpečných, schopných dobře plnit své poslání. Oproti řešením monolitický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 nezá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 textových souborů na jednotné místo v adresářové struktuře. Každý takový konfigurač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 klientu, 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ě 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 – potřebu integrovat správu tak, aby jeden úkon (přidání zákazníka, odstranění zákazní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 jednoduchý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 logické, že neimplementuje dokonale automatizovaný systém, ale spokojí se s automatizací 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áklady a přínosy by se vyrovnaly někde u mnohem dokonalejšího řešení. Proč tedy takový 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 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 nejvhodně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 primá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:

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 sledoval konkrétní službu. Celek by byl vnitřně provázaný.

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žadavků, funkcí, vztahů, definici toho kdo a co a nikoliv jak. Rozhraní by mohlo vypadat prakticky stejně, i kdyby na pozadí obsluhovalo úplně jiné programy.

Jakmile zahlédnu závislost na konkrétní technologii, řešení, produktu, 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 bez zásahů do dat, přejít na jiný systém. Zatím neznám žádný administrač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 zobecně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.

C.4 Problémy a rizika řešení s ontologiemi

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é.

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 nedostatečnou otevřeností, platformní závislostí apod.

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..

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

Jak mohu soudit z komunikace s některými zkušenými správci UNIXový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ředí 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:

5.1 Základní komponenty

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 ontologie formou tabulek a přehledů a také by zahrnovalo třídy pro generování formulářů na zadávání údajů a manipulaci ontologií.

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.

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čí šablony. Části závislé na doménových datech by byly naplněny daty z ontologie 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.

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.

V implementačně nejjednodušší variantě systému by šlo prostě o naplnění šablon daty z ontologie, případně ověření toho, zda existují potřebné databáze, adresáře apod. a jejich vytvoření.

Po každé změně v ontologii by bylo třeba takto zaktualizovat konfiguraci 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ákazníka“ a pro jednotlivé podporované technologie (konkrétní konfigurované aplikace) vytvořit řetězce úkolů, které je třeba provést třeba nějak takto:

Potom, například pří vkládání nového zákazní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 úkoly úlohy „přidání zákazníka“ související s požadovanými službami.

5.2 Některé podstatné podrobnosti

Bavíme-li 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.

Veškeré prováděné úkoly by měly být propojeny transakčním návratový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ě voláním příslušných úkolů úlohy „zruš zákazníka“.

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í.

Vlastní úkoly by mohly mít podobu nezávislých skriptů, v rámci který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.

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í:

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 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 ontologie (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í:

Komplikovanější by byl rovněž dialog mezi řídícím jádrem a uživatelem. Mohl by probíhat třeba takto:

jádro:
dobrá, přidávám ho do ontologie, spouštím
úlohy přidání pro web a poštu..

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é úlohy (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í obsluž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 identifiková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.

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ý.

Nezbytným parametrem u naznačené flexibilnější varianty bude podpora 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, dozví 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řidat takový naslouchač. Ten bude sledovat buďto co se děje přímo s konceptem, anebo jeho instancemi (potomky) kdekoliv v podřízené hierarchii.

Celým systémem se prolíná potřeba stanovovat závislosti – které moduly se vzájemně potřebují pro správnou funkci, které úlohy předchá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 doporuč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.

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 programu, jeho odolnost proti chybně zadaným hodnotám a mnohdy to také zvýší pohodlí.

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 datový typ, sestávající ze sady rozbalovacích menu a speciálních formá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í:

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):

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

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

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.

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

Ten, v jehož prospěch jsou služby provozovány. V jeho kontextu budou prováděny úpravy. Vazbami, nejčastěji s kardinalitou n, bude napojen na koncepty jím využívaných služeb.

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

D Další možnosti praktické integrace

Je jasné, že systémy s ontologickým jádrem lze integrovat snadněji. Postupy mapová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ředevší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ě.

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.

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 marketingové aktivity a pro další činnosti.

Jako základ systému CRM by mohl sloužit adresář informací o zákazní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 systé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ůžeme hledat také směrem k systémům znalostním – viz níže

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.

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 dokumentů by mohla opět nabídnout zajímavé vazby na produkty, zákazníky apod.

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ů.

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 rozhraní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 ontologie.

To je myslím velkou výzvou v oblasti aplikace možností aplikace ontologií. Tak jako nejlepší server pro poskytování síťových služeb sestává z mnoha otevřených, vzájemně nezávislých komponent, tak by mohl vzniknout podobně komplexní, provázaný a integrovaný informační systém z původně nezávislých kusů.

V oblasti open-source existuje mnoho systémů, které řeší dílčí úlohy 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 (OpenGroupWare..) 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 projektům. Výjimkou z tohoto pravidla je třeba monolitický kancelářský balík OpenOffice.org – za ním ale stojí silná společnost (Sun Microsystems), 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.

Zajímavou oblastí jsou možnosti integrace různých subjektů – dodavatelů 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 podpořit již existující svazky nebo pomoci při formování nových. Jak vyplý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 ontologie, byť zatím možná ještě v této oblasti nedoceněné do něj jistě patří), neuspěje.

IV Projekt ontologického systému

Na základě poznatků načerpaných z případů použití ontologií v různých prostředí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].

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.

Již tuším, že systém bude velmi komplexní. Nesmí to ale být na úkor použitelnosti.

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...

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ě mechanismů 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žitých funkcí). Spíše systém pojmu jako konfigurovatelný – meta model půjde vybudovat konfigurací pro konkrétní užití.

Jakmile bude jednou nakonfigurovaný, měl by kontrolovat a vynucovat validitu ontologie na něm postavené. Nemělo by být snadné poruš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ý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álovatelnosti – především co se týče možností ukládat data do více databází, 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 dekompozicí 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....

A Meta model ontologie

Předchozí část zkoumala možnosti nasazení ontologií především tam, kde to dosud není příliš běžné. Předkládala doklady toho, proč jsou ontologie pro dané použití vhodné, jak by systém s jejich využitím mohl fungovat, jak by mohl vypadat. 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 ontologie. Jednoduchou definici tohoto pojmu jsme již uvedli v úvodu práce, sloužila především k odlišení ontologie, jejího modelu a meta modelu. Teď je čas na definici podrobnější:

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 parametrů 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, modifikovat, 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

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í vyjá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í.

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ě orientované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žaduje 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í ontologie – 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.

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řejmé že televize je koncept, je subkonceptem „bílé elektroniky“, ta je subkonceptem elektroniky a tak dále. Televize může mít další hierarchii 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 1960-62: Dvanáctikanálový televizní 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á clona, 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 jednoduchý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álkový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...

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ýrobce 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 subinstanci 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ě ontologií 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ů charakteristických rysů.

Nebo trochu jiný problém. Například jedna konkrétní televize je v něčem výjimečná – má nedopatřením neobvyklou 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 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ávrhu 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í abstraktně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ý realizuje 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á.

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 zamyslet 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.

Vraťme se k příkladu s televizi. Půjdeme-li po stopách dědičnosti, zjistíme, že subkoncepty se od rodičů vyhraňují několika způsoby:

Dokonce můžou některé vlastnosti či vztahy rušit, což ovšem přinese 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 budou 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šechny 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:

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:

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 automatizovaně usuzovat, zda je entita konceptem nebo instancí na dané úrovni podrobností.

Klíčovým přínosem takového řešení bude zjednodušení návrhu ontologie – nebude 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 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ě zatratit. Zabudoval bych ji do systému pouze jako jednu variantu meta modelu. Tak bych tedy prozatím uzavřel dilema instance.

1.2 Entity

Slovník [HMC00] definuje jako „něco, co existuje jako určitá a diskré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.

Slovník definuje jako „neodvozený od ničeho jiného, základní, výchozí nebo původní“.

Opět, ontologický význam docela odpovídá – jsou to ty entity, které jsou na vrcholech hierarchií, nejsou definovány jinými entitami.

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ě:

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 hodnotu 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, kategorizuje, katalogizuje nebo jinak uspořádává externí data.

Je zřejmé, že hranice mezi těmito typy ontologií není ostrá a nejběžnějším případem 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 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ématických map. Vážně pojatou specifikaci tématických map vypracovalo konzorcium 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].

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.

I u odkazů na externí zdroje musí být možné stanovit, v jaké roli je externí 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.

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 podporovaný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ějaké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íme-li se o hierarchii, 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 nedefinuje nové. Ani nevymezuje hodnoty atributů stanovených u předků v hierarchii 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í.

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é definovat, do kolika kategorií jednoho typu (třeba typ hostitel) může jedna entita patřit.

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 subkategorie 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 krabič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.

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:

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

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

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 uvedené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.

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.

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

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 podporovat navrhovaný meta model.

Pokud entita zboží definovala atribut záruka, pak odvozená entita elektronika jej přejala.

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 specifické 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 nedefinovanou hodnotu.

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

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 pravda, ž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ží-elektronika-televize.

Vztah elektronika-televize 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 obchodu 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.

Z jejich pohledu televize zbožím být nemusí. V takovém případě nebudou souhlasit s naší ontologií jako sdíleným komunikačním jazykem, protože vazba zboží-televize by narušila vnímání světa jejich informačním systémem.

Ve sdílené ontologii by měly být zachyceny pouze takové vztahy, které platí dostateč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šeobecné spokojenosti. Řešení nabízí vícenásobná dědičnost. Hierarchii díky ní budeme 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.

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:

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 který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řekrý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 situaci 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.

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 vyrovná 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í redefinice v nejnižší části problémy také nezpůsobí. Pokud ale dojde v kritické části ke změně, nelze použít žádný obecný postup pro zjištění hodnoty vespod kruhu – můžeme volit kteroukoliv cestu vedoucí kritickou částí kruhu a cesty jsou rovnocenné.

Žá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ý jednoznačný výběr cesty, anebo zajistit, aby návrhář taková pravidla nadefinoval, 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 hierarchie), 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...

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č..

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.

Konkrétní hodnota (datová položka) či předpis pro její odvození, přiřazená konkrétní instanci 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í entitě, vazba mezi entitou a atributem není rovnocenná – instance atributu entitě patří. Jedna instance atributu patří právě jedné entitě.

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

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).

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

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:

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.

Například takto by mohla vypadat definice specifických typů z oblasti webhostingu; upozorňuji že jde jen o příklad, opravdové definice 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:

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.

Hodnota má maximálně jednu datovou položku. Datová položka odpovídá typu.

Je datový typ složený z dalších typů. Odpovídající atribut má maximá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 dílčímu datovému typu. Každá položka je kvalifikovaná identifikátorem dílčího typu. Dílčí datové typy se mohou lišit. Mohou být jednoduché, násobné, komplexní i komplexní násobné.

Příklad: typ osobnijmeno (jmeno:string, prijmeni:string): jmeno Jan prijmeni Novák

Kterýkoliv typ, jednoduchý i komplexní, může být použit na místě užití 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.

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ů).

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.

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íč.

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

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ž používáním.

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ů.

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ů, relevance domény je nový pojem. Relevance přidává k datovému typu konceptuální rozmě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ězcový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í disponovat odpovídajícími prostředky. Relevance domény pomůže porozumět datů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 zachytit jako datový typ číslo s relevancí dny (ve významu počet dní řekněme od 1.1.1900).

2.2 Prostředky pro zvýšení robustnosti

2.2.1 Mechanismy vyžádání

Výchozí mechanismus, entita i její potomci mohou a nemusí specifikovat hodnoty.

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.

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.

2.2.2 Mechanismy podsouvání

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 hodnoty nedefinované. Mohou ji ale explicitně překrýt.

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

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ě evidovat vlastnosti, které přímo vyplývají ze vztahů a vlastností jiných, již evidovaný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ů..

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.

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 samostatný prvek ontologie, jednotlivé instance vazeb jsou od něj odvozeny.

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ý.

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).

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

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 libovolná entita, obecněji ale každý prvek, tedy například i atribut nebo jiná vazba.

Ty informace, které nedokážeme zachytit pomocí prostředků specifický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é

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

Mají význam v obou směrech, byť podle směru pohledu se jejich charakter 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

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

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 jeden úč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 konceptuá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 modelových vazeb přenést do modelu samotného, a tak zvýšit jeho univerzálnost a flexibilitu. 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ů, které jsou obvykle vyčleňovány mimo základní hierarchii modelu.

3.2.2 Vztahy modelu

Do této kategorie patří ty typy vztahů, o které jsme se doposud zajímali především – vztahy použitelné ve vlastní univerzální potažmo i v doménově specifické ontologii.

Vsadíme je do širší hierarchie, která odhalí zajímavé souvislosti. Když zmiňuji hierarchii, 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:

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 definovanými v uznávaných top-level 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 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í

Č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.

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:

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

Úč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ředevší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 koleno – 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é.

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 komplikovaly život.

3.3.2 Násobné

Násobnost vazby je jiný pojem. Násobná vazba může být i bilaterální, ale minimá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 prodáváme máslo po celých krabicích. V jedné krabici je dejme tomu 40 kusů. Nadefinovali jsme si koncept máslo a koncept krabice.

Jak zachytíme naznačený vztah? Řekněme že jde o orientovanou typovou vazbu

je
umístěno/obsahuje

. Ve směru máslo-krabice 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:

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 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:

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ů. Rozhodovací řetězce mají jednoduchou strukturu, jsou přehledné a snadno pochopitelné a umožňují poměrně přesně specifikovat, co je povoleno a co nikoliv.

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 podle jednoznačně daného pořadí.

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

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ů.

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ů vazby. Budou vykonána pokud finální ukončující rozhodnutí dopadne kladně.

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:

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:

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 rozhodnutí:

Ukončující rozhodnutí, vazba je povolena (allow) a k tomu navíc doporuč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.

Vazba je nejen povolena, ale dokonce vyžadována – bez ní bude ontologie 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.

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

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é shody.

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á rozhodnutí 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 vazby. 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 technologií a implementací, půjde téměř jistě o vztah implementuje. Takové pravidlo můžete zachytit třeba takto:

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

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

Pro situaci splňující podmínky testu bude automaticky vybrán konkrétní 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

Je-li 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 potomek nedědí vazby předka.

Třeba nová verze programu již nepodporuje zastaralý protokol, který podporovala verze předchozí.

Na druhou stranu, pokud umožníme rušit již ustavené vazby, přijdeme o podstatný 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:

Potomek zdědí všechny vazby předka. Nikde v hierarchii se vazby nemohou ztratit.

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í.

Napadá mě veselá analogie s dědictvím v občanskoprávním smyslu – 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í variantě. 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 potř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:

Situace, kdy vazba dvou prvků má za následek vznik nebo zánik vazby úplně jiný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 šetří č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ícekrá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 explicitní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.

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

Takové vyjádření, o němž je možno v souvislosti s konkrétní entitou jednoznačně prohlásit, zda platí.

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

4.2 Predikát

Například systém JADE zná pojem „identifikující referenční vyjádření“, v originá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 programovacích jazycích (Prolog apod.).

Zamyslíme-li se nad predikátem, zjistíme, že je třeba vymezit minimálně dvě věci:

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é považuji následující možnosti:

Platí, pokud entita disponuje uvedeným atributem. Jeho hodnota není pro platnost rozhodující.

Platí, pokud entita disponuje uvedeným atributem a jeho hodnota odpoví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ů takových datových typů, které porovnání umožní a u nichž je mechanismus porovnání definován.

Platí, pokud entita disponuje uvedenou vazbou a přitom nezáleží na tom, jaké entita je jí ve vazbě partnerem.

Platí, pokud entita disponuje uvedenou vazbou a partner splňuje další podmínku.

Stejný mechanismus bude možné použít pro hledání všech členů kategorie:

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.

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ší potomky.

4.3 Efekty pravidel

V případě použití pravidel při interaktivní práci s ontologií si vystačíme s predikátem – interpretaci a využití nalezené množiny prvků ontologie provede uživatel. 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 navrhneme některé další:

Je to postup, který prvky splňující podmínky predikátu dynamicky zařadí do kategorie.

Jde o mechanismus odvozování vztahů na základě podmínek v predikátu pravidla.

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 „technologie“, je to alternativa“

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 entita produkt, nesmí být zároveň technologie:

Za zmínku stojí, že dynamické atributy, přestože jsou jim charakterem blízké, mezi pravidla nepatří, protože místo s hodnotami logickými (pravda/nepravda) mohou pracovat i s jinými, v zásadě libovolný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

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.

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 široké 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 parametry 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ějaká 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é databá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 ontologie, 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í.

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ě, 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ů pracují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ž nebude 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čitě 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říchodu 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.

Návrhový vzor, definuje vztah jeden-ku-mnoha mezi objektem-subjektem a libovolným množstvím objektů-naslouchačů tak, že vždy když se změní stav subjektu, všechny naslouchající objekty jsou automaticky informovány a mohou na změnu reagovat. [OBSRLAM98]

V našem případě budeme pro účely definice mechanismu naslouchá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ředkové. 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ředkovávající spojení s vnějším světem.

1.2.2 Využití pro RSS

O využití tohoto systému jsme již mluvili, když jsme hledali možnosti využití ontologií v případových studiích. Mluvili jsme například o tom, že tento mechanismus 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í budou moci sloužit jako základ velmi snadno implementovatelného systému 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 zaregistrovat k odběru pro něj zajímavého kanálu.

Šéf bude sledovat nové zakázky, zákazník nové produkty ve vybraný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é.

1.3.1.a Nakládání s potomky

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římí potomci smazaného prvku budou připojeny vazbou isa přímému předkovi smazaného prvku.

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.

1.3.1.b Nakládání s instancemi atributů

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

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.

1.3.1.c Nakládání s vazbami

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

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.

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á hierarchie nemá valný smysl. Proto je tady možnost nastavit, co se má v takové situaci stát:

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

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 nezbytná, pokud chceme pokrýt širokou paletu aplikací, jak jsme naznačili.

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. Souhlasí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:

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. Nastavení 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:

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 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, lidově ř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í definice validity je i splnění podmínek nastavení meta modelu. Invalidní změny budou 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.

2.3 Konfigurovatelné vlastnosti meta modelu

Téměř jistě zde nezmíním všechno, na mnohé další možnosti pravděpodobně narazíme až časem, při implementaci nebo používání. Myslím že další konfigurovatelné 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.

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

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

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

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

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

2.3.4 Vazby

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 vyexportovat, a tak dát k dispozici ostatním.

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

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í kompatibilních profilů usnadní integraci.

Pokud se partneři dohodnou, že oba použijí například profil charakterizač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 donastavit. V této souvislosti je vhodné definovat co je to

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.

Profil k jednotlivým volbám připojuje příznak, zda je o nastavení nemě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.

2.4.2 Vybrané profily

Úplný a bezmocný profil, po kterém by měl sáhnout začínající uživatel. 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 konfigurovatelný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řipojeny odpovídající dekorátory.

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

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

Profil odpovídající definici jak je uvedena třeba v [GARS02] nebo v [XTMSPEC].

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

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 terminologických versus axiomatických ontologiích více třeba [ONTOSOW00].

2.4.3 Znovupoužití profilů

Z příkladů profilů je zřejmé, že jejich šíře je různá – od definice jediného parametru až po kompletní nastavení. Zjevně by bylo praktické umožnit

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

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:

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

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ů.

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

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

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é koncepty, případně provádět jiné podobné úpravy, které spadají spíše do fáze návrhu.

2.5.2 Základní módy

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

Zejména v souvislosti s potřebou rozdělovat role a spravovat oprávnění jednotlivých uživatelů bude třeba tyto mechanismy rozvést podrobněji, umožnit definovat různé režimy a zejména módy podle oblasti v ontologii.

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 definovali 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

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 doposud 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 budoucími nadstavbami – zejména s tím, co budou od jádra vyžadovat a jaké technologie 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.

Pokud uživatel odešle nějaký požadavek, řekněme dotaz, povede to k řetězu akcí. Uživatelské rozhraní zformuluje dotaz v podporované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 koneckonců nehrozí poškození integrity. Zjistí, že objekty, které reprezentují 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é naslouchače o zahájení zpracování dotazu. Perzistenční jádro zformuluje příslušný SQL dotaz, který odešle do databáze. Databáze odpoví, 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í. Dotazovací modul sestaví odpověď ve svém jazyce a tu předá uživatelské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.

Je zřejmé, že komunikace nebude triviální, a to jsme vůbec nezmínili další systé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.

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 používání.

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

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.

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í nedílnou komponentou je systém pro řízení a hlášení událostí.

Jak již bylo několikrát opatrně naznačeno, vše potřebné - definice konceptů entit a vazeb, instancí entit a vazeb, modifikace, základní prohledá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.

Jsou to data a dokumenty uložené jinde než v ontologii – články, obrázky... 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, objektové 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.

2.1.1 Relační model

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

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 systé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..

Prosím ale pozor - nezavrhuji zde relační databáze jako takové ani mohutnou relač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 RDBMS 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]

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ž nestačí a byly překonány objektově orientovaným modelováním. Toto doporučení možná není lehké přijmout, ale čím dříve začnete, tím lépe pro vás.

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 relač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ů (document-management). V čistém XML modelu není snadné realizovat dynamičnost – data jsou pouze data a samo o sobě nic neumí. Navíc hrozí podobná nebezpečí 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 volbou se zúží volba programovacího jazyka na ty objektově orientované.

Samotný objektový model sám o sobě samozřejmě žádnou flexibilitu či robustnost 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ě nebude stačit.

Pro dokreslení uvádím diagram pokroku v oblasti architektur. Půjčil jsem si jej z [METADIB00]. Ukazuje postupný odklon od relač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 obory dosti blízké námi navrhovanému systému.

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

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 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 je jazyk pro programování symbolických výpočtů. Jeho název, odvozený ze slov PROgramování v LOGice, naznačuje, že jazyk vychá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 databázových a expertních systémech, při počítačové podpoře specializovaný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 konstrukce 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 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 reprezentovat poznatky: pravidly - jsou určena k heuristickým poznatkům založ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 integraci 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ždopá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í 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 proprietá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 který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é platformy. 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řitelnost 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 technologiemi, 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, například z hlediska výkonu či bezpečnosti, zatímco jiná (nová, lepší, rychlejší, bezpeč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 kteréhokoliv z počítačů by funkčnost aplikace měla zůstat nedotčena.

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

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

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 je další silně (byť nikoliv čistě) objektově orientovaný programovací jazyk založený na interpretaci bytekódu. Má silnou podporu 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 podporovatelem je firma Sun Microsystems. Ale kromě standardní implementace 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ů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 je interpretovaný, interaktivní, objektově orientovaný jazyk. Obsahuje velké množství modulů, které podstatně usnadňují práci. Interpret 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 svobodně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:

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.

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.

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é.

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.

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řenositelné 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řenositelných) jazyků, která je vlastní mnoha interpretovaným jazykům. Použijeme-li 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šemu, co budeme využívat.

2.2.4 Jazyky interpretované s bytekompilací

Jazyky interpretované s bytekompilací jsou další generací jazyků interpretovaný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.

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řenositelné knihovny.

2.2.5 Volba jazyka

Otázkou je, který jazyk konkrétně je nejvhodnější? Odpověď nemůže být naprosto 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 nativního.

Co třeba Smalltalk? Je dobře navržený, výkonný, čistě objektově orientovaný, interpretovaný 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ěř jistě nehrozí, že bychom museli použít cokoliv nativního proto, že nenajdeme vhodný nativní ekvivalent. Interpretery rovněž existují a jsou svobodně k dispozici.

K řešení postaveném na Pythonu se přikláním, zejména když si vzpomenu na studii 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 e-business – šéfové velkých firem naopak neuzná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ů.

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řeberné 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áti-dal :-).

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 databází, XML databází, LDAP struktur nebo třeba něčeho úplně jiného.

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 souboru. 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í aplikač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.

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 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 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 serializace je nadstavbou standardní serializace. Proces je rozdělen do dvou fází: Všechny objekty jsou serializovány do java.io.ObjectOutputStream 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].

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ýkonem. [JAXB]

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.

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:

Avšak volně nabízené a otevřené OODBMS jsou stále (již několik let) v experimentá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řitom používané a stále nejpopulárnější ze všech. Přispívá k tomu jejich jednoduchost, efektivita, obecně nižší nákladnost. Existuje i mnoho poměrně pokročilý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.

Takzvaný impedanční nesoulad vyplyne na povrch, když porovnáme upřednostňované řešení přístupu. U objektového řešení je zvykem objekty procházet tak, jak jsou vystavěny příslušné závislosti, zatímco relač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žadovalo 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 specifikovat 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.

3.5 Mnoharozměrné databáze

Je technologie, která umožňuje pohlížet na data tradiční relační databáze jako na mnoharozměrnou strukturu. Příklad inspirovaný [SICO99]:

Tento model včetně implementace a nezbytných nástrojů umožňuje rychlé, přirozené zpracovávání dat podél všech rozměrů. Má význam zejména pro velké databáze, kde jsou potřeba postupy označované jako data mining. Součástí mnoharozměrného pohledu mohou být hierarchie a mnoharozměrná aritmetika. OLAP analýza může být implementována nad tradičními (zejména relačními) databázemi, 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 je specifická databáze určená pro ukládání stromových datový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é implementace (OpenLDAP). [HEPP03]

3.6.2 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 libovolnou částí XML dokumentů.

Někdo možná namítne, že to vše lze obvykle provádět i bez specializované databáze s využitím rozhraní DOM. XML databáze k tomu přidávají možnost dokumenty 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řeba 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 standard, jemuž se dostane podpory ze strany dodavatelů řešení úložišť.

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 databá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 objektové. Použití JDO rozhraní usnadní programátorům práci tím, že se nemusí 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 nejsilně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 je komponentní architektura pro distribuované aplikace, která může být využita spolu s JDO. Komponenty EJB nabízejí svůj mechanismus pro ukládání dat, a to CMP. Na rozdíl od JDO je použití CMP omezeno pouze na komponenty EJB, ale zase umožňuje distribuované transakce, přístup k distribuovaným objektům a rovněž nabí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 instalovat 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íme-li 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 pracujeme v heterogenním prostředí, které musí integrovat data z různých zdrojů – ontologie 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 chyba. Architektura podřízená modelu [ASMZEJ03] naopak doporučuje:

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á desí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 standardů všude, kde je to možné.

Jakarta OJB (původně ObjectRelationalBridge, po kompletním přepracová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 jednoduchý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.

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 open-source. 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.

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í zobrazovací ř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 rozhraní 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.

Co se dotazování a prohledávání týče, v systému zatím uvažujeme předevší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ší neobjektový 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é rozhraní (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škrtá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 napří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étní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.

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ředcích pro budování uživatelského rozhraní se obvykle vyznačují například těmito přednostmi:

V Javě byl takovou sadou komponent AWT, tento balík je ovšem zastaralý, nahradil ho nověji JFC, jehož současné verze jsou známy pod kódovým jménem 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:

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.

4.2 Scénář „z intranetu“

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é nezbytné softwarové vybavení klienta, proto je použitelný prakticky výhradně na intranetech. Časem, s rozvojem Internetu, se to ale možná změní.

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áme-li vše výše uvedené dohromady, nepřekvapí nás, že tato technologie si udělala špatné jméno svou nespolehlivostí a nestabilitou 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 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 model-view-controller architektura. I přes svou značnou popularitu toho MVC příliš mnoho neříká a prakticky cokoliv o sobě může prohlašovat, že je implementuje MVC přístup.

Klíčová myšlenka MVC by se mohla shrnout slovem „oddělenost“. Jednotlivé komponenty aplikace, tedy

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 logické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 dynamiku. 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“.

4.3.1.a 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 iniciová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 implementaci koncepčně špatných řešení, která jsou u push technologií technicky neproveditelná. 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.

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ě.

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ě statickou stránku a „vtlačí“ do ní na požadovaná místa dynamický obsah. Statická stránka je zde jakýmsi „substrátem“ na kterém program dodávající dynamický obsah pracuje.

Příkladem produktu, který implementuje push přístup je open-source 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í dynamického obsahu a snadno ho včlení do stránky se zachováním jednotného vzhledu. Tento postup schematicky znázorňuje obrázek, který jsem si půjčil z [XMLCJSY02]:

4.3.2 Formuláře

Obdobou desktopových „widgetů“ jsou pro webové vývojáře tzv. formulářové tagy.

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.

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 systémů řeší navíc další běžné úkoly související s vytvářením aplikací pro tak heterogenní 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.

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, standardy 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í displeje zařízení, nesmí také vyžadovat nadbytečné datové přenosy nebo „myšově orientovanou“ 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.

4.5 Scénář „hendikepovaní“

Kromě grafických výstupů má význam uvažovat též rozhraní pro slabozraké a nevidomé, 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ě zvukový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ýhody, 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řeba 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?

Navrhovaná knihovna by neměla nijak zužovat možnosti volby uživatelského rozhraní. 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ůsobitelná 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 objektového modelu, dynamicky se mu přizpůsobovat pokud možno co nejvíce automatizovaně, 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 nejbližší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.

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 formuláře jsou interpretovány klientskou částí Xermesu a přetvořeny do konkrétní podoby komponent uživatelského rozhraní. Veškerá komunikace mezi klientem a serverem probíhá v XML.

Prozatím je vytvořen klientský modul využívající primitivní komponenty 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.

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 jednoduchým pokynem a jinak spoustu práce vykonají samostatně. Neprobíhá žádný skutečný dialog.

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 exportech do ontologií s nižší vyjadřovací schopnosti.

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.

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í neinteraktivní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í 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í textu 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.

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. Mechanizmus „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 kancelářskými balíky, jejichž nativní formáty jsou vzájemně nekompatibilní, ale i jako výstup IS.

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é transformace.

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 PostScript 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 oblouků. [PSCRPTM97] Rozdíl oproti RTF spočívá ve schopnosti stránku popsat přesně a precizně, tedy tak jak je to třeba pro profesionálnější tiskový vzhled.

PDF vychází z PS, je vnitřně komprimovaný, se zvýšenou přenositelností, podporou Unicode a mnoha jinými výhodami, princip i primární použití je ovšem stejné.

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šechny myslitelné platformy.

Principiálně zhruba odpovídá PDF, jeho vyjadřovací schopnosti jsou ale ještě o trochu lepší..

Jazyk pro popis dvourozměrné grafiky, založený na XML. SVG zná tři typy grafických objektů:

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“.

Uvedené formáty se liší tím, jaký důraz kladou na textovou a nebo spíše grafickou podobu informací, které zachycují, proto mají všechny své opodstatně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ýstupů..

5.2 Netiskové výstupy, komunikace

Již jsme o tom na mnoha místech mluvili, proto pro oživení jen pár příkladů:

Elektronický obchod postavený na ontologii bude za běhu generovat XHTML obsah – katalog produktů.

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, objednávku, reklamaci...

Na ontologii postavený elektronický obchod našeho distributora průběžně (třeba každou) automaticky aktualizuje svoje data dotazem, který odešle našemu systému. Čeká nová data ve formátu RDF a ta také pokaždé dostane.

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 ontologiemi. 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 zkoumat žádný další nástroj...

Je libo daňové přiznání v elektronické podobě, ve formátu založ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 napří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).

Pouze graficky formátované informace jsou takřka nepoužitelné jinak, zejména strojově.

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žadovat 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. Bude-li primární výstup dostateč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ý systém. Transformace proběhne „vně“. Přiložený obrázek [XMLKOSE00] demonstruje 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 primární výstup použijeme XML s vhodným schématem, a ten transformujte dle XSLT šablony do výsledného výstupu.

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.

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í koneč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:

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á použ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é.

C.6 Infrastruktura nasazení

To zde označuji jako model, v našem případě ontologický model. Modelu „slouží“

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 doposud chápali.

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 definuje mechanismy pro výměnu strukturovaných a typových dat ve formátu XML mezi účastníky v decentralizovaném, distribuované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 interakce – 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 doporučuje, jak má být zpráva zpracována a jak mohou být vhodně reprezentována data. [SOAP12]

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 integrace 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..

Na okraj poznamenávám, že obrázky jsou UML diagramy nasazení, 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é nasazení. 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í.

Z užití, kterými jsme se podrobně zabývali takto bude typicky vypadat třeba aplikace pro organizaci dat, provozovaná jediným uživatelem, 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 poskytovat 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í aplikač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 hlediska 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 celodesktopové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í na vzdálenou databázi a administrátor má dále přehled a může ontologii 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.

6.3 Třívrstevná infrastruktura

Je-li každý popisovaný systém maximálně autonomní, je to třívrstevná infrastruktura (three-tier, multilayered)

Tato varianta je každopádně nejsložitější, ale přináší mnohé výhody například: [TRILAYCH]

Tyto výhody ji předurčují pro použití ve složitých podnikových systémech, obchodních aplikacích, tam kde k jedné ontologii bude přistupovat 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)

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. [SAASLBM04]

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].

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 dynamicky 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ů.

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 nezá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 koncovým uživatelům unifikovaný pohled na data z mnoha zdravotnických zařízení a institucí. Autoři navrhli Architekturu integrace dat orientovanou na služby (SODIA). Na rozdíl od SaaS jejich systém nevyhledává poskytovatele služeb na základě funkcionality, ale spíše na poskytovaných dat. [IBROKER04]

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 diktoval co mají dělat. Místo toho vedle sebe působí předem neurčený počet nezávislých programových instancí, ty se vzájemně vyhledávají, dorozumívají, poskytují a využívají služby.

Pro komunikaci mezi agenty je zřejmě ideální Internet. Takové distribuované pojetí 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 serverů. 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ěkteré spíše podpůrné služby může poskytovat jeden nebo více k tomu určených 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 existují 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 skuteč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řejmě 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]:

Schopnost provádět uživatelem definované úlohy nezávisle na uživateli a často i bez přítomnosti nebo vedení uživatele. Uživatel jednou specifikuje co, kde a kdy má agent vykonávat, a ten provádí daný úkol pouze tehdy, když nastanou vhodné podmínky.

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.

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é architektury 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.

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í

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 manipulovatelné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í. Elektronické zprávy je třeba inteligentně směrovat a filtrovat.

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 jednoduchost. 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, heterogenní 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.

V Příloha - CD

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:

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:

VI Závěr

A Shrnutí výsledků

Prozkoumali jsme souvislosti, východiska internetových aplikací a trochu jsme je systematizovali. Také jsme prozkoumali trendy v této oblasti a pokusili jsme se predikovat budoucí vývoj. Za klíčový považujeme 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í.

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 použ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.

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 zajímavým skutečnostem a návrhům. Za všechny jmenujme třeba:

Myslím že se nám tak nakonec podařilo splnit hlavní cíl, totiž navrhnout 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 ontologií a zejména potřeby aplikací, které by na knihovně mohly být vystavěny. Nakonec jsme se zmínili o technologiích a možných architekturá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 nezávislosti, jako základem pro snadnou správu a možnost budoucího rozvoje.

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 produkč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...

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.

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/) Open-IT 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/opencrx)

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 e-Business - Nitin Nayak, Kumar Bhaskaran, Raja Das, (http://doi.ieeecomputersociety.org/10.1109/ITVE.2001.904491) 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/ppt-2005/modeling.ppt) 2005

ONTPADE05 The Web of Patterns Project - Object-Oriented Software Design Ontology ODOL - Jens Dietrich, Chris Elgar, (http://www-ist.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/nextwebgen/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_ossont.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-ker-ent-ontology.ps) 1998

XERM Xermes - nástroj pro generování uživatelského rozhraní - , (xermes.sourceforge.net)

GHJV95 Design Patterns: Elements of Reusable Object-Oriented 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.o-it.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.pdf) 2002 TILAB

OBSRLAM98 SENG 609.04 Design Pattern"Observer Design Pattern" - Stephen Lam, (http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html) 1998

PATTGOF95 Design Patterns - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1995 Addison-Wesley 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 Springer-Verlag

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/presentations/uml_presentations/Tutorial%204-1%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.html) 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=XMLCvsJSP) 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/postscript/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-8859-1)

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.icse-conferences.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/pdfversion/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