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.