Ontologický model pro portály

Rozměr: px
Začít zobrazení ze stránky:

Download "Ontologický model pro portály"

Transkript

1 Univerzita Hradec Králové Fakulta informatiky a managementu Katedra informačních technologií Ontologický model pro portály Podtitul práce: Využití ontologií pro tvorbu funkčně bohatých, flexibilních a př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ů. Diplomová práce Autor: Bc. David Zejda Informační management Vedoucí práce: Mgr. Daniela Ponce Chrudim duben 2005

2 Anotace abstract Ontologický model pro portály 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. Ontological model for portals 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.

3 Poděkování 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...

4 Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Chrudimi dne 26. dubna 2005 David Zejda Copyright 2005 Informace, které jsou v tomto dokumentu zveřejněny mohou být chráněny jako patent. Jména produktů jsou použita bez záruky jejich volného použití. Některé názvy mohou být registrovanými známkami nebo jinak chráněny. Při sestavování textu jsem se snažil postupovat pečlivě, nicméně nemohu 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

5 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í Systémy pro správu obsahu (CMS) Kolaborativní systémy E Commerce B2C C2C B2B a B2G 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 Pojmenování a meta data Grafy Sémantické sítě Ontologie Význam Ontologický model a meta model Souvislosti s jinými formalismy a Ontologie a datové modelování b Ontologie a objektové modelování c Ontologie a rámce Ontologické inženýrství a Nástroje b Činnosti c Znovupoužití ontologií Konkrétní ontologické slovníky Top level ontologie a WordNet b Cyc c The Suggested Upper Merged Ontology (SUMO) d Další zajímavé projekty Vybrané ontologie pro podniky a obchod a KSL b AIAI Enterprise 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

6 2.1 Přehled a zvládnutelnost Spojení Komunikace a vzájemné porozumění...41 C.3 Sémantický web Obsah, tvorba a údržba Využití...44 C.4 Podle typu média Lexikografická data Procesy a spolupráce Multimédia Správa sítě...47 C.5 Podle architektury...48 C.6 Podle oborů a činností Komerční 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í Struktura Charakter Charakter logiky dotazovacího modulu Cíle Složitost modulů Kritéria posouzení úspěchu Stav...66 A.6 Klíčové parametry ontologického meta modelu...69 A.7 Významné koncepty a vztahy Základní koncepty Příklad doménově specifické aplikace 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í Struktura Charakter Uživatelské rozhraní Ostatní moduly Cíle Stav...83

7 B.6 Klíčové parametry ontologického meta modelu...83 B.7 Významné koncepty a vztahy Základní koncepty Příklad doménově specifické aplikace Produkty Tvorba ontologie...90 C Administrace serveru...93 C.1 O co jde...93 C.2 Běžné řešení bez ontologií Výchozí stav 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í Základní komponenty Některé podstatné podrobnosti Spolupráce Základní model spolupráce Architektura založená na naslouchačích C.6 Klíčové parametry ontologického metamodelu C.7 Významné koncepty a vztahy D Další možnosti praktické integrace IV Projekt ontologického systému A Meta model ontologie A.1 Koncepty a instance Dilema instance Problémy rozlišení konceptů a instancí Řešení těchto problémů a Odvozené rozlišení konceptů a instancí Entity Hodnotnost, umístění, externí zdroje Samohodnotná ontologie Meta ontologie Parametry řešení Hierarchie Kategorizace Dynamická kategorizace Dědičnost, nejprve obecně Dědičnost vícenásobná a Potřebujeme ji? b Komplikace vícenásobné dědičnosti A.2 Atributy Doména Datový typ Relevance Prostředky pro zvýšení robustnosti...137

8 2.2.1 Mechanismy vyžádání Mechanismy podsouvání Odvozený atribut A.3 Vazby Orientace a navigabilita Neorientované Orientované Navigabilita Hierarchie vazeb Vztahy meta modelu Vztahy modelu Vazby více prvků Multilaterální Násobné Prostředky zvýšení robustnosti Rozhodovací řetězce Struktura rozhodovacích řetězců Rozhodnutí v rozhodovacích řetězcích Mechanismus aplikace pravidel Automatický typ vazby Důsledky dědičnosti účastníků Dědictví vazeb Další automatické manipulace vazbami A.4 Pravidla Struktura pravidel Predikát Báze Efekty pravidel Operátory B Provozní požadavky B.1 Sledování provozu Správa změn a událostí Statistika Návrat Zachycení faktoru času Události naslouchači Probublávání zpráv Využití pro RSS Strategie vývoje Strategie likvidace a Nakládání s potomky b Nakládání s instancemi atributů c Nakládání s vazbami Strategie duplicity B.2 Konfigurovatelnost meta modelu Důvody pro konfigurovatelnost...163

9 2.2 Mechanismus vynucené integrity Konfigurovatelné vlastnosti meta modelu Provozní nastavení Dědičnost Atributy Vazby Profily nastavení meta modelu Smysl a charakter profilů Vybrané profily Znovupoužití profilů Režimy a módy Základní režimy Základní módy C Struktura a technologie C.1 Systém jako celek Základní a rozšiřující části Příklad komunikace Původ jednotlivých komponent C.2 Jádro a API Model Relační model Model založený na XML Objektový model Logické, deklarativní, pravidlové apod Platforma Přenositelnost Jazyky kompilované Jazyky interpretované Jazyky interpretované s bytekompilací Volba jazyka C.3 Zajištění perzistence Soubory Serializace XML mapování Objektově orientované databázové systémy Objektově relační mapování Objektově relační technologie Mnoharozměrné databáze Úložiště pro stromové struktury LDAP (Lightweight Directory Access Protocol) Nativní XML databáze Snahy o univerzální přístup Zvolené řešení C.4 Uživatelské rozhraní Scénář desktop Scénář z intranetu...201

10 4.3 Scénář z Internetu Vytváření dynamického obsahu a Pull b Push Formuláře Kontroler Scénář mobilní Scénář hendikepovaní Jak to tedy vyřešíme? C.5 Neinteraktivní rozhraní Sestavy zejména pro tisk Netiskové výstupy, komunikace Univerzální řešení Rizika Požadavek a řešení C.6 Infrastruktura nasazení Nevrstvená infrastruktura Dvouvrstevná infrastruktura S mohutným klientem S tenkým klientem Třívrstevná infrastruktura Software jako služba (SaaS) Data jako služba (DaaS) Nezávislí agenti Inteligentní agenti a Charakteristické rysy b Použití Infrastruktura pro navrhovaný systém V Příloha CD VI Závěr A Shrnutí výsledků B Jak pokračovat...232

11 Úvod Úvod I Úvod 1

12 Úvod Cíl A Cíl Na titulním listě jste si mohli povšimnout obecného cíle práce. Ještě než se 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. Co cílem není Tak tedy, hlavním cílem není vytvořit učebnici pro práci s ontologiemi popsat nějaký konkrétní nástroj či technologii srovnávat a hodnotit technologie vytvořit ucelený a vyčerpávající přehled čehokoliv třeba internetových aplikací To vše se ale v práci alespoň částečně objeví, ale pouze účelově, k podpoře cíle. Co cílem je Cílem naopak je navrhnout univerzálně použitelnou knihovnu pro práci s ontologiemi K tomu bude třeba prozkoumat souvislosti, východiska a trendy v oblasti internetových aplikací trochu uspořádat typy těchto aplikací probrat základní východiska ontologií, částečně i jejich současný význam a vlastnosti provést několik projektových studií pro odlišné typy nasazení navrhovaného systému a především, rozebrat vlastní systém z různých hledisek při tom všem hledat souvislosti se současným stavem poznání v oblasti ontologií a aplikovat poznatky o těch typech aplikací, v nichž by systém mohl najít uplatnění 2

13 Úvod Motivace 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í...co se mi nelíbilo Nelíbí se mi, když musím cokoliv z jednoho programu ručně přepisovat do druhého. Nemám rád duplikaci a bojím se nekontrolované redundance. Považuji za 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...a pak přišly ontologie Před pár lety jsem zkoumal přesně takové věci a hledal jsem řešení. A pak přišly ontologie nebo spíše já jsem přišel k nim... Od té doby na každém kroku 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. 3

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

15 Úvod Jak číst dál C Jak číst dál pokud spěcháte.. Pokud spěcháte celou teoretickou část možná přeskočíte jejím smyslem je 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... jak se vyznat aneb formátovací konvence Základní text je na celou použitou šíři stránky, pouze ty skutečně veliké obrázky ho občas přesáhnou. O dva řádky výše vidíte styl používaný pro uvození definovaných anebo vysvětlovaných položek, někdy sloužící také jako podnadpis nejnižší úrovně. a toto je ta vlastní definice takhle vypadá příklad, co má charakter souvislého textu a takhle zdrojový nebo pseudozdrojový kód..a ještě tohle je poznámka na okraj, která dodává nějakou zajímavou souvislost, ale pro pochopení hlavních myšlenek je vedlejší 5

16 Teoretická část Teoretická část II Teoretická část 6

17 Teoretická část Úvod a systematizace internetových aplikací A Úvod a systematizace internetových aplikací A.1 Typy webových aplikací Vraťme se zpátky na zemi a pěkně od podlahy probereme, s čím se můžeme na Internetu setkat. V tuto chvíli nám nejde o vyčerpávající seznam a ani o dokonalé členění, koneckonců ani hranice nejsou pevně definovatelné. Cílem je spíše 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: portálové systémy Existuje mnoho systémů, které se zabývají integrací komponent pro účely prezentace uživatelům. Komponentám se často říká portlety, jsou to taková malé okénka do dat z různých zdrojů z místní databáze nebo třeba z nějakého zpravodajského serveru. Tvorba portálu pak znamená především výběr a vhodnou kombinaci portletů. Příkladem portálových systémů jsou například Jakarta Jetspeed, Liferay, Exo, Pluto, 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í. portál v užším smyslu 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, 7

18 Teoretická část Úvod a systematizace internetových aplikací 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. My budeme pod pojem portál shrnovat mnohem širší paletu aplikací: portál v pojetí práce V zásadě jakýkoliv počítačový systém, který integruje heterogenní zdroje a využívá síťovou infrastrukturu. Občas se ale nevejdeme asi ani do takto široce pojaté definice, protože cílem je, aby v dalších kapitolách navrhovaný systém byl opravdu hodně univerzální. A ještě jedna věc nebudeme se příliš zabývat těmi typy webů, které má na mysli většina lidí, když mluví o webové prezentaci. webová prezentace Plní pouze roli jakési reklamní vývěsky, bezostyšně propaguje firmu nebo výrobek. Soudím, že reklamní vývěsky jsou přežitkem doby, 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) systémy pro správu dokumentů (DMS) Znalosti se stávají základem ekonomiky. Intelektuální kapitál může být nejsilnější zbraní v silné konkurenci. Je třeba zachytit a řídit tok 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.. 8

19 Teoretická část Úvod a systematizace internetových aplikací redakční a publikační systémy 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. blogy galerie 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. publikačně - aplikační systémy Redakční systém je speciálním typem obecnějšího systému. Systému, který umožní volně definovat datové objekty, jejich možné stavy a př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. 9

20 Teoretická část Úvod a systematizace internetových aplikací 1.2 Kolaborativní systémy P2P pro sdílení dat Nemá cenu je definovat snad jen některá jména: Bittorent, edonkey, Gnutella, DC++, exeem, Soulseek MUD (multi user dungeon) webmail groupware 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ěkný přehled konkrétních systémů je třeba [GRPWREB]. wiki Původní definice wiki podle autora myšlenky a tvůrce prvního wiki systému p. Warda: The simplest online database that could possibly work. Wiki je kus softwaru, který umožňuje uživatelům volně tvořit a upravovat webové stránky pomocí libovolného prohlížeče. Podporuje hyperlinky a, což tyto systémy odlišuje od čehokoliv jiného, disponuje jednoduchou syntaxí pro tvorbu nových stránek a vazeb mezi nimi. Je opravdu vzrušující a dosud nepříliš běžné povolit návštěvníkům upravit kteroukoliv stránku. Musíte při tom počítat s tím, že občas se 10

21 Teoretická část Úvod a systematizace internetových aplikací 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. systémy pro řízení vztahů se zákazníky (CRM) Customer Relationship Management, jinak též Customer Information Systems, Customer Interaction Software (CIS), Technology Enabled Relationship Manager (TERM). Aplikace, které pomáhají společnostem spravovat všechny aspekty vztahů se zákazníky. Pomáhají vybudovat trvalé vazby, obrátit zá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] znalostní systémy (KM) 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. 11

22 Teoretická část Úvod a systematizace internetových aplikací 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] systémy pro řízení zdrojů (ERP) 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 B2C obchodní dům C2C 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. Pojem to není dokonalý, ale snad trochu vyjadřuje myšlenku, že uživatelé si mohou být vzájemně zákazníkem; stejně tak obchodníkem není jedna firma, ale může jím být každý. 12

23 Teoretická část Úvod a systematizace internetových aplikací virtuální aukční síň inzertní systémy B2B a B2G 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.. 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í. e-marketplace V principu stále jednoduchá aplikace, podobná aukční síni, s tím rozdílem, že je určena společnostem. Pokud někdo potřebuje nakoupit služby, zařízení, cokoliv, zadá do takového systému poptávku a stanoví kritéria hodnocení. Systém zorganizuje výběrové řízení, jednotliví účastníci zadají nabídky a zadavatel je nakonec s podporou systému vy 13

24 Teoretická část Úvod a systematizace internetových aplikací hodnotí 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 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, 14

25 Teoretická část Úvod a systematizace internetových aplikací 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í... 15

26 Teoretická část Úvod do problematiky ontologií B Úvod do problematiky ontologií B.1 Zachycení složité informační struktury Svět okolo nás je komplikovaný. Nejsme schopni plně ho popsat, vystihnout 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 Samotný přirozený jazyk poskytuje různé prostředky konceptualizace. V minulých několika stovkách let jsme vybudovali techniku (efektivní proceduru) psaného slova. Díky ní můžeme jednoduše a automaticky generovat pojmenování jakéhokoliv konceptu. Prehistorické jazyky touto, pro nás možná samozřejmou, technikou nebo technikou ekvivalentní nedisponovaly. Konvencí je, pokud 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. dům dům dům 16

27 Teoretická část Úvod do problematiky ontologií Když chceme popisovat svět, potřebujeme definice. Zajímavých je např. sedm druhů definic, které zmiňuje Norman Swartz [DEFDICS97]: smluvní definice lexikální definice zpřesňující definice teoretické definice operační definice rekurzivní definice argumentační definice Data jsou vždy nějakým odrazem, zachycením reality data tvoří vlastní meta realitu. Meta data přidávají další rozměr datům, dodatečnou informaci, hodnotu, popisují data, jsou to data o datech. V tomto smyslu bychom ale mohli pokračovat dále meta meta data, meta meta meta data... Jak tedy popíšeme svět? Můžeme využít různé informační struktury, například (částečně podle [MATHBKS01]): množiny, pytle, sekvence, seznamy funkce, relace lambda kalkulus grafy, mříže, stromy, herní grafy propoziční logika predikátová logika (first order) axiomy, tvrzení, důkazy formální gramatika formální specifikace teorie modelu teorie množin stromy, mříže a jiné hierarchie Petriho sítě, Markovovy řetězce 17

28 Teoretická část Úvod do problematiky ontologií Za každým uvedeným formalismem je široká teorie, spousta metod, technik, nástrojů Grafy Z hlediska popisné schopnosti si ze všech těch formalismů zvláštní pozornost zaslouží grafy koneckonců, od grafů vede k ontologiím poměrně krátká cesta. graf V diagramech je graf znázorněn jako síť uzlů spojených hranami. Konkrétní vizuální reprezentace není důležitá, nezáleží na to, zda jsou hrany krátké, dlouhé, rovné, klikaté, zda jsou uzly malé nebo velké, tečky nebo čtverečky. Jde čistě o existenci vztahu. Proto je grafické znázornění chápáno pouze jako neformální pomůcka pro zvýšení názornosti, vlastní graf je primárně zachycen formálním jazykem. Následující diagramy tedy znázorňují stejný graf: Obecný graf povoluje libovolné počty rodičů a dětí, povoluje rovněž kruhy, jako např. ABCD z příkladu výše. Hierarchie obsahující kruhy je někdy také označovaná jako nestrom nebo tangled hierarchy. Pokud se na graf podíváme z jedné strany, z pohledu jednou uzlu (třeba když si představíme, že za uzel graf pověsíme), můžeme sledovat určitou hierarchii tvořenou rodiči a potomky. Podle povoleného počtu rodičů a možnosti nebo nemožnosti tvořit kruhy můžeme sledovat speciální případy, např: strom Je graf, který neobsahuje kruhy. Podle počtu rodičů a dětí můžeme rozlišovat různé varianty. 18

29 Teoretická část Úvod do problematiky ontologií Např. takto vypadá binární strom každý prvek kromě nejvyššího má právě jednoho rodiče, maximální počet potomků jsou 2 proto binární: mříž Ta vypadá zase třeba takto: 1.3 Sémantické sítě Počítačová podoba sémantických sítí měla původně sloužit umělé inteligenci a strojovému překládání, ale již mnohem dříve byly tyto sítě používány ve filozofii, psychologii a lingvistice. Nejstarší známou sémantickou síť sestavil ve třetím století našeho letopočtu řeckým filosof Poryfyros ve svém komentáři k 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 19

30 Teoretická část Úvod do problematiky ontologií šuje jeho podtypy [SEMNETS02]. Mimochodem až tak hluboko a možná ještě hlouběji sahají myšlenky dědičnosti používané nejen v definičních sémantických sítích, ontologiích, ale i objektovém programování nebo třeba v relační analýze. I moderní pojetí sémantických sítí a pojem samotný sahá hluboko do počítačové prehistorie pojem jako takový můžeme vysledovat až do r. 1968, kdy jej použil Ross Quillian's ve své disertační práci jako způsob uvažování o lidské sémantické paměti (paměti pro slovní koncepty). Sám pojem sémantické sítě je značně široký: sémantická síť O sémantickou síť jde vždy, kdykoliv je informace zachycena v grafu (viz výše), kde uzlům a hranám jsou přiřazeny významy a topologie grafu je důležitá pro tyto významy. [SEMNETG82] Jedna trochu konkrétnější definice tvrdí, že je to graf, sestávající z uzlů reprezentujících fyzické nebo konceptuální objekty a hran, které 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. definiční sítě 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, infor 20

31 Teoretická část Úvod do problematiky ontologií prohlašovací sítě implikační sítě vykonatelné sítě učící se sítě hybridní sítě mace 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é 21

32 Teoretická část Úvod do problematiky ontologií 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í. ontologie (technicky) 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. ontologie (podle použití) Sdílené konceptualizace konkrétní domény nebo rovnou celého světa. John Sowa nabízí třeba takovouto, na význam a obsah zaměřenou 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 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 22

33 Teoretická část Úvod do problematiky ontologií 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. Podle [ONTADGL02] je význam ontologií především takovýto: pro komunikaci mezi implementovanými počítačovými systémy mezi lidmi mezi lidmi a implementovanými počítačovými systémy pro automatizované usuzování pro vnitřní reprezentaci plánů a souvisejících informací pro analýzu vnitřních struktur, algoritmů, vstupů a výstupů systémů pracujících s teoretickými a konceptuálními významy a pojmy pro znovupoužití a organizaci znalostí 23

34 Teoretická část Úvod do problematiky ontologií pro strukturalizaci a organizaci knihoven, repozitářů, datových úložišť a doménových informací Myslím, že především v praktické části se dotkneme i lecčeho dalšího Ontologický model a meta model Tyto pojmy si musíme trochu vyjasnit, protože dále s nimi budeme pracovat. Tak tedy ontologie model ontologie Vlastní, konkrétní slovník, obsahuje koncepty, instance, vazby... a popisuje nějakou část našeho světa. Tvar konkrétní ontologie, nejde nám o detaily. meta model ontologie Popisné a inferenční schopnosti modelu. Formální definice toho, co ontologie může obsahovat, co jsou uzly, co vazby, jaké typy vztahů připouští, jak je možné specifikovat pravidla a funkce apod. Ontologie je jedna a má svůj model. Více ontologií ale může být vystavěno podle stejného meta modelu 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... 24

35 Teoretická část Úvod do problematiky ontologií 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ě 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: jsou formálnější, a tedy snadněji automatizovatelné mohou být snadno převedeny do méně formálního popisu (grafické notace) použitím stylu, opačně je to podstatně složitější není žádný centrální model softwarového designu ani ústřední bod kontroly. Vizí je, že softwaroví inženýři použijí ontologie pro zachycení návrhových vzorů (design patterns) a zveřejní je na webu. S podporou indexačních služeb, jako např. google, budou snadno dohledatelné díky kvalitním meta informacím. nabízejí možnosti inference 25

36 Teoretická část Úvod do problematiky ontologií mohou být snadno rozšířeny přidáním dalších konceptů typických pro konkrétní programovací jazyky nebo jejich verze (java asserty, vnitřní třídy, meta tagy) nebo přidáváním AOP konceptů. tato rozšíření mohou být implementována jako nezávislé zdroje, které mohou být pospojovány dohromady. Výsledkem bude síť návrhových vzorů. 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ů c Ontologie a rámce Rámce jsou dalším, dosud nezmíněným druhem formalismu. rámce Jsou to struktury pro reprezentaci stereotypních situací a odpovídajících stereotypních činností (scénářů). Inspirují se lidskou schopností na základě zkušeností si utvářet rámcové myšlenkové struktury. Rámce se pokoušejí reprezentovat obecné znalosti o třídách objektů, znalosti pravdivé pro většinu případů, tedy počítá se s tím, že mohou existovat objekty, které porušují některé vlastnosti popsané v obecném rámci. Rámec je tvořen jménem a množinou atributů. Atribut (rubrika, slot) může dále obsahovat položky (links, facets), jako např. aktuální hodnotu (current), implicitní hodnotu (default), rozsah možných hodnot (range). Dalšími položkami slotu mohou být speciální 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 generalizationof). [EXPERTD01] Dědičnost může být u rámců i vícenásobná jeden rámec je potomkem více jiných. 26

37 Teoretická část Úvod do problematiky ontologií 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ý [ON TOLED03]. Nedělám si valné iluze o smyslu definovaných rámců, ale i tak bude užitečný. Je z něj zřejmé například to, že nejdříve se obvykle nadefinují typy, a třeba až konkrétní potomek může doplnit konkrétní hodnoty. Nic takového na druhou stranu meta model rámců striktně nevyžaduje. class-def Keyword class-def Similarity slot-constraint keyword1 value-type Keyword slot-constraint keyword2 value-type Integer class-def KeywordSimilarity subclass-of Keyword subclass-of Similarity slot-constraint keyword1 has-value BlahBlah slot-constraint keyword2 has-value 10 Rámce mohou sloužit k popisu prvků ontologie a také se tak občas používají. Uzel v takovém případě bude vlastně rámcem bude mít sloty, bude zapadat do hierarchie dědičnosti apod 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ý 27

38 Teoretická část Úvod do problematiky ontologií 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í a Nástroje formální specifikace ontologie 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ší. neformální vizualizace Nástrojem neformální vizualizace ontologie je graf. Tak jak jsme zmiňovali u sémantických sítí, jde pouze o uzly a vazby mezi nimi, tedy o to, zda tam uzel je nebo není a stejně tak zda hrana je a jaké uzly 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. aplikace pro práci s ontologiemi Existuje mnoho specializovaných nástrojů, které pomáhají tvořit, spravovat i využívat ontologie. Většina z nich podporuje několik 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ře 28

39 Teoretická část Úvod do problematiky ontologií devším aplikační server pro sémantický web nazvaný Kaon [KAEVOH04] univerzity Karlsruhe b Činnosti dolování ontologií Ontologie může být budována výhradně ručně, inženýr vytváří veškeré koncepty a vazby mezi nimi. Může být ale také alespoň z části načerpána (vydolována) z nějaké jiné reprezentace. Existují nástroje na generování ontologií z textu, z databází, z dalších ontologií a z různých kombinací datových zdrojů. Podobně automaticky získaná ontologie ale samozřejmě vyžaduje dodatečnou revizi a validaci. mapování ontologií Jde o hledání vazeb mezi ontologií a neontologickými entitami nebo naopak připojování ontologických meta informací datům. Příkladem intenzivního využívání těchto postupů je tvorba tématických map ( topic maps) c Znovupoužití ontologií spojování ontologií (merge) Výsledkem jsou stále dvě ontologie, ale s definovanými společnými místy a přesahujícími vztahy. Význam má především tam, kde se očekává budoucí rozvoj a údržba spojovaných ontologií. integrace ontologií Výsledkem je jedna nová ontologie, která zahrnuje informace z ontologií původních. Jde o nejtěsnější možné spojení. Integrovaná ontologie je již nezávislá na ontologiích původních. 29

40 Teoretická část Úvod do problematiky ontologií transformace ontologií evoluce ontologií 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 Top-level ontologie a WordNet WordNet WordNet je online lexikální referenční systém, inspirovaný současnými psycholingvistickými teoriemi lidské lexikální paměti. Anglická podstatná jména, slovesa, přídavná jména a příslovce jsou zorganizovány do systémů množin, kde každá reprezentuje příslušný lexikální koncept. Mezi koncepty jsou různé vazby, například jsou takto zachycena synonyma. [WORDNET] Pro práci s ontologií je možné použít webové rozhraní nebo speciální klientský program b Cyc Cyc Znalostní server Cyc je velmi rozsáhlá multikontextová znalostní báze a inferenční stroj vyvinutý společností Cycorp [CYCORP]. 30

41 Teoretická část Úvod do problematiky ontologií 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: porozumění textu a příprava dokumentů porozumění řeči inteligentní strojový překlad generování textu expertní systémy tréningové simulace umělá inteligence her online komerce online poradenské služby cílený marketing čištění a integrace databází čištění a integrace tabulek (spreadsheets) aktivní menu a formuláře praktická encyklopedie odpovídání na otázky vyhledávání dokumentů a fotografií distribuovaná umělá inteligence zprostředkování prodeje zboží a služeb chytrá rozhraní inteligentní simulace pro hry 31

42 Teoretická část Úvod do problematiky ontologií bohatá virtuální realita sémantické dolování inteligentní agent osobní poradce pro nakupování Inspirativní je i architektura systému: Existuje i open source verze Cyc ontologie a nástrojů pro práci s ní [OPENCYC] c The Suggested Upper Merged Ontology (SUMO) 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í konceptů a 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: komunikace země a regiony 32

43 Teoretická část Úvod do problematiky ontologií distribuované výpočetní systémy ekonomie finance inženýrské komponenty geografie vláda vojenství severoamerický klasifikační systém průmyslu lidé fyzické elementy mezinárodní otázky doprava viry světová letiště terorismus zbraně hromadného ničení Na rodině SUMO je založena spousta výzkumných projektů i funkčních aplikací z oblastí prohledávání, lingvistiky a usuzování. SUMO je také jedinou formální ontologií, která je plně namapovaná na lexikon WordNet zmíněný výše. 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. 33

44 Teoretická část Úvod do problematiky ontologií d Další zajímavé projekty Dolce Popisná ontologie pro lingvistiku a kognitivní inženýrství. OntoMap OntoKhoj Portál pro ověřování a porovnávání upper level ontologií a lexikálních znalostních bází. Portál pro ontologické inženýrství Vybrané ontologie pro podniky a obchod 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: Product ontology Component Assemblies 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 34

45 Teoretická část Úvod do problematiky ontologií 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ší: Effect Resource Activity performs is performed Doer Subactivity Time Range Person Machine Org.unit šálek kávy pít kafe skill Franta hold (permission) c Business Management Ontology (BMO) Open source integrovaný informační model pro spojení informačních technologií s prostředím obchodu. Zabývá se návrhem obchodních procesů, správou a 35

46 Teoretická část Úvod do problematiky ontologií ří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: 36

47 Teoretická část Synergie ontologií a webových aplikací C Synergie ontologií a webových aplikací C.1 Vize: Ontologický Internet Již jsme se lehce zabývali tím, jak Internet změnil zaběhnuté pořádky. Že přinesl mnohem větší změnu, než třeba telefon, že má potenciál nahradit nejen telefon, částečně poštu, ale také televizi, rozhlas, knihovny, banky, podatelny úřadů a částečně možná i úřady samotné... Internet poskytuje především technickou infrastrukturu, propojuje celý svět. Jeho obsah ne nesmírně rozsáhlý, ale také silně decentralizovaný. To je jistě výhoda přináší odolnost, umožňuje aplikovat principy volného trhu můžeme říct, že 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 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. 37

48 Teoretická část Synergie ontologií a webových aplikací 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ů. 38

49 Teoretická část Synergie ontologií a webových aplikací 2.1 Přehled a zvládnutelnost popis Ontologie dokáží velmi kvalitně a precizně popsat problém, situaci, produkt, službu nebo obecně cokoliv. Popis je vysoce strukturovaný, a tedy mnohem snáze uchopitelný, strojově zpracovatelný. souvislosti porovnávání 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. ovladatelnost a prohledávání clustering 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 39

50 Teoretická část Synergie ontologií a webových aplikací 2.2 Spojení 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] agragace, integrace, unifikace 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. snížení redundance 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. 40

51 Teoretická část Synergie ontologií a webových aplikací znovupoužití Konceptualizovaná data by bylo mnohem snadnější použít, a to nejen jednou a jednoúčelově, ale mnohokrát a i doposud netušenými způsoby. 2.3 Komunikace a vzájemné porozumění propojení Ontologie by mohly vytvořit komunikační platformu pro spojení lidí vzájemně, lidí a technologií, technologií mezi sebou. Rozdíly mezi výsledky práce lidí a strojů by se mohly postupně stírat. Pokud vám například robot v centru technické podpory dobře 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. sdílení Čí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. 41

52 Teoretická část Synergie ontologií a webových aplikací spolupráce 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 automatizace Představme si web, který anotuje a popisuje sám sebe i to mohou systémy postavené na ontologiích nabídnout. Úspěch sémantického 42

53 Teoretická část Synergie ontologií a webových aplikací agregace 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. Směry dalšího výzkumu jsou například: sémantický hypertext, konceptuální spojování, vypočítatelná hypertextová struktura (metahypertext) hromadná a automatizovaná kategorizace webu katalogizace služeb na webu generování webu ze znalostí (ontologií) sémantické dolování (semantic web mining) 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í. spravovatelnost, trvalá hodnota 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í vzhledu obsahu významu 43

54 Teoretická část Synergie ontologií a webových aplikací 3.2 Využití navigace logiky 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. Ontologie mohou nabídnout nové možnosti navigace. Můžeme zvažovat různé úrovně ontologické podpory navigace navigace ontologií podporovaná, na ontologii založená anebo ontologií řízená. Například ontologií podporovaná navigace může vypadat takto [ONNAVCR00]: 1. Systém načte profil uživatele ten obsahuje cíle a omezení. 2. Automaticky vygeneruje vážené sémantické odkazy mezi dokumenty. 3. Vazbám dodá role, významy (půjde o typové vztahy). Při tom bude brát v úvahu profil a doménovou ontologii a ontologii diskuze a vyjednávání. 4. Mezi množstvím odkazů vybere nejrelevantnější vůči kontextu a záměrům uživatele. 5. Poskládá zdroje s využitím vhodných pedagogických a vypravěčských strategií. 6. Výpočty provádí v souladu s omezeními časovými a jinými ekonomickými, jak jsou stanoveny v profilu. hledání Přínos ontologií je zřejmý, již jsme jej zmiňovali s jejich použitím vzroste výkonnost a přesnost. Ontologie mohou být použity pro anotaci dokumentů, ale i pro specifikaci dotazů. Pomocí může být i perso 44

55 Teoretická část Synergie ontologií a webových aplikací nalizovaný 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. objevování (semantic discovery) 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ů. setkávání (matching) 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 přirozený jazyk Jednou z hlavních aplikací ontologií je právě reprezentace, přenos a sdílení jazykových konstrukcí, vazeb a významů. Obor, který se tím zabývá se nazývá ontologická sémantika. Cílem je pomoci strojům pochopit text, hledat vazby mezi různými jazyky, což může být základem kvalitních překladových nástrojů, výkladových slovníků apod. text Mohli bychom ještě mluvit o extrakci významu z textu, dolování pravidel, hodnocení novosti.. 45

56 Teoretická část Synergie ontologií a webových aplikací 4.2 Procesy a spolupráce spotřební elektronika Především výrobci spotřební elektroniky (Sony..) se předhánějí ve zveřejňování vizí, kde spotřebiče budou vzájemně komunikovat a 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. procesy Ontologie jsou často využívány pro modelování, dekompozici, restrukturalizaci a simulaci procesů. toky dokumentů 4.3 Multimédia 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. streamovaná multimédia Množství takového obsahu na Internetu silně roste. Nemyslím si, že by měla být multimédia reprezentována ontologiemi, ale ontologické anotace (metadata) by usnadnily setkání uživatelů, kteří požadují nějaký obsah a poskytovatelů, kteří jej nabízejí. multimédia obecně Mnoho multimédií je v současné době anotováno primitivními prostředky příkladem mohou být ID3 tagy MP3 dokumentů nebo 46

57 Teoretická část Synergie ontologií a webových aplikací 4.4 Správa sítě ú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. práva a oprávnění 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. Například Active Directory ve Windows nebo třeba Netware NDS, edirectory... 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). plánování a správa síťové infrastruktury 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. 47

58 Teoretická část Synergie ontologií a webových aplikací 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.. weboví agenti 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. adaptivní systémy Nejde nikoliv o konkrétní architekturu, spíše o konkrétní výraznou nebo dokonce klíčovou charakteristiku. Jsou to systémy, které 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. znalostní systémy Velká kategorie programů pro zachycení, manipulaci, sdílení a využívání znalostí a korporátních vzpomínek. Ontologie jsou nedílnou součástí nebo dokonce jádrem mnoha z nich. Stále běžnější jsou tyto systémy jako nástroj znalostního managementu ve velkých společnostech. Myslím že je zde ale ještě velký potenciál, především v oblastech, 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 48

59 Teoretická část Synergie ontologií a webových aplikací 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ě Komerční Podle [VALPRBM00] je pro úspěšné elektronické obchodování nezbytné řídit se pěti pravidly: Jedinou možností je dát zákazníkům na výběr, ale chytřeji než dosud dostatečná volnost, ale nikoliv přesycení; výběr z možností, které jsou specificky uzpůsobené podle profilu... Rychlejší je lepší, zákazníci platí za rychlost Uděláte dobře, pokud nebudete dělat všechno Zacházejte s partnery jako s partnery Poznejte, co zákazníci potřebují aneb super služby a perfektní objednávky Co pomůže naplnit tyto cíle? Například kvalitní popis produktů a nabízených služeb, sběr a analýza informací o zákaznících, unikátní zacházení s každým zá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. B2C se sériovým zbožím Myslím že význam ontologií je zřejmý u klasických obchodů s běžným zbožím pro snadnější hledání, porovnávání, efektivnější transakce... o tom všem jsme již mluvili. B2C a C2C se specifickým zbožím Řekl bych ale, že ještě větším přínosem by byly ontologie obchodům se zbožím specifickým, kde každý kus je originál. U takových obchodů 49

60 Teoretická část Synergie ontologií a webových aplikací B2B a B2G 6.2 Nekomerční 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... Zatím jsme se zajímali především o aplikaci v komerčních oblastech; možnosti použití ontologií a sémantického webu je ale široce přesahují, zasahují do snad všech oblastní lidské činnosti. Jen pár příkladů: knihovny, muzea Představme si digitální knihovny s plnými texty miliónů publikací, důsledně anotované podle vhodných ontologií, digitální muzea s 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? 50

61 Teoretická část Synergie ontologií a webových aplikací mapy, GIS.. 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í.. archivy Možnosti využití ontologií jsou zde nebývalé. Prakticky celé archivní fondy (matriky, historické záznamy, výroční zprávy) by mohly být př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ší.. státní správa, místní samospráva.. Ontologie vlády, správních úřadů, místní samosprávy interoperabilita, efektivní komunikace: vertikálně i horizontálně mezi jednotlivými úřady sdílení informací, snížení redundance, úspory stohů papíru, pracovních nákladů úředníků i občanů...; nadřízené úřady by mohly snáze hledat a vyhodnocovat nejen chyby, ale i rizika a hrozby; například policie jednotlivých států a bezpečnostní a zpravodajské služby by mohly spolupracovat a sdílet konceptualizovaná data pro vyhledávání hrozeb, pátrání po nebezpečných osobách, sledování transportů zbraní, drog, chráněných zvířat a rostlin... mezi úřady a občany občan by již nebyl horkým bramborem, který si jednotliví úředníci přehazují tak dlouho, dokud nevychladne a nepřestane ho to bavit; každý úředník by díky znalostnímu systému postavenému na ontologii věděl vše úředník ka 51

62 Teoretická část Synergie ontologií a webových aplikací e-learning tastrálního úřadu o daních z převodu nemovitosti, finanční úředník o sociálních dávkách.. Význam ontologií pro e learning je myslím rovněž zřejmý... 52

63 Projektové studie Projektové studie III Projektové studie Jak vyplývá z teoretické části, možností použití ontologií ve webových aplikacích je nepřeberně. Tuto rozmanitost budu mít na paměti při analýze požadavků vyvíjeného systému. Smyslem práce není detailně zkoumat každé možné použití, pokusím se ale vybrat několik reprezentativních možností, kterým se budu věnovat více a ze kterých především následně odvodím požadavky na systém. 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: samohodnotná Ontologie hodnotná sama o sobě, obsahuje vlastní doménová data. samohodnotná ontologie reálný svět meta ontologie Ontologie je v v pozici metainformačního systému nad daty reprezentovanými převážně jinak. 53

64 Projektové studie Projektové studie meta ontologie externí datová základna reálný svět 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. 54

65 Projektové studie Evidence a organizace dat A Evidence a organizace dat A.1 O co jde Již několik let se potýkám s problémem, jak organizovat například informace převážně textového charakteru programy 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.. jakákoliv jiná data Mám na mysli především různá multimédia obraz, zvuk, hudbu, video S dostupností digitalizačních zařízení (skenerů, digitálních 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 55

66 Projektové studie Evidence a organizace dat 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 efektivní tok dat bezpečnost (security) distribuovanost uvnitř sítě mnoho otázek spíše psychologického charakteru A.2 Běžné řešení bez ontologií Zvažoval jsem využití některých klasických systémů pro správu dokumentů, ale nenarazil jsem na žádný, který by byl současně snadno použitelný a zároveň dostatečně flexibilní, aby splnil základní požadavek: uspořádej cokoliv! V současné době vše organizuji v poměrně propracované adresářové struktuře na pevném disku a v databázovém katalogu uchovávám rozličné meta informace. 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. 56

67 Projektové studie Evidence a organizace dat 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. najdu co hledám Bez použití kvalitního systému pro správu dat se snadno může stát, že se vůbec nepodaří najít relevantní data. Stát se to může jednotlivci, který organizuje svá osobní data, tím spíše to hrozí v organizaci kde spolupracuje lidí více a mnozí často nemají ponětí o práci některých svých kolegů. Důsledky toho, že se nepodaří najít to, co je třeba mohou být různé, ale obecně negativní. Často to povede k dodatečným nákladům spojeným s opětovnou tvorbou již vytvořeného (redundance, duplikace)... najdu to nejrelevantnější Uživatel při prohledávání možná často skončí u prvního trochu použ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: 57

68 Projektové studie Evidence a organizace dat 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. vnější konzistence pro správu i užívání 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í. konsolidace procesů Před zavedením zvažovaného systému každý uživatel má svůj způsob práce s dokumenty. Použití systému sjednotí nejen postupy jednoho uživatele pro dosahování různých cílů, ale také doposud nezávislé a leckdy nekompatibilní, nesourodé a třeba i nepříliš kompatibilní postupy jednotlivých uživatelů. Konsolidace procesů povede k úsporám. univerzálnost znamená širokou uživatelskou základnu Kvalitní systém, který by splňoval popsané požadavky by mohl dosá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. uchování cenných expertíz Znalosti, které pomáhají popsat, třídit a najít potřebná data bývají mnohdy nashromážděny mnohaletou zkušeností. Zkušenost může ode 58

69 Projektové studie Evidence a organizace dat jí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: špatný způsob kategorizování 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. rizika přechodu nechuť a obavy moc práce 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. 59

70 Projektové studie Evidence a organizace dat Jako klíčová se v této souvislosti jeví jednoduchost obsluhy systému. A.5 Kostra architektury ontologického řešení 5.1 Struktura Z jakých funkčních celků by se systém mohl skládat? V diagramu je znázorněn hrubý návrh architektury včetně vazeb mezi moduly, o jejich významu se zmíním dále. Zákaznické rozhraní Správa kategorií Správa produktů jádro Katalogizační ontologie Databáze produktů Rozhraní do IS cizích podniků Rozhraní do IS podniku Modul událostí pořizovací modul Umožní lidskému operátorovi ( pořizovači ) doplnit k datům informace, které i chytrý počítačový systém těžko zjistí. správa ontologie doménových kategorií Přestože každá položka dat by měla být vhodně obalena svou meta informací nezávisle na jiných, pro účely prohledávání bude třeba na množinu těchto informací nahlížet jako na celek. 60

71 Projektové studie Evidence a organizace dat správa rolí 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. modul fyzické organizace 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. dotazovací modul Brána, kterou uživatelé prahnoucí po datech použijí pro formulování dotazů. Vnitřně by se skládala z minimálně 2 co nejvíce oddělených částí vrstvy logiky a prezentační vrstvy. Výchozí implementací 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 61

72 Projektové studie Evidence a organizace dat problém není formálně vyjádřitelný řešení není založeno na deterministických reproduktivních postupech princip řešení nemá teoreticky dobré a ucelené podklady, užité znalosti nejsou formálně dobře vyjádřitelné užívané údaje jsou vágní, nepřesné, nespolehlivé, vzhledem ke své nedostupnosti neúplné Které moduly systému splňují uvedená kritéria? Začněme pořizovacím modulem ten by měl být hodně flexibilní, měl by disponovat i nějakými heuristickými schopnostmi, aby uživatele navedl k zadání správných kategorií metadat. To vše ale lze řešit konvenčními prostředky, tedy v procedurálním objektově 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. Zbývá logika dotazovacího modulu, což je ovšem něco docela jiného Charakter logiky dotazovacího modulu Shrňme, jaké by měl mít schopnosti. Z nich vyplynou i podrobnější požadavky na zachycená a zpracovávaná data: maximum informací čerpat samostatně přímo z dat Lidé by při takovém čerpání dat mohli asistovat data validovat, zpřesňovat, doplňovat apod., ale systém by je měl ušetřit maxima 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. Mohl by uvažovat například takto: má příponu MP3 => je to hudba má příponu MP3 => možná obsahuje ID3 tag možná obsahuje ID3 tag => načti meta informace Pro úlohu by možná mohl sloužit samostatný modul. 62

73 Projektové studie Evidence a organizace dat zpracovat nejasné, neúplné dotazy Klíčovým parametrem systému, který by jej měl odlišit od běžných systémů pro správu obsahu by měla být výjimečná vyhledávací schopnost. Uživatele nechceme nutit uvažovat podle počítače, ale naopak. odpovídat na základě neúplných meta informací Systém by měl být rozumně použitelný i v době, kdy bude probíhat výstavba katalogů pokud uživatel (investor) neuvidí první známky přínosu co nejdříve, těžko bude věnovat svůj čas, energii či finance dalšímu nasazování systému. Kromě toho žádná ontologie není dokonalá, vždy jde o určitou aproximaci či odraz světa. Systém by ale měl vytěžit maximum z toho, co k dispozici má. snadno vstřebávat doménové zvyklosti pro pokládání dotazů Mám na mysli doménově specifickou terminologii, strukturu dat, vzájemné souvislosti dat i metadat. Systém by měl být schopný zachytit doménové znalosti nezbytné pro porozumění dokumentům, jejich obsahu a významu, především s cílem porozumět případným vyhledávacím dotazům. Určitou drobnou znalostí je dejme tomu vztah: PDF dokument=>čitelný Acrobat Readerem Systém by měl takovou znalost obsáhnout a také využít všude, kde to bude vhodné. Z toho vyplývá, že souběžně s naplňováním stromu společných kategorií meta informací by měla být doplňována rovněž odpovídající pravidla v logice dotazovacího modulu, o kterých bude souzeno, že z hlediska účelu nasazení mohou být praktická. chápat význam kategorií Třeba co je to program, zakázka prvním stupněm by mohla být schopnost rozeznat synonyma, antonyma a jiné lexikální vztahy. rozpoznávat přirozený jazyk V ideálním případě by vyhledal vhodné informace na základě dotazu typu 63

74 Projektové studie Evidence a organizace dat Chci navrhnout www stránku, ale neumím moc syntax HTML jazyků což ale rozhodně snadné není, alespoň při současném stavu poznání v příslušných oborech. Ovšem 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. propojit obecné znalosti se znalostmi v doméně 5.3 Cíle 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í 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. 64

75 Projektové studie Evidence a organizace dat Ú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]) Kritéria posouzení úspěchu Stanovme si nějaká kritéria pro posouzení výsledků. Projekt bude v pokusné implementaci úspěšný, pokud s jeho pomocí bude možné 1) připojovat takové meta informace k datům, která umožní zachytit vlastnosti, relevantní místa v kontextu kategorií domény a základní souvislosti s jinými daty z domény 2) přizpůsobovat centrální databázi kategorií 3) data automaticky, logicky (dle daných pravidel nejspíše dle přiřazených kategorií) přeuspořádat v rámci fyzického úložiště, zpočátku zejména souborového systému pevného disku. 4) integrovat více fyzických úložišť, v prvních fázích například vědět o datech, která právě nejsou systému fyzicky dostupná např. protože byla přenesena na CD. 5) pokládat jednoduché dotazy (dotazovací modul prozatím bez navrhovaných heuristik) 65

76 Projektové studie Evidence a organizace dat 6) vytvořit nebo z vhodné top level ontologie načerpat univerzální kategorie a pravidla 5.4 Stav Již jsem vytvořil primitivní prototyp. Sice by se dal použít pro organizaci 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: technologie Zvolil jsem jazyk Java, především pro jeho platformní nezávislost a silnou podporu pokročilých technologií (XML, databáze,...) ontologický model Používá primitivní interní ontologii, kterou může uživatel z grafického prostředí programu budovat a upravovat. Použitý ontologický meta model umožňuje definovat kategorie pojmů a základní vztahy. Má ale také řadu omezení, například nelze definovat vztahy mezi kategoriemi (pouze mezi daty), vztahy nemohou mít vlastní hierarchii apod. Také chybí podpora pro pravidla. podporované typy dat Pracuje výhradně s daty na pevném disku se soubory a adresáři. Na druhou stranu disponuje určitou inteligencí v rozpoznávání typů dat podle toho nabízí vhodné kategorie k zařazení, také přizpůsobuje vzhled uživatelského rozhraní (generuje náhledy dokumentů, umožňuje přehrávat audiovizuální data apod.). úložiště pro databázi kategorií a metadat Kategorie ukládá do centrálního XML souboru na disku. Metadata ukládá do XML souborů poblíž popisovaných dat. Protože si systém zatím nečiní nároky na kompletní správu zařazených dat (pořád to jsou soubory na disku), bylo zvoleno právě toto řešení, aby příliš nehrozilo, že při běžné manipulaci (přesouvání, přejmenovávání..) budou metadata ztracena či oddělena od jimi popisovaných entit. 66

77 Projektové studie Evidence a organizace dat Formát pro zachycení metadat je takovýto použit je vlastní na XML založený jazyk: <eltree name="program"> <eldesc name="verze"/> <eldesc name="s/n"/> <elbranch name="co" necessity="required"> <eltwig name="úpravy"> <eltwig name="hromadné"/> </eltwig> </elbranch> <elbranch name="s čím"> <eltwig name="dle formátu"> <eltwig name="text"> <eltwig name="web"/> </eltwig> </eltwig> </elbranch> dotazovací modul a uživatelské rozhraní Dotazovací modul pro jistotu chybí úplně. Přikládám dvě obrazovky uživatelského rozhraní, které umožňuje popisovat data, budovat 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. 67

78 Projektové studie Evidence a organizace dat 68

79 Projektové studie Evidence a organizace dat A.6 Klíčové parametry ontologického meta modelu V první řadě, jde o typickou meta ontologii, která pouze popisuje externí data. Informace zachycené v systému budou trojího typu: příslušnost ke kategorii v terminologii domény, ve které by byl systém nasazen. Například ke grafickému editoru pod Linux by mohly být: program/pracuje s/grafika/bitmapy program/poběží na/unix/linux/debian program/vrstva/frontend aplikace Údaje k firemnímu dokumenty by mohly obsahovat třeba: dokumenty/zakázky/střechy vztah k jiné položce v databázi popisné údaje rozšiřuje (odkaz) popisuje (odkaz) následuje po (odkaz) 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? 69

80 Projektové studie Evidence a organizace dat 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 co (= co program dělá) s čím (= s jakým typem dat) pro koho (je vhodný) na čem (poběží požadovaná platforma) vrstva (frontend aplikace nebo třeba na pozadí běžící služba) copyright (výrobce) licence (ne znění, ale její charakter) popisy jméno verze slovní popis vztahy k jiným datům závisí na (a obráceně je nezbytný pro ) následuje po (a obráceně předchází ) rozšiřuje (možnosti jiného programu a obráceně) je popsáno (dokumentem) Kategorie mohou být obecně větveny jako stromy, nejvyšší stupeň udá kategorii a další stupně jednotlivé možnosti na zařazení v rámci této kategorie. Kategorie pro evidenci programů by mohly vypadat třeba takto: 70

81 Projektové studie Evidence a organizace dat na čem DOS Windows UNIX 16-bit 9x ME NT řada Linux NT 2000 XP Debian Některé z nich (s čím, pro koho, na čem, copyright apod.) by koncepčně odpovídaly spíše vztahům, ale takové řešení by vyžadovalo již v první fázi reálného 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 dotazy na kategorie Například: co:úpravy 71

82 Projektové studie Evidence a organizace dat s čím:dle formátu:text:neformátovaný na čem:unix:linux fulltext Sice poměrně primitivní, ale pořád přesto relativně účinný způsob 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 v rámci popisných položek kompletními metadaty a nakonec daty Poslední jmenovaný by mohl časem sloužit i při analýze obsahu 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. navigace dle závislostí Na stránce či obrazovce s vyhledanou informací o položce dat budou též odkazy na jiná související data. Modul umožní tyto odkazy sledovat. 72

83 Projektové studie Elektronická komerce B Elektronická komerce Elektronický obchod má budoucnost jistou, otázkou je spíše, jak se na vzdouvající se vlně co nejlépe svézt konkurence je tvrdá a počítají se milimetry. O stavu elektronického obchodování a jeho problémech jsme již mluvili. Proto si jen trochu připomeneme o co jde a myšlenky rozvedeme více směrem k praktické aplikaci. B.1 O co jde B2C C2C B2B 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. 73

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

85 Projektové studie Elektronická komerce by bylo snadné integrovat, transformovat, modifikovat, vše značně automatizovaně. informační jistota pro zákazníka Ontologie jako informačně i sémanticky bohaté, přesné, výstižné... by přinesly nové kvality i do obchodování B2C. Souvislosti, podrobné 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. znovupoužitelnost, e-shop reflektuje skutečné rozdíly A co je klíčové pro úsporu nákladů detaily o produktech by stačilo udržovat pouze jednou postaral by se o to například sám výrobce a používat opakovaně, bez dodatečných nákladů. Obchody by se mohly více zaměřit na soutěž v tom, v čem jsou opravdu odlišné, tedy nikoliv v parametrech jimi nabízeného zboží (které je stejné, vždyť všechno vyrábí Čína, že?), ale spíše v dodacích podmínkách doprovodných službách, reklamaci a samozřejmě v cenách. sdílení Podobně by bylo možné sdílet třeba i uživatelské připomínky k danému zboží hodnocení, recenze, nápady, podněty.. Každý obchod by je umožnil doplňovat o připomínky vztahující se právě k jeho obchodu (kvalita služeb..), které by již dále nesdílel. nový stupeň flexibility Pokud jsou produktová data zachycena ve struktuře relační databáze nebo v podobě objektů, není snadné strukturu měnit a přizpůsobovat. Objektový model oproti relačnímu sice usnadňuje vývoj, ale stále se nedá mluvit o flexibilitě za běhu pokud zjistíte, že třída, která 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 rekompi 75

86 Projektové studie Elektronická komerce laci). Takové zásahy by měly být doprovázeny testováním, navíc bude možná třeba zasáhnout do starých dat. Ontologický datový model by přinesl novou dimenzi flexibility umožnil by za běhu podstatně měnit obsah obchodu. V extrémně 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: apatie ze strany dodavatelů 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é.. obavy obchodníků Zvýšení transparentnosti někteří obchodníci ponesou nelibě dost možná se jim nebude líbit, že uživatel na dvě kliknutí porovná jejich nabídku s přesně odpovídající nabídkou konkurence. Internet ovšem k otevřenosti směřuje a je čím dál zřejmější, že tradiční metody utajování, těžící z asymetrické informace kupujícího a 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. nechuť ze strany uživatelů 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í. 76

87 Projektové studie Elektronická komerce rizika slabé vůle k dohodě Velmi přínosné by bylo sdílení doménově specifických ontologií. Pokud se ale klíčové subjekty z nějakého důvodu nedohodnou na společných postupech, nevytvoří univerzální slovníky, věc sice nebude úplně ztracena, ale promrhá se část integračního potenciálu neshody bude třeba překlenout technologiemi mapování, propojování a transformace ontologií. B.5 Kostra architektury ontologického řešení 5.1 Struktura zákaznické uživatelské rozhraní Ta část aplikace, se kterou bude uživatel přímo komunikovat. Základem budou sady transformačních mechanismů pro spojení dále informací čerpaných z jádra systému a šablon s vizuálním stylem sada formulářů a jiných prvků pro zadávání dotazů různí průvodci rozhraní pro správu a sem tam něco dalšího 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. ontologie kategorií Nejzajímavější část systému, klíč k integraci rozdílných systémů a zvýšení informační hodnoty obchodu pro zákazníka. Bylo by zde sou 77

88 Projektové studie Elektronická komerce stř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. databáze informací o produktech Sem patří vše, co není dostatečně univerzální, aby se hodilo alespoň obchodům působícím ve stejném oboru s jiným sortimentem. I tak je zde prostor pro znovupoužití produktové katalogy navázané na 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ů. modul událostí (transakční modul) Klíčový prvek pro zajištění rozšiřitelnosti, taková komunikační brána se dvěma základními úkoly: odesílat informace o událostech vybraným naslouchačům a naopak přijímat informace o událostech ve vnějším světě, tedy zejména v jiných systémech. Typickou událostí ve vnitřním světě by bylo třeba zařazení nového produktu nebo kategorie do ontologie, ale také třeba uživatelská žádost o načtení informací o vybraném produktu. Na další zvážení bude, zda by ostatní moduly rozhraní, především 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í. 78

89 Projektové studie Elektronická komerce rozhraní do IS podniku Modularitu považuji za klíčový parametr architektury, který umožní vybudovat živou, flexibilní a snadno spravovatelnou aplikaci namísto monolitického molocha. Proto nečekám, že by systém řešil vše, co 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: rozšiřující modul objednávek Je sice integritní součástí každého elektronického obchodu, tudíž by měl možná být modulem základním. Zabývám se především aplikací ontologií, proto vzniká otázka, jak by vypadalo ontologické pojetí 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. rozšiřující modul analýzy chování uživatele Znát chování uživatelů bylo dříve konkurenční výhodou, dnes je to již téměř nezbytnost. Již zmíněný mechanismus předávání událostí by příslušnému statistickému modulu naprosto postačoval. Co by se mělo sledovat? Nejen realizované nákupy a celé zakázky, ale i pohyb uživatele po webu, a také nerealizované poptávky, nedokončené objednávky.. 79

90 Projektové studie Elektronická komerce rozšiřující modul kalkulace nákladů Ontologie je schopna evidovat vztahy mezi součástmi a celkem, různé podmíněnosti a další vztahy. To ji přímo předurčuje k dalšímu využití jako základu kalkulačního modulu. K produktům již tak evidovaným v ontologii bude stačit připojit 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. Židle cena:sedák + 4*židle Sedák cena: 50, Noha cena: 30, Nositel ceny cena:? 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ů. 80

91 Projektové studie Elektronická komerce rozšiřující modul stanovení cen Je zřejmé, že náklady jsou funkcí různých typů vstupů: kdo?..cena pracovní síly kde?..cena nemovitostí, půdy co?..spotřebovaný materiál čím/na čem..cena výrobního zařízení a dalších tech. prostředků 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 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 81

92 Projektové studie Elektronická komerce 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 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. 5.3 Cíle 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 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ů: 1. funkční a v zásadě použitelné jádro postavené na vlastních obecnějších nástrojích pro práci s ontologiemi, ovšem bez pokročilejších schopností vyhledávání a inteligence 2. základní zákaznické webové rozhraní 3. perzistenční vrstva schopná integrovat více datových úložišť pro ukládání ontologií 82

93 Projektové studie Elektronická komerce 4. spartánské administrační uživatelské rozhraní Takový prototyp bychom rádi vyzkoušeli na vybraných projektech skutečných elektronických obchodů. 5.4 Stav Zatím pouze zvažuji, zda rizika nejsou příliš značná a tedy zda se vůbec vyplatí systém vyvíjet. Souběžně provádím analýzu zkoumám prostředí, ve kterém by byl systém případně nasazován a snažím se odvodit další klíčové charakteristiky, které by mohly promluvit do analýzy proveditelnosti, a to jak na straně nákladů, tak případných přínosů a z nich plynoucího zájmu uživatelů, investorů... B.6 Klíčové parametry ontologického meta modelu Ontologie zde vystupuje především v roli meta systému, ale má i některé rysy samohodnotné. Zjevně musí být schopna pojmout (v podobě odkazů nebo i nějak těsněji) existující propagační materiály, obrázky, příklady, obchodní informace apod., a to zejména tam, kde by se na ontologické řešení postupně přecházelo z nějakého konvenčnějšího systému. Na druhou stranu zároveň značnou dávku informace obsahuje ontologie sama o sobě a lze si představit i elektronický obchod plně vybudovaný na ontologii, který by se bez externích materiálů obešel. Pokud by ontologie obsahovala opravdu vše podstatné, bylo by možné všemožné přehledové i produktově specifické 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: skládání na různých úrovních 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í. 83

94 Projektové studie Elektronická komerce násobnost vazeb události sledování času 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. 84

95 Projektové studie Elektronická komerce Inspirací mohou být schopnosti databáze ZoDB aplikačního serveru [ZOPE] nebo třeba systémy Wiki. dynamické vlastnosti, možná dokonce metody Například pro cenové kalkulace bude velmi praktické, pokud budou 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... základní sémantické souvislosti vlastnosti 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. Velký důraz bude kladen na možnost precizně popsat vlastnosti. To nás vrací k myšlence kombinovat ontologii s rámci. 85

96 Projektové studie Elektronická komerce internacionalizace V našem stále se zmenšujícím světě stále roste potřeba vyjít vstříc zákazníkům ze všech možných zemí, mluvících rozličnými jazyky, 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. verze Tento bod možná trochu souvisí se schopností zachycovat čas. O co jde? Konkrétní produkt prochází svou vlastní historií od prototypů a testovacích modelů, pokračuje v různých verzích, končí jako výběhový typ. Celou dobu ho tvůrci udržují v konkurenceschopném stavu neustálým doplňováním, vylepšováním. Podpora verzí je pro aplikaci ontologie v elektronickém obhodě 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. vazby ven Poměrně běžnou potřebou jistě bude zapojit do ontologií konvenční data elektronické podoby propagačních letáků, prezentací, fotografií, url... Ontologie musí být také dostatečně otevřená, aby se snadno propojila s ontologií jiného systému, a také s například podnikového informačního, adres 86

97 Projektové studie Elektronická komerce dilema instance a probublávání vlastností Nejsem si úplně jistý, zda má praktický význam explicitně rozlišovat koncepty a instance. Jak to? Instance je z jiného úhlu pohledu může být konceptem. Například, uvaž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. K těmto otázkám se jistě ještě vrátíme. Nastínil jsem, myslím, docela zajímavý meta model ontologií, který možná 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ů. 87

98 Projektové studie Elektronická komerce 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: Produkty obecné a základní služby monitorování a servis zálohování dat služby spojené s doménovým jménem doména druhého řádu subdoména alias k doméně služby elektronické pošty poštovní schránka (umožní cizím SMTP serverům umístit zprávu) přístup k poštovním schránkám prostřednictvím IMAP přístup k poštovním schránkám prostřednictvím POP webové rozhraní pro poštu alias k e mailu automatický odpovídač přesměrování pošty na e mail přesměrování pošty na mobil základní webhostinové služby SSH přístup pro upload (SCP/SFTP) 88

99 Projektové studie Elektronická komerce upload přes prohlížeč ankety kniha návštěv modifikace chyby 404 statistiky přístupů odesílání formulářů obchod WAP aktivní technologie pro webhosting PHP CGI JSP a servlety Perl PHP řešení založené na xml obsahu prezentační framework dynamické xml řešení (Apache Cocoon) relační databáze PostgreSQL MySQL HSQLDB Firebird jiné databáze objektová databáze XML databáze 89

100 Projektové studie Elektronická komerce Tvorba ontologie Jak by vypadalo ontologické pojetí takového portfolia? Zkusím na zkoumaném příkladě naznačit postup tvorby ontologie. Postup by šlo jistě zpřesnit a zobecnit a vytvořit příslušnou metodiku. Tak tedy: virtuální produkty Pokud bychom požadovali, aby systém rozuměl vztahům mezi 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. závislosti (kompozice) konceptualizace 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ě... 90

101 Projektové studie Elektronická komerce další vztahy cenové předpisy 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. Šlo by především o alternativy, komplementarity apod. 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. detaily o produktech 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. 91

102 Projektové studie Elektronická komerce konektivita místo e mail web databáze alias schránky aktivní technologie relační databáze JSP PHP 92

103 Projektové studie Administrace serveru C Administrace serveru C.1 O co jde Představte si Linuxový server pro poskytování mnoha služeb. Je to server složený z velkého množství vzájemně nezávislých softwarových komponent. Nemyslím si totiž, že je dobré, když jeden program umí všechno kromě toho, že pak většinou sice dělá všechno, ale nic pořádně, přináší to často také řadu dalších problémů. Například problémy bezpečnostní pokud je kompromitována jedna služba, jsou 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ě 93

104 Projektové studie Administrace serveru 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 94

105 Projektové studie Administrace serveru 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: přirozená integrace abstrakce snadný přechod 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 95

106 Projektové studie Administrace serveru 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. konkrétní nástroj Postfix Courier Apache OpenLDAP... protokol SMTP POP3 IMAP HTTP LDAP... kategorie služby Pošta Web Data... Rozhraní pro správu C.4 Problémy a rizika řešení s ontologiemi nevhodnost ontologií Univerzální, nezávislý nástroj pro správu serveru by byl užitečný to je myslím mimo jakoukoliv diskuzi. Je tady ale určité riziko, že ontologie nejsou tím nejvhodnějším způsobem reprezentace dat. Možné to je, ale dovolím si tvrdit, že jsou pro toto užití přinejmenším vhodné. nevhodnost technologií Mohlo by se stát, že některá použitá technologie nebude vyhovovat prostředí serverů svými závislostmi na jiném softwaru, svou nedostatečnou otevřeností, platformní závislostí apod. 96

107 Projektové studie Administrace serveru Toto riziko je třeba mít na paměti při návrhu systému a stále si pokládat vhodné otázky.. komplikace přechodu Nebude snadné převést nastavení stovek či tisíců účtů různých služeb do podoby ontologie. psychologické zábrany Jak mohu soudit z komunikace s některými zkušenými správci UNI Xových serverů, jsou to obvykle lidé nadprůměrně inteligentní a také dosti sebevědomí. Jsou pyšní na své znalosti technologií se kterými pracují a mají obecně odpor ke grafickým rozhraním, konfiguračním pomáhátkům a dalším kusům softwaru, o kterých s oblibou prohlašují, že je pro neschopné.. Mnohdy také, co si nenaprogramují sami, tomu často nedůvěřují. A za roky své praxe si již vytvořili obstojná, ale nikoliv univerzální prostř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: Postfix Apache Tomcat SSH Generování konfigurace Ontologie Šablony konfigurací 97

108 Projektové studie Administrace serveru 5.1 Základní komponenty Základních komponent je vcelku málo: uživatelské rozhraní ontologie 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. šablony V šablonách konfigurací by byla naopak data závislá na konkrétních použitých technologiích, ale nezávislá na zákaznických datech na informacích o zákaznících, jejich požadavcích apod. U většiny služeb je třeba v konfiguračních souborech definovat obecné funkční parametry týkající se celé aplikace a také informace specifické podle uživatelů. Pro tyto typy informací by byly definovány dílčí š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. Mohlo by to vypadat třeba takto: 98

109 Projektové studie Administrace serveru #mark_start aaa.cz mark_start #mark_end aaa.cz mark_end #mark_appendhere Určitou komplikací pro proces spojování ontologie a šablon budou obecně vícehodnotové položky například mailové nebo doménové aliasy. Je třeba na ně pamatovat při volbě či návrhu šablonového jazyka. modul generování konfigurace V implementačně nejjednodušší variantě systému by šlo prostě o 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: přidej zákazníka zruš zákazníka 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. Postfix Apache povol příjem pro doménu vytvoř schránky nastav hosting připrav adresář pro hosting zakaž příjem pro doménu zruš schránky zruš hosting smaž adresář pro hosting 99

110 Projektové studie Administrace serveru 5.2 Některé podstatné podrobnosti kontext 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. transakce sanity check obsah úkolů 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. 100

111 Projektové studie Administrace serveru řetězce závislostí 5.3 Spolupráce Mezi úkoly bude také třeba definovat závislosti. Například že nelze spouštět úkol nastavení webhostingu pokud ještě nebyl vytvořen adresář pro budoucí prezentaci s provizorní stránkou, která o tom informuje. Vlastní proces přidání zákazníka do ontologie by mohl spustit příslušný řetěz úkolů. Jak již bylo naznačeno, pokud kdekoliv dojde k chybě, bude třeba vrátit se do stavu na začátku 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í: Řídící jádro Ontologie Konfigurační úloha přidej přidej konfigurace služeb dílčí úkol souv. úkol OK chyba vrať změny informuj o chybě odstraň V odpověď na modifikaci ontologie je spuštěna konfigurační úloha. Ta volá první úkol z řetězce. Úkol potřebuje, aby byl nejdříve 101

112 Projektové studie Administrace serveru 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í: nastav prostředí pro úkol zkontroluj současný stav proveď všechny závislé předběžné úkoly proveď úkol proveď navazující úkoly zkontroluj stav Komplikovanější by byl rovněž dialog mezi řídícím jádrem a uživatelem. Mohl by probíhat třeba takto: uživatel: chci přidat zákazníka jádro: musíš vyplnit jméno a příjmení, doménu... uživatel: tady to je Franta Novák, franta.cz... (ověří dostupnost domény, provede pár dalších kontrol) jádro: vyber, jaké služby bude požadovat uživatel: poštu a web jádro: dobrá, přidávám ho do ontologie, spouštím úlohy přidání pro web a poštu.. (dopočítává další proměnné podle potřeb úlohy, spouští jednotlivé úlohy, provádí kontroly..) 102

113 Projektové studie Administrace serveru 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. čas a změny naslouchači 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. 103

114 Projektové studie Administrace serveru závislosti 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. uživatelské datové typy Praktická by byla podpora nepříliš běžných datových typů, jako , 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í. Například datový typ domainentry bude obsahovat položky jako: www A 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í: služby Jako kategorie toho, co lze nabízet. Například: pošta SMTP, IMAP, POP3.. web HTTP, aktivní technologie databáze relační, objektové

115 Projektové studie Administrace serveru komponenty služeb Kromě služeb samotných bude třeba nadefinovat obecné elementární kategorie, které se v konfiguraci mohou vyskytovat doména, poštovní schránka.. Komponenty budou mít například takové atributy (naznačeny jsou datové typy a jejich kardinalita): MAIL: DOMENA: WEB: technologie address heslo pwd 1..1 mailbox dir 1..1 jmeno jmeno:text, prijmeni:text 1..1 alias 0..n address domain 1..1 entry domainentry 0..n address domain 1..1 alias domain 0..n 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. Apache Postfix Courier IMAP...apod. 105

116 Projektové studie Administrace serveru Technologicky specifické adaptéry by zahrnovaly šablony konfigurací a také specifické konfigurační postupy (skripty). Každý adaptér také ponese seznam jím vyžadovaných dat, zejména těch trvale uložených v ontologii v podobě konceptů komponent služeb. komponenty technologií Konkrétní, technologicky specifické realizace obecných konceptů komponent služeb. poštovní schránka v Postfixu poštovní schránka v Courieru doménový záznam v NSD...apod. Koncept Technologie (realizace) Služba pošta Courier Postfix Konfigurační komponenta pošt. box Courier box Postfix box hostitel (zákazník) Ten, v jehož prospěch jsou služby provozovány. V jeho kontextu budou prováděny úpravy. Vazbami, nejčastěji s kardinalitou n, bude napojen na koncepty jím využívaných služeb. 106

117 Projektové studie Administrace serveru Tedy nějak takto v obrázku jsou čtverečkem naznačeny násobné kardinality: alias webu web databaze alias pošty poštovní schránka domena domenovy zaznam 107

118 Projektové studie Další možnosti praktické integrace D Další možnosti praktické integrace Je jasné, že systémy s ontologickým jádrem lze integrovat snadněji. Postupy 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ě. systém fakturace Vhodným propojením systému pro správu serveru a ekonomického informačního systému by mohl vzniknout automatizovaný systém pro fakturace na základě skutečně odebíraných služeb. CRM Jak jsme již zmiňovali, pojem nemá jednoznačně definovaný význam, ale obecně se jím rozumí evidence zákazníků, jejich potřeb, jednání s nimi, evidence a správa uzavřených kontraktů, podpora pro 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 108

119 Projektové studie Další možnosti praktické integrace sklad a logistika Informace o zboží z webového obchodu by byly navázány na logistiku a skladové hospodářství. Skladové hospodářství by třeba samo doporučovalo objednání zásob podle vhodného modelu zásob. správa dokumentů Ontologie by zde byla v typické meta roli pouze by popisovala data uložená v jiné podobě. Oproti klasickým systémům pro správu dokumentů by mohla opět nabídnout zajímavé vazby na produkty, zákazníky apod. řízení workflow, groupware systém znalostní 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. podnikový informační systém jako integrovaný portál 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 se 109

120 Projektové studie Další možnosti praktické integrace stá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 (OpenGroup Ware..) apod. Neznám ale ani jediný, který by byl flexibilní, ale zároveň dostatečně komplexní. Komunitní způsob vývoje příliš nepřeje podobně rozsáhlým 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. integrace subjektů 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. 110

121 Projekt ontologického systému Projekt ontologického systému IV Projekt ontologického systému Na základě poznatků načerpaných z případů použití ontologií v různých prostř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]. univerzálnost, přizpůsobitelnost použitelnost Systém musí umět poskytnout cenné služby výše zkoumaným typům aplikací, ale i aplikacím jiným, které jsme podrobně nezkoumali. Na druhou stranu nesmí pro dané použití vnucovat nevhodné a zbytečné funkce. Klíčem k řešení bude konfigurovatelnost. Již tuším, že systém bude velmi komplexní. Nesmí to ale být na úkor použitelnosti. 1. Uživatelská přívětivost: Systém by měl pomáhat uživateli kde to jen půjde a nevyžadovat od něj víc než je nezbytné. V tomto směru bude klíčová opět konfigurovatelnost spolu s mechanismy skrývání. 2. Snadnost správy: Instalace a konfigurace včetně propojování s dalšími systémy uživatelským rozhraním, databází a systémy aplikačními musí být rozumně snadná. Klíčem bude otevřenost, respektování standardů, kvalitní dokumentace. 3. Snadný vývoj: Při vývoji by měly být používány dostupné prostředky pro udržení přehledu nad projektem, pro a zajištění spravovatelnosti i do budoucna. Důležitá bude kvalitní analýza a návrh, v rámci implementace pak API dokumentace a jednotkové testy. Nesmíme opomenout také volbu vhodné technologie. 111

122 Projekt ontologického systému Projekt ontologického systému nezávislost Systém musí běžet na všech běžných operačních systémech Windows, Linux, MacOS Nesmí být závislý na žádné knihovně nebo aplikaci s restriktivní licencí, která by omezovala jeho další použití. Nesmí být pevně svázaný s žádnou konkrétní databází, aplikačním serverem... rozšiřitelnost a flexibilita robustnost 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ýkon Výkonové požadavky jsem zařadil až na poslední místo, protože upřednostňuji čistotu návrhu a jsem toho názoru, že výkon je lépe řešit, až když systém funguje správně. Na druhou stranu je třeba mít na paměti, že v reálném nasazení půjde i o výkon, rychlost, spotřebu paměti a podobné parametry. Ve fázi budování prototypu se ale spokojíme s tím, když budou nároky v zásadě rozumné. Hned od začátku ale budeme pamatovat na budoucí potřebu škálovatelnosti především co se týče možností ukládat data do více databází, 112

123 Projekt ontologického systému Projekt ontologického systému 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

124 Projekt ontologického systému Meta model ontologie A Meta model ontologie Předchozí část zkoumala možnosti nasazení ontologií především tam, kde to 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ší: meta model ontologie Ontologickým meta modelem rozumím souhrn toho, co ontologie dokáže popsat a jak může fungovat. Tedy její vyjadřovací schopnosti, bez ohledu na konkrétní obsah. Třeba to, jaké datové typy podporuje v roli atributů, jaké typy vztahů zná, zda umí pracovat s pravidly a jak jsou pravidla definovaná, jaké typy dědičnosti podporuje a tak dále. Jde tedy v zásadě o souhrn 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 Začněme klíčovou položkou struktury koncepty a instancemi. Co je to koncept? 114

125 Projekt ontologického systému Meta model ontologie koncept 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í. Podle stejného slovníku je to případ, příklad nebo výskyt. U ontologií jde opět o formalizaci informace o takovém výskytu v reálném světě. 1.1 Dilema instance 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. 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. 115

126 Projekt ontologického systému Meta model ontologie 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 : 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

127 Projekt ontologického systému Meta model ontologie 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 117 Oravan konkrétní Oravan Oravan+ konkrétní Oravan+

128 Projekt ontologického systému Meta model ontologie 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á. Prostě jako lupa záleží na podrobnosti pohledu Ř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. Jak by vypadalo řešení bez takového důsledného rozlišení? 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: 1. přidávají nové sledovatelné vlastnosti U elektroniky můžeme sledovat třeba spotřebu 118

129 Projekt ontologického systému Meta model ontologie 2. nově stanovují nebo upřesňují hodnotu nějaké vlastnosti zavedené dříve v hierarchii dědičnosti (a to je v objektovém programování mnohem méně reflektovaná skutečnost) Dokonce můžou některé vlastnosti či vztahy rušit, což ovšem př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 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: jakou má vlastnost konkrétní hodnotu případně že nevíme, ale v principu můžeme zjistit že taková hodnota nelze sledovat (třeba barva očí u televize je to spíše známka chybného návrhu) Možná vám to připadá stále jako nepříliš jasné rozlišení u konceptů přeci také víme nebo nevíme. Ale u nich připadá v úvahu ještě čtvrtá možnost: hodnotu sice lze teoreticky sledovat, ale nejsme v principu schopni jednoznačně ji stanovit Je to sice na první pohled drobná nuance, ale pokud přidáme možnost stanovit, jakým způsobem je hodnota neznámá, bude možné podle uvedených pravidel 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 119

130 Projekt ontologického systému Meta model ontologie 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 Koncepty a instance budu dál víceméně shrnovat pojmem entity. entita Slovník [HMC00] definuje jako něco, co existuje jako určitá a 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. primitiv Slovník definuje jako neodvozený od ničeho jiného, základní, výchozí nebo původní. Typickým primitivem v geometrickém významu je bod. Opět, ontologický význam docela odpovídá jsou to ty entity, které jsou na vrcholech hierarchií, nejsou definovány jinými entitami. agregovaná entita Je entita v konkrétním těsném vztahu k jiné entitě je její součástí. Agregovaná entita nemůže existovat samostatně bez entity, se kterou je svázána. V případě profilu s explicitním rozlišením konceptů a instancí můžeme rozlišovat ještě: 120

131 Projekt ontologického systému Meta model ontologie konkrétní koncept Koncept, od kterého mohou být odvozovány instance. abstraktní koncept Koncept, od kterého nemohou být odvozovány instance, pouze subkategorie. 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ě 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í 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. Typickým příkladem jsou tématické mapy (topic maps). Je zřejmé, že hranice mezi těmito typy ontologií není ostrá a nejběžnějším pří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 121

132 Projekt ontologického systému Meta model ontologie 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 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]. externí entita Tak nazveme externí datový zdroj, který byl propojen s ontologií. Zdroje mohou být mnoha různých typů, například: textové dokumenty všech možných formátů (HTML, RTF, PDF, XML, neformátovaný text...), to vše v různých kódováních a znakových sadách) obrázky zvukové záznamy videosekvence kvalifikované vazby databáze (relační, objektové, XML..) Ať již bude uznán za vhodný kterýkoliv standard (což by měl být vždy upřednostňovaný postup), řešení které bude nakonec vybráno musí především podporovat kvalifikované vazby. 122

133 Projekt ontologického systému Meta model ontologie celek i části 1.4 Hierarchie 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. Hierarchizace v ontologii může být postavena na dvou paralelně využívaných principech 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í. kontext Kategorie mohou pěkně definovat kontext. 123

134 Projekt ontologického systému Meta model ontologie 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. kruhy identita 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 Dynamická kategorizace Kromě explicitního zařazení do kategorie bude praktické podporovat automatické zařazení na základě kategorizačního pravidla. Vyhodnocením pravidla budou za běhu entity přiřazeny do kategorií a poplynou z toho pro ně a pro kategorii stejné důsledky, jako kdyby bylo přiřazení explicitní. Při navrhování této funkce jsem se inspiroval především zpětnými kategoriemi v systémech wiki. V úvahu připadají například tyto varianty: podle výskytu Každá entita, která disponuje zvoleným atributem nebo kombinací atributů, bez ohledu na jeho hodnotu, patří do vybrané kategorie. 124

135 Projekt ontologického systému Meta model ontologie podle hodnoty 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 Dědičnost, nejprve obecně Zachycuje těsnější a ve svých důsledcích mnohem komplikovanější vztah než kategorizace. Článek je druhem publikace. Stejně tak je dokumentem. Vztahem dědičnosti entita nabývá anebo může nabývat atributy entity, od které dědí. Nejprve stručně shrnu, co je pro nás teď podstatné a zamyslím se především nad dalšími důsledky a dilematy, které dědičnost přinese. třída, rodič Je entita, která ve vztahu k jiným entitám vystupuje nebo může vystupovat jako nadřazená ve vztazích dědičnosti. Vztahy třída potomek realizují dědičnost. přejímání atributů V objektově orientovaného návrhu je běžným zvykem, že potomek zdědí veškeré vlastnosti předka. Podobný mechanismus by měl podporovat navrhovaný meta model. Pokud entita zboží definovala atribut záruka, pak odvozená entita elektronika jej přejala. přejímání hodnot atributů U objektů trochu méně řešený efekt dědičnosti. 125

136 Projekt ontologického systému Meta model ontologie 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. televize záruka: 2r napájení: ano sériové číslo:? spotřeba:? obrazovka:? digitální:? elektronika záruka:? napájení: ano sériové číslo:? spotřeba:? TV Oravan záruka: 2r napájení: ano sériové číslo:? spotřeba: 20W obrazovka: 35 digitální: ne zboží záruka:? napájení:? TV Oravan e.č.154 záruka: 2r napájení: ano sériové číslo: as4-45 spotřeba: 20W obrazovka: 35 digitální: ne 126

137 Projekt ontologického systému Meta model ontologie Dědičnost vícenásobná násobnost dědičnosti Násobnost dědičnosti vyjadřuje, kolik přímých předků může mít jedna entita. Jednoduchá násobnost povoluje maximálně jednoho přímého předka, vícenásobná jich povoluje více. Zda povolit i násobné vazby, to je docela složitá otázka. Odpověď záleží na váze, jakou přiřadíme jednotlivým kritériím především flexibilitě plynoucí z násobnosti a jednoduchosti a přehlednosti návrhu v případě jejího zakázání 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. 127

138 Projekt ontologického systému Meta model ontologie Z jejich pohledu televize zbožím být nemusí. V takovém případě nebudou nelze univerzálně sdílet žádnou část souhlasit s naší ontologií zboží jako sdíleným komunikačním jazykem, protože elektronika televize vazba zboží televize by narušila vnímání světa jejich informačním systémem. TV Oravan Jaký z toho plyne závěr? 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. Řešení s vícenásobnou dědičností: univerzální definice => lze sdílet televize elektronika zboží TV Oravan 128

139 Projekt ontologického systému Meta model ontologie b Komplikace vícenásobné dědičnosti Takové řešení vypadá komplikovaně (a komplikovanější skutečně o trochu je), ale umožní sdílet ontologii s kýmkoliv, což za to myslím stojí. Koneckonců zboží a televize jsou jiná hlediska charakteru entity TV Oravan, a tak by měly patřit do různých hierarchií. Vícenásobná dědičnost ale přináší i potíže kdyby tomu tak nebylo, asi by např. v návrhu jazyka Java nechyběla. Některé z těch, které souvisí s již prozkoumanými tématy zmíníme, o dalších se zmíníme na patřičných místech: potíže při přejímání atributů V hierarchii se vyskytne více atributů stejného jména, ale jiného typu. Vzniká otázka, jak situaci řešit. Jedna možnost je povolit stejně pojmenované atributy a následně podle vkládané nebo žádané hodnoty (jejího datového typu) určovat, o 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. 129

140 Projekt ontologického systému Meta model ontologie potíže při přejímání hodnot Přestavme si situaci, kdy jeden atribut nabude v hierarchii různých hodnot. V případě jednoduché dědičnosti to není problém způsob stanovení aktuální hodnoty je jednoznačný a byl popsán výše. Násobná dědičnost ale věci komplikuje. Problém si můžeme přiblížit, když se zmíníme o tom, k čemu může taková dědičnost vést u jazyků OOP, konkrétně v jazyce jako C++. Tady je třeba zbystřit kdykoliv dojde k uzavření kruhu v hierarchii. Proměnné třídy na nejvyšší úrovni hierarchie v kruhu jsou pak třídou nejnižší zděděny vícekrát, u jednoduchého kruhu konkrétně dvakrát, a to pod stejnými jmény. Více o problému se dozvíte třeba v kurzu C++ [CPPKURP00] v časopise Progres. U navrhované ontologie můžeme vytvořit mechanismus, který se 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é. Při jednoduché dědičnosti není žádný problém: a:[5] a:5 a:? směr hledání hodnoty Ale tady nevíme, zda vybrat pětku nebo sedmičku: 130

141 Projekt ontologického systému Meta model ontologie a:5 a:? a:7 a:nelze zjistit směr hledání hodnoty Žádné zázračné řešení asi neobjevíme. Některá z řešení naznačených v předchozí části, mírně upravená můžeme uplatnit i zde asi nelze zvažovat přetěžování, protože už z definice problému jde o atributy stejných typů. Můžeme ale stanovit pravidla pro automatický 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

142 Projekt ontologického systému Meta model ontologie A.2 Atributy V předchozí části jsme již zkoumali, jaký vliv na vlastnosti (atributy) entit bude mít hierarchizace, především dědičnost. Ještě jsme se ale příliš nezamýšleli, co jsou atributy vlastně zač.. koncept atributu Primitivní, ale plnohodnotná komponenta ontologie. Skládá se z povinných komponent názvu a datového typu a volitelně může být doplněn o vysvětlující popisek. Od jednoho konceptu může být odvozeno libovolně mnoho instancí atributu. hodnota atributu Konkrétní hodnota (datová položka) či předpis pro její odvození, přiřazená konkrétní instanci atributu. instance atributu název atributu popiska 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). identifikátor atributu Atribut je jednoznačně identifikován názvem, v případě přetěžování názvem a datovým typem. 132

143 Projekt ontologického systému Meta model ontologie atribut hmotnost :kilogramy :0 PDA Zaurus entita instance atributu hmotnost:0,17 V dalším textu pokud budu mluvit o atributu, budu mít na mysli koncept atributu, případně instanci atributu. 2.1 Doména Doména určuje, jaké datové položky jsou přípustné v roli hodnot atributu a také význam těchto hodnot Datový typ I zde je to, co je pod tímto pojmem běžně chápáno určitý způsob definice množiny přípustných hodnot. Definice může být provedena výčtem všech možných prvků anebo předpisem, který nějak omezuje množinu nadřazenou. Část hierarchie předpisem definovatelných typů neboli množin povolených hodnot může vypadat třeba takto: string numeric... integer real 133

144 Projekt ontologického systému Meta model ontologie Způsob definice podtypů nelze stanovit univerzálně podtypy číselných hodnot budou dány matematickým předpisem (třeba sudá čísla jako dělitelná dvěma), podtypy v řetězcové hierarchii zase regulérními výrazy. Pouze stanovení výčtem je dostatečně univerzální z hlediska typů, na něž je lze aplikovat. Navrhovaný systém by měl obsahovat kvalitní, univerzálně použitelnou hierarchii typů. Vedle toho by mohly vznikat ontologie oborových typů. Konečně, úplně specifické typy si navrhne sám uživatel / tvůrce ontologie. Smysl je jasný typ by měl být schopný pojmout veškerá omezení povolených hodnot, aby nebylo třeba vymýšlet další omezující mechanismy. uživatelský typ Například takto by mohla vypadat definice specifických typů z 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: domain a-za-z0-9.a-za-z jednoduchý typ komplexní typ ipaddress dnsrecord a-za-z0-9 'CNAME' 'A' {ipaddress} Za zmínku stojí druhý a poslední příklad ukazuje možnosti kompozice typů. Přesné mechanismy kompozice budou specifické pro jednotlivé hierarchie typů, zatím se jimi více zabývat nebudeme. Podotýkám rovněž, že kompozice datových typů je něco jiného než komplexní datové typy popsané dále. Hodnota má maximálně jednu datovou položku. Datová položka odpovídá typu. Příklad: typ domain: 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 134

145 Projekt ontologického systému Meta model ontologie násobný typ 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 s. Hodnota má minimálně m a maximálně n datových položek. Pokud není stanoveno jinak, číslo m je rovno nule a n nekonečnu a je tedy přípustný jakýkoliv počet položek. Všechny datové položky odpovídají typu atributu. Příklad: typ V úvahu připadají též speciálnější možnosti omezení kardinality, obecně dané předpisem. Díky tomu by bylo možno povolit například pouze sudé počty datových položek (třeba seznam účastníků soutěže manželských párů). U násobného typu navíc může být anebo nemusí být důležité pořadí. množina synonym Speciální typ, umožňuje zachytit více položek, ale položky jsou považovány pouze za jiná vyjádření téhož. Vychází z jiného datového typu, v praxi asi nejspíše řetězcového. mapa Speciální typ, seznam dvojic klíč a hodnota, obdoba hashovacích tabulek známých například z jazyka Java. Jednotlivé položky lze vkládat pouze v kombinaci s klíčem a přístup k nim bude opět přes klíč. 135

146 Projekt ontologického systému Meta model ontologie statická mapa 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é. dynamická mapa Taková mapa, která může měnit nejen hodnoty, ale i své klíče, případně při definici mohou být klíče opomenuty úplně a naplní se až používáním. literál V zásadě pouze speciální případ mapy, typu string a s klíči v podobě kódů jazyků. Umožní vytvářet lokalizované verze textových údajů. kořenový typ Relevance 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. 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í dis 136

147 Projekt ontologického systému Meta model ontologie ponovat 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 ). Relevance je údaj nepovinný ne vždy má smysl jej udávat. 2.2 Prostředky pro zvýšení robustnosti Mechanismy vyžádání volitelné (optional) Výchozí mechanismus, entita i její potomci mohou a nemusí specifikovat hodnoty. doporučené (suggested) Do možností ontologie nevnáší žádná pevná pravidla, vyplnění hodnot v celé hierarchii entit je pouze doporučeno. To se projeví například při návrhu varovnými hláškami, pokud není doporučení respektováno. Je věcí konkrétní aplikace, jak bude s nerespektovanými doporučeními zacházet. požadované (required) Nejvyšší stupeň vyžádání. Každá entita s atributem v nedefinovaném stavu je považována za nevalidní. Doplnění hodnoty je vynuceno. V rámci hierarchie dědičnosti lze mechanismy vyžádání zpřísňovat. Potomek s volitelným atributem může změnit stav vyžádání na doporučení nebo požadavek. Žádný z jeho potomků se již ale nebude moci vrátit ke stavu výchozímu. 137

148 Projekt ontologického systému Meta model ontologie Mechanismy podsouvání výchozí hodnoty (default) Pokud je konkrétní hodnota uvedena již při definici konceptu atributu, dostává roli výchozí hodnoty. Odvozené instance ji zdědí místo hodnoty nedefinované. Mohou ji ale explicitně překrýt. doporučené hodnoty Seznam běžných hodnost atributu, může být sestaven a modifikován kdekoliv v hierarchii (u konceptu i instance), slouží pouze jako pomocné vodítko pro uživatele. nemodifikovatelné (immutable) Pokud je instance atributu označena jako nemodifikovatelná, nemůže být její hodnota v další hierarchii změněna. 2.3 Odvozený atribut Zatím jsme zvažovali pouze možnost, že instance atributu explicitně specifikuje konkrétní hodnotu anebo je atribut nedefinovaný. Bylo by chybou explicitně 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ů.. Příklad: obsah čtverce: obsah = strana*strana 138

149 Projekt ontologického systému Meta model ontologie A.3 Vazby Nejjednodušší možné vazby mezi dvěma entitami nedefinují charakter vztahu jsou netypové a neorientované. Přestože i takovými primitivními vazbami by bylo možno vyjádřit mnohem více informací než bez nich, k blízkému konceptuálnímu popisu světa by měla taková ontologie daleko. Přesto jednou z možností meta modelu by mělo být povolení netypových vazeb asi bychom nalezli případy, kdy je naprosto klíčová snadnost použití a typy vazeb by znamenaly zbytečnou komplikaci. V dalším textu se budeme zabývat vazbami typovými a zejména orientovanými typovými. Nadefinujeme kostru hierarchie typů vazeb, zamyslíme se nad násobností a také třeba nad komplikacemi, které vazbám přináší dědičnost entit. koncept vazby jméno vazby popiska vazby instance vazby Je to typ vazby, myšlenka vyjadřující druh a charakter vztahu, nikoliv nějaký konkrétní vztah mezi konkrétními entitami. Existuje jako 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. 139

150 Projekt ontologického systému Meta model ontologie účastník vazby atribut vazby Pokud vazbu znázorníme jako hranu grafu, pak účastníky vazby jsou uzly, které vazba spojuje. V ontologii jím může být především 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 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 Orientované jednosměrné obousměrné 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 140

151 Projekt ontologického systému Meta model ontologie Neorientované vazby lze implementovat jako orientované, jsou speciální pouze v tom, že jsou tvořeny vazbou, která je inverzní sama sobě. role Má význam v případě orientovaných vazeb. Je to postavení účastníka v rámci vztahu. Například ve vztahu otcovství vystupuje pan Novák v roli otce a malý Franta v roli potomka. Nebo třeba ve vztahu dědičnosti je jeden účastník v roli nadypu a druhý v roli podtypu 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: 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. 141

152 Projekt ontologického systému Meta model ontologie 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: /vztah / fyzická souvislost / má popis / kontext / má vlastnost / má (sou)část / logická souvislost / je (sou)částí (e) / je agregováno ( ) / isa (^) ~je instancí, je podtypem /je verzí / asociace ( ) / alternativa / je implementací (o) Návrh je třeba chápat pouze jako pracovní a měl by být podroben hlubší analýze, především v souvislosti se vztahovými koncepty 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 142

153 Projekt ontologického systému Meta model ontologie 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é? Multilaterální V reálném světě takové souvislosti jistě existují. Časté a zřejmé je to například u smluv. Smlouva vlastně vyjadřuje vztah mezi subjekty vzájemné povinnosti a práva, vztah na kterém se smluvní strany dohodly. Smlouva může mít dva účastníky, ale může jich mít i více. kupní smlouva s ručením prodávající kupující ručitel Vzniká otázka, jak takové vztahy zachytit. Jsou obecně dvě možnosti, buďto reálnému světu podřídit meta model ontologie a povolit multilaterální vazby: 143

154 Projekt ontologického systému Meta model ontologie vztahy mezi subjekty explicitní Tonda Jirka prodávající kupující ručitel Franta Anebo vztah dekomponovat na více vztahů jednoduchých a přímé vztahy mezi účastníky odvozovat na základě pravidel: Tonda Jirka smlouva vztahy mezi subjekty odvozeny pravidlem Franta Účastníky jsme nahradili jejich konceptuálním odrazem, smlouva je zachycena v podobě trojité vazby nebo zvláštní entity. Klíčové je, že obě řešení jsou co do schopnosti zachytit vazbu ekvivalentní, př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é. 144

155 Projekt ontologického systému Meta model ontologie 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 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. Čerstvé máslo Čerstvé máslo Čerstvé máslo Čerstvé máslo 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: x10 máslo krabice máslo máslo máslo..a dalších 36 Představa, že by to měl člověk ručně provádět není nijak příjemná, u másla by se to zvládnout ale ještě dalo. Horší by bylo, kdybychom měli dávat do krabiček špendlíky nebo sypat písek do pytlů jak by 145

156 Projekt ontologického systému Meta model ontologie bylo možné bez násobnosti vyjádřit množství (hmotnost, délku..) nějaké entity? Proto potřebujeme vhodnější řešení, třeba takovéto: máslo 40 je umístěno v obsahuje 1 krabice Myšlenka je zřejmá vazba je v systému pouze jedna, ale účastník je násobný. Úplně se zde nabízí využít mechanismů násobnosti definovaných u atributů a myslím že to přesně tímto způsobem také zrealizujeme. Zbývá určit, kde vlastně má být násobnost stanovena. Asi nejflexibilnější bude spolehnout se na mechanismus dědičnosti. Výchozí násobnost u konceptů vazeb bude u všech rolí 1, tedy do vztahu bude moci vstoupit pouze jeden účastník za každou roli. Pokud bude násobnost u konceptu výslovně specifikována (např. 40), bude tato přenesena do všech odvozených vazeb. Obecně bude připadat v úvahu redefinice kdekoliv v hierarchii, pokud nebude redefinice zakázána pomocí prostředků pro zvýšení robustnosti popsaných níže. 3.4 Prostředky zvýšení robustnosti 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. rozhodovací řetězec (decisive chainlink) Je posloupnost testů a rozhodnutí, která mají být přijata v případě platnosti testu. Na základě rozhodnutí může být provedena určitá akce nebo posouzena přípustnost situace. Pravidla jsou vyhodnocována podle jednoznačně daného pořadí. 146

157 Projekt ontologického systému Meta model ontologie test rozhodovacího řetězce (rule) 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). rozhodnutí (decision) V úvahu připadá především rozhodnutí o povolení nebo zakázání konkrétní vazby. Přidejme ještě rozhodnutí o změně parametrů vazby zejména kardinality (násobnosti) na stranách účastníků. ukončující rozhodnutí (terminal decision) Ta rozhodnutí, která ukončí další provádění řetězce. pomocné rozhodnutí (supplementary decision) politka (policy) 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 Struktura rozhodovacích řetězců Jak bude takový řetězec vypadat? Půjde o posloupnost testů a rozhodnutí shrnutých do velkého seznamu. Například pro vazbu je částí/obsahuje v prostředí publikačního serveru může část tohoto řetězce vypadat takto: vazba prvek= celek= decis. částí/obs. {have} schválený=ne {isa} rubrika deny částí/obs. {isa} článek {isa} rubrika allow částí/obs. 147

158 Projekt ontologického systému Meta model ontologie částí/obs. default deny Jak vidíte, pravidlo, které vyřadí neschválené články je vykonáno dříve než to, které povolí zařazení článků obecně. Celé to bude fungovat tak, že bude povoleno zařadit článek do rubriky pouze pokud je schválen redaktorem. Poslední řádek řetězce obsahuje výchozí politku, která zamítne vazby, které nebyly výslovně povoleny. Možná se zeptáte, jak budou vypadat rozhodovací řetězce u vztahů dostupných obecně všem prvkům, například u vazby isa. Jednoduše: vazba test decision isa default allow 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í: zakázáno (deny) povoleno (allow) Ukončující rozhodnutí, vazba je zakázána. Ukončující rozhodnutí, vazba je povolena. doporučeno (suggest) 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. vyžadováno (require) 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. 148

159 Projekt ontologického systému Meta model ontologie změnit kardinalitu (change_cardinalty) 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í). změnit účastníka (modify_counterpart) Změní atributy nebo jiné vazby účastníků 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é 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: vazba prvek= celek= decision? {isa} technologie {isa} implementace s_type=implementuje 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. 149

160 Projekt ontologického systému Meta model ontologie doporučit typ (suggest_type) Pro situaci splňující podmínky testu bude při jejím zřizování navržen konkrétní typ vazby. doplnit typ (auto_type) Pro situaci splňující podmínky testu bude automaticky vybrán konkrétní typ vazby. S tímto typem rozhodnutí je třeba zacházet opatrně. 3.5 Důsledky dědičnosti účastníků 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í. hosting JSP hosting v.1 hosting v.2 podporuje ruší podporuje JSP v.1 JSP v.2 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: 150

161 Projekt ontologického systému Meta model ontologie zaručené dědictví Potomek zdědí všechny vazby předka. Nikde v hierarchii se vazby nemohou ztratit. selektivní dědictví Potomek zdědí ty vazby, které určí tvůrce ontologie. V úvahu připadají drobné nuance explicitní dědění a explicitní rušení. Rozdíl je v tom, zda je třeba vyjmenovat ty vazby, které mají být zděděny nebo naopak ty, které zděděny být nemají. odmítnuté dědictví V rámci hierarchie se vazby nepřenášejí vůbec. Napadá mě veselá analogie s dědictvím v občanskoprávním 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 Další automatické manipulace vazbami Kromě dědičnosti by bylo možné zkoumat i další použitelné mechanismy rušení anebo naopak vyžádání vazeb. Například automatické zrušení či vyžádání jedné vazby v důsledku vzniku vazby nové. Dejme tomu, že máme dva typy vztahů (A a B) a mezi entitami, které označíme n1 a n2. Obecný mechanismus by se dal shrnout třeba takto: vyloučení specifické n1 A n2 => ruší n1 B n2 vyloučení generální n1 A n2 => ruší cokoliv B n2 151

162 Projekt ontologického systému Meta model ontologie vyžádání specifické n1 A n2 => musí být/implikuje n1 B n2 vyžádání obecné n1 A n2 => musí být/implikuje n1 B cokoliv a obráceně režim vyžádání stanoven... hmotnost:? required PDA...hodnota musí být doplněna hmotnost:0,17 required PDA Zaurus Situace, kdy vazba dvou prvků má za následek vznik nebo zánik vazby úplně 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. 152

163 Projekt ontologického systému Meta model ontologie Pravidla lze kromě definice vlastní ontologie také vhodně použít jako prostředek dotazování v rámci interaktivní práce s ní. 4.1 Struktura pravidel Pravidlo je předpis, který se skládá ze dvou hlavních částí: predikát, výrok Takové vyjádření, o němž je možno v souvislosti s konkrétní entitou jednoznačně prohlásit, zda platí. Příklad: works for :person Franta :company Open IT efekt Důsledek platnosti predikátu. Ta část pravidla, která definuje nový poznatek, vztah apod 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.). Příklad: works for :person?x :company Open IT Zamyslíme li se nad predikátem, zjistíme, že je třeba vymezit minimálně dvě věci: co můžeme zjišťovat, hodnotit, posuzovat a u čeho, tedy u jakých prvků ontologie. Odpověď na druhou otázku je poměrně snadná u entit, vazeb a atributů, další podrobnosti musíme ale rozebrat trochu více 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: 153

164 Projekt ontologického systému Meta model ontologie atribut entity Platí, pokud entita disponuje uvedeným atributem. Jeho hodnota není pro platnost rozhodující. Příklad: {have} hmotnost hodnota atributu entity vazba entity 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. Příklad: {have} hmotnost > 5kg Platí, pokud entita disponuje uvedenou vazbou a přitom nezáleží na tom, jaké entita je jí ve vazbě partnerem. Příklad: {have} bratr partner ve vazbě entity předek entity Platí, pokud entita disponuje uvedenou vazbou a partner splňuje další podmínku. Příklad: {have} bratr Jan Stejný mechanismus bude možné použít pro hledání všech členů kategorie: Příklad: {have} kategorie Recenze Platí, pokud je entita předkem dané entity. Možno specifikovat hloubku hledání zda je zájem pouze o rodiče nebo i o vzdálenější předky. Příklad: {ancestor} televize nalezne elektronika. 154

165 Projekt ontologického systému Meta model ontologie potomek entity Platí, pokud je entita potomkem dané entity. Možno specifikovat hloubku hledání zda je zájem pouze o děti nebo i o vzdálenější potomky. Příklad: {isa} elektronika nalezne televize. 4.3 Efekty pravidel V případě použití pravidel při interaktivní práci s ontologií si vystačíme s 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ší: dynamická kategorizace Je to postup, který prvky splňující podmínky predikátu dynamicky zařadí do kategorie. Příklad:?x {have} cena =>?x belongs Zboží dynamické vztahy Jde o mechanismus odvozování vztahů na základě podmínek v predikátu pravidla. Příklad: (?x vztah1?y) & (?y vztah2?z) =>?x vztah3?z Dynamické vztahy umožní třeba definovat tranzitivitu: Příklad: (?x tranzitivni_vztah?y) & (?y tranzitivni_vztah?z) =>?x tranzitivni_vztah?z Příklad: pokud má technologie stejného předka z větve technologie, je to alternativa JSP1 > JSP > webtechnologie < PHP < PHP4 => PHP4 alternativa JSP1 155

166 Projekt ontologického systému Meta model ontologie pravidla validity 4.4 Operátory 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: Příklad: {isa} produkt =>! {isa} 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é. Je zřejmé, že pouze s výše uvedenými podmínkami by nebylo možné definovat i jen trochu komplikovanější predikáty. Pomohou operátory, především logický součin & logický součet negace! Platí obě podmínky. Příklad: ({have} bratr?x) & (?x {have} barva_oci = červená ) Platí alespoň jedna alternativa. Příklad: ({have} bratr) ({have} dcera) Unární operátor negující výsledek jiného testu. Příklad:! ({have} hmotnost) Operátory naleznou uplatnění nejen v části predikátu, ale i u efektu. Trochu problematické by bylo pojetí efektu logického součtu nebylo by jasné, který efekt zvolit. Proto je logický součet aplikovatelný pouze u predikátu. 156

167 Projekt ontologického systému Provozní požadavky B Provozní požadavky Zatím jsme se zabývali především meta modelem ontologie, tedy jejími vyjadřovacími schopnostmi. Snažili jsme se respektovat cíl, totiž navrhnout takový kus softwaru, který by byl univerzálně použitelný pro definici ontologického jádra š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í. Evidence půjde využít minimálně takto: Statistika Pokud bude zaznamenáván kromě změny samotné také přesný čas, kdy nastala a nejlépe také kdo ji provedl (jaký uživatel), bude možné generovat sestavy zpráv o vývoji ontologie. Takové sestavy pomohou administrátorům při správě, 157

168 Projekt ontologického systému Provozní požadavky 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í 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é 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. Jádrem řešení bude.. 158

169 Projekt ontologického systému Provozní požadavky naslouchač (listener, observer design pattern) 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) 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. nová vazba registrován jako naslouchač informace o nové vazbě 159

170 Projekt ontologického systému Provozní požadavky 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 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ů 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] Strategie likvidace Problém se týká především odstraněných předků jak již bylo naznačeno. Již v menší míře budeme požadovat připojení atributů odstraňované entity nějaké jiné entitě většinou již potřeba nebudou, ale pro úplnost se o nich zmiňuji také. 160

171 Projekt ontologického systému Provozní požadavky a Nakládání s potomky smazat připojit 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. osamostatnit dotázat se 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. Neřešit situaci automaticky, vždy se dotázat uživatele b Nakládání s instancemi atributů smazat připojit 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. dotázat se Neřešit situaci automaticky, vždy se dotázat uživatele c Nakládání s vazbami smazat Pokud smažete prvek, který má definované vazby, smazány budou i tyto vazby. 161

172 Projekt ontologického systému Provozní požadavky připojit Vazby budou připojeny přímému potomkovi, pokud je tento doposud dědil a nerušil. Pokud je přímých potomků více, instance vazeb budou nakopírovány pro každého z nich. dotázat se Neřešit situaci automaticky, vždy se dotázat uživatele. Aby likvidace prvku proběhla úspěšně, musí být po jejím dokončení prověřeny podmínky validity 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á vazba nic specíálního kratší smazat dotázat se Nově vytvářená cesta bude přijata jako platná, stará zůstane beze změny. Kratší hierarchie vyjadřuje méně informací, proto bude odstraněna. Neřešit situaci automaticky, vždy se dotázat uživatele. B.2 Konfigurovatelnost meta modelu Na mnoha místech jsme zmiňovali, že to či ono půjde v meta modelu nastavit a tak jej přizpůsobit konkrétním potřebám. Tvrdím, že taková flexibilita je nezbytná, pokud chceme pokrýt širokou paletu aplikací, jak jsme naznačili. Co obecně může být v meta modelu konfigurováno? 162

173 Projekt ontologického systému Provozní požadavky konfigurace meta modelu Nastavením meta modelu rozumím definici toho, co je v něm povoleno zakázáno vyžadováno 2.1 Důvody pro konfigurovatelnost Někdo bude možná oponovat, proč jednoduše neumožnit naráz používat všechny ty vymoženosti kdo je použije, použije, kdo ne, nebude si jich všímat. 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: jak zažít informační opaření Dejme tomu, že potřebuji řešit nějaký průměrně složitý problém. Pokud k jeho vyřešení dostanu do ruky něco pro mě neznámého, ve svých schopnostech ale velmi mocného a složitého, nějakou dobu se budu snažit pochopit, jak by to mohlo posloužit k vyřešení problému. Dost možná ale po čase usoudím, že úsilí věnované do zvládnutí nástroje bude větší, než přímá pomoc nástroje. Pokud bych nástroji věnoval více pozornosti, časem bych možná zjistil, že mi pomůže řešit i úplně jiné a třeba i komplikovanější problémy. Kvůli prvotní negativní zkušenosti dané složitostí i při jednoduchém použití jsem se o to připravil. Systém by neměl působit jako kanón, v případě že je třeba sestřelit vrabce. 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: robustnost, logická integrita Je zřejmé, že ve světě okolo nás jsou složité vztahy. Ontologie je jejich konceptuálním odrazem. Na jedné straně je musí odrážet co nejvěrněji 163

174 Projekt ontologického systému Provozní požadavky 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. Výjimka by měla nést dostatek informací, aby bylo možné říci co se nepovedlo, nestalo co je špatně proč je to špatně a jak je možno situaci řešit 2.3 Konfigurovatelné vlastnosti meta modelu Téměř jistě zde nezmíním všechno, na mnohé další možnosti pravděpodobně 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. 164

175 Projekt ontologického systému Provozní požadavky 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 Dědičnost Dědičnost může být podporována v různém stupni: vůbec jednoduchá vícenásobná A toto nastavení může být jiné pro jednotlivé typy prvků, tedy zejména pro: entity (koncepty a instance) koncepty atributů koncepty vazeb Kromě toho můžeme vysledovat další parametry související s dědičností, například, zda mohou existovat: finální prvky Ty prvky ontologie, od nichž je zakázáno odvozovat jakékoliv potomky. Nebo zda je povoleno nedědění vazeb a jakým způsobem více viz oddíl o dědičnosti Atributy Půjde především o to, zda jsou povoleny atributy odvozené finální uživatelské A zda mají fungovat mechanismy vyžádání 165

176 Projekt ontologického systému Provozní požadavky podsouvání Tak jak je vše definováno v kapitole o atributech. Kromě toho mohou být selektivně povoleny složitější datové typy jako mapy nebo literály (pro lokalizaci) Vazby Důležité bude stanovit, zda mohou být v ontologii vazby: multilaterální násobné vazby na externí data Rozhodovací řetězce mohou být podporovány v různém stupni: vůbec pouze ukončující rozhodnutí ukončující i pomocná rozhodnutí Dále půjde povolit nebo zakázat mechanismy vyloučení vyžádání 2.4 Profily nastavení meta modelu Bude jistě pěkné, pokud bude možné nakonfigurovat si meta model přesně podle potřeb. Na druhou stranu, i to bude činnost, která by mohla vést k informačnímu opaření uživatel by byl zpočátku jistě zmaten tím, co znamená mechanismus vyžádání nebo co jsou rozhodovací řetězce 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. profil meta modelu Je souhrn nastavení meta modelu, uložený do přenositelné a sdílitelné podoby. 166

177 Projekt ontologického systému Provozní požadavky 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 šíře profilu síla profilu Profil může shrnovat veškerá možná nastavení na každou otázku v souvislosti s meta modelem s určitostí odpoví, to je úplný profil. Pokud mnohá nastavení, je to široký profil. Pokud jenom několik málo, je to úzký profil. 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. 167

178 Projekt ontologického systému Provozní požadavky Vybrané profily základní ontologie meta ontologie Ú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. samohodnotná ontologie (self-valuable) Úzký a jednoznačný, vnější zdroje jsou zakázány, opak meta ontologie. charakterizační síť Široký a silný profil odvozený v rámci případové studie využití ontologií v elektronické komerci. Podpora externích vazeb, lokalizace, selektivní dědictví... tématická mapa (topic map) Profil odpovídající definici jak je uvedena třeba v [GARS02] nebo v [XTMSPEC]. terminologická ontologie Profil pro budování jednoduchých ontologií, s důrazem na entity a vazby, každopádně bez podpory pravidel. axiomatická (formální) ontologie Umožňuje vše, co umí terminologická a přidává pravidla navíc. Pro budování ontologií s důrazem na pravidla a dynamičnost. O terminologických versus axiomatických ontologiích více třeba [ONTOSOW00]. 168

179 Projekt ontologického systému Provozní požadavky 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 a) skládat úzké profily b) od univerzálních profilů odvozovat profily speciální Oba mechanismy mají své opodstatnění a oba je třeba podporovat. kompozice profilů Je mechanismus, který umožní definovat profil jako sloučení profilů 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: specializace profilů profil A profil B profil AB výchozí výchozí A výchozí neměnný B neměnný výchozí A neměnný neměnný nelze Je mechanismus dědičnosti, který umožní definovat profil jako speciální případ profilu jiného. Je třeba respektovat omezení předka. S jednotlivými parametry bude naloženo takto: předek profil 1 výsledné nastavení výchozí nedefinuje zděděno výchozí definuje předefinováno neměnný nedefinuje zděděno neměnný definuje nelze Místo násobné dědičnosti, která podporována nebude lze využít kombinaci kompozice a dědičnosti jednoduché. 169

180 Projekt ontologického systému Provozní požadavky 2.5 Režimy a módy Nastavení meta modelu a profily řeší trvalé a univerzální parametry a chování, zejména s ohledem na použitelnost ontologie. Smyslem režimů a módů je dále zjednodušit práci s ontologií a především předcházet nežádoucím zásahům ze strany uživatelů. režim mód Zpřístupňuje funkce podle fáze životnosti ontologie a systému vůbec. Zpřístupňuje ty funkce, které odpovídají oprávnění a záměrům konkrétního uživatele Základní režimy návrhu V tomto režimu bude možno využít veškerých možností API, jak jsou definovány nastavením meta modelu. provozu Přestože to nastavení meta modelu umožňuje, v klasickém režimu provozu nebude například možné vytvářet nebo měnit kořenové koncepty, případně provádět jiné podobné úpravy, které spadají spíše do fáze návrhu Základní módy čtení API povoluje všechno vytváření Uživatel může vytvářet nové prvky, zejména entity a vazby, ale nemůže měnit prvky stávající. úpravy Uživatel může měnit stávající prvky. 170

181 Projekt ontologického systému Provozní požadavky mazání Uživatel může odstraňovat prvky. Zejména v souvislosti s potřebou rozdělovat role a spravovat oprávnění jednotlivých uživatelů bude třeba tyto mechanismy rozvést podrobněji, umožnit definovat různé režimy a zejména módy podle oblasti v ontologii. 171

182 Projekt ontologického systému Struktura a technologie C Struktura a technologie Nyní je čas zamyslet se nad případnou aplikací využívající navrhovaný systémem jako nad celkem, nasazeným v reálném prostředí, komunikujícím s reálnými uživateli a systémy, pracující s konkrétními daty a nastaveními. Budem především hledat vhodné technologie, které splní jak kvalitativní požadavky definované v úvodu praktické části, tak zároveň funkční a procesní požadavky, které jsme definovali o něco později. Pokud vás zajímají bližší podrobnosti, případně byste si rádi přečetli něco o tom, jak části zapadají do celkové architektury aplikace a jaké má to všechno důsledky pro snadnost její údržby, rozšiřitelnost a další parametry, můžete se podívat do [ASMZEJ03]. Celá tato část je vlastně aplikací zásad a pravidel Architektury podřízené modelu, včetně důsledků pro volbu technologií. Za klíčové pro další návrh a implementaci považuji to, aby byly jasně stanoveny hranice vyvíjeného systému. Musí být zřejmé, co je integritní součástí, a co je nadstavba nebo úplně cizí systém. Jsem toho názoru, že je mnohem lepší, když se samotný systém soustředí skutečně na jádro své činnosti, tj. zpracování ontologií a vše ostatní přenechá dalším, jasně odděleným modulům a systémům. C.1 Systém jako celek 1.1 Základní a rozšiřující části Za základní v tomto smyslu považuji: Ontologické jádro, které dokáže zachytit ontologii v operační paměti počítače, v rámci běžícího procesu aplikace, která jej využívá. API rozhraní tohoto jádra, umožňující pracovat s ontologií klást dotazy, sledovat vazby, provádět modifikace apod. Systém řízení zpráv, který umožní registrovat naslouchače a tyto bude informovat o veškerém dění v ontologii. 172

183 Projekt ontologického systému Struktura a technologie Na obrázku jsou tyto základní komponenty systému zachyceny černou barvou: registrovaní naslouchači sestavy interaktivní rozhraní dotazovací modul statistiky cizí IS API externí entity RSS CRM top level ontologie... řízení událostí doménová ontologie perzistenční vrstva DB export/import nastavení meta modelu Vše ostatní je rozšiřující, a jako takové není přímou součástí vyvíjeného systému a tedy ani není předmětem vývoje prvního prototypu. Těmito moduly jsme se doposud téměř vůbec nezabývali, přestože pro použitelnost aplikace jsou rovněž podstatné zkuste vytvořit aplikaci, jejíž data a nastavení nelze ukládat a která nemá uživatelské rozhraní. Myslím že moc nepochodíte. Aby se ale někdo necítil ochuzen, zamyslíme se alespoň nad technologiemi, které by mohly sehrát úlohu v implementaci těchto částí. Přeci jenom i při vývoji jádra je třeba počítat s budoucími nadstavbami zejména s tím, co budou od jádra vyžadovat a jaké technologie mohou být použity při jejich budování. 1.2 Příklad komunikace Jak bude probíhat komunikace mezi moduly? Vezměme si jeden takový příklad vyhledávací dotaz. 173

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

185 Projekt ontologického systému Struktura a technologie Je zřejmé, že komunikace nebude triviální, a to jsme vůbec nezmínili další systémy a protokoly, které se jí účastní prostředky síťové komunikace (protokoly TCP/IP, HTTP), databází prováděné čtení z úložiště někde na disku nebo třeba vykreslování komponent HTML stránky prohlížečem. A opět, vlastní navrhovaný systém je pouze uprostřed. 1.3 Původ jednotlivých komponent Za zamyšlení stojí i to, co bude natolik univerzální, že to bude součástí dodávky systému, co bude k dispozici jako doplněk a co vznikne v průběhu instalace a používání. Nuže, univerzální bude například: prázdný ontologický systém základní entity, vztahy, datové typy.. čerpající z vhodné top level ontologie (isa, part_of...) prázdná perzistenční vrstva možná i dotazovací jazyk postavený nad API Jako dodatek či rozšíření bude k dispozci: uživatelská rozhraní (HTML, Swing..) generátory a analyzátory sestav konektory pro jednotlivá úložiště doménové a jiné speciální ontologie Naopak v průběhu života projektu využívajícího náš systém vznikne především: vlastní ontologie entity, vztahy... nastavení a profily specifické doplňky 175

186 Projekt ontologického systému Struktura a technologie C.2 Jádro a API Nejprve vymezíme co vlastně máme na mysli, když mluvíme o jádru. Následně se budeme trochu detailněji zabývat tím, jaké základní technologie použijeme pro jeho implementaci. jádro API Nemá cenu detailně představovat, protože o něm je prakticky celá práce. Je to hrst provázaných objektů reprezentujících ontologii. Patří do něho také API pro manipulaci s ní a API pro konfiguraci. Poslední nedílnou komponentou je systém pro řízení a hlášení událostí. Jak již bylo několikrát opatrně naznačeno, vše potřebné definice konceptů entit a vazeb, instancí entit a vazeb, modifikace, základní prohledávání podle entit i atributů (Kdo všechno sídlí v ulici Škroupova?), počítání diferencí (rozdílů entit)... lze provádět voláním metod objektů jádra. Inspirací může být API již zmiňované knihovny OJB. externí entity 2.1 Model Jsou to data a dokumenty uložené jinde než v ontologii články, obrázky... Již jsme zkoumali, proč je třeba umožnit jejich zasazení do kontextu ontologie. Do jádra sice přímo samy o sobě nepatří, a nepatří do něj ani adaptéry pro různé typy dokumentů a dat. Jádro pouze musí poskytnout obecné rozhraní těmto adaptérům. Asi jste si již všimli, že když mluvím o jádru, občas zmiňuji nějaké objekty, objektové návrhové vzory a podobné věci. V této části se pokusím obhájit volbu právě takového typu modelu a rovněž dospěji ke konkrétnímu jazyku, který považuji pro realizaci za vhodný. Nuže, jak by mohl model vypadat? Podle ASM je potřeba zvolit model, který má dostatečné vyjadřovací schopnosti a tak umožní vytvoření flexibilní aplikace. Přidejme k tomu ještě robustnost a širokou použitelnost a uvidíme, že mnoho možností nezbude. 176

187 Projekt ontologického systému Struktura a technologie Relační model Datový model navržený pomocí metodologie zvané strukturální analýza má několik nesporných výhod, které jeho stále ještě přežívající skalní příznivci jistě nezapomenou zdůraznit. Například: Existuje solidně propracovaná teorie strukturální analýzy. Databáze jsou podepřeny kvalitní relační teorií. Mocný jazyk SQL je i přes implementační odlišnosti standardní. Existují silné CASE nástroje podporující tvorbu datového modelu. Z kterékoliv části programu je možné vidět celý systém najednou, z ptačí perspektivy data jsou všude přístupná, díky tomu nový požadavek zapadající do modelu je pouze jeden SELECT navíc. Ovšem systémy založené na relačním modelu trpí podobnou chybou jakou trpí i strukturální programování a kvůli které možná i někteří příznivci raději poslední výhodu nezmíní: Zásahy v modelu značně ovlivní program a znesnadňují tak údržbu a vývoj celé aplikace. Co se stane, když máme bohatou košatou databázi a v jedné tabulce změním jednu definici sloupce, anebo dokonce když změním na základě změny požadavků celou vazbu? Co když požadavky na systém natolik narostou, že počty tabulek začínají přerůstat rozumnou mez a jdou do počtu až několika stovek a poté provedu změnu v několika z nich? Je to jednoduché procesy začnou padat. Systém se stane neudržitelným a jakýkoliv zásah do něj způsobí neustálé problémy pracovníkům z jiných částí týmu, kteří nic netuší a všichni se jenom rozčilují, proč databáze najednou nefunguje. Navíc, a to je horší, nelze mnohdy ani určit, kterých procesů se změny dotknou. Musíte, ať už s podporou programovacího prostředku anebo čistě ručně, projít všechny příkazy SQL databáze, které tabulky, vazby atd. používají, a měnit, měnit, měnit... A protože máte vytvořit systém dost složitý, zákonitě se dostane do kruhu oprava jedné skupiny tabulek s sebou přináší další opravy jiných tabulek a procesů atd. a systém se stane krajně nestabilním. [ZOOPKR98] A proč to všechno nastane? Může za to výhoda veřejnosti procesy počítají s datovou strukturou tabulek, kterou jste publikovali všem. Takové řešení by jistě nebylo příliš robustní a snadno spravovatelné, proto musíme pátrat dále.. 177

188 Projekt ontologického systému Struktura a technologie Prosím ale pozor nezavrhuji zde relační databáze jako takové ani mohutnou relační teorii, pouze nedoporučuji chápat relační model jako jádro aplikace a zároveň nedoporučuji kombinovat SQL s programovým kódem. I přes to jsou RD BMS ověřeným a široce podporovaným standardem pro úložiště, jak prozkoumáme dále. Na závěr ještě připojím podnětné vzkazy pana Amblera pro návrháře datových modelů. Pokud ale spěcháte, můžete jej přeskočit, o relačním modelu jsem toho, myslím, napsal již až dost. [AMBL] návrháři logických modelů Ve skutečnosti již nebude třeba logických datových modelů, pouze tam, kde se ještě nezačalo pracovat v souladu se současným trendem a tedy podle zásad OO, a to jen dočasně. Návrháři logických modelů se proto budou muset naučit navrhovat objektové a/nebo fyzické datové modely. Dobrou zprávou je, že mnohé zkušenosti, které jako návrháři logických modelů získali, budou moci využít schopnost nadhledu, schopnost modelovat, schopnost dodržovat doporučení. Špatnou zprávou ovšem je, že jejich oblíbený modelovací mechanizmus a datové modely již nestačí a byly překonány objektově orientovaným modelováním. Toto doporučení možná není lehké přijmout, ale čím dříve začnete, tím lépe pro vás. návrháři fyzických modelů Ať samozvaní OO guruové říkají co chtějí, fyzické modely jsou stále potřeba. Budete se ale muset naučit navíc mapovat objekty do re 178

189 Projekt ontologického systému Struktura a technologie lačních databází. Dobrou zprávou pro vás je, že po lidech, kteří to dokáží je silná poptávka Model založený na XML Má své opodstatnění ve speciálních případech, ale spíše jako pomocný model pro zachycení jednotlivých dokumentů, třeba v rámci systémů pro správu dokumentů (document management). V čistém XML modelu není snadné realizovat dynamičnost data jsou pouze data a samo o sobě nic neumí. Navíc hrozí podobná nebezpečí jako u relačních modelů, způsobená přílišnou veřejností dat i jejich schémat. Opět těžko bychom mohli dostát požadavkům robustnosti a rozšiřitelnosti. Na druhou stranu je zda spousta prostředků pro manipulaci s XML, samotný jazyk dokáže ontologii zachytit docela účelně a pro tyto účely se také hojně využívá. Proto jej rozhodně nemůžeme jednoznačně zatratit a budeme uvažovat o vhodné kombinaci s jiným modelem Objektový model Myslím že platí univerzální poučka pokud nemáte závažný důvod pro jiný přístup, jakýkoliv informační systém založte na objektovém modelu. Takovou volbou se zúží volba programovacího jazyka na ty objektově orientované. Samotný objektový model sám o sobě samozřejmě žádnou flexibilitu či robustnost nezajistí, pouze nabízí prostředky, kterými je možné udělat to dobře a průběžně vás k relativně dobrým řešením směruje. Nijak tím ale není snížen význam analýzy a návrhu koneckonců o nich je celá tato práce a stále to ještě nebude stačit. 179

190 Projekt ontologického systému Struktura a technologie Pro dokreslení uvádím diagram pokroku v oblasti architektur. Půjčil jsem si jej z [METADIB00]. Ukazuje postupný odklon od relačních modelů a strukturovaného programování Logické, deklarativní, pravidlové apod. Jde o různé specifické modely vhodné především pro zachycení znalostí a různé obory umělé inteligence, například dolování informací, rozpoznávání tvarů, práce s lidskou řečí, zpracovávání nejasných a neúplných údajů. Zdá se, že jsou to obory dosti blízké námi navrhovanému systému. LISP Scheme LISP (LISt Processing, zpracování seznamů) je interpretovaný, plně strukturovaný jazyk, v zásadě se skládá pouze ze seznamů volání funkcí. To mu dodává neobvyklou flexibilitu. Scheme je mnohaúčelový programovací jazyk vyšší úrovně, podporuje operace se strukturovanými daty (řetězci, seznamy, vektory) stejně jako s primitivními typy. Často je spojován se symbolickým 180

191 Projekt ontologického systému Struktura a technologie programováním, ale jeho bohatá nabídka datových typů a flexibilní struktury pro práci s nimi z něj dělá skutečně univerzální jazyk. Důkazem je, že existují textové editory, kompilátory, operační systémy, grafické knihovny, expertní systémy, výpočetní aplikace, aplikace pro finanční analýzy a snad každý další představitelný typ aplikace. A začít se Scheme není nijak obtížné! [SCHEMED96] Prolog Prolog je jazyk pro programování symbolických výpočtů. Jeho název, odvozený ze slov PROgramování v LOGice, naznačuje, že jazyk vychází z principů matematické logiky. Od počátku byl Prolog využíván při zpracování přirozeného jazyka (francouštiny) a pro symbolické výpočty v různých oblastech umělé inteligence. Používá se v databázových a expertních systémech, při počítačové podpoře specializovaných činností, např. při projektování (CAD) nebo výuce (CAI), i v klasických úlohách symbolických výpočtů, jako je návrh a konstrukce překladačů, a to nejen jako prostředek vhodný pro reprezentaci a zpracování znalostí, ale i jako nástroj pro řešení úloh. CLIPS CLIPS je nástroj pro tvorbu expertních systémů vyvinutý skupinou Software Technology Branch (STB) v NASA. Nyní je používán mnoha tisíci lidmi na celém světě. V CLIPSu existují 3 způsoby, jak reprezentovat poznatky: pravidly jsou určena k heuristickým poznatkům založeným na zkušenostech, definování funkcí (deffunctions) a generic function jsou primárně určeny pro procedurální poznatky, objektově orientované programování také je určeno primárně pro procedurální poznatky. Program lze sestavit použitím jen pravidel, jen objektů nebo kombinací objektů a pravidel. CLIPS byl také navržen pro plnou integraci s jinými jazyky. [CLIPSMI99] Sice vše, co dokáží, lze ekvivalentně vyřešit i v čistě objektovém jazyce, ale právě díky specializaci mnoho věcí jde s těmito jazyky snáze, rychleji a přirozeněji. Tam, kde objekty působí těžkopádně a je třeba mnoho kódu možná postačí jedno či dvě krátká pravidla v Prologu. Využití některého takového modelu bych každopádně úplně nezavrhoval, pravděpodobně v kombinaci s modelem objektovým. Bude ale třeba ještě důkladně prověřit dostupnost, platformní nezávislost, licenční 181

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

193 Projekt ontologického systému Struktura a technologie Zmiňme nyní krátce některé běžně používané objektově orientované programovací jazyky, abychom následně zlehka prozkoumali, jaký vliv bude mít jejich použití na platformní závislost: C++ Kompilovaný, hojně využívaný v praxi, vyvinul se ze strukturovaného předchůdce jazyka C zejména přidáním objektové orientovanosti. Object Pascal Smalltalk Object Pascal se vyvinul ze strukturovaného předchůdce, jazyka Pascal zejména přidáním objektové orientovanosti. Stejně jako C je kompilovaný. Podporuje jej především firma Borland, která prodává odpovídající vývojová prostředí Delphi a Kylix. Smalltalk považuji za velmi zajímavý jazyk. Je možná jako jediný plně objektový, v zásadě interpretovatelný (ale se současnými rozšířeními již nikoliv na 100%). Převzal rovněž dost z myšlenek neméně zajímavého LISPu. Pěkným úvodem do práce s ním je třeba [SMALTHU95]. Java Java je další silně (byť nikoliv čistě) objektově orientovaný programovací jazyk založený na interpretaci bytekódu. Má silnou podporu ze strany firem, standardizačních skupin, open source skupin i samostatných vývojářů, k dispozici je ohromné množství technologií, nástrojů a pomůcek, které řeší mnoho běžných i méně běžných programátorských úkolů. Interpreter Javy se jmenuje Java Virtual Machine (JVM) a existuje skutečně pro cokoliv PC s jakýmkoliv operačním systémem, handheld, mobilní telefon. Zakladatelem Javy a jejím silným podporovatelem je firma Sun Microsystems. Ale kromě standardní implementace JVM firmou Sun je možné použít i jiné například IBM JVM nebo některou z open source, svými funkcemi se ale s oficiálním JVM nemohou příliš měřit. Na druhou stranu, pokud by Sun z nějakého dů 183

194 Projekt ontologického systému Struktura a technologie vodu přestal Javu podporovat, je dostatečně otevřená na to, aby se jí ujal kdokoliv jiný ať již společnost nebo komunita. Python Python je interpretovaný, interaktivní, objektově orientovaný jazyk. Obsahuje velké množství modulů, které podstatně usnadňují práci. Interpret je k dispozici v mnoha systémech: Unix, Windows, DOS, OS/2, Mac, Amiga... Je sice rovněž opatřený Copyrightem, ale je volně použitelný a šiřitelný i pro komerční využiti. Příslušná licence je svobodnější než u konkurenční Javy Přenositelnost Důležitým pojmem zde je přenositelnost. Tu můžeme sledovat na různých úrovních: 1. přenositelnost zdrojových kódů 2. přenositelnost bytekódu 3. přenositelnost nativního kódu 4. přenositelnost používaných knihoven Kromě toho můžeme zkoumat přenositelnost uživatelského rozhraní, dat apod., ale o tom se ještě zmíníme dále. Pro zodpovězení otázky jaký vyšší programovací jazyk je dostatečně přenositelný je třeba poukázat na principiální rozdíly mezi jazyky z hlediska jejich schopnosti odstínit operační systém, a to ani ne tak v průběhu programování (to je spíše věc procesu vývoje než užití, o které nám jde především), ale zejména při běhu. 184

195 Projekt ontologického systému Struktura a technologie Jazyky kompilované Nejdelší historii mají jazyky kompilované. Jejich výhodou je rychlost výsledných programů relativně časově náročná kompilace ze zdrojového do nativního kódu, kterému rozumí přímo operační systém proběhne pouze jednou, při běhu se pouze spustí na obrázcích jsem to znázornil překrývajícími se ovály. Proces vytvoření a spuštění kompilovaného programu vypadá takto: Výsledný program je nativní, tedy nutně nepřenositelný. Řešením by mohlo být (a bývá) použití specifických kompilátorů a skutečně, kompilátory například jazyka C++ jsou dostupné prakticky pro všechny běžné platformy. V čem je tedy problém, když pomineme drobnost, že náš systém by musel být distribuován v různých vydáních pro jednotlivé platformy? Zejména v knihovnách, které vaše aplikace použije, protože ty musí být také k dispozici pro každou podporovanou platformu. A dokonce ani mnohé standardní knihovny například již zmíněného jazyka C++ se nechovají všude stejně. Z těchto důvodů je zajištění přenositelnosti buď nepříjemné, nebo hodně nepříjemné, nebo (a bohužel velice často) nemožné. Proto, kompilovaných jazyků se vyvarujeme. 185

196 Projekt ontologického systému Struktura a technologie Jazyky interpretované O něco novější jazyky interpretované přinášejí zásadní změnu vlastní kompilace probíhá až při spuštění programu a nazývá se interpretace. Do této skupiny patří LISP, Scheme, Prolog, ale i většina jazyků označovaných jako skriptovací jazyky, tedy PHP, Perl, Python, Tcl, JavaScript a v neposlední řadě Python. Proces vytvoření a spuštění interpretovaného programu vypadá takto: Z hlediska přenositelnosti je to dobré řešení stačí aby existoval interpret pro každou platformu, která má být podporována. Pokud použijete výhradně přenositelné knihovny (např. v tom samém jazyce), je vše v pořádku. Nebezpečí se skrývá ve schopnosti využívat knihoven neinterpretovaných (a tedy nepřenositelných) jazyků, která je vlastní mnoha interpretovaným jazykům. Použijeme li nativní knihovnu, přenositelnost se rázem zboří. Před volbou interpretovaného jazyka budeme muset prověřit, zda jsou k dispozici přenositelné knihovny ke všemu, co budeme využívat. Nevýhody jsou dvě: 1. Dáme veřejně k dispozici svůj zdrojový kód, i kdybychom náhodou nechtěli a především by to nemuseli chtít případní uživatelé naší knihovny. 2. A dále, program je pomalý časově náročná kompilace se provádí při každém spuštění. Tento problém již dnes ale tolik nepálí kvalita interperterů je mnohem vyšší než dříve a hardware také pokročil.. 186

197 Projekt ontologického systému Struktura a technologie Jazyky interpretované s bytekompilací Jazyky interpretované s bytekompilací jsou další generací jazyků interpretovaných. Rozdělují proces kompilace do dvou fází. Bytekompilátor převede zdrojový kód do tzv. bytekódu, což je operace časově srovnatelná s kompilací do nativní podoby, ale bytekód je platformně nezávislý. Interpretr bytekódu je již nutně platformně závislý, a proto musí existovat pro každou podporovanou platformu. Proces vytvoření a spuštění bytekompilovaného programu je takovýto: Z hlediska přenositelnosti je to řešení stejně dobré, jako čistá interpretace. Navíc přináší výhodu v podobě vyšší rychlosti běžících aplikací a odpadá nutnost zveřejnit zdrojový kód. Ovšem i zde musíme dbát na to, že využijeme pouze přenositelné knihovny. Věřím ale, že cesta vede nejspíše právě tudy. 187

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

199 Projekt ontologického systému Struktura a technologie C.3 Zajištění perzistence Umožnit datům přežít konec běhu programu, to patří mezi základní požadavky. Pokud bude chybět možnost ontologii, ale rovněž nastavení systému uchovat, těžko se najde pro systém nějaké reálné využití. Zdálo by se možná, že jde o samozřejmost nebo trivialitu, ale ukládání komplikovaných dat, když jsou tady požadavky výkonové a také požadavky stability a robustnosti, není nic snadného. Bylo by ale chybou snažit se perzistenci řešit úplně po svém, když existuje nepřeberné množství různých databází, všech možných typů a parametrů. Chybou by rovněž bylo vybrat jedno z té záplavy možných úložišť a systém na něm udělat závislým. To by byl prohřešek proti snaze o maximálně univerzální použití je zřejmé, že jiné úložiště bude používat domácí uživatel pro organizaci rodinných fotografií a úplně jiné úložiště zvolí nadnárodní korporace pro ukládání informací o svých produktech (a ještě jiné pro evidenci přijatých a vydaných úplatků má dáti dal : ). Musíme najít nebo vytvořit univerzální perzistenční vrstvu, konkrétní úložiště bude využíváno s pomocí pro něj specifických adaptérů do této vrstvy. Existuje nepřeberně možností, jak ukládat data z aplikace. Data můžeme ukládat jako soubory uvnitř souborového systému, můžeme vytvořit nějaký proprietární atypický ukládací systém, můžeme využít relačních databází, objektových databází, XML databází, LDAP struktur nebo třeba něčeho úplně jiného. V dalším textu se zaměřím především na možnosti pro jazyk Java. 3.1 Soubory Serializace Serializace je nástroj standardní knihovny Javy, tedy je ihned k dispozici. Princip je stručně řečeno takový, že objekt je převeden do binárního datového proudu a nástroje pro zpracování datových proudů ho pak můžou uložit například do souboru. Ze souboru je možné objekt zrekonstruovat do původní podoby. Pokud nechceme promíchat kód specifický pro tento typ ukládání s vlastní aplikační logikou, musíme vytvořit nějakou vrstvu, která bude ukládání řídit... což znamená vytvořit v zásadě celý databázový systém. Ano, serializace je použitelná pro jednoduché nebo specifické úlohy. 189

200 Projekt ontologického systému Struktura a technologie XML mapování O řešení některých nedostatků standardní serializace se pokouší různé nástroje, které uloží objekt nikoliv v binární podobě, ale do XML a z XML ho umí zpětně zrekonstruovat, tedy provádějí XML mapování. Produktů v této kategorii je více. JOX JOX je skupina Java knihoven, které usnadňují přenos dat mezi XML dokumentem a objektem odpovídajícím JavaBeans specifikaci. Můžete chápat JOX jako speciální formu serializace, kde použitým formátem je XML. JOX je tak snadno použitelný, jako samotná serializace. Výstupní XML soubor má ovšem poměrně plochý formát a nejde příliš (téměř vůbec) přizpůsobovat. Pro naše účely není vhodný. Více viz [JOX]. KBML - The Koala Bean Markup Language KBML přístup zvládne mnohem více typů objektů než JOX, ale musíte se uvázat k použití jejich speciálního XML formátu. Koala XML serializace je nadstavbou standardní serializace. Proces je rozdělen do dvou fází: Všechny objekty jsou serializovány do java.io.objectoutput Stream a následně převedeny do KOML dokumentu. Deserializace probíhá obráceně. Pro naše účely se jeví použitelnější, ale téměř jistě bychom narazili na problémy s výkonem u větších ontologií. Více viz [KBML]. JAXB Sun si je rovněž vědom potřeby XML reprezentace objektů. Vybrali si širší řešení, nazvané data binding (JAXB). Toto řešení je mnohem více řízeno daty, protože využívá XML schémata přímo pro generování tříd schopných XML data zpracovávat. Serializace má být nabízena spíše jako vedlejší efekt. Hlavní nevýhoda tohoto využití spočívá v nutnosti opatřit objekty specifickými serializačními a deserializčními metodami (nazvané marshal/unmarshal). Kromě proprietárnosti a přesahů do designu tříd bychom asi opět narazili na problémy s výkonem. [JAXB] 190

201 Projekt ontologického systému Struktura a technologie Každý ze zmiňovaných nástrojů má své výhody i nevýhody. Ovšem všechny nástroje řeší opět jenom mechanizmus převodu objektu do nějaké uložitelné formy a nikoliv pokročilejší funkce, které bychom potřebovali. 3.2 Objektově orientované databázové systémy Objektově orientované systémy (OODBMS) umožňují ukládat objektová data ve tvaru, který je jim přirozený [SICO99] a jsou tak řešením, které se tak říkajíc na první pohled nabízí, má li aplikace propracovaný objektový návrh. ODMG Již několik let starý standard vytvořený sdružením Object Database Management Group (ODMG). S ODMG je možné vytvářet transakce, přistupovat do databáze více vlákny, znovupoužívat připojení (connection pooling). Definuje komponenty: objektový model specifikační jazyky dotazovací jazyk vazby do programovacích jazyků Avšak volně nabízené a otevřené OODBMS jsou stále (již několik let) v experimentální fázi vývoje a tak či onak nestabilní, zatímco komerční systémy ohromí svými cenami. Co je ale nejhorší, kromě ODMG existuje hned několik dalších dotazovacích jazyků a žádný není široce podporovaný. 3.3 Objektově-relační mapování Na rozdíl od objektově orientovaných, kde jsou data silně strukturovaná a logicky propojená, jediné co relační databáze (RDBMS) nabízejí, jsou tabulky propojené relacemi. Relační databázové technologie jsou vyspělé jedny z nejstarších, přitom používané a stále nejpopulárnější ze všech. Přispívá k tomu jejich jednoduchost, efektivita, obecně nižší nákladnost. Existuje i mnoho poměrně pokročilých RDBMS úplně zdarma, například PostgreSQL. Objektový přístup k tvorbě aplikací pracuje s objekty strukturami, kombinujícími data a chování, zatímco relační přístup je zaměřený čistě na ukládání dat. 191

202 Projekt ontologického systému Struktura a technologie impedanční nesoulad (impedance mismatch) Takzvaný impedanční nesoulad vyplyne na povrch, když porovnáme upřednostňované řešení přístupu. U objektového řešení je zvykem objekty procházet tak, jak jsou vystavěny příslušné závislosti, zatímco relační přístup duplikuje data při spojování řádků tabulek. Tento základní rozdíl znesnadňuje kombinaci obou přístupů, ale, přiznejme si, kdy jste naposled použili dvě různé, primárně nesouvisející věci, aniž by to vyžadovalo pár triků? Jedním z tajemství úspěchu při objektově relačním mapování je porozumět oběma přístupům, jejich odlišnostem a na základě tohoto poznání je přimět ke spolupráci. Tyto postupy jsou již dnes docela dobře propracované a dobrým úvodem je [AMBL]. V současné době jsou také k dispozici použitelné nástroje, které značně usnadní mapování. Jsou to řešení proprietární, liší se funkcemi, podporovanými formáty popisu mapování, programátorským rozhraním, podporovanými RDBMS a mnoha dalšími vlastnostmi. Na Internetu je k dispozici celá řada srovnání. Pan Ambler vzkazuje: Již před lety samozvaní objektoví guruové nabádali, abychom nechodili cestou nesouladu. Ano, objektový přístup je jiný než relační, ale v 99% případů, kdy vývojové prostředí je objektově orientované, úložištěm bude relační databáze. Prosím, smiřte se s tím. [AMBL] Ano, zdá se, že nejvhodnějším úložištěm ontologie bude relační databáze. 3.4 Objektově-relační technologie Mnoho výrobců databází, např. Oracle používá technologie, které zachovávají přednosti relačních databází a zároveň umožňují podle standardu SQL 99 specifikovat uživatelské datové typy (UDT), které logicky odpovídají objektům. Datový model je přímo v databázovém systému objektový a na jeho základě se tvoří jednotlivé tabulky. Toto řešení se principiálně neliší od O2R mapování popsaného výše, rozdíl je pouze v přímé podpoře ze strany databáze. 192

203 Projekt ontologického systému Struktura a technologie 3.5 Mnoharozměrné databáze OLAP (On-Line Analytical Processing) Je technologie, která umožňuje pohlížet na data tradiční relační databáze jako na mnoharozměrnou strukturu. Příklad inspirovaný [SICO99]: Tradiční tabulka vypadá takto: Příklad pohledu podél jiného rozměru: Tento model včetně implementace a nezbytných nástrojů umožňuje rychlé, přirozené zpracovávání dat podél všech rozměrů. Má význam zejména pro velké databáze, kde jsou potřeba postupy označované jako data mining. Součástí mnoharozměrného pohledu mohou být hierarchie a mnoharozměrná aritmetika. OLAP analýza může být implementována nad tradičními (zejména relačními) databázemi, 193

204 Projekt ontologického systému Struktura a technologie anebo nad speciálním optimalizovaným úložištěm mnoharozměrnou databází (MDBMS). Jejich cena odpovídá typickému nasazení. Možná by byly schopny zachytit ontologii, ale spíše se mi zdá, že jsou určeny pro jiné typy nasazení. Každopádně nemůžeme systém postavit na nich už pro jejich vysokou cenu. 3.6 Úložiště pro stromové struktury Stromová datová forma je velmi vhodná pro některá silně strukturovaná data, např. pro dokumenty, hierarchie objektů (třeba uživatelů), reprezentaci plánů apod. Příslušné technologie jsou například: LDAP (Lightweight Directory Access Protocol) LDAP LDAP je specifická databáze určená pro ukládání stromových datových struktur. Používá se především pro administraci v prostředí počítačových sítí, ale může slouží pro ukládání v podstatě čehokoliv, co má smysl ukládat na síť a co potřebujeme častěji číst než zapisovat. Od databáze uživatelů až po televizní program... Rozlišuje služby autorizované a neautorizované, globální a lokální, jak můžou být aktualizované záznamy a kým, co položky mohou obsahovat a mnoho dalších věcí. Je velice rychlá při čtení a vyhledávání, a to jsou operace prováděné mnohem častěji než zápis. Technologie je to zavedená a stabilní, existují otevřené implementace (OpenLDAP). [HEPP03] Nativní XML databáze Nativní XML databáze Jsou databáze specializované na ukládání XML dokumentů, místo tabulek pracují s kolekcemi XML dokumentů. Dokumenty v kolekci obvykle mohou, ale nemusí odpovídat určitému schématu. Poskytují také prostředky pro manipulaci (výběr, změna, smazání, přidání) s libovolnou částí XML dokumentů. Někdo možná namítne, že to vše lze obvykle provádět i bez specializované databáze s využitím rozhraní DOM. XML databáze k tomu přidávají možnost doku 194

205 Projekt ontologického systému Struktura a technologie menty indexovat a sofistikovaně prohledávat. K databázi lze obvykle přistupovat příkazovým řádkem, různými API nebo přes síť (nejčastěji protokol HTTP). Příklady: Tamino, Xindice, exist, Xhive. [XMLKOSE00] Kromě relačních databází v kombinaci s prostředky O2R mapování považuji právě tato úložiště za vhodná. LDAP zejména ve specifických nasazeních např. pro systém pro správu serveru apod. a XML databázi i pro použití běžné. 3.7 Snahy o univerzální přístup Sami vidíte různorodost existujících řešení perzistence aplikací, z nichž každé má své výhody a nevýhody a to jsem se o mnoha možnostech vůbec nezmínil. Potřeba zastřešit takto různorodé zdroje dat nějakým jednotným rozhraním vyústila v definování konkrétních standardů. Kromě příkladů specifických pro jazyk Java (níže) stojí za zmínku ještě jednou ODMG. Tento standard měl původně sloužit jako jednotné rozhraní objektových databází, ale teoreticky (díky svému poměrně univerzálnímu návrhu) by mohl splnit stejnou funkci. Je potřeba mít ovšem na mysli, že použitelný bude ten standard, jemuž se dostane podpory ze strany dodavatelů řešení úložišť. JDO (Java Data Objects) Standard JDO byl definován jako standardní rozhraní mezi objekty Java aplikací a úložišti persistentních dat, nejčastěji relačními databázemi. Snahou bylo oddělit vlastní logiku aplikací od konkrétního způsobu uložení dat, tedy od konkrétní databáze, ať relační či objektové. Použití JDO rozhraní usnadní programátorům práci tím, že se nemusí přímo zabývat konkrétním datovým modelem na úrovni databáze a mohou se plně soustředit na logiku aplikace. V současné době je nejsilnější podpora relačních databází. Od roku 2002, kdy byla zveřejněna specifikace a referenční implementace je standard již poměrně vyspělý a jeho podpora poměrně dobrá. Nevýhodou JDO je to, že spoléhá na modifikaci bytekódu tříd. EJB CMP Enterprise JavaBeans Container Managed Persistence EJB je komponentní architektura pro distribuované aplikace, která může být využita spolu s JDO. Komponenty EJB nabízejí svůj mechanismus pro ukládání dat, a to CMP. Na rozdíl od JDO je použití 195

206 Projekt ontologického systému Struktura a technologie CMP omezeno pouze na komponenty EJB, ale zase umožňuje distribuované transakce, přístup k distribuovaným objektům a rovněž nabízí bezpečnostní služby. JDO zase operuje s bohatším, ale zase s lokálním objektovým modelem. Např. objekty CMP musí být z balíků java.util.set nebo java.util.collection. Ukazuje se tedy, že JDO a EJB se vhodně doplnují zejména při distribuovaném zpracování. Když komponenty EJB zapouzdří třídy JDO, tak bude možné přistupovat k instancím tříd JDO vzdáleně a přímo. Použití CMP u navrhovaného systému vidím jako problematické má příliš velké požadavky na objektový model systému, navíc nelze očekávat že každý bude instalovat J2EE aplikační server. JDO se jeví jako použitelnější. Uvidíme v co vyústí snahy spojit výhody JDO a CMP v návrhu JDO Zvolené řešení Jaký typ úložiště zvolit? Otázka to mnohdy není jednoduchá a její zodpovězení běžně (často negativně) ovlivní celou aplikaci včetně jejího objektového návrhu. Co je horší, v mnoha případech není vůbec jednoznačné, které řešení je to pravé, dokonce ani který druh úložiště. Navíc, pokud je něco tím pravým nyní, nemusí tomu tak být natrvalo. Opět, hledíme li do budoucnosti, derou se nám do mysli otázky podobné, jaké jsme si již kladli v části o platformní nezávislosti: Co se stane, když výrobce použité databáze zbankrotuje? Co když databázový systém přestane vyhovovat, ale jiný by by byl lepší.. V našem konkrétním případě je problém ještě komplikovanější, protože pracujeme v heterogenním prostředí, které musí integrovat data z různých zdrojů ontologie mají sloužit jako prostředek spojení a dorozumění. Stojíme před otázkami jak provázat systémy, aniž by to bylo za cenu kompromisů v čistotě návrhu? Jak si nezavřít vrátka k jiným, modernějším možnostem ukládání, jakmile bude možné starý systém odstavit? Komplikovanost takových přechodů je zřejmá z návrhových vzorů a dalších informací z [MERGKELL]. Většina vyvíjených aplikací je silně svázána s konkrétním úložištěm. A to je chyba. Architektura podřízená modelu [ASMZEJ03] naopak doporučuje: Výběr úložiště nesmí ovlivnit objektový návrh 196

207 Projekt ontologického systému Struktura a technologie Aplikace nesmí být pevně svázána s žádným konkrétním úložištěm a dokonce s žádnou konkrétní třídou úložišť. Změna úložiště musí být proveditelná pouhou rekonfigurací či doplněním části podpůrného nástroje, který zajistí perzistenci objektovému modelu aniž by se to dotklo kterékoliv jiné části aplikace (zejména objektového modelu nebo uživatelského rozhraní) Aplikace by měla být schopna integrovat data z různých úložišť a dokonce z různých tříd úložišť Zajištění perzistence by mělo být z hlediska programátorů a vývojářů co nejsnadnější První vývojovou fází většiny nástrojů je čisté objektově relační mapování nástroje zastřešují různé (ideálně všechny dostupné) RDBMS tak, aby se případná záměna nedotkla vlastní aplikace. Takových řešení je poměrně mnoho (možná desítky). Druhá generace se snaží o skutečně univerzální přístup, jak byl popsán výše, tedy kromě RDBMS umožňují jednotně pracovat též s OODBMS, LDAP, souborovým systémem a většinou po doprogramování příslušného modulu obecně se vším. I těchto nástrojů existuje poměrně dost, populární je například Hibernate. Jeden systém ovšem vybočuje svým vysoce kvalitním návrhem a snahou jít cestou standardů všude, kde je to možné. Jakarta OJB Jakarta OJB (původně ObjectRelationalBridge, po kompletním přepracování a zuniverzálnění dále už jen OJB) je knihovna pro jazyk Java, která zpřístupňuje nejen relační databáze, ale teoreticky všechny běžné typy úložiště. Aplikace může přistupovat k úložišti přímo jednoduchým, ale proprietárním rozhraním nazvaným PersistenceBroker. OJB ale přidává další vrstvu abstrakce i směrem dovnitř, tedy k aplikaci a té tak umožňuje pracovat dle nejznámějších standardů ODMG či JDO. Tato architektura je dobře vidět z obrázku, který jsem si půjčil z [OJB]. Můžete si všimnout toho, že v návrhu se počítá se všemi typy úložišť, které pro naše použití připadají v úvahu RDBMS, OODBMS, XMLDBMS a LDAP. 197

208 Projekt ontologického systému Struktura a technologie OJB dokáže pracovat jak ve vícevrstevné architektuře uvnitř EJB aplikačního serveru, tak u nevrstvené aplikace. Je, ostatně jako všechny jiné projekty Apache Jakarta, dobře dokumentována. Její novější verze se i docela snadno nastavují i používají. A je zadarmo, dokonce open source. Sám jsem nepatrně jsem i přispěl k jejímu vývoji a její funkčnost odzkoušel na jednoduchých aplikacích. OJB je ale nasazena i v silně zatížených podmínkách. 198

209 Projekt ontologického systému Struktura a technologie C.4 Uživatelské rozhraní Tato část je možná trochu rozsáhlejší, proto hned v úvodu zmíním, o co půjde. Uživatelské rozhraní budu chápat pouze jako slupku okolo vlastního API. Budu se zamýšlet nad možnostmi kombinovat uživatelské rozhraní ručně vyprojektované s částmi automatizovaně generovanými z ontologického modelu. Důraz budu klást na rozhraní typické pro web, ale zároveň budu doporučovat univerzální zobrazovací řešení se snadnou záměnou konkrétních uživatelských rozhraní. Opět si ukážeme, co znamená zásada volná vazba snadná změna. Zmíníme se i o rozhraní pro hendikepované nebo pro intenzivní cestovatele... Než se do toho pustíme, tak si neodpustím ještě jednu odbočku, která s tématem přeci jenom trochu souvisí zmíníme co zahrnuji pod pojem dotazovací modul, aby bylo jasno, až na něj dále narazíme. dotazovací modul Co se dotazování a prohledávání týče, v systému zatím uvažujeme především klasické objektové řešení dotazy bude možno klást formou volání metod objektů, reprezentujících prvky ontologie. Na jejich základě bude možné v případě potřeby vybudovat abstraktnější neobjektový dotazovací modul pracující s jazykem blízkým přirozenému ve stylu typu SQL nebo OQL. A právě tento modul bude tvořit dotazovací systém. Případné uživatelské rozhraní tak bude moci využívat jak přímých volání API, tak služeb dotazovacího modulu. Zdaleka nejběžnějším typem uživatelského rozhraní je grafické uživatelské rozhraní (GUI). Jeho vytváření obvykle probíhá jako manuální skládání jednotlivých obrazovek z primitivních komponent, jakými jsou například vstupní pole, zaškrtávací políčka, výběrové seznamy ap. a následné propojení s modelem pomocí tzv. událostí. Komponenty uživatelského rozhraní bývají označovány též jako widgety. Každý programovací jazyk má svou sadu takových komponent, podobně i například jazyk HTML má odpovídající sady formulářových tagů (Forms, XForms, XUL..). V následujících oddílech shrnu možné scénáře ui na příkladech konkrétních technologií. Pokud jsou implementace konkrétních scénářů závislé na konkrétním programovacím jazyce, použiji příklad z Javy. 199

210 Projekt ontologického systému Struktura a technologie 4.1 Scénář desktop Z grafických uživatelských rozhraní dosud drtivě převažuje právě tento typ. Vzhled je včleněn do oken, ta se skládají z běžných i méně běžných widgetů, převzatých z programovacího jazyka či vývojového prostředí, ve kterém je aplikace tvořena a z jejich derivátů. Je to typický vzhled aplikací vytvořených pro Windows, MacOS nebo třeba X Window. Aplikace postavené na těchto prostředcích pro budování uživatelského rozhraní se obvykle vyznačují například těmito přednostmi: jednoduchost použití bohaté možnosti stabilita, vyspělost, spolehlivost V Javě byl takovou sadou komponent AWT, tento balík je ovšem zastaralý, nahradil ho nověji JFC, jehož současné verze jsou známy pod kódovým jménem Swing. Swing Tato knihovna je svým návrhem, funkcemi a použitelností podle mého názoru jednou z nejlepších vůbec, byť je občas kritizována za svou komplikovanost. Přiblížíme některé její části a schopnosti, jak jsou uvedeny ve specifikaci [J2SDK150] a můžeme je považovat za etalon schopností widgetového systému: Komponenty zahrnují vše od tlačítek až k rozdělovačům obrazovky a tabulkám. Výměnný vzhled a chování Každý program, který využívá Swing komponenty, si může vybrat, jak mají vypadat a jak se mají chovat. Například stejný program může jednou vypadat jako klasická MS Windows aplikace, podruhé jako Gnome a nakonec kovově ( Metal l&f je výchozí). Kdokoliv může vytvořit balíček vzhledu a chování, pokud si z existujících nevybere v úvahu připadá třeba i využití zvuku místo obrazu. Usnadnění API pro zapojení technologií jako např. čtečky obrazu, Braillovy panely 200

211 Projekt ontologického systému Struktura a technologie Java2D API Možnost zahrnout 2D grafiku, text a obrázky Drag and Drop Schopnost přetahovat informace mezi Swing rozhraním a nativním prostředím 4.2 Scénář z intranetu X Window Java applety Systém X Window, dodávající grafické uživatelské rozhraní UNIXům předběhl dobu už od svých počátků nabízel i přes desktop charakter aplikací možnost pracovat distribuovaně. Tento systém může běžet v režimu na způsob Windows, ale stejně snadno může server zobrazovat programy na dálku, tedy u klienta. Nevýhodou jsou značné nároky na server a přenosový kanál a také nezbytné softwarové vybavení klienta, proto je použitelný prakticky výhradně na intranetech. Časem, s rozvojem Internetu, se to ale možná změní. Technologie, která umožňuje včlenit aplikaci se Swing uživatelským rozhraním (pouze některé funkce jsou omezené či zakázané) do HTML stránky a výsledek, pokud se zveřejní na internetu, je možné spustit prakticky odkudkoliv. Zdálo by se, že applety jsou dokonalým řešením, jeho nevýhody ale nejsou zanedbatelné: Například vyžaduje stažení poměrně velikého programu před jeho spuštěním, prohlížeč musí být vybaven správnou verzí JVM a správně nakonfigurován, výsledný applet přeci jenom všechno neumí. Dáme li vše výše uvedené dohromady, nepřekvapí nás, že tato technologie si udělala špatné jméno svou nespolehlivostí a nestabilitou a proto se používá téměř výhradně v rámci intranetů, kde tyto nevýhody nejsou až tak moc citelné. 4.3 Scénář z Internetu Různé aplikace na Internetu jsou (a budou) čím dál významnější, prostředky pro jejich vytváření proto přibývají jako houby po dešti a jsou velice různorodé. Stručné a přehledné srovnání přístupů (nikoliv konkrétních nástrojů) jsem nikde 201

212 Projekt ontologického systému Struktura a technologie nenašel, proto jsem se tomuto námětu věnoval o trošičku více koneckonců zajímá nás především použití ontologií v prostředí Internetu. I tak jde ale spíše o pouhý rozcestník.. Populárním termínem v této oblasti je MVC, tedy model view controller architektura. I přes svou značnou popularitu toho MVC příliš mnoho neříká a prakticky cokoliv o sobě může prohlašovat, že je implementuje MVC přístup. MVC Klíčová myšlenka MVC by se mohla shrnout slovem oddělenost. Jednotlivé komponenty aplikace, tedy model view (vzhled) controller (kontroler) musí být maximálně oddělené jeden od druhého a komunikovat přes co nejužší, jasně vymezené rozhraní. Tato zásada je všeobecně přijímána jako důležitý předpoklad dosažení flexibility a snadné spravovatelnosti. V dalších částech se zamyslíme nad konkrétními typy MVC technologií pro prostředí webu. Termín model se poměrně dobře kryje s tím, jak zde chápeme jádro o něm jsme toho napsali už dost, tak jej dále zkoumat nebudeme. Z logického celku view probereme postupy vytváření dynamického obsahu a poté se dotkneme standardů pro vlastní formulářové prvky. O části controller se zmíním na závěr, hodně stručně Vytváření dynamického obsahu Aplikace na webu, to je vlastně hrst běžných HTML stránek doplněných o dynamiku. Takové stránky musí na jedné straně určitým způsobem prezentovat model (jádro) a na straně druhé zpracovávat uživatelské vstupy. Je možné odlišit dva principiálně odlišné přístupy, jak toho dosahovat někdy označované jako push a pull. 202

213 Projekt ontologického systému Struktura a technologie a Pull pull Historicky starší je pull přístup a funguje tak, že do jinak statické stránky dotáhne dynamický obsah. Důležitým momentem je zde to, že tento proces je iniciován a řízen z pohledu statické stránky. Klasickým příkladem pull technologie jsou skripty včleněné do HTML stránky (ASP, PHP, JSP,..). Výzkumy i zkušenosti čím dál tím jasněji ukazují, že tento přístup nevede k vytvoření snadno spravovatelné, flexibilní webové aplikace. Základní příčinou je jednoduchý fakt, že není technicky zaručeno, aby obsah, vzhled a logika byly maximálně odděleny a naopak jsou nabízeny prostředky k implementaci koncepčně špatných řešení, která jsou u push technologií technicky neproveditelná. Silná stránka skriptovacích jazyků ( moc a značné schopnosti) je v důsledku slabinou. O trochu méně výrazný, ale pořád ještě dostatečně nepříjemný je tento problém u template engines (Velocity, WebMacro, FreeMarker, Tea,...), které jsou principiálně ekvivalentní skriptování. Jejich výhodou je, že to nejsou plnohodnotné programovací jazyky, a tak nabízejí o něco méně možností k prohřeškům. Více v tomto směru např [XMLCJSY02]. Technologie umožňující obojí přístup existují od samého začátku dynamických stránek. Mám na mysli CGI skripty, tedy samostatně spustitelné programy, jejichž jediným úkolem je generovat výsledný kód stránky. V zásadě shodné s CGI jsou servlety (vlastně CGI napsané v Javě). Jakým způsobem si výsledek sestaví, je jejich soukromou věcí mohou kombinovat kód programu se statickým obsahem (pull) anebo načíst šablonu stránky a vhodně ji doplnit (push). V zásadě všechny výše uvedené technologie oddělit vzhled, logiku a obsah umožňují, ale žádná z výše uvedených to nemůže zaručit. 203

214 Projekt ontologického systému Struktura a technologie b Push Push technologie jsou naopak k takové záruce o dost blíže. Musíte se opravdu snažit, abyste princip oddělenosti porušili, a i to se vám podaří jen částečně. push Zásadní, ale velice praktické omezení spočívá v tom, že šablona, zdrojová stránka (nejspíše XHTML) prostě je statická a není žádný způsob, jak to změnit. Program načte ve vhodné podobě tuto čistě statickou stránku a vtlačí do ní na požadovaná místa dynamický obsah. Statická stránka je zde jakýmsi substrátem na kterém program dodávající dynamický obsah pracuje. Příkladem produktu, který implementuje push přístup je open source projekt Enhydra XMLC. Návrhář stránek použije svůj oblíbený editor a pouze místa, kde má stránka obsahovat dynamický obsah, označí id atributem a o logiku dotlačení dat se nestará. XMLC kompilátor z takové stránky sestaví specifickou DOM (stromovou) reprezentaci, a usnadní programátorovi přístup k označeným místům, určeným pro dynamický obsah. Programátor doplní postup získání dynamického obsahu a snadno ho včlení do stránky se zachováním jednotného vzhledu. Tento postup schematicky znázorňuje obrázek, který jsem si půjčil z [XMLCJSY02]: 204

215 Projekt ontologického systému Struktura a technologie Formuláře Obdobou desktopových widgetů jsou pro webové vývojáře tzv. formulářové tagy. HTML forms Klasickým řešením jsou HTML forms, tedy HTML formuláře, součást specifikace HTML jazyka. Jsou široce rozšířené a široce podporované. Snadno se kombinují s jinými prvky HTML jazyka, takže výsledná aplikace vypadá v mnoha případech moderněji a lehčeji než její monoliticky působící desktopový dvojník. Trpí ovšem některými chybami: příliš zjednodušující, míchá obsah a vzhled nežádoucím (správu znesnadňujícím) způsobem, na rozdíl od desktop řešení mají značně omezenou množinou použitelných grafických prvků... Kandidátem na místo formulářových značek je kromě jiných zejména standard XForms. XForms Podpora všech typů prohlížečů včetně handheldů, televizí, počítačů, tiskáren a skenerů Bohatší uživatelské rozhraní Oddělení dat, logiky a vzhledu Snadnější podpora více jazyků Strukturovaná data Pokročilá formulářová logika Více formulářů na stránce a více stránek tvořících jeden formulář Pozastavení a obnova Integrace s dalšími XML značkovacími jazkyky 205

216 Projekt ontologického systému Struktura a technologie Zdá se, že XForms nemají chybu. Ano, je to dobrý standard, ale stejně jako HTML Forms má jedno podstatné funkční omezení, které způsobuje, že trochu pokulhává za desktop řešeními: vše co zná jsou formuláře. Formuláře je možné pouze vyplnit a odeslat, což je ve srovnání s komfortem desktop řešení docela málo. Více o nich viz [XFORMS]. S formuláři si vystačíme pro dotazovací rozhraní, ale pro další interaktivní práci s ontologií její procházení, sledování vazeb, operativní úpravy apod. již nejsou příliš pohodlné. Další (a prozatím kritickou) nevýhodou je stále ještě nedostatečná podpora ze strany prohlížečů a vývojových nástrojů. Jsou zde i další možnosti, například XUL prosazovaný Mozilla Foundation. XForms jsou ale nejdále a vznikly jednáním širokého vývojového týmu, tudíž lze alespoň do budoucna očekávat i jejich silnější podporu Kontroler Existuje mnoho systémů, jejichž hlavním posláním je usnadnit navigaci uživatele po dynamicky generovaných stránkách, sledovat sezení apod. Většina těchto systémů řeší navíc další běžné úkoly související s vytvářením aplikací pro tak heterogenní prostředí, jakým je Internet např. lokalizace či bezpečnost (security). Spolupracují se systémy pro generování dynamických stránek, z nichž některé jsme zmínili výše. Patří sem Tapestry, Barracuda, Struts, Turbine a další. 4.4 Scénář mobilní Pěkné srovnání je například na stránkách [WAFEREW] a navíc uživatelské rozhraní jako takové nepatří do jádra navrhované aplikace, proto se tímto námětem nebudu blíže zabývat. I s mobilními telefony a různými PDA zařízeními je nutno počítat mobilní aplikace budou pravděpodobně jedním z nosných směrů blízké budoucnosti. Existuje obdoba jazyka HTML (WML), dále speciálně upravený virtuální stroj Javy včetně nejnutnějších knihoven (J2ME) a různé další pomůcky, nástroje, standardy a technologie. Nebudu zabíhat do podrobností, pouze připomenu, že uživatelské rozhraní na podobných zařízení má svá specifika, především si musí poradit s velikostí displeje zařízení, nesmí také vyžadovat nadbytečné datové přenosy nebo myšově ori 206

217 Projekt ontologického systému Struktura a technologie entovanou výraznou interaktivitu... Každopádně je jasné, že i s mobilními zařízeními při vývoji uživatelského rozhraní bude třeba počítat. Určité ambice v tomto směru má již zmíněný standard XForms. 4.5 Scénář hendikepovaní Kromě grafických výstupů má význam uvažovat též rozhraní pro slabozraké a nevidomé, např. systémy s Braillovým písmem a zejména zvukové. Rozhraní pro hendikepované vyžadují mnohdy kompletně odlišný přístup. Nové možnosti se otvírají v souvislosti s pokrokem systémů umělé inteligence z oblasti rozpoznávání mluvené řeči. Vytvoření podobného rozhraní pro složitější aplikace je zatím velice pracné a nevím o žádné běžně použitelné knihovně zvukových widgetů. Je pravda, že takováto rozhraní nemají tu nejvyšší prioritu, ale výslovně odmítnout hendikepované lidi by bylo diskriminující a koneckonců asi i obchodně neprozíravé, zejména pokud by řešení příliš nezkomplikovalo návrh jádra. 4.6 Jak to tedy vyřešíme? Například Swing teoreticky umožňuje vytvořit zvukový l&f. Potíž je v tom, že widgety jsou navrženy zejména pro grafická rozhraní, a tak obsahují mnoho informací o tom, jak mají vypadat, kde mají být ve formuláři apod., ale chybí jim specifické informace pro snadnou implementaci zásadně odlišných scénářů. Řešením by byla nějaká mezivrstva, která by obsahovala maximum informací o modelu a ty byla schopna převést či předat jak do specificky grafické reprezentace (např. Swingu), tak do jakékoliv jiné... Jaké sady widgetů či tagů využít? Tato otázka je poměrně komplikovaná, zejména když je nutné počítat s různými typy klientů. Klasický vzhled má nesporné výhody, ale uživatelé potřebují svá data odkudkoliv, třeba i z internetové kavárny nebo mobilního telefonu. Situace je ještě více komplikovaná tím, že současný stav na poli technologií uživatelského rozhraní není jistě definitivní. Co když bude potřeba v budoucnosti podporovat nějaký další typ klienta? Co když klienti pro námi zvolený typ uživatelského rozhraní přejdou na jiný standard? Tvrdím, že: 207

218 Projekt ontologického systému Struktura a technologie Navrhovaná knihovna by neměla nijak zužovat možnosti volby uživatelského rozhraní. S tím, že API bude sloužit i uživatelskému rozhraní a dotazovacímu modulu je třeba počítat, ale nesmí to snížit kvalitu objektového návrhu. Aplikace nesmí být závislá na použitém uživatelském rozhraní, naopak musí být snadno přizpůsobitelná jakémukoliv uživatelskému rozhraní pouhou rekonfigurací pomůcky, která vytvoří prezenční vrstvu, aniž by se to jakkoliv dotklo jakékoliv jiné části aplikace (objektového modelu, ontologie, jiných podporovaných uživatelských rozhraní či dokonce perzistenční vrstvy). Uživatelské rozhraní musí být odvozeno od objektového modelu, dynamicky se mu přizpůsobovat pokud možno co nejvíce automatizovaně, ale zároveň umožnit doladění podle potřeb uživatelů. Jak jsem již naznačil, konkrétní uživatelské rozhraní není předmětem našeho nejbližšího zájmu, ale neodpustím si zmínit nástroj, na kterém jsem pracoval a který by mohl pro jeho tvorbu posloužit nebo by mohl být alespoň inspirací. Nástroj dostal název Xermes. Xermes Serverová část generuje formuláře uživatelského rozhraní ve formátu nezávislém na konkrétním scénáři uživatelského rozhraní. Tyto formuláře jsou interpretovány klientskou částí Xermesu a přetvořeny do konkrétní podoby komponent uživatelského rozhraní. Veškerá komunikace mezi klientem a serverem probíhá v XML. Prozatím je vytvořen klientský modul využívající primitivní komponenty knihovny Swing, počítá se ale s klientem pro prostředí Internetu, využívající nejspíše HTML formuláře a XMLC pro snadné včlenění do konkrétních stránek. Podstatné ovšem je, že architektura systému umožňuje doplnit klientskou část pro prakticky každý jmenovaný scénář. Více informací o projektu najdete na jeho stránkách [XERMES], ty jsou ovšem trochu zastaralé, proto je berte s rezervou. 208

219 Projekt ontologického systému Struktura a technologie C.5 Neinteraktivní rozhraní Pod tento pojem shrnuji několik na první pohled nesouvisejících rozhraní, které spojuje jedno pokud vůbec vyžadují interakci uživatele, vystačí si s jednoduchým pokynem a jinak spoustu práce vykonají samostatně. Neprobíhá žádný skutečný dialog. export / import ontologie Tento modul zajistí interoperabilitu vytvořené ontologie s jinými nástroji pro práci s ontologiemi. Jednotlivé adaptéry budou rozumět konkrétním jazykům reprezentace ontologií (RDF, OIL, KAON...). Bude třeba více rozebrat, jak si má systém poradit s takovými situacemi, kdy meta model importované / exportované ontologie bude nekompatibilní. Vzhledem k univerzálnosti navrhovaného systému takové situace asi budou nastávat často především při exportech do ontologií s nižší vyjadřovací schopnosti. sestavy Tím myslím především statistiky, různé informace o činnosti, součty, porovnání, analýzy, doporučení, všemožné přehledové tiskové sestavy... prostě různé informace vydolované z ontologie, požadované v konkrétním formátu buď pro další zpracování nebo pro tisk. komunikace Ostatní typy komunikace, jiné než o kterých jsme doposud mluvili tedy nikoliv dialog s uživatelem, export nebo import ontologií, hlášení událostí naslouchačům ani sestavy navržené výše. Příkladem může být třeba výměna nastavení a profilů. Tuším, že dospějeme k řešení, které bude alespoň z pohledu jádra a jeho nejbližšího okolí všechny tyto výstupy integrovat do jednoho univerzálního řešení neinteraktivního rozhraní. 5.1 Sestavy zejména pro tisk Začněme běžnou věcí tiskovými sestavami. Ty je možné řešit proprietárním způsobem (jako vše) nebo využít některého ze standardních formátů pro popsání 209

220 Projekt ontologického systému Struktura a technologie textové informace s přihlédnutím k její grafické podobě. Uvedu některé zástupce a v další části se pak krátce zamyslím nad výstupy, které nesměřují na papír. Když mluvím o grafické podobě výstupů, nemám na mysli pouze uspořádání textu na stránce, ale i skutečné grafické informace buďto načerpané z externích entit anebo vygenerované číselné grafy, grafická zachycení struktury částí ontologie apod. Rich Text Format (RTF) OOo 2.0 RTF je formát pro zachycení textu včetně formátování, struktury, dalších vlastností s použitím tisknutelných znakových sad. Mechanizmus kontrolních příkazů nabízí jmenný prostor, který může být využit k definování speciálních znaků, ale také různých vložených objektů, maker apod. [FFORMENM] Jeho výjimečnost spočívá v tom, že je na rozdíl od silně proprietárních formátů (DOC, WLS,...) je celkem dobře popsán. Díky tomu může sloužit jako výměnný formát mezi různými textovými editory a kancelářskými balíky, jejichž nativní formáty jsou vzájemně nekompatibilní, ale i jako výstup IS. Nový formát balíku OpenOffice.org byl přijat jako standard sdružením OASIS OPEN a jedná se o jeho přijetí jako ISO standardu. Pravděpodobně se stane formátem výměny dokumentů mezi evropskými vládami a orgány Evropské unie. Vnitřní struktura je velmi přehledná, tak jak tomu bylo již u formátu předchozího je to sada XML souborů a použitých objektů zabalená do ZIP archivu a tak je formát vhodný i pro různé dodatečné transformace. PostScript (PS) a Portable Document Format (PDF) PostScript je jazyk určený pro popis stránek dokumentu nezávisle na výstupním zařízení respektive na jeho rozlišení. Tvůrcem tohoto jazyka je firma Adobe. Mnoho laserových tiskáren ho přímo zná, proto stačí dokument na tuto tiskárnu přímo poslat. Pokud tiskárna Post 210

221 Projekt ontologického systému Struktura a technologie Script nedokáže interpretovat, je k tomu potřeba softwarový interpretr, např. GhostScript. Základní elementy v PostScriptu jsou Bézierova křivka, úsečka, text lze popsat přímo jako text avšak ve výsledku se písmena kreslí z oblouků. [PSCRPTM97] Rozdíl oproti RTF spočívá ve schopnosti stránku popsat přesně a precizně, tedy tak jak je to třeba pro profesionálnější tiskový vzhled. PDF vychází z PS, je vnitřně komprimovaný, se zvýšenou přenositelností, podporou Unicode a mnoha jinými výhodami, princip i primární použití je ovšem stejné. TeX Viz TeX je fenomén pocházející původně z UNIXů. Pod touto zkratkou se skrývá jak vlastní formát, tak množina programových nástrojů pro sazbu. V současnosti existují různé implementace pro všechny myslitelné platformy. Principiálně zhruba odpovídá PDF, jeho vyjadřovací schopnosti jsou ale ještě o trochu lepší.. SVG (Scalable Vector Graphic) Jazyk pro popis dvourozměrné grafiky, založený na XML. SVG zná tři typy grafických objektů: vektorové grafické tvary (např. cesty skládající se z rovných linií a křivek) bitmapové obrázky text. Grafické objekty mohou být seskupovány, dolaďovány použitím stylů, transformovány, komponovány do předrenderovaných objektů. Mezi interní funkce patří vnořené transformace, ořezové cesty, alfa masky, efekty a šablony. [SVG] Ano, SVG je především standardní grafický formát schopnost uchovávat textové informace je až na druhém místě. Je to patrné i z toho, že MIME typ pro SVG je image/svg+xml. 211

222 Projekt ontologického systému Struktura a technologie Uvedené formáty se liší tím, jaký důraz kladou na textovou a nebo spíše grafickou podobu informací, které zachycují, proto mají všechny své opodstatnění a všechny se více či méně používají. Zmiňujeme je všechny proto, že ani jeden z nich nelze zavrhnout a ideální formát se bude lišit podle charakteru a použití sestavy. Systém by je měl svým způsobem podporovat všechny. Klíčem k řešení je dekompozice vrstvy rozhraní na část obecnou, která bude produkovat pouze holá data pro zařazení do sestavy a na část specifickou. Vlastní formát sestaví specifický formátový adaptér. Než se zamyslíme nad detaily, vrhneme se na další kapitolu z kategorie neinteraktivních výstupů Netiskové výstupy, komunikace Již jsme o tom na mnoha místech mluvili, proto pro oživení jen pár příkladů: prezentace (XHTML) Elektronický obchod postavený na ontologii bude za běhu generovat XHTML obsah katalog produktů. cizí klasický systém (SQL) Výstupem z ontologie může být být také například SQL INSERT příkaz, který doplní záznam v nějaké cizí databázi. Mám na mysli například nějaké logy, statistická data, informace pro prezentaci, objednávku, reklamaci... cizí ontologický systém (RDF...) Na ontologii postavený elektronický obchod našeho distributora průběžně (třeba každou) automaticky aktualizuje svoje data dotazem, který odešle našemu systému. Čeká nová data ve formátu RDF a ta také pokaždé dostane. 212

223 Projekt ontologického systému Struktura a technologie klient pro sledování stavu sítě (SNMP) Administrátor chce mít vždy přehled o tom, co se děje v jeho síti. Systém pro správu je tvořený především několika propojenými ontologiemi. Je zvyklý používat nástroje pro sledování stavu aktivních síťových prvků využívající standardní protokol SNMP. Velmi se mu zamlouvá, že ontologický systém dokáže hlásit změny rovněž v podobě tohoto protokolu pro sledování nemusí instalovat a zkoumat žádný další nástroj... elektronické podání (XML) Je libo daňové přiznání v elektronické podobě, ve formátu založeném na XML? 5.3 Univerzální řešení Rizika Základní nevýhoda formátů pro tiskový výstup spočívá v tom, že jsou nevhodné pro jiné použití informace chápou graficky a neznají význam informací. Dejme tomu, že pro tiskové výstupy programu použijeme RTF. Ale co když si pořídíme PostScriptovou tiskárnu a budeme chtít využít její schopnosti pro zvýšení kvality výstupů? Tak je převedeme, možná řeknete a s jistými obtížemi se vám to podaří. Ano, tak jiná otázka: Co když podobné výstupy, jaké tisknete, budete posílat ke zpracování cizímu informačnímu systému, spravovaného například ministerstvem financí. A co když požadovaný formát bude vyžadovat VÍCE informací, než kolik jich je v RTF, takže automatizovaný převod bude znamenat spoustu práce při psaní nějakého převodního programu či schématu a nebo bude principiálně neproveditelný. Ano, přijde to nejhorší zásah do vlastní aplikace (do metod uvnitř tříd modelu). Shrneme li výše uvedený příklad: Pouze graficky formátované informace jsou takřka nepoužitelné jinak, zejména strojově. Podobné otázky si můžeme klást i u netiskových výstupů: 213

224 Projekt ontologického systému Struktura a technologie Dejme tomu že náš systém bude produkovat SQL příkazy. Ale co když po čase zjistíme, že potřebujeme nikoliv SQL výstup, ale výstup například v nějakém proprietární textovém formátu? Bude to znamenat úpravu informačního systému? A co když budeme chtít ještě části výstupů tisknout? Tady není situace tak kritická, protože SQL, byť je pro výše uvedené použití nevhodný, obsahuje poměrně dost metainformací o charakteru posílaných dat jsou skryty v použitých názvech tabulek a sloupců Požadavek a řešení Změna konkrétního výstupního formátu možná a maximálně snadná a nesmí vyžadovat zásahy do modelu. Nezbytným předpokladem úspěšného řešení je zachování co největšího množství informací a meta informací v primárním výstupu. Bude li primární výstup dostatečně informačně bohatý, finálního výstupu docílíme poměrně snadno sestavením transformačního schématu, které ovšem nijak neovlivní vlastní ontologický systém. Transformace proběhne vně. Přiložený obrázek [XMLKOSE00] demonstruje snadnost transformace z informačně bohatšího zdroje do informačně chudšího formátu. Jaký formát dokáže zachytit v zásadě libovolné informace, aniž by je nějak okleštil? Už nebudu dále chodit kolem horké kaše a řeknu to na rovinu: pro primární výstup použijeme XML s vhodným schématem, a ten transformujte dle XSLT šablony do výsledného výstupu. 214

225 Projekt ontologického systému Struktura a technologie Co je XML, XSLT, schéma a podobné věci vysvětlovat nebudu o tom již byly popsány napsány mnohé stohy papíru. Pouze zmíním jeden nástroj, který by mohl usnadnit a zpřehlednit generování různých výstupů z různých XML zdrojů, pokud by se situace ve vašich výstupech stala nepřehlednou. Apache Cocoon Systém pro pro usnadnění provádění hromadných transformací. Je vhodný především pro generování stránek pro WWW prezentace z všemožných datových zdrojů především z XML. Je ale navržený natolik univerzálně, že by mohl výhodně posloužit i jako vrstva ontologického systému zodpovědná za vytváření konečných neinteraktivních výstupů, ovšem toto použití jsem zatím neověřil v praxi. Jak bude vypadat architektura navrženého neinteraktivního rozhraní? Trochu jsem pozměnil původní návrh architektury a znázornil jsem pouze na ty části systému, které mají přímou souvislost: RDF e/i tiskové sestavy šablona PDF print cizí IS XML db SQL neinteraktivní rozhraní naslouchání událostem volání API API ontologie A co bude finálním výstupem? Cokoliv, pro co bude napsán adaptér. Jak jsme již zmiňovali, každý formát má svá pro a proti a zejména svá vhodná a nevhodná použití. Při implementaci pluginů budu sám dávat přednost formátům standardním před proprietárními, ale každý nechť sestaví adaptér pro to, co je mu milé. 215

226 Projekt ontologického systému Struktura a technologie C.6 Infrastruktura nasazení Jádrem každé aplikace je její vnitřní logika struktura dat a procesů nad nimi To zde označuji jako model, v našem případě ontologický model. Modelu slouží nějaké úložiště, které dodává datům trvalost a dále uživatelské rozhraní. Tyto funkční celky můžeme chápat v ideálním případě jako uzavřené subsystémy, které navenek komunikují pouze přes konkrétní veřejná rozhraní. Vzájemné vztahy mezi těmito subsystémy definují architekturu systému, tak jak jsme ji doposud chápali. infrastruktura Nasazení na konkrétních počítačích nebo počítačových systémech. U každého programového subsystému nás zajímá, ve spojení s kterým dalším programovým subsystémem je umístěn na společném počítačovém systému. Ještě zmíníme nějaké ty standardy, vhodné pro realizaci komunikace mezi komponentami: SOAP SOAP definuje mechanismy pro výměnu strukturovaných a typových dat ve formátu XML mezi účastníky v decentralizovaném, distribuovaném prostředí. Specifikuje formální podobu zpráv (XML Infoset) včetně abstraktního popisu obsahu. Je bezstavový, vybudovaný podle paradigmatu jednosměrné výměny a je až na konkrétních aplikacích, zda jej obohatí o složitější vzor interakce požadavek/odpověď, požadavek/mnoho odpovědí atp. SOAP nedefinuje jaká data mohou být přenášena zabývá se zejména směrováním, garancí doručení, průchodem firewally.. Aplikacím pouze do 216

227 Projekt ontologického systému Struktura a technologie poručuje, jak má být zpráva zpracována a jak mohou být vhodně reprezentována data. [SOAP12] RPC, XML-RPC, CORBA, RMI Použití ontologických dat uvnitř SOAP obálky se úplně nabízí.. Různé metody vzdáleného volání procedur a metod a využívání vzdálených komponent. Nosnou myšlenkou všech uvedených metod je integrace systémů v zásadě běžících v různém prostředí, na vzdálených počítačích, pod jinými systémy a kromě RMI i napsaných v rozdílných jazycích.. Připadá v úvahu několik typických infrastruktur. 6.1 Nevrstvená infrastruktura Na okraj poznamenávám, že obrázky jsou UML diagramy nasazení, krabice v nich znamená hardwarový prostředek, nejspíše počítač. Nejběžnějším řešením v jednouživatelském prostředí je nevrstvená infrastruktura. Obvykle všechny části aplikace běží na jednom stroji, výhodou je jednoduchost ve všech směrech jednoduchá výroba, jednoduché testování, jednoduché nasazení. Implementačně jde o první řešení, které by nás asi napadlo, kdybychom se infrastrukturou vůbec nezabývali. Není použitelná v distribuovaném prostředí, kde například s jednou ontologií pracuje více lidí. 217

228 Projekt ontologického systému Struktura a technologie Z užití, kterými jsme se podrobně zabývali takto bude typicky vypadat třeba aplikace pro organizaci dat, provozovaná jediným uživatelem, který si v ní uspořádá třeba svou sbírku písniček a fotografií. 6.2 Dvouvrstevná infrastruktura Základní způsob jak umožnit více uživatelům pracovat se sdílenými prostředky (v našem případě ontologií), je vytvořit server, který bude tyto prostředky poskytovat klientům, kteří je budou naopak využívat. V oblasti kritických aplikací je tato infrastruktura spíše na ústupu ve prospěch modernějších struktur, které popíšeme dále, přesto ji ale nemůžeme opomenout. Data je nutné sdílet prakticky ve všech případech, ale z hlediska umístění aplikační logiky připadají v úvahu dvě varianty: S mohutným klientem Pokud klient obsahuje kromě uživatelského rozhraní i aplikační logiku, je to mohutný klient (thick client). Pro nás by to nejspíše znamenalo pouze oddělení databáze od ontologického systému jinak nasazeného na jediném stroji. Z hlediska implementace je to řešení snadné, pouze v nastavení databázového konektoru bude třeba udat adresu počítače s databází a tím veškeré rozdíly oproti celodesktopovému řešení končí. Tento model by se uplatnil třeba v situaci, kdyby bylo třeba ke stejné ontologii přistupovat z více míst, ale bez složitější spolupráce mezi uživateli například správce sítě chce mít přehled i doma, tak vždy než odejde z práce ukončí ontologickou aplikaci a když přijde domů spustí si ji na svém soukromém počítači. Aplikace se připojí 218

229 Projekt ontologického systému Struktura a technologie na vzdálenou databázi a administrátor má dále přehled a může ontologii třeba i upravovat S tenkým klientem Klient, který neumí nic jiného, než zprostředkovat uživateli přístup k datům a programové logice tím, že se spojí se serverem je tenký (thin). Takovým klientem může být například prohlížeč internetových stránek ( browser ), který žádnou logiku konkrétní aplikace už ze své podstaty obsahovat nemůže. Typickým užitím je třeba elektronický obchod postavený na ontologii. 6.3 Třívrstevná infrastruktura Je li každý popisovaný systém maximálně autonomní, je to třívrstevná infrastruktura (three tier, multilayered) 219

230 Projekt ontologického systému Struktura a technologie Tato varianta je každopádně nejsložitější, ale přináší mnohé výhody například: [TRILAYCH] snadná zaměnitelnost úložiště nebo prezentační vrstvy snadnější škálovatelnost a z toho plynoucí nižší nároky na hardware snadnější integrace starých systémů lepší odolnost a výkon Tyto výhody ji předurčují pro použití ve složitých podnikových systémech, obchodních aplikacích, tam kde k jedné ontologii bude přistupovat spousta uživatelů, půjde o bezpečnost, výkon... Tím jsme prozkoumali konvenční a klasické infrastruktury, teď přidáme pár méně běžných, o to ale zajímavějších a možná i perspektivnějších Software jako služba (SaaS) Nejde přímo o typ infrastruktury, ale úzce s tím souvicí. SaaS je někdy popisována jako hlavní výzva pro komunitu výzkumníků v oblasti systémového inženýrství. Jde o souhrn technologií a metod pro rychlý a efektivní vývoj a evoluci (a to i ve smyslu dlouhodobé správy) počítačových systémů. Jádrem je premisa, že uživatel považuje software nikoliv za produkt, ale za službu. Když pořizuje software, nejde mu o krabici, ale o to, co mu přinese. [SAASL BM04] Aplikace vystavěné podle zásad SaaS mají infrastrukturu, která přímo směřuje k dynamické integraci. Výhody takového pojetí jsou zřejmé částečně čerpám z [SAASWHC04]. Jedna aplikace nabízí funkčnost, kterou potřebují mnozí. Díky tomu, že je pojímána jako služba je univerzálnější neliší se v různých nasazeních. Umožňuje nastavení a parametrizaci, ale SaaS model na druhou stranu brání klientům, aby si vymýšleli zbytečnosti. Vynucuje dobré mravy při vývoji i při používání. Brání znovuvynalézání kola. Šetří peníze a čas. SaaS informační služba přináší informace agregované z mnoha zdrojů, prezentuje je unifikovaně, v příjemném webovém rozhraní. To je vlastně i původní myšlenka portálů. 220

231 Projekt ontologického systému Struktura a technologie Typickým modelem provozu SaaS software je hosting; hostované služby je snadnější provozovat. Částečně kvůli limitovaným možnostem parametrizace, částečně proto, že nemusíte kupovat hardware ani software, instalovat atp. O to vše se postará poskytovatel vám jde o službu. Vy nemusíte nic spravovat, opravovat, upgradovat, udržovat, kontrolovat za to vše ručí on. Dostanete vyzkoušenou aplikaci sestavenou z komponent (služeb) a nemusíte najímat vývojáře a správce. Ceny SaaS jsou predikovatelné (reprodukované) a typicky odvoditelné od intenzity používání. Nezávislost. Pokud dodavatel neplní očekávání, je neobyčejně snadné se přepnout na jiného. Toto vědomí udrží dodavatele bdělé a ochotné pomáhat a spolupracovat. Do našeho ontologického pojetí to vše zapadá velmi dobře rovněž usilujeme o integraci, nezávislost, flexibilitu. 6.5 Data jako služba (DaaS) Architektura, která má mnohé rysy společné se SaaS, zejména schopnost dynamicky vázat služby a protože jsou službami vlastně komplexní data, jde o Data as Service (DaaS). Ano, přímým cílem je integrace heterogenních datových zdrojů. 221

232 Projekt ontologického systému Struktura a technologie V centru dění je broker (zprostředkovatel), který agreguje informace z různých systémů, transformuje je a zprostředkovává pro další použití. Takovou integraci velmi usnadní sdílený slovník, na kterém se třeba ve spolupráci s nějakou nezávislou autoritou dohodnou zúčastněné subjekty. Zajímavý projekt architektury service brokeru v prostředí nemocnic a zdravotní péče dostal název IBHIS. Jeho cílem je poskytnout koncovým uživatelům unifikovaný pohled na data z mnoha zdravotnických zařízení a institucí. Autoři navrhli Architekturu integrace dat orientovanou na služby (SODIA). Na rozdíl od SaaS jejich systém nevyhledává poskytovatele služeb na základě funkcionality, ale spíše na poskytovaných dat. [IBROKER04] Jak do tohoto scénáře zapadají ontologie? mohou být těmi daty, která jsou agregována mohou sloužit jako zprostředkovatel, jako společný slovník mohou doplnit jiná data (relační, dokumenty..) o jejich význam viz meta ontologie a třeba tématické mapy. 222

233 Projekt ontologického systému Struktura a technologie 6.6 Nezávislí agenti Další perspektivní a bouřlivě se vyvíjející typ infrastruktury. Systémy jsou občas popisovány v analogiích s přírodou v pojmech jako ekosystém, společenstvo, symbióza. Základní myšlenka je prostá na rozdíl od všech předchozích modelů zde není žádné centrum, žádný nadřazený kus softwaru, který by ostatním diktoval co mají dělat. Místo toho vedle sebe působí předem neurčený počet nezávislých programových instancí, ty se vzájemně vyhledávají, dorozumívají, poskytují a využívají služby. agent agent agent agent Jaké to přináší výhody? výhody architektury nezávislých agentů Vyšší odolnost nejsou zde žádná zranitelná centra. Živelná pohroma, útok konkurence, vládní agentura (ani všemocná RIAA), válka nic z toho neohrozí systém samotný. Vyšší výkon a škálovatelnost nejsou zde úzká místa, výkon celku je teoreticky neomezený. Extrémní škálovatelnost předurčuje agentní systémy třeba pro využití pro budování výpočetních klastrů nebo technologie grid computingu. Pro komunikaci mezi agenty je zřejmě ideální Internet. Takové distribuované pojetí Internetu mnohem více odpovídá záměrům původních jeho tvůrců, než současný systém službami napěchovaných, mnohdy mohutných a zranitelných serverů. Web je vlastně krok zpět k určité míře centralismu. Kromě úplně decentralizovaných řešení existují různá přechodová stádia některé spíše podpůrné služby může poskytovat jeden nebo více k tomu určených 223

234 Projekt ontologického systému Struktura a technologie serverů. Nejde ale o řízení, ale spíše podporu pomoc při objevování ostatních agentů, překládání komunikace mezi nimi apod. Častým řešením je, že sice existují servery, ale těch je předem neurčený počet. Seznamy aktuálně dostupných serverů jsou neustále dynamicky aktualizovány s přispěním klientů ti se vzájemně o serverech informují, informace předávají serverům samotným a ty je opět šíří dále... Ve všech těchto případech se přímo nabízí použití ontologie při komunikaci pro sdělování požadavků, odpovědí, pro popisy nabízených dat a služeb.. Ve skutečnosti různé platformy pro budování agentních systémů s využitím ontologií počítají. Takovou infrastrukturu mají dnes tolik oblíbené P2P systémy pro sdílení dat nové generace. Agenty a P2P systémy lze ale samozřejmě využít i ke skutečně seriózním účelům, například k budování samoučících se repozitářů, viz [P2PLTDN] Inteligentní agenti a Charakteristické rysy Inteligentní informační agent je opět autonomní a adaptabilní počítačový program, pracuje obvykle v prostředí počítačových sítí, spolupracuje s různými systémy a databázemi. Technologie kombinuje umělou inteligenci (uvažování, plánování, práce s přirozeným jazykem atd.) s technikami vývoje inteligentních systémů (objektově zaměřené plánování apod.). Inteligentní agent má tyto typické rysy [INTAGEM04]: autonomní působnost Schopnost provádět uživatelem definované úlohy nezávisle na uživateli a často i bez přítomnosti nebo vedení uživatele. Uživatel jednou specifikuje co, kde a kdy má agent vykonávat, a ten provádí daný úkol pouze tehdy, když nastanou vhodné podmínky. přizpůsobivé chování Schopnost napodobovat jednotlivé uživatelovy kroky během provádění úlohy. Například si agent může uložit do paměti různé reakce uživatele na dané situace a podle toho potom sám provádět rozhodnutí apod. 224

235 Projekt ontologického systému Struktura a technologie mobilnost Schopnost volně procházet počítačovými sítěmi a vykonávat úlohy na vzdálených místech. Agenti jsou většinou tvořeni přeložitelným scriptem, který napomáhá bezproblémovému pohybu přes různé architektury sítí. Například komunikačně orientovaný script jako Telescript může ulehčit vzájemnou komunikaci mezi jinými agenty, kteří jsou uloženi na odlišných procesorech. kooperativní chování Schopnost dvousměrné komunikace mezi agenty, kteří pak mohou společně provádět větší a komplexnější úlohy. Například pan X pošle panu Y elektronický dopis, který musí být neprodleně doručen. Agent nesoucí dopis od pana X se spojí s agentem pana Y a ten mu sdělí, že pan Y je na dovolené, tudíž je lepší zprávu odfaxovat sekretářce pana Y b Použití Agent může provádět takové věci, jako filtrování elektronické pošty organizování schůzek lokalizování požadovaných informací upozorňování na vhodnou možnost investice zjištění nejvhodnějšího dopravního spojení. Uživatelé jsou v současné době zahlceni obrovským množstvím informací, které se na ně ze všech stran valí vede to k informační zahlcenosti, možná až úzkosti či apatii. Proto potřebují získat žádané informace v co nejkratší době, bez zbytečného šumu. Agenti mohou pomoci roztřídit a profiltrovat data do lehce manipulovatelného a přehledného množství relevantních informací, přesně podle požadavků a potřeb uživatele. Čím dál více lidí intenzivně cestuje, ale zároveň musí být stále k zastižení. Elektronické zprávy je třeba inteligentně směrovat a filtrovat. 225

236 Projekt ontologického systému Struktura a technologie A obecně, jak se tempo života zrychluje, je třeba minimalizovat čas strávený nad rutinními úkoly, aby se člověk vůbec také někdy dostal k odpočinku, zábavě, ke svým koníčkům apod. 6.7 Infrastruktura pro navrhovaný systém Při tvorbě konkrétní aplikace je zde dilema funkce a komplexnost versus jednoduchost. Distribuované systémy na jedné straně umožňují dostat funkce a data tam, kde jsou potřeba, ale na druhé straně zvyšují složitost. Klient/server systémy mají tendenci být mnohem komplexnější než konvenční desktop architektury. Zmiňme jen pár zdrojů této složitosti: GUI, vrstva aplikačního serveru, heterogenní platformy. Je zřejmé, že je často nutné volit mnoho kompromisů v zájmu snížení složitosti na zvládnutelnou úroveň. [CLSERRK97] Jinými slovy někdy je chybou zvolit nevrstevnou architekturu, jindy je zase chybou distribuovat. Ontologický systém proto nesmí infrastrukturu jej využívající aplikace v žádném případě diktovat. Musí být snadno škálovatelný, a to nejlépe z jednoduché desktop aplikace, přes různé klient server modifikace, až po třívrstevný model s aplikačním serverem uprostřed. Celé jádro musí být navrženo co nejlépe, bez specifik pro nějaké konkrétní finální nasazení. Přechod mezi různými typy infrastruktury by měl být realizovatelný pouhou rekonfigurací podpůrných nástrojů, které obalují ontologický model. 226

237 Příloha CD Příloha CD V Příloha - CD Přílohou práce je CD. Najdete na něm především: první prototyp knihovny ELONT (ELastic ONTtology) Tak jsem nazval knihovnu pro práci s široce konfigurovatelnými ontologiemi jejíž analýza a návrh byla předmětem značné části dokumentu. Na CD najdete především: UML diagramy knihovny, především diagramy tříd, ve formátech ZARGO Formát open source modelovacího nástroje ArgoUML. XMI výměnný formát pro UML modely Zdrojový kód v jazyce Java. Jednotkové testy v jazyce Java pro ověření funkčnosti jednotlivých klíčových částí knihovny a zajištění kvality a konzistence i v případě budoucích úprav a rozšiřování. API dokumentace popis rozhraní pro programátory, kteří by knihovnu rádi vyzkoušeli. HTML, podle zvyklostí JavaDoc Binární podoba knihovny JAR archiv pro použití v aplikacích Všechny cizí knihovny, které jsou pro běh prototypu nezbytné První prototyp aplikace (pro změnu nazvané) ELORD (ELastic ORDer) Je to ta aplikace pro organizaci dat, kterou jsem zmiňoval v příslušné případové studii UML diagramy knihovny, především diagramy tříd, opět ve formátech ZARGO 227

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Znalostní systém nad ontologií ve formátu Topic Maps

Znalostní systém nad ontologií ve formátu Topic Maps Znalostní systém nad ontologií ve formátu Topic Maps Ladislav Buřita, Petr Do ladislav.burita@unob.cz; petr.do@unob.cz Univerzita obrany, Fakulta vojenských technologií Kounicova 65, 662 10 Brno Abstrakt:

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale

Tovek Server. Tovek Server nabízí následující základní a servisní funkce: Bezpečnost Statistiky Locale je serverová aplikace určená pro efektivní zpracování velkého objemu sdílených nestrukturovaných dat. Umožňuje automaticky indexovat data z různých informačních zdrojů, intuitivně vyhledávat informace,

Více

Olga Rudikova 2. ročník APIN

Olga Rudikova 2. ročník APIN Olga Rudikova 2. ročník APIN Redakční (publikační) systém neboli CMS - content management system (systém pro správu obsahu) je software zajišťující správu dokumentů, nejčastěji webového obsahu. (webová

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 AGENDA definice IS, zavedení pojmů možnosti a rozdělení typická struktura technologie nasazení praktická ukázka

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Strana 1 z 12 Obsah 1. Leady... 3 a. Shrnutí... 3 b. Popis modulu... 3 c. Technické podrobnosti o modulu... 5 2. MERK... 6 a. Shrnutí... 6 b.

Více

Wonderware Information Server 4.0 Co je nového

Wonderware Information Server 4.0 Co je nového Wonderware Information Server 4.0 Co je nového Pavel Průša Pantek (CS) s.r.o. Strana 2 Úvod Wonderware Information Server je výrobní analytický a reportní informační portál pro publikaci výrobních dat

Více

Specializace Kognitivní informatika

Specializace Kognitivní informatika Specializace Kognitivní informatika Otevřené dveře specializace Kognitivní informatika, 10.5.2007 V rámci projektu, financovaného Evropským sociálním fondem pod č. 3206 Multi- a transdisciplinární obor

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Česká zemědělská univerzita v Praze

Česká zemědělská univerzita v Praze Česká zemědělská univerzita v Praze Provozně ekonomická fakulta Katedra informačních technologií Teze diplomové práce Operační systém Google Android Petr Koula 2011 ČZU v Praze Souhrn Diplomová práce zahrnuje

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Manažerská ekonomika

Manažerská ekonomika PODNIKOVÝ MANAGEMENT (zkouška č. 12) Cíl předmětu Získat znalosti zákonitostí úspěšného řízení organizace a přehled o současné teorii a praxi managementu. Seznámit se s moderními manažerskými metodami

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

Obsah ČÁST I JAK SE UCHÁZET O ZÁKAZNÍKY NA WEBU KAPITOLA 1

Obsah ČÁST I JAK SE UCHÁZET O ZÁKAZNÍKY NA WEBU KAPITOLA 1 Obsah O autorech 11 Poděkování 13 Předmluva 15 Úvod 17 Proč byste se měli přečíst tuto knihu 17 Co tato kniha obsahuje 18 Jak používat tuto knihu 19 Zpětná vazba od čtenářů 20 Errata 20 ČÁST I JAK SE UCHÁZET

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

případová studie KB - BLOK systém, s.r.o. Nová webová prezentace rozšířená o e-shop www.fg.cz

případová studie KB - BLOK systém, s.r.o. Nová webová prezentace rozšířená o e-shop www.fg.cz případová studie KB - BLOK systém, s.r.o. Nová webová prezentace rozšířená o e-shop www.fg.cz KB - BLOK systém, s.r.o. Nová webová prezentace rozšířená o e-shop Nová webová prezentace rozšířená o e-shop.

Více

JAK NA PAPERLESS. Petr Dolejší Senior Solution Consultant

JAK NA PAPERLESS. Petr Dolejší Senior Solution Consultant JAK NA PAPERLESS Petr Dolejší Senior Solution Consultant PAPERLESS CO TO VLASTNĚ JE Wikipedia - Paperless představuje fungování, kde je odstraněno nebo výrazně omezeno používání papíru. Toho se dosáhne

Více

Management informačních systémů. Název Information systems management Způsob ukončení * přednášek týdně

Management informačních systémů. Název Information systems management Způsob ukončení * přednášek týdně Identifikační karta modulu v. 4 Kód modulu Typ modulu profilující Jazyk výuky čeština v jazyce výuky Management informačních systémů česky Management informačních systémů anglicky Information systems management

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013 EKONOMICKÝ A LOGISTICKÝ SOFTWARE Luhačovice 24.10.2013 CRM řízení vztahů se zákazníky CRM - je zkratka z anglického Customer Relationship Management a označují se tak systémy pro řízení vztahů se zákazníky.crm

Více

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH Jindřich Kaluža Ludmila Kalužová Recenzenti: prof. Ing. Milan Turčáni, CSc. prof. Ing. Ivan Vrana, DrSc. Tato kniha vznikla za finanční podpory Studentské grantové

Více

Znalostní báze pro obor organizace informací a znalostí

Znalostní báze pro obor organizace informací a znalostí Znalostní báze pro obor organizace informací a znalostí Představení projektu Programu aplikovaného výzkumu a vývoje národní a kulturní identity (NAKI) DF13P01OVV013 2013 2015 Helena Kučerová ÚISK FF UK

Více

Management IS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1

Management IS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1 Management IS Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 22/ 1 Učitelé Přednášející: Cvičící: Doc.Ing.Miloš Koch,CSc. Ing.Aleš Klusák Kontakt: koch@fbm.vutbr.cz 22/ 2 Literatura Skripta: Koch,M. Dovrtěl,J.:

Více

ArcGIS Online Subscription

ArcGIS Online Subscription ArcGIS Online Subscription GIS pro organizace ArcGIS Online je GIS v cloudu. Poskytuje služby GIS v prostředí internetu, ať už se jedná o úložné místo, publikaci mapových a geoprocessingových služeb, nebo

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Myšlenkové mapy v Linuxu

Myšlenkové mapy v Linuxu Myšlenkové mapy v Linuxu Michal Černý LinuxAlt 2011 Abstrakt Myšlenkové mapy se staly nezpochybnitelným fenoménem. Používají se k rozvoji kreativního myšlení, ke studiu, kooperaci na projektech nebo jako

Více

PRODUKTY. Tovek Tools

PRODUKTY. Tovek Tools jsou desktopovou aplikací určenou k vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci i s velkým objemem textových dat z různorodých informačních zdrojů.

Více

Zavedení e-learningu

Zavedení e-learningu Zavedení e-learningu Česká pojišťovna snižuje díky e-learningu náklady na školení svých pracovníků Přehled Země: Česká republika Odvětví: Bankovnictví a finance Profil zákazníka Česká pojišťovna a.s. je

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Design systému. Komponentová versus procesní architektura

Design systému. Komponentová versus procesní architektura Design systému Komponentová versus procesní architektura Architektura : třídy statické aspekty propojení logický pohled struktura popisu systému Architektura procesů: objekty dynamické aspekty koordinace

Více

RDF DSPS ROZVOJ PORTÁLU

RDF DSPS ROZVOJ PORTÁLU RDF DSPS ROZVOJ PORTÁLU ČEZ Distribuce, a.s. HSI, spol. s r.o. Zbyněk Businský Miroslav Kaňka ZÁKAZNÍK A DODAVATEL ČEZ DISTRIBUCE, A.S. ČEZ distribuční síť Od r. 2012 implementován GEOPORTÁL (1. ETAPA),

Více

OBJEDNÁVACÍ A INFORMAČNÍ SYSTÉMY

OBJEDNÁVACÍ A INFORMAČNÍ SYSTÉMY OBJEDNÁVACÍ A INFORMAČNÍ SYSTÉMY STAkis-W STAkis-S Již dnes k dispozici všem zákazníkům společnosti Stahlgruber bez výjimky! www.stahlgruber.cz STAkis-W OBJEDNÁVACÍ SYSTÉM BEZ NUTNOSTI INSTALACE Jako výchozí

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Ukládání a vyhledávání XML dat

Ukládání a vyhledávání XML dat XML teorie a praxe značkovacích jazyků (4IZ238) Jirka Kosek Poslední modifikace: $Date: 2014/12/04 19:41:24 $ Obsah Ukládání XML dokumentů... 3 Ukládání XML do souborů... 4 Nativní XML databáze... 5 Ukládání

Více

Optimalizaci aplikací. Ing. Martin Pavlica

Optimalizaci aplikací. Ing. Martin Pavlica Optimalizaci aplikací Ing. Martin Pavlica Vize: Aplikace v dnešním světě IT Ze všech částí IT jsou aplikace nejblíže businessu V elektronizovaném světě významným způsobem podporují business, ten se na

Více

2013 IBM Corporation

2013 IBM Corporation 2013 IBM Corporation Connections v praxi Jak vypadá nasazení Social software v praxi MICHAL HOLOUBEK Social Business konzultant, oxy Online, s.r.o. 2013 IBM Corporation Agenda Úvod Zadání a specifikace

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ Podle toho, zda informační systém funguje na operativní, taktické nebo strategické řídicí úrovni, můžeme systémy rozdělit do skupin. Tuto pyramidu

Více

Honeywell & Masarykova univerzita v Brně

Honeywell & Masarykova univerzita v Brně Honeywell & Masarykova univerzita v Brně Představení projektu ifest a dosavadních výsledků jeho řešení Ing. Jan Beran, Ph.D., Advanced Technology Europe (Platform Systems), Honeywell International Představení

Více

Firemní informační systém

Firemní informační systém Pracující data Firemní informační systém Data pracující v týmu FIS je aplikační řešení IBM Notes/Domino pro řízení procesů včetně oběhu dokumu- spojující klíčové požadavky na CRM, DMS, netů. Systém pracuje

Více

Není nic staršího než včerejší web

Není nic staršího než včerejší web Není nic staršího než včerejší web Jan Ondrák Technická správa komunikací Praha René Zahradník IBM Lotus Software 2007 IBM Corporation Technická správa komunikací Praha Tradice od roku 1963, od roku 1996

Více

Big data ukážou mapu, TOVEK řekne kudy jít

Big data ukážou mapu, TOVEK řekne kudy jít Řešení pro Competitive Intelligence Big data ukážou mapu, TOVEK řekne kudy jít Tomáš Vejlupek President Tovek 6.11.2015, VŠE Praha TOVEK, spol. s r.o. Výsledek zpracování BIG DATA Jaké cesty k cíli mohu

Více

Software a související služby

Software a související služby Software a související služby Webové technologie, přístup uživatele do systému přes webový prohlížeč Software na zakázku Webové stránky a e-shopy s plnou administrací Intranet, webové aplikace, informační

Více

Aplikační software. Řízení lidských zdrojů PRAHA 2014. Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE

Aplikační software. Řízení lidských zdrojů PRAHA 2014. Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE Aplikační software Řízení lidských zdrojů PRAHA 2014 Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE Volně použito podkladů z Internetových serverů www.vikupedie.com a dalších. 1 Procesy a dokumenty

Více

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI Cyril Klimeš a) Jan Melzer b) a) Ostravská univerzita, katedra informatiky a počítačů, 30. dubna 22, 701 03 Ostrava, ČR E-mail: cyril.klimes@osu.cz b) DC Concept

Více

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

TOP Katalog online řešení a služby pro podnikatele

TOP Katalog online řešení a služby pro podnikatele TOP Katalog online řešení a služby pro podnikatele Předmětem tohoto dokumentu je stručná charakteristika mezinárodních internetových multimediálních projektů poskytující moderní obchodní, propagační a

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

Více

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML ROZHRANÍ ESA XML Ing. Richard Vondráček SCIA CZ, s. r. o., Thákurova 3, 160 00 Praha 6 www.scia.cz 1 OTEVŘENÝ FORMÁT Jednou z mnoha užitečných vlastností programu ESA PT je podpora otevřeného rozhraní

Více

3. Očekávání a efektivnost aplikací

3. Očekávání a efektivnost aplikací VYUŽÍVANÍ INFORMAČNÍCH SYSTÉMŮ V ŘÍZENÍ FIREM Ota Formánek 1 1. Úvod Informační systémy (IS) jsou v současnosti naprosto nezbytné pro úspěšné řízení firem. Informačním ním systémem rozumíme ucelené softwarové

Více

icc Next Generation atlantis Copyright 2011, atlantis

icc Next Generation atlantis Copyright 2011, atlantis icc Next Generation atlantis Copyright 2011, atlantis Zaměření icc zdravotnická zařízení výrobní podniky instituce a samospráva jednotky až stovky agentů malé, střední a velké organizace kontextově zaměřený

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

Informace a znalosti v organizaci

Informace a znalosti v organizaci Informace a znalosti v organizaci Vladimíra Zádová Postavení informací a znalostí z hlediska úspěšnosti firmy Vnitřní faktory Rámec 7S faktorů úspěchu firmy [ Mc Kinsey ] Struktura Strategie Systémy Spolupracovníci

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_33_02 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

ELO ECM Suite 9 Just Better Business

ELO ECM Suite 9 Just Better Business ELO ECM Suite 9 - Ve zkratce ELO ECM Suite 9 Just Better Business ELO Enterprise Content Management www.elo.com ELO ECM Suite 9 - Ve zkratce ELO ECM Suite 9 Just Better Business Z inteligentní správy informací

Více

Spojení OntoUML a GLIKREM ve znalostním rozhodování

Spojení OntoUML a GLIKREM ve znalostním rozhodování 1 Formalizace biomedicínských znalostí Spojení OntoUML a GLIKREM ve znalostním rozhodování Ing. David Buchtela, Ph.D. 16. června 2014, Faustův dům, Praha Skupina mezioborových dovedností Fakulta informačních

Více

Firma příjemce voucheru. ACEMCEE, s. r. o. (www.acemcee.com) U Vodárny 2, 616 00 Brno. Informační a komunikační technologie

Firma příjemce voucheru. ACEMCEE, s. r. o. (www.acemcee.com) U Vodárny 2, 616 00 Brno. Informační a komunikační technologie Firma příjemce voucheru ACEMCEE, s. r. o. (www.acemcee.com) Sídlo Obor Velikost Profil U Vodárny 2, 616 00 Brno Informační a komunikační technologie Drobný podnik ACEMCEE je firma působící v oblastech

Více

Kolaborativní aplikace

Kolaborativní aplikace Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, 638 00 Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů,

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

A. Charakteristika vyučovacího předmětu

A. Charakteristika vyučovacího předmětu Vyučovací předmět:: INFORMATIKA A. Charakteristika vyučovacího předmětu a) Obsahové, časové a organizační vymezení předmětu U vyučovacího předmětu informatika je časové vymezení dáno učebním plánem. V

Více

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy

Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Ing. Jiří Fejfar, Ph.D. Geo-informační systémy Definice, budování a život GIS Kapitola 1: Vztahy strana 2 Data, informace, IS, GIS Kapitola 1: Vztahy strana 3 Rozhodnutí Znalosti Znalostní systémy. Informace

Více

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Databázové patterny MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace Databázové patterny o Odzkoušené a doporučené

Více

06/03/15. Exekuce ios. Deliverable 01. Vojtěch Micka mickavoj Naim Ashhab ashhanai

06/03/15. Exekuce ios. Deliverable 01. Vojtěch Micka mickavoj Naim Ashhab ashhanai [BIS-EXE] Deliverable 01 06/03/15 Exekuce ios Deliverable 01 Vojtěch Micka mickavoj Naim Ashhab ashhanai [BIS-EXE] Deliverable 01 Zadání Migrace části webové aplikace Lustrátor (lustrator.bisnode.cz) od

Více

Moderní systémy pro získávání znalostí z informací a dat

Moderní systémy pro získávání znalostí z informací a dat Moderní systémy pro získávání znalostí z informací a dat Jan Žižka IBA Institut biostatistiky a analýz PřF & LF, Masarykova universita Kamenice 126/3, 625 00 Brno Email: zizka@iba.muni.cz Bioinformatika:

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

EMBARCADERO TECHNOLOGIES. Jak na BYOD chytře? Možnosti zapojování různých mobilních zařízení do podnikových informačních systémů.

EMBARCADERO TECHNOLOGIES. Jak na BYOD chytře? Možnosti zapojování různých mobilních zařízení do podnikových informačních systémů. Jak na BYOD chytře? Možnosti zapojování různých mobilních zařízení do podnikových informačních systémů. Trendy a móda EMBARCADERO TECHNOLOGIES Popularita a prodej mobilních zařízení roste Skoro každý má

Více

SOU Valašské Klobouky. VY_32_INOVACE_3_20_IKT_Tvorba_webovych_stranek_Redakcni_systemy. Mgr. Radomír Soural. Zkvalitnění výuky prostřednictvím ICT

SOU Valašské Klobouky. VY_32_INOVACE_3_20_IKT_Tvorba_webovych_stranek_Redakcni_systemy. Mgr. Radomír Soural. Zkvalitnění výuky prostřednictvím ICT SOU Valašské Klobouky VY_32_INOVACE_3_20_IKT_Tvorba_webovych_stranek_Redakcni_systemy Mgr. Radomír Soural Zkvalitnění výuky prostřednictvím ICT Název a číslo projektu CZ.1.07/1.5.00/34.0459 Název školy

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Operační program Lidské zdroje a zaměstnanost

Operační program Lidské zdroje a zaměstnanost Operační program Lidské zdroje a zaměstnanost EDUCA III Další profesní vzdělávání zaměstnanců společnosti T-MAPY spol. s r.o. 2013-2015 září 2013 - únor 2015 Charakteristika projektu Projekt je zaměřen

Více

Vysoká škola finanční a správní, o.p.s. Katedra řízení podniku a podnikové ekonomiky. Metodické listy pro předmět ŘÍZENÍ PODNIKU 2

Vysoká škola finanční a správní, o.p.s. Katedra řízení podniku a podnikové ekonomiky. Metodické listy pro předmět ŘÍZENÍ PODNIKU 2 Vysoká škola finanční a správní, o.p.s. Katedra řízení podniku a podnikové ekonomiky Metodické listy pro předmět ŘÍZENÍ PODNIKU 2 Studium předmětu umožní studentům základní orientaci v procesech, které

Více

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků Microsoft.NET AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků Přehled Země: Velká Británie Odvětví: Informační technologie Profil zákazníka Pantek Ltd.

Více

Vypracoval: Antonín Krumnikl Email: antonin.krumnikl@ha-velfamily.cz Mob.: 606 778 713 Tel.: 552 302 362

Vypracoval: Antonín Krumnikl Email: antonin.krumnikl@ha-velfamily.cz Mob.: 606 778 713 Tel.: 552 302 362 Vypracoval: Antonín Krumnikl Email: antonin.krumnikl@ha-velfamily.cz Mob.: 606 778 713 Tel.: 552 302 362 Stránka 1 z 21 Obsah 1. Co je systém HELPdesk?... 2 2. Možnosti využití systému HELPdesk:... 2 3.

Více

Tovek Tools. Tovek Tools jsou standardně dodávány ve dvou variantách: Tovek Tools Search Pack Tovek Tools Analyst Pack. Připojené informační zdroje

Tovek Tools. Tovek Tools jsou standardně dodávány ve dvou variantách: Tovek Tools Search Pack Tovek Tools Analyst Pack. Připojené informační zdroje jsou souborem klientských desktopových aplikací určených k indexování dat, vyhledávání informací, tvorbě různých typů analýz a vytváření přehledů a rešerší. Jsou vhodné pro práci s velkým objemem textových

Více

Technologie Sharepoint

Technologie Sharepoint Jan Salajka 25. 3. 2010 ČVUT FEL Technologie Sharepoint Letem světem Sharepoint - Co to je??? Je to technologie Slouží především k řízené tvorbě a správě informací ve webovém prostředí Slouží jako podklad

Více

Systémy pro podporu. rozhodování. 2. Úvod do problematiky systémů pro podporu. rozhodování

Systémy pro podporu. rozhodování. 2. Úvod do problematiky systémů pro podporu. rozhodování 1 Systémy pro podporu rozhodování 2. Úvod do problematiky systémů pro podporu rozhodování 2 Připomenutí obsahu minulé přednášky Rozhodování a jeho počítačová podpora Manažeři a rozhodování K čemu počítačová

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz

INFORMAČNÍ SYSTÉMY. 03. 01. 2006, Ing. Jiří Mráz INFORMAČNÍ SYSTÉMY 03. 01. 2006, Ing. Jiří Mráz PŘEDNÁŠEJÍCÍ Jiří Mráz Production Coordinator UNICORN jiri.mraz@unicorn.cz AGENDA Informační a komunikační technologie (ICT) podniku Informační systémy Zakázkový

Více