012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Analýza a návrh ICT pro popis a representaci znalostí D IPLOMOVÁ PRÁCE

Martin Fajmon

Brno, jaro 2008

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Vedoucí práce: prof. RNDr. Jiˇrí Hˇrebíˇcek, CSc. ii

Podˇekování Mé podˇekování patˇrí vedoucímu práce prof. RNDr. Jiˇrímu Hˇrebíˇckovi, CSc. za jeho cenné pˇripomínky v prubˇ ˚ ehu práce a za trpˇelivost, se kterou práci cˇ etl.

iii

Shrnutí První teoretická cˇ ást diplomové práce se zabývá interoperabilitou a problémy získání potˇrebné informace z dat pro potˇreby sémantické interoperability. Dále se práce v první cˇ ásti zabývá strukturou a formální reprezentací ontologií, které jsou jedním z nástroju˚ pro sémantickou interoperabilitu. Cílem druhé praktické cˇ ásti je navrhnout a implementovat webový systém pro správu a distribuci ontologií ve formátu OWL. Cílem tˇretí cˇ ásti je vybrat vhodnou doménu z legislativy životního prostˇredí a popsat doménovou znalost pomocí ontologie, která bude distribuována a zpracována pomocí webového systému z druhé cˇ ásti práce.

iv

Klíˇcová slova Sémantická interoperabilita, IDABC, XML, Ontologie, OWL, Ontologický portál, Informaˇcní systémy, Enviromentální informace, Legislativa

v

Obsah 1

2

3

4

5

6

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Interoperabilita . . . . . . . . . . . . . . . . . . . . . . . 1.2 IDABC a Evropský interoperabilní rámec . . . . . . . . ˇ 1.3 Clenˇ ení interoperability v eGovermentu . . . . . . . . . Sémantická interoperabilita . . . . . . . . . . . . . . . . . . . 2.1 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Mapování metadat . . . . . . . . . . . . . . . . . . . . . 2.4 Techniky mapování metadat . . . . . . . . . . . . . . . . 2.5 Sémantický web . . . . . . . . . . . . . . . . . . . . . . . 2.6 XML, RDF a ontologie jako základ sémantického webu Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Struktura ontologií . . . . . . . . . . . . . . . . . . . . . 3.2 Jazyky a nástroje pro manipulaci s ontologiemi . . . . . 3.2.1 Ontolingua . . . . . . . . . . . . . . . . . . . . . 3.2.2 OCML . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 SHOE . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Ontobroker . . . . . . . . . . . . . . . . . . . . . 3.2.5 RDF Schema . . . . . . . . . . . . . . . . . . . . . 3.2.6 DAML+OIL . . . . . . . . . . . . . . . . . . . . . 3.3 OWL – souˇcasný jazyk webových ontologií . . . . . . . 3.4 Všestranné ontologické editory a reasonery . . . . . . . 3.4.1 Protégé . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 SWOOP . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Reasonery . . . . . . . . . . . . . . . . . . . . . . 3.5 Praktické využití ontologií . . . . . . . . . . . . . . . . . Webový portál pro správu a distribuci ontologií . . . . . . . 4.1 Proˇc používat a vyvíjet Open Source rˇ ešení? . . . . . . . 4.2 Doménové ontologie . . . . . . . . . . . . . . . . . . . . 4.3 Top-level ontologie . . . . . . . . . . . . . . . . . . . . . 4.4 Webový portál jako úložištˇe ontologií . . . . . . . . . . Identifikace požadavku˚ a návrh webového portálu . . . . . 5.1 Technologie a architektura . . . . . . . . . . . . . . . . . 5.1.1 Presentaˇcní vrstva . . . . . . . . . . . . . . . . . 5.1.2 Aplikaˇcní vrstva . . . . . . . . . . . . . . . . . . 5.1.3 Databázová vrstva . . . . . . . . . . . . . . . . . 5.2 Specifikace a návrh . . . . . . . . . . . . . . . . . . . . . Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Základní popis systému . . . . . . . . . . . . . . . . . . 6.2 Uživatelé . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 3 6 8 9 11 12 13 14 15 18 19 20 21 21 23 24 25 26 28 36 36 37 39 40 41 41 42 44 44 47 47 48 48 49 49 57 57 57 vi

6.3 6.4

Registrace uživatelu˚ . . . . . . . . . . . . . . . . . . . . Jednotlivé sekce portálu . . . . . . . . . . . . . . . . . . 6.4.1 Sekce „Uživatelský úˇcet“ . . . . . . . . . . . . . 6.4.2 Sekce „Autoˇri ontologií“ . . . . . . . . . . . . . . 6.4.3 Sekce „Ontologie“ . . . . . . . . . . . . . . . . . 6.4.4 Editace ontologií . . . . . . . . . . . . . . . . . . 6.5 Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . . 6.6 Instalace portálu na webový hosting . . . . . . . . . . . 7 Ontologie s problematikou odpadového hospodáˇrství . . . 7.1 Enviromentální informace a souvislost s ontologiemi . 7.2 Informaˇcní zdroje o odpadovém hospodáˇrství . . . . . 7.3 Postup pˇri tvorbˇe ontologie o odpadovém hospodáˇrství 7.3.1 Skupiny odpadu˚ . . . . . . . . . . . . . . . . . . 7.3.2 Katalog odpadu˚ . . . . . . . . . . . . . . . . . . . 7.3.3 Nebezpeˇcný odpad . . . . . . . . . . . . . . . . . 7.3.4 Nebezpeˇcné vlastnosti odpadu . . . . . . . . . . 7.3.5 Nakládání s odpady . . . . . . . . . . . . . . . . 7.3.6 Doplnˇení ontologie . . . . . . . . . . . . . . . . . 7.3.7 Souhrn . . . . . . . . . . . . . . . . . . . . . . . . 8 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah pˇriloženého CD . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

58 59 59 60 60 61 62 62 65 65 66 67 68 68 68 69 70 71 71 72 73 74

vii

Kapitola 1

Úvod V dnešní dobˇe se využívají ruznorodé ˚ informaˇcní a komunikaˇcní technologie (ICT). Prostˇredky ICT využívá stále více firem, úˇradu˚ i jedincu. ˚ Vzniká velké množství nových technologií, platforem, webových portálu, ˚ informaˇcních systému, ˚ programu˚ a jiných druhu˚ ICT. Nárust ˚ nových ICT musí pružnˇe reagovat na potˇreby uživatelu, ˚ kteˇrí mají stále vˇetší nároky a využívají ICT stále na nové cˇ innosti, které do té doby provozovali bez podpory ICT. Na tyto uživatelské nároky musí stejnˇe tak reagovat i stávající ICT, a proto se i již vytvoˇrené a hotové ICT stále upravují. Otázkou zustává, ˚ kdy se zastaví tento rozvoj a nárust? ˚ Myslím, že na tuto otázku si zatím mužeme ˚ odpovˇedˇet tak, že zastavení nebo jen ustálení tohoto rozvoje je zatím v nedohlednu. Dalším trendem je ústup od velkých monolitických rˇ ešení, která umí vše, co uživatel potˇrebuje, k jednotlivým menším cˇ ástem (modulum, ˚ službám), které si pak data mezi sebou vymˇenují. ˇ Duvod ˚ u˚ je nˇekolik, jmenujme ty nejduležitˇ ˚ ejší: •

Modul se naprogramuje rychleji než monolitický celek, takže se pak mohou prosadit nové vývojáˇrské firmy, které zatím nemají kapacity pro vytvoˇrení celku.

•

Modul má menší složitost než celek, takže v nˇem vývojáˇri nenadˇelají tolik chyb, jako kdyby byla stejná cˇ ást kódu souˇcástí celku.

•

Modul je zapouzdˇrený a jeho funkce se využívají prostˇrednictvím nˇejaké komunikaˇcní brány. Pokud se objeví nˇejaká chyba, opraví se jen vnitˇrek modulu, ale komunikaˇcní brána zustane ˚ stejná, i když se modul vnitˇrnˇe tˇreba kompletnˇe zmˇení. Opravy tak probíhají levnˇeji, jednodušeji a rychleji než v pˇrípadˇe celku.

•

Pokud uživatel zjistí, že potˇrebuje do svého informaˇcního systému (IS) nové funkce, je jednodušší pˇridat jen nový modul než pˇreprogramovávat celý stávající IS.

•

Modul muže ˚ pro ostatní software nabízet své služby prostˇrednictvím sítˇe internet. Mohou ho pak využívat ruzné ˚ jiné IS po celém svˇetˇe. A pokud vývojáˇrská firma aktualizuje daný modul, nemusí ho distribuovat ke všem zákazníkum, ˚ ale aktualizuje ho jen u sebe na serveru.

Jednotlivé ICT rˇ ešení a moduly si pak musí data mezi sebou nˇejakým zpusobem ˚ vymˇenovat, ˇ aby mohly být využity jako komplexní rˇ ešení uživatelských nároku. ˚ A data si nestaˇcí jenom vymˇenovat, ˇ ale musí tˇemto datum ˚ navzájem rozumˇet. Musí se tedy hledat rˇ ešení výmˇeny dat, která budou pružnˇe reagovat jak na nová ICT rˇ ešení, tak i na zmˇenu stávajících. 1

1.1. INTEROPERABILITA

1.1

Interoperabilita

Pojem „interoperabilita“ je velice širokým pojmem, a proto se používá v nejruznˇ ˚ ejších souvislostech. Interoperabilita pochází z anglického originálu „interoperability “. Nebudeme se pokoušet tento termín pˇrekládat, jen ho poˇceštíme. O pˇreklad se však již pokusili jiní - zalistujete-li anglicko-ˇceským výkladovým slovníkem výpoˇcetní techniky, najdete tam na stranˇe 109, že „interoperability“ znamená v cˇ eštinˇe „stykovou provozuschopnost“, pˇrípadnˇe „stykovou funkceschopnost“ [1]. Myslím, že tyto pˇreklady jsou velice nešt’astné, a proto zu˚ staneme u poˇceštˇené interoperability. Pˇredstavte si, že si koupíte nový elektrický spotˇrebiˇc, zapojíte ho do elektrické sítˇe a zapnete. To, že spotˇrebiˇc funguje, je projevem interoperability mezi spotˇrebiˇcem a vaší elektrickou sítí. V tomto pˇrípadˇe je interoperabilita zajištˇena normovanou elektrickou zástrˇckou a také tím, že je v elektrické síti pˇredem dohodnuté napˇetí. V ruzných ˚ souvislostech je tˇreba definovat interoperabilitu jinak, pˇresto lze najít spoleˇcný jmenovatel. Obecná definice interoperability by mohla znít jako schopnost vzájemnˇe si rozumˇet, vzájemnˇe spolupracovat, dosáhnout vzájemné souˇcinnosti. V oblasti ICT se pojem interoperability používá v souvislosti s možností vzájemné výmˇeny dat mezi ruznými ˚ systémy. Za interoperabilitu lze považovat tˇreba to, že si mužeme ˚ soubor vytvoˇrený na operaˇcním systému Linux prohlédnout na poˇcítaˇci s Microsoft Windows. Vidíme zde, že má interoperabilita více úrovní. Je potˇreba nˇejakým zpusobem ˚ dva poˇcítaˇce propojit fyzicky, zajistit schopnost obou operaˇcních systému˚ vzájemnˇe si pˇredávat data a nakonec souˇcinnost aplikaˇcních programu, ˚ která je rˇ ešena nˇejakým standardizovaným formátem souboru. Interoperabilita na vyšších úrovních tedy musí využívat interoperability na úrovních nižších. Aby bylo dosaženo interoperability na ruzných ˚ úrovních, musí se pˇresnˇe dodržovat stanovené standardy. Pro oblast, o kterou se tato diplomová práce zajímá, lze tedy interoperabilitu definovat jako schopnost systému˚ založených na ICT a business procesu, ˚ které tyto systémy podporují, vymˇenovat ˇ si navzájem data a umožnit sdílení informací a znalostí [12]. Interoperabilní rámec (Interoperability Framework) je množina standardu˚ a smˇernic, která popisuje zpu˚ sob na kterém by se mˇeli úˇcastníci komunikace shodnout, aby mohli komunikovat bez problému. ˚ Jelikož jsme si již výše rˇ ekli, že tehcnologie v ICT se velice rychle mˇení, je z toho jasné, že se bude v cˇ ase mˇenit i interoperabilní rámec (s pˇríchodem nových technologií vzniknou nová doporuˇcení). V tomto pˇrípadˇe je vždy doporuˇceno volit takové technologie, které nejsou na pokraji svých možností. Tzn. doporuˇcuje se využití nových technologií a otevˇrených standardu. ˚ Interoperabilita je velice významná nejen pro soukromé firmy pro komunikaci mezi sebou nebo v rozsáhlých organizacích pro komunikaci mezi jejich rozliˇcnými systémy, ale také pro státní správu a její úˇrady. A nezáleží, zda jde o úˇrady stejné úrovnˇe cˇ i mezi úˇrady naprosto odlišného typu, velikosti i úrovnˇe. Dokonce nehraje roli, zda se jedná o úˇrady v rámci konkrétního regionu cˇ i zemˇe. S postupující globalizací požadavek interoperability smˇerˇ uje i ke spolupráci v rámci sousedních státu˚ cˇ i napˇríˇc kontinentem. Nutnost interoperability si nyní stále silnˇeji uvˇedomují i ve všech cˇ lenských státech Evropské unie (EU). 2

1.2. IDABC A EVROPSKÝ INTEROPERABILNÍ RÁMEC

1.2

IDABC a Evropský interoperabilní rámec

IDABC [15] znamená Interoperabilní dodávání Pan-evropských služeb eGovernmentu správním orgánum, ˚ podnikum ˚ a obˇcanum. ˚ IDABC je komunitární program rˇ ízený Generálním rˇ editelstvím pro podnikání a prumysl ˚ Evropské komise. IDABC využívá možností, které skýtají informaˇcní a komunikaˇcní technologie pro podporu dodávání veˇrejných služeb obcˇ anum ˚ i podnikum ˚ v Evropˇe pˇres hranice, ke zlepšení úˇcinnosti a spolupráce mezi evropskými veˇrejnými správami a pˇrispívá k tomu, aby se Evropa stala atraktivním místem pro život, práci a investování. K dosažení svých cílu˚ IDABC vydává doporuˇcení, vyvíjí rˇ ešení a poskytuje služby, které umožnují ˇ národním a evropským veˇrejným správám komunikovat elektronicky a nabízet moderní veˇrejné služby podnikum ˚ a obˇcanum. ˚ Program také poskytuje financování projektu˚ splnujících ˇ požadavky evropské politiky zlepšovat spolupráci mezi veˇrejnými správami v Evropˇe.

Obrázek 1.1: Interoperabilita v EU. Evropská komise pˇrijala rozhodnutí, které pˇrijímá základní principy interoperability. Ev3

1.2. IDABC A EVROPSKÝ INTEROPERABILNÍ RÁMEC ropský interoperabilní rámec je tedy množina doporuˇcení a smˇernic EU pro elektronizaci veˇrejné správy (eGovernment) a jejich služeb tak, aby veˇrejná správa, podniky a obˇcané mohli komunikovat pˇres hranice na pan-Evropské úrovni v celé EU. Základní principy jsou tyto [11]: 1. Pˇrístupnost (Accesibility) – eGovernment musí vytváˇret rovnocennou pˇríležitost pro všechny vrstvy potencionálních uživatelu˚ na základˇe otevˇrených a všeobecnˇe pˇrijatých prostˇredku, ˚ které jsou veˇrejnˇe pˇrístupné a dostupné bez jakékoliv diskriminace. Existují ekonomické a sociální rozdíly mezi regiony a obˇcany, proto by mˇely být služby eGovermentu dostupné ruznými ˚ zpusoby ˚ (web, televize, mobil, mobilní kiosky . . . ). Jako samozˇrejmost se bere pˇrístupnost pro postižené obˇcany a vícejazyˇcný pˇrístup. 2. Mnohojazyˇcnost (Multilingualism) – zejména na území EU je mnoho národních jazyku, ˚ které jsou využívány v eGovermentu. Dá se rˇ íci, že jazyk je hlavním faktorem pˇri efektivním poskytování pan-Evropských eGovernment služeb, zejména pak pˇri prezentaci informací. Princip architektury informací by mˇel být tedy jazykovˇe neutrální (pokud je to možné), napˇríklad XML-schema, aby se usnadnil “pˇrekládací mechanismus”. V pˇrípadˇe, že není toto možné držet, je potˇreba zajistit pˇrekládací mechanismus. 3. Bezpeˇcnost (Security) – cˇ lenské státy a jejich úˇrady a instituce musí posoudit vlastní bezpeˇcnostní politiku a tuto politiku musí postavit do souladu s obecnou bezpeˇcnostní politikou na pan-Evropské úrovni. Pro pan-Evropskou úrovenˇ platí bezpeˇcnostní zásady podle smˇernice 2001/264/EC. Bezpeˇcnostní funkce by mˇely dosahovat maximální úrovnˇe transparentnosti pˇri vynaložení minimálního úsilí, ale pˇritom stále zachovat dohodnutou úrovenˇ bezpeˇcnosti. 4. Soukromí a ochrana osobních dat (Privacy and personál data protection) – služby v pan-Evropském eGovernmentu potˇrebují zajistit jednotnou úrovenˇ ochrany osobních dat, vˇcetnˇe možnosti pro jednotlivce se rozhodnout poskytnout svá data jinak, než bylo puvodnˇ ˚ e urˇceno. Pˇri návrhu by mˇel být kladen duraz ˚ na dodržování a zajištˇení plné podpory existující evropské a národní legislativy související s ochranou dat. 5. Podˇrízenost (Subsidiarity) – doporuˇcení poskytovaná evropským interoperabilním rámcem jsou odpovˇedná za pan-Evropskou úrovenˇ služeb. Podle principu˚ podˇrízenosti smˇernice nezasahují do interní práce správ cˇ lenských státu˚ a EU institucí. Rozhodnutí o nasazení odpovídajících technologických implementací je v rukou konkrétní instituce, a každá z nich by mˇela podniknout maximum pro dosažení co nejvyššího stupnˇe interoperability. 6. Užití otevˇrených standardu˚ (use of open standartds) – Pro dosažení interoperability v souvislosti s pan-Evropskými eGovernment službami by se smˇernice mˇely zamˇerˇ it na otevˇrené standardy. Tyto standardy by mˇely dodržovat tyto principy: 4

1.2. IDABC A EVROPSKÝ INTEROPERABILNÍ RÁMEC •

Standard je pˇrijat a bude udržován nˇejakou nevýdˇeleˇcnou organizací.

•

Standard byl publikován a dokument s jeho specifikací je dostupný zdarma nebo za nominální poplatek. Každému musí být povoleno jeho jakékoliv kopírování, distribuce a užívání – zdarma nebo za nominální poplatek.

•

Duševní vlastnictví, které mohou být souˇcástí otevˇreného standardu nesmí být poskytovány za úplatu. Licenˇcní poplatek musí být zdarma.

7. Prospˇech z software s otevˇreným kódem (Benefits of Open Source software) – software s otevˇreným kódem (Open Source software) pomáhá vytváˇret a definovat otevˇrené standardy a veˇrejnˇe dostupné specifikace. Otevˇrený software má veˇrejnˇe dostupné zdrojové kódy a to otvírá veˇrejnou demokratickou debatu o jeho funkcích, specifikaci a bezpeˇcnosti, takže se otevˇrený software stává více robustní a interoperabilní. 8. Užití „mutltilateral” rˇ ešení (use of multilateral solutions) – „multilateral” rˇ ešení je systém, kde každý cˇ len komunikuje s ostatními pˇres jedno centrum. Toto centrum podporuje dohodnuté zpusoby ˚ komunikace a dohodnuté standardy a specifikace. Oproti tomu systém využívající „bilateral“ rˇ ešení dovoluje každému komunikujícímu prvku v systému se spojit pˇrímo se všemi ostatními prvky. Takže tato komunikace muže ˚ probíhat na rozdílných standardech nebo bez standardu. ˚ Dodržovaní tˇechto principu˚ by mˇelo vést k tomu, aby mohly instituce efektivnˇe komunikovat s okolím. Bude možno jednodušeji z dat zprostˇredkovat informaci, a tím bude možno zajistit svobodný pˇrístup k co nejvíce informacím. Dalším pˇrínosem bude, že se co nejvíce subjektu˚ bude moci zapojit do procesu rozhodování. Všechna doporuˇcení rˇ íkají pouze popis, co se musí splnit, ale nenaˇrizují užití konkrétní technologie. Tento výbˇer je ponechán na samotných institucích. Existují tˇri základní typy komunikací, které evropská interoperabilita musí rˇ ešit pˇri výmˇenˇe dat mezi cˇ lenskými státy [11]: 1. Komunikace osoby nebo podniku z jednoho cˇ lenského státu s administrativou jiného státu nebo s evropskými institucemi. 2. Výmˇena dat mezi administrativami ruzných ˚ státu˚ pokud impuls k této výmˇenˇe vzešel z požadavku˚ obˇcanu˚ nebo podniku˚ na jejich vlastní instituce. 3. Výmˇena dat mezi cˇ lenskými státy a institucemi EU. Tˇreba pokud evropské instituce vyžadují od jednotlivých státu˚ statistická data ke zpracování.

5

ˇ ˇ 1.3. CLEN ENÍ INTEROPERABILITY V EGOVERMENTU

Obrázek 1.2: Komunikace v evropské interoperabilitˇe.

1.3

ˇ Clenˇ ení interoperability v eGovermentu

Interoperabilitu v eGovermentu lze obecnˇe rozdˇelit do tˇrech základních skupin [11]: 1. Organizaˇcní interoperabilita – zamˇerˇ uje se na definování obchodních cílu, ˚ modelování obchodních procesu, ˚ informování o spolupráci správ, které si pˇrejí vymˇenovat ˇ informace a mohou mít rozdílné vnitˇrní struktury a procesy. Navíc organizaˇcní interoperabilita pomáhá doruˇcování (a rˇ ešení) požadavku˚ uživatelské komunity tím, že jsou služby dosažitelné, snadno identifikovatelné, pˇrístupné a orientované na uživatele. Byly dohodnuty standardní veˇrejné služby pro národní úrovenˇ interoperability. 2. Sémantická interoperabilita – tento pohled interoperability zaruˇcuje, že existuje pˇresný zpusob ˚ výmˇeny informací a je srozumitelný pro jakoukoliv aplikaci, která nebyla puvodnˇ ˚ e navržena pro tento úˇcel. Sémantická interoperabilita umožnuje ˇ systémum ˚ kombinování doruˇcených informací s jinými informaˇcními zdroji a jejich zpracování smysluplným zpusobem. ˚ Proto je sémantická interoperabilita pˇredpokladem pro vícejazyˇcné zpracování služeb pro uživatele. 3. Technická interoperabilita – rˇ eší technické problémy spojené s propojením poˇcítaˇcových systému˚ a služeb. Obsahuje vˇeci jako otevˇrený interface, vzájemné propojení služeb, integrace dat, middleware, prezentaci a výmˇenu dat, pˇrístupnost a bezpeˇcnost služeb. Zde je potˇreba zohlednit všechny technické odlišnosti systému˚ 6

ˇ ˇ 1.3. CLEN ENÍ INTEROPERABILITY V EGOVERMENTU Nastavení pan-Evropských služeb eGovermentu vyžaduje uvažování o interoperabilitˇe jak z hlediska organizaˇcního, sémantického i technického.

7

Kapitola 2

Sémantická interoperabilita Pro eGoverment je nejduležitˇ ˚ ejší rˇ ešit sémantickou interoperabilitu. Pˇredstavme si situaci, že si chceme mezi dvˇema rozdílnými systémy vymˇenit data. Nebudeme ted’ rˇ ešit technickou interoperabilitu, kde je potˇreba zajistit, aby se data dostala nˇejakým zpusobem ˚ z jednoho systému do druhého, a aby mohl druhý systém data v poˇrádku neporušená pˇreˇcíst. Musíme ale vyˇrešit, aby pro druhý systém byla data užiteˇcná, a aby to nebyla jenom zmˇet’ nul a jedniˇcek. Pro druhý systém se z dat musí stát plnohodnotná informace. Asi nejjednodušší rˇ ešení, které každého napadne je, že se oba systémy dohodnou na stejné struktuˇre datového souboru, který si vymˇenují. ˇ Pokud budeme chtít vymˇenovat ˇ základní údaje napˇríklad o knize v textovém souboru, tak se dohodneme, že textový soubor bude mít vždy zakonˇcení nových rˇ ádku˚ Dos/Windows (\r\n), bude v kódování UTF-8 a každý rˇ ádek bude obsahovat jeden záznam o knize ve formátu: autor, název knihy, nakladatel, rok vydání, ISBN

Konkrétní rˇ ádek souboru by pak vypadal tˇreba takto: Božena Nˇ emcová, Babiˇ cka,

Prostor, 2006, 80-7260-155-5

Ano, toto je asi nejjednodušší a nejrychlejší rˇ ešení jak dosáhnout interoperability. Tímto jsme vlastnˇe nadefinovali klasický CSV soubor (Comma-separated values, hodnoty oddˇelené cˇ árkami), což je je jednoduchý souborový formát urˇcený pro výmˇenu tabulkových dat. I když je v dnešní dobˇe stále CSV formát využíván mnoha systémy pro výmˇenu dat a u starých systému, ˚ které neumí pracovat s novˇejšími standardy to ani jinak nejde, tak má toto zastaralé rˇ ešení hodnˇe nedostatku. ˚ Pokud chceme napˇríklad pˇrehodit poˇradí sloupcu, ˚ nˇejaký sloupec pˇridat nebo ubrat, tak vždy o této zmˇenˇe musíme dát vˇedˇet systému, který naše datové soubory cˇ te. Nemluvím o tom, jak je velice složité spravovat a upravovat takové systémy. Problémy s pˇridáním nového datového sloupce nebo s pˇrehozením poˇradí sloupcu˚ se dají rˇ ešit napˇríklad dohodou, že na prvním rˇ ádku budou popisy sloupcu˚ dat. Tím vlastnˇe pˇridáme do souboru metadata, pomocí kterých si vyjádˇríme sémantiku jednotlivých datových prvku. ˚ 8

2.1. METADATA

2.1

Metadata

Metadata jsou strukturovaná data, která nesou informace o puvodních ˚ primárních datech [10]. Pˇríkladem mohou být napˇríklad Exif (Exchangeable image file format) informace, které vkládá digitální fotoaparát pˇri poˇrizování fotografie k puvodním ˚ obrazovým datum. ˚ V tˇechto metadatech jsou uloženy informace o vzniku fotografie – datum a cˇ as poˇrízení, použitá ohnisková vzdálenost, použití blesku, typ a výrobce fotoaparátu apod. Tyto data tedy popisují situaci, pˇri které byla fotografie poˇrízena. Metadata mohou mít tyto funkce: •

Zjišt’ovací – zjištˇení, zda dokument existuje.

•

Výbˇerová – užití dat k výbˇeru dokumentu odpovídajícího požadavkum ˚ uživatele (napˇr. nalezení dokumentu v jazyce, jemuž uživatel rozumí; zjištˇení údaje, podle kterého lze dokument vyhledat – tzv. pˇrístupový bod).

•

Lokaˇcní – užití dat k nalezení (zjištˇení umístˇení) dokumentu.

•

Identifikaˇcní – užití nalezených dat k identifikování entity (napˇr. odlišení dvou titulu˚ se stejným autorem).

•

Popisná, dokumentaˇcní – popis zdroje nebo jeho cˇ ásti (formálních a obsahových znaku) ˚ reprezentaˇcní (názvy elementu, ˚ kódování elementu). ˚

•

Hodnotící (sémantika elementu, ˚ klasifikace elementu) ˚ – pˇrispívá k rozhodnutí, zda se jedná o relevantní objekt.

•

Strukturální – data o formální struktuˇre zdroje za úˇcelem jeho správného uložení a zobrazování.

•

Administrativní – užití dat k manipulaci s dokumentem.

•

Archivaˇcní – zajišt’uje identitu a kontext zdroje (podmínka pro dlouhodobé zpˇrístupnˇení).

•

Užití dat k získání entity nebo pˇrístupu k ní (napˇr. sestavení objednávky).

•

ˇ Rízení zpˇrístupnování ˇ urˇcitých informací (napˇr. podle profilu˚ nebo práv).

•

Sjednocující – jednotný formát metadat umožnuje ˇ rˇ ízení a správu ruznorodých ˚ kolekcí (interoperabilita a integrace ruzných ˚ informaˇcních systému˚ a zdroju˚ pracujících s ruznými ˚ formáty a aplikaˇcními protokoly).

Pokud se vrátíme k našem pˇríkladu s výmˇenou informací o knihách. Pˇridali jsme metadata na první rˇ ádek souboru a vyˇrešili tím zmˇeny poˇradí sloupcu˚ nebo pˇridání a odebírání nových sloupcu. ˚ A co když se zmˇení kódování znakové sady souboru, potˇrebujeme v jednom 9

2.1. METADATA souboru pˇrenášet ruznorodé ˚ struktury nebo evidovat nˇejaké relace mezi daty? Zvolme tedy jinou podobu metadat. Dohodnˇeme se, že každý záznam uzavˇreme do textové znaˇcky (tagu) a každou datovou položku do vlastního tagu , , , , . Každý tag bude párový, takže bude mít poˇcáteˇcní i koneˇcný tag. Výsledný záznam v souboru pak bude vypadat takto: Božena Nˇ emcová Babiˇ cka Prostor 2006 80-7260-155-5

Vidíme, že zde není žádný problém s rˇ azením datových položek uvnitˇr tagu (pokud zpracovávající aplikace ví, že autora najde v tagu , je už jedno kolikátý je autor v poˇradí). Stejnˇe tak je bez problému˚ pˇridání nebo ubrání nové datové položky, zde už je jen na zpracovávající aplikaci, jestli pˇridanou položku zná nebo dokáže zpracovat ostatní položky bez ubrané položky. Pokud chceme zpracovávat ruznorodé ˚ struktury není to také problém. Pˇridejme si tˇreba definici kódování, která je úplnˇe ruzná ˚ od jiných datových položek: Božena Nˇ emcová Babiˇ cka Prostor 2006 80-7260-155-5

Nyní jsme vyˇrešili i to, že pˇredem nemusí být dohodnuto jaké kódování soubor používá, jelikož si to zpracovávající aplikace jednoduše zjistí ze souboru samotného. Relace mezi daty také nejsou problém. Evidujme zvlášt’ autory a knihy, tím uspoˇríme místo a budeme mít datech vˇetší pˇrehled: 34 <jmeno>Božena Nˇ emcová 34 Babiˇ cka Prostor 2006

10

2.2. XML 80-7260-155-5

Samozˇrejmˇe vše máme v rámci jednoho souboru. Takové kombinování metadat s pu˚ vodními daty je velice výhodné. Tuto strukturu používá formát XML, který se v dnešní dobˇe postupnˇe stává otevˇreným standardem pro sémantickou inteoperabilitu.

2.2

XML

XML (Extensible Markup Language) je podmnožinou SGML (Standard Generalized Markup Language). Je to zjednodušená verze SGML, která obsahuje to nejduležitˇ ˚ ejší a naopak vypouští vše nepotˇrebné. XML formát je nástupce HTML (HyperText Markup Language), zdˇedil nˇekteré vlastnosti z HTML, ale podstatnˇe je vylepšuje. Mužeme ˚ si tedy definovat vlastní tagy a pak pomocí nich vytváˇret dokumenty a zpˇrístupnovat ˇ je ostatním pomocí webu a jiných technologií. Finální verze XML 1.0 byla uvolnˇena konsorciem W3C (World Wide Web Consortium) [13] v roce 1998. Aktuální verze XML je verze 1.1 vydaná v roce 2004. Diskutuje se o verzi 2.0, která ale zatím ještˇe vydána nebyla. XML dokumenty lze definovat také pomocí gramatik DTD. Jaké jsou rozdíly XML oproti HTML? V HTML se dokumenty znaˇckují zpusobem, ˚ který zabranuje ˇ zpracování dat pomocí efektivnˇejších prohledávacích metod. Tagy mají cˇ istˇe prezentaˇcní význam, takže pˇri zpracování HTML dokumentu se mužeme ˚ ptát maximálnˇe na pozici hledaného rˇ etˇezce. Text je oznaˇcen napˇríklad jako nadpis, tuˇcné písmo nebo tabulka. Oproti tomu v XML si mužeme ˚ nadefinováním vlastních tagu˚ jednotlivé cˇ ásti textu oznaˇcit i logicky. Muže ˚ nám potom vzniknout napˇríklad kniha rozdˇelená na kapitoly a ke každé kapitole pˇriˇradíme jiného autora. Potom už se mužeme ˚ jednoduše ptát na dotaz, kterým zjistíme, kdo kterou kapitolu napsal a ne pouze na polohu. Tímto nám vznikají logické dotazy nad XML dokumentem, které se pro interoperabilitu velice hodí. Samozˇrejmˇe není problém vytvoˇrit XML dokument v jiném kódování. Nejvíce se asi používá standardní UTF-8. Použité kódování se musí uvést v deklaraci XML dokumentu:

Tím, že je XML jednoduché, je možno rychle vytváˇret a upravovat a zpracovávat XML dokumenty automaticky. Staˇcí jen mít software, který dokáže zpracovat tento standard. Pak jen staˇcí znát význam jednotlivých tagu˚ a data z XML jednoduše zpracujeme. Puvodní ˚ formát HTML urˇcený pro internet nahradil na XML postavený formát XHTML (extensible hypertext markup language). Dalšími známými formáty pro ukládání dat v XML jsou DocBook, ODF (Open Document Format), na kterém staví známé OpenOffice. Novˇe pˇribyl Open XML formát od Microsoftu, na kterém staví nová verze Microsoft Office. Je tedy vidˇet, že XML se zaˇcíná prosazovat skoro všude, kde je tˇreba ukládat a pˇrenášet textová data. Náš ukázkový výsledný soubor postavený na XML by tedy mohl vypadat tˇreba takto:

11

2.3. MAPOVÁNÍ METADAT <jmeno>Božena Nˇ emcová Babiˇ cka Prostor 2006 80-7260-155-5

Tím, že použijeme jednotný formát pro výmˇenu informací dosáhneme syntaktické interoperability, kterou lze chápat jako vyjádˇrení struktury metadat umožnující ˇ syntakticky kombinovat datové prvky z ruzných ˚ schémat, slovníku˚ a jiných nástroju. ˚ Syntaktické interoperability se dosáhne vyznaˇcením dat podobným zpusobem, ˚ takže je možné sdílet data v ruzných ˚ systémech. Pokud nad takovýmto formátem dohodneme stejnou strukturu metadat (DocBook, ODF, Open XML), tak navíc dosáhneme interoperability strukturální, která vyjadˇruje strukturu metadat. Strukturální interoperability se tedy dosáhne pomocí datového modelu pro specifikaci sémantických schémat, takže se mohou aplikovat spoleˇcnˇe.

2.3

Mapování metadat

Mapování metadat mužeme ˚ chápat jako schéma nebo tabulku, která pˇredstavuje sémantické mapování polí nebo datových prvku˚ v jednom datovém standardu k polím nebo datovým prvkum ˚ ve druhém datovém standardu, který má podobnou funkci nebo význam. Mapuje vztahy a ekvivalence mezi dvˇema nebo více metadatovými formáty. Použijme náš puvodní ˚ zjednodušený soubor s knihou: Božena Nˇ emcová Babiˇ cka Prostor 2006 80-7260-155-5

Tento soubor vyexportujeme z jednoho systému a chceme ho naimportovat do druhého systému. V druhém systému se bohužel nepoužívá , ale <spisovatel>, stejnˇe tak se místo používá . Pole mají jiný název i když mají stejný význam. Namapujeme si pole dle tabulky 2.1. Pokud tedy importujícímu systému dodáme toto mapování, tak tento systém si puvodní ˚ soubor pˇremapuje na novou strukturu: <spisovatel>Božena Nˇ emcová Babiˇ cka

12

2.4. TECHNIKY MAPOVÁNÍ METADAT Puvodní ˚ název pole:

Nový název pole: <spisovatel>

Tabulka 2.1: Tabulka mapování metadat. Prostor 2006 80-7260-155-5

Takto upravený soubor již importující systém dokáže zpracovat. Samozˇrejmˇe musí jít takto mapovat napˇríklad i víc polí z puvodního ˚ souboru do jednoho pole v novém souboru nebo nˇejaká pole tˇreba úplnˇe vynechat. Jedinˇe tak se dosáhne vˇetší variability a tím i interoperability. Pro transformaci XML souboru˚ máme pˇredem pˇripraveny nástroj XSLT (eXtensible Stylesheet Language), který se používá pro transformaci XML souboru˚ na HTML pro prohlížení v prohlížeˇci. Lze ale pomocí tohoto nástroje jednoduše pˇrevést strukturu jednoho XML souboru na jinou strukturu. XSLT je velice mocný jazyk, podporuje napˇríklad i vˇetvení, podmínˇené pˇríkazy aj. Mapování a kˇrížové pˇrevody dat umožnují ˇ vyhledávacím strojum ˚ souˇcasné prohledávání v heterogenních databázích zadáním jediného dotazu, jako kdyby byly jedinou databází (sémantická interoperabilita) a efektivnˇe pˇrevádˇet data z jednoho metadatového standardu do jiného. Zopakujme tedy to nejduležitˇ ˚ ejší, že sémantické interoperability lze dosáhnout mapováním metadat a lze ji chápat jako obsahové vyjádˇrení struktury metadat, které dovoluje sémanticky kombinovat datové prvky z ruzných ˚ schémat, slovníku˚ a jiných nástroju˚ a umožnuje ˇ tak vyhledávat informace napˇríˇc heterogenními distribuovanými databázemi, zejména v prostˇredí internetu zadáním jediného dotazu. Pomocí sémantické interoperability jsou rˇ ešeny napˇr. pˇrípady, kdy jednotlivé zdroje používají ruzné ˚ termíny pro popis téhož pojmu (napˇr. autor, tvurce ˚ a skladatel) nebo naopak používají stejné termíny pro ruzné ˚ pojmy. Sémantické interoperability lze dosáhnout užíváním standardu˚ popisu obsahu zdroju˚ (napˇr. AACR nebo Dublin Core).

2.4

Techniky mapování metadat

Jelikož mapování není vždy tak jednoduché, jak jsem si pˇredvedli, tak se na mapování metadat dají použít nejruznˇ ˚ ejší techniky SIA (Semantic Interoperability Assets). Napˇr. [16]: •

Nomenklatura je systém pojmenování a zaˇrazování (klasifikace) urˇcitých objektu˚ jakožto prvku˚ dané kategorie. Nejˇcastˇeji se nomenklaturou rozumí ve vˇedˇe nemˇenná soustava termínu. ˚ Nomenklatrua neobsahuje slovesa, adjektiva, názvy dˇeju, ˚ ale jen názvy substantivní povahy. 13

2.5. SÉMANTICKÝ WEB •

Tezaurus je slovník, který uživateli nabízí seznam synonym, nˇekdy i antonym. Je to slovník, který umožnuje ˇ uživatelum ˚ nabízet shodný nebo podobný seznam slov, což zajišt’uje shodné vyjádˇrení problematiky pˇrekladu urˇcitého tématu popsaného jazykem autora do jazyka systému. Vyjadˇruje pojmy, které jsou v pˇrirozeném jazyce tˇežko postižitelné a pomocí složených termínu˚ a dalších nástroju˚ pˇrekonává problémy s jazykem umˇelým. S jeho pomocí mužeme ˚ hledat nˇejaké informace, aniž bychom vˇedˇeli, co je preferovaný termín. Umožnuje ˇ nám ulehˇcit práci pˇri nepˇreberném množství informací jako propojovací jazyk v informaˇcních systémech.

•

Vícejazyˇcný slovník je slovník, který je využíván pro vyhledávání slova nebo fráze ve více národních jazycích. Jeden jazyk je zvolen jako základní. Jelikož má nejvíce termínu˚ angliˇctina, tak se vˇetšinou stává základním jazykem. Vyhledávané slovo je pˇreloženo do základního jazyka, jsou vyhledány ekvivalenty v ostatních jazycích a pak se ˇ prohledají dokumenty v ruzných ˚ jazycích. Casto pak ještˇe následuje pˇreklad vyhledaných dokumentu˚ do národního jazyka hledajícího. Duležité ˚ je mít dobˇre zpracováné národní slovníky oboru, pro který se multijazyˇcný slovník vytváˇrí.

•

Ontologie je popis urˇcité problematiky. Je to formální a deklarativní reprezentace, která obsahuje definici pojmu˚ (glosáˇr) a definici vztahu˚ mezi jednotlivými pojmy (tezaurus). Ontologie je slovníkem, který slouží k uchovávání a pˇredávání znalosti týkající se urˇcité problematiky. Ontologií se budeme zabývat podrobnˇe v následující kapitole.

•

Mapovací tabulka je tabulka, ve které je uloženo jak namapovat datový prvek z jednoho standardu na datový prvek z druhého standardu. Vlastnˇe je to zhruba nˇeco takového, co jsme použili zjednodušenˇe v našem pˇríkladu pˇri mapování našeho pˇríkladu s knížkou.

•

Mapovací pravidla jsou pravidla, která vyjadˇrují vztahy mezi prvky mapovaných schémat.

•

Popisy webových služeb se využívají k tomu, abychom vˇedˇeli, jaké funkce nám webová služba nabízí a tudíž s ní pak mohli následnˇe pracovat. Lze pak tedy využívat ruzné ˚ webové služby v ruzných ˚ systémech. Systém si z popisu zjistí informace o webové službˇe a pak s ní muže ˚ náležitˇe pracovat.

2.5

Sémantický web

Když se podíváme na souˇcasný web, tak má jedno velké omezení. Dokumenty zobrazované na dnešním webu jsou strukturovány tak, že jsou dobˇre cˇ itelné pro cˇ lovˇeka. S cˇ itelností souˇcasných webových dokumentu˚ mají ale problémy poˇcítaˇce. To co je dobˇre cˇ itelné pro cˇ lovˇeka, nemusí být dobˇre cˇ itelné pro poˇcítaˇce. Právˇe toto by mˇel sémantický web zmˇenit. 14

2.6. XML, RDF A ONTOLOGIE JAKO ZÁKLAD SÉMANTICKÉHO WEBU V sémantickém webu jde tedy o to, aby byl význam informace definován tak, aby ho pochopil i poˇcítaˇc. Na webu lze najít velké množství informací. Pokud hledáme nˇejakou informaci, je velice pravdˇepodobné, že tato informace nˇekde na webu existuje. Velké množství dat je velice nároˇcné na prohledávání, a proto již ale není zaruˇceno, že hledanou informaci skuteˇcnˇe najdeme, i když existuje. Pˇri prohledávání webu se musíme spoléhat na služby nˇekterého vyhledávaˇce, který je ale velice nároˇcný na údržbu. Obsahuje databázi pro fulltextové prohledávání, která se musí cˇ asto aktualizovat. Najít v takovém pˇrípadˇe pˇresnˇe tu informaci, kterou potˇrebujeme je velice složité. Pokud vyhledávaˇc najde odpovˇedi na náš dotaz, tak se cˇ asto stane, že najde tisícovky dokumentu˚ a je potom veliký problém vybrat dokument, kde je pˇresnˇe to, co hledáme. Lze tedy konstatovat, že vyhledat relevantní informaci na dnešním webu se stává stále složitˇejší. Sémantický web si klade za cíl opatˇrit webové dokumenty novými tagy. Souˇcasné HTML tagy jsou totiž nedostateˇcné pro to, aby dokázaly dokument formátovat do strojovˇe cˇ itelné podoby. Pomocí HTML tagu˚ poˇcítaˇc dokument jen dokáže pˇretransformovat do podoby cˇ itelné pro cˇ lovˇeka. Internetový prohlížeˇc tak pozná tˇreba, že cˇ ást textu v dokumentu je kurzívou, ale už nezná význam této cˇ ásti dokumentu. Zde se jen potvrzuje to, že co má cˇ itelný význam pro cˇ lovˇeka nemá cˇ itelný význam pro poˇcítaˇc. Prohlížíme-li si stránky o Rakousku, je pro cˇ lovˇeka zcela cˇ itelná vˇeta „hlavní mˇesto Rakouska Víden“. ˇ Pokud je tˇreba Vídenˇ obklopena tagem <strong>, tak poˇcítaˇc neví nic víc než jen to, že má toto slovo zobrazit tuˇcnˇe a snad si z toho odvodí jen to, že je to o nˇeco duležitˇ ˚ ejší informace než okolní text. Ale to, že je Vídenˇ hlavní mˇesto Rakouska už poˇcítaˇc nijak nerozliší. Tagy sémantického webu, ale zapisují informace takovou formou, že je poˇcítaˇc schopen porozumˇet i významu. Tak lze v sémantickém webu zachytit vztahy mezi množinami dat. V sémantickém webu je duležitá ˚ existence inteligentních vyhledávacích agentu. ˚ Tito agenti jsou softwarové nástroje, které dokáží efektivnˇe procházet Internet a vybírat z nˇej pouze relevantní informace. Toto pak zajistí, že takový agent je schopen odpovˇedˇet na velice složitý dotaz uživatele ve velice krátkém cˇ ase. Agenti vedle toho, že porozumí významu dat, mezi kterými prohledávají, dokáži i najít souvislosti mezi již známými skuteˇcnostmi. Pˇrihlédneme-li k množství dat, která Internet obsahuje, tak získáme opravdu veliký potenciál.

2.6

XML, RDF a ontologie jako základ sémantického webu

Základním prvkem sémantického webu je XML, o kterém jsem se mohli již doˇcíst výše. Jelikož je XML navrženo tak, že je možnost se zamˇerˇ it na strukturu a význam dat, lze pomocí nˇeho vytváˇret složitˇejší datové struktury a definovat vztahy mezi tˇemito strukturami. Vezmˇeme pˇríklad s hlavním mˇestem Rakouska. Oznaˇckujeme-li tento pˇríklad patˇriˇcnými znaˇckami XML, tak sice ještˇe poˇcítaˇc nebude vˇedˇet, co znamenají výrazy „hlavní mˇesto Rakouska“ a „Víden“, ˇ ale již ví, že „Víden“ ˇ je hodnotou promˇenné „hlavní mˇesto Rakouska“. Jak si uživatel dané XML tagy nadefinuje je již jenom na nˇem. Tím vyhledávací agent muže ˚ porozumˇet struktuˇre dokumentu, ale nerozumí jeho obsahu. Pro tyto úˇcely bylo vytvoˇreno 15

2.6. XML, RDF A ONTOLOGIE JAKO ZÁKLAD SÉMANTICKÉHO WEBU RDF. RDF (Resource Description Framework) [13] je obecný rámec pro popis jakéhokoli elektronického zdroje, resp. webové stránky a jejího obsahu, tedy pro vyjádˇrení sémantiky a pro podporu sémantického webu. Popisná metadata mohou zahrnovat údaje o autorovi, datu vytvoˇrení nebo aktualizace, organizaci stránek (sitemap), klíˇcová slova, pˇredmˇetové kategorie aj. Jazyk RDF poskytuje robustní flexibilní architekturu pro zpracování metadat na internetu; umožnuje ˇ komukoli definovat a používat metadatové schéma, které slouží nejlépe jeho potˇrebám a souˇcasnˇe umožnuje ˇ interoperabilní výmˇenu metadat. RDF je aplikací formátu XML a je vyvíjen konsorciem W3C [13]. RDF je vlastnˇe kombinace slovníku a tezauru pro tagy XML. Význam je kódován do jednoduchých tvrzení, kterým dokáží porozumˇet softwaroví agenti. Je to systém trojic, kde každá trojice obsahuje subjekt, predikát a objekt tvrzení. Opˇet v našem pˇríkladu je tedy: Hlavní mˇesto (predikát) Rakouska (objekt) Vídenˇ (subjekt). Takto lze tvoˇrit opravdu složité struktury dat, které dokáží popsat skuteˇcnost jako pˇrirozená rˇ eˇc. Subjektem nebo objektem nemusí být pouze jednoduchý výraz, ale celé dokumenty nebo jejich cˇ ásti. Tím, že je RDF v jazyce XML je pˇrenositelné mezi ruznými ˚ platformami a systémy. RDF nepˇredjímá konkrétní reprezentaci – ta muže ˚ být napˇr. grafová nebo vyjadˇrovat tvrzení prostˇe jako posloupnost tˇrí výrazu˚ na tomtéž rˇ ádku. Jednotlivé prvky tvrzení RDF jsou rˇ azeny za sebe do elementu˚ a atributu˚ XML. Ukažme pˇríklad zápisu tvrzení „Tvurcem ˚ (= predikát) zdroje http://www.w3.org/Home/Lassila (= subjekt) je Ora Lassila (= objekt)“: <s:Creator>Ora Lassila

Element rdf:RDF obsahuje atributy definující jmenné prostory :rdf pro konstrukty samotného RDF, a dc pro standard Dublin Core1 , z nˇehož je pˇrevzata vlastnost „být tvurcem“. ˚ Vlastní tvrzení je pak obsaženo v elementu Description, jehož atribut about odkazuje na subjekt. Sémantický web staví na RDF. Realizace sémantického webu pˇredpokládá implementaci standardu˚ pro sémantickou (RDF), strukturální (XML) a syntaktickou (URI) složku architektury webových dokumentu. ˚ Výsledkem aplikace uvedených standardu˚ bude konzistentní logická struktura dat, která bude implicitnˇe vyjadˇrovat význam zaznamenaných informací. Sémantický web definuje význam pomocí ontologií a odvozuje nové informace zejména pomocí odvozovacích pravidel. Ontologie popisuje vztahy mezi výrazy XML a položkami RDF. Ontologie pro web obsahují taxonomii a množinu odvozovacích pravidel. Pomocí taxonomie definujeme tˇrídy objektu˚ a vztahy mezi nimi. Pomocí odvozovacích pravidel poˇcítaˇc z již známých faktu˚ odvodí nové skuteˇcnosti. 1.

16

2.6. XML, RDF A ONTOLOGIE JAKO ZÁKLAD SÉMANTICKÉHO WEBU XML tedy zprostˇredkovává syntaktickou vrstvu sémantického webu, zatímco ontologie tvoˇrí vrstvu sémantickou. Sémantický web by mˇel podstatnˇe usnadnit vyhledávání. Dalo by se zjednodušenˇe rˇ íci, že sémantický web je v principu relaˇcní databázi publikovanou na webu. Nikoli však pouze v podobˇe v ní uložených dat, ale s pˇríslušným kontextem, se strojovˇe cˇ itelnou informací o významu dat.

17

Kapitola 3

Ontologie Ve filosofii se ontologie chápe jako nauka (ˇci soubor nauk) o „bytí“, popˇrípadˇe jako univerzální soustava znalostí popisující objekty, jevy a zákonitosti svˇeta. Když se na poˇcátku 90. let minulého století zaˇcal objevovat termín „ontologie“ i v informatice, vyvolalo to jistou nevoli ve filosofických kruzích, které se obávaly zmˇeny významu již zavedeného pojmu. Navzdory tomu se použití termínu rozšiˇrovalo i v informatice. Rozvoj sítˇe Internet si vyžádalo zaˇclenˇení ontologií pˇrímo do webu. To vedlo ke standardizaci tohoto pojmu i v informatice. V informatice je ontologie specifikována jako "explicitní specifikace konceptualizace". Konceptualizace (tj. systém pojmu˚ modelující urˇcitou cˇ ást svˇeta) musí být specifikována explicitnˇe, tj. nikoliv jen "skryta" v hlavˇe svého autora. Úˇcelem ontologií je podpora porozumˇení mezi lidmi, podpora komunikace mezi poˇcítaˇcovými systémy a podpora návrhu znalostnˇe orientovaných systému. ˚ Základní využití ontologií jsou tato [14]: •

Podpora porozumˇení mezi lidmi (napˇr. mezi experty a znalostními inženýry).

•

Podpora komunikace (interoperability) mezi poˇcítaˇcovými systémy.

•

Usnadnˇení návrhu znalostnˇe-orientovaných aplikací.

Ontologie lze cˇ lenit do tˇrí základních typu[14]: ˚ •

Terminologické jsou založeny na bázi pokroˇcilejších tezauru. ˚ Používané jsou v knihovnictví a oborech zamˇerˇ ených pˇrevážnˇe na textové informace. Jejich charakteristickým rysem je ústˇrední role termínu, ˚ které již nejsou dále (formálnˇe) definovány. Používané relace mají z velké cˇ ásti taxonomický charakter (vymezení vztahu obecnˇejšího a speciálnˇejšího termínu), vedle toho bývá vyjádˇrena synonymie, meronymie (vztah termínu˚ oznaˇcujících celek a jeho cˇ ást) a další relace obecného charakteru. Nejznámˇejší terminologická ontologie je nepochybnˇe WordNet1 a z nˇej odvozený Sensus2 nebo vícejazyˇcný EuroWordNet3 .

•

Informaˇcní rozvíjejí databázová konceptuální schémata. Zajišt’ují abstrakci a vyšší kontrolu integrity. Hrají roli nadstavby nad primárními (relaˇcnˇe-databázovými) zdroji,

1. 2. 3.

18

3.1. STRUKTURA ONTOLOGIÍ pro které zabezpeˇcují jednak konceptuální abstrakci potˇrebnou pro pojmové dotazování, jednak vyšší úrovenˇ kontroly integrity než bˇežné nástroje. •

Znalostní reprezentují znalosti v rámci umˇelé inteligence. Ontologie jsou zde chápány duslednˇ ˚ e jako logické teorie a jejich vazba na reálné objekty (instance) je oproti informaˇcním ontologiím relativnˇe volná. Tˇrídy (koncepty) a relace jsou systematicky definovány prostˇrednictvím formálního jazyka.

Pokud se podíváme na cˇ lenˇení ontologií dle pˇredmˇetu formalizace, mužeme ˚ zmínit tyto hlavní typy [14]: •

Doménové ontologie jsou nejfrekventovanˇejším typem. Jejich pˇredmˇetem je vždy urcˇ itá specifická vˇecná oblast vymezená široce (napˇr. problematika medicíny) nebo úzce (problematika konkrétní choroby).

•

Generické ontologie zachycují obecné zákonitosti, které platí napˇríˇc vˇecnými oblastmi, napˇr. problematiky cˇ asu, vzájemné pozice objektu˚ (topologie), skladby objektu˚ z cˇ ástí apod. Nˇekdy se ještˇe výslovnˇe vyˇclenují ˇ tzv. ontologie vyšší úrovnˇe, které usilují o zachycení nejobecnˇejších pojmu˚ a vztahu˚ jako základu taxonomické struktury každé další ontologie.

•

Úlohové ontologie jsou generické modely znalostních úloh a metod jejich rˇ ešení. Na rozdíl od ostatních ontologií, které zachycují znalosti o svˇetˇe, se zamˇerˇ ují na procesy odvozování. Mohou rˇ ešit napˇríklad úlohy plánování.

•

Aplikaˇcní ontologie je konglomerát modelu˚ pˇrevzatých a adaptovaných pro konkrétní aplikaci. Obsahuje doménovou i úlohovou cˇ ást (a tím automaticky i generickou cˇ ást).

3.1

Struktura ontologií

Základní struktura ontologií je ve všech projektech podobná, ale cˇ asto se liší terminologie [14]. Nejvíce se liší tradiˇcní jazyky jako Ontolingua a nové odlehˇcené webové jazyky. Proto budu uvádˇet synonymní termíny v závorce. Základem ontologií jsou tˇrídy (koncepty, kategorie), které oznaˇcují množiny konkrétních objektu. ˚ Tˇrídy pro které jsou specifikovány podmínky nutnosti i postaˇcitelnosti (pˇríslušnosti individua) se oznaˇcují jako definované. Ostatní tˇrídy se oznaˇcují jako primitivní. Na množinˇe tˇríd pak bývá definována taxonomie (hierarchie). všechny hlavní ontologické jazyky podporují vícenásobnou dˇediˇcnost, která se cˇ asto využívá. Individuum odpovídá konkrétnímu objektu reálného svˇeta. Termín instance je nˇekdy chápán jako ekvivalentní, asociuje ale pˇríslušnost k urˇcité tˇrídˇe. Ale individuum muže ˚ být do ontologie vloženo i bez vazby na tˇrídu. Zda je objekt tˇrídou nebo instancí cˇ asto nezávisí na objektivním stavu svˇeta, ale na úhlu pohledu, kterým se na daný objekt díváme. 19

3.2. JAZYKY A NÁSTROJE PRO MANIPULACI S ONTOLOGIEMI Duležitou ˚ složkou ontologií jdou vztahy neboli relace n-tic objektu. ˚ V tradiˇcních jazycích mohou být relace specifikovány pomocí logických podmínek. V odlehˇcených webových jazycích se jim pˇriˇrazují jen pˇreddefinovaná omezení globálnˇe nebo lokálnˇe. Odlehˇcené jazyky se omezují na binární relace a používají pro nˇe pojem slot (vlastnost). Zvláštními typy relací jsou funkce. Jde o relace, u kterých je hodnota n-tého argumentu jednoznaˇcnˇe urˇcena pˇredchozím argumentem n-1. Funkˇcní slot se oznaˇcuje také jako atribut a je definován pro všechny instance tˇrídy. Je tˇreba ještˇe doplnit, že i relace mohou mít nad sebou definovanou hierarchii. Pˇríkladem muže ˚ být tˇreba dvojice „má otce“ a „má pˇredka“. Relace nemusí být jen popis vztahu mezi n-ticí objektu. ˚ Argumenty relací mohou být i primitivní hodnoty, které žádnému objektu neodpovídají. Obor hodnot v takovém pˇrípadˇe bývá omezen nˇekterým základním datovým typem (integer, float, string...), cˇ íselným cˇ i alfanumerickým intervalem nebo výˇctem. Do ontologií lze zaˇrazovat i další logické formule, které mohou oznaˇcovat napˇr. ekvivalenci tˇríd cˇ i relací, disjunktnost tˇríd, rozklad tˇrídy na podtˇrídy apod. Oznaˇcujeme je jako axiomy (pravidla). Ontologie ještˇe mohou obsahovat souhrnné údaje, které se umist’ují do hlaviˇcky. Lze takto napˇríklad pomocí odkazu˚ importovat jiné ontologie nebo ontologie doplnit metadaty o autorovi, verzi, cˇ asu vytvoˇrení, zpusobu ˚ vytvoˇrení apod. Ontologickým závazkem nazýváme rozhodnutí daného subjektu využít pro vyjádˇrení pojmu˚ prvky a strukturu dané ontologie. Uživatel tedy pˇri volbˇe ontologie akceptuje ontologické závazky v ní zahrnuté. V prubˇ ˚ ehu vývoje ontologických aplikací byly identifikovány dva významné problémy, komplikující tvorbu a využívání ontologií. První z nich je problém rozsahu. Poˇcet pojmu, ˚ které by se mohly chápat jako relevantní zvolené doménˇe, je nezvládnutelné množství. Pˇri tvorbˇe ontologie je proto nutné systematicky provádˇet selekci a zaˇrazovat zejména ty pojmy, které mají jasnou vazbu na pojmy z “jádra” ontologie. Dalším pˇrirozeným opatˇrením je rozdˇelení ontologie do více nezávislých modulu. ˚ Druhým je problém interakce. Optimální tvar ontologie je závislý na zpusobu, ˚ jakým se bude používat. Nˇekdy se také mluví o nutnosti ˇ kompromisu mezi použitelností a znovupoužitelností ontologie. Cím je ontologie nezávislejší na konkrétní aplikaci, tím ménˇe efektivním se stává její pˇrímé využívání. Z tohoto si lze odvodit, že je velice tˇežké (ne-li nemožné) vytvoˇrit obecnou ontologii na dané doménˇe, kterou by mohly využívat ruznorodé ˚ aplikace. Pokud ontologii vytvoˇríme, tak existují softwarové nástroje zvané reasonery (usuzovaˇce), dávají ontologiím veliký význam, jelikož dokáží pracovat se vztahy v nich uvedených. Reasonery totiž dokáží odvodit vztahy v ontologii obsažené, ale výslovnˇe neuvedené.

3.2

Jazyky a nástroje pro manipulaci s ontologiemi

Za nepˇríliš dlouhou dobu, bˇehem které se ontologie zkoumají, bylo vyvinuto nˇekolik desítek formálních jazyku˚ pro reprezentaci ontologie [14]. Nˇekteré se používají ménˇe, nˇekteré více. Nyní se podíváme velice struˇcnˇe na ty nejvýznamnˇejší. Momentálnˇe asi nejvíce duležitému ˚ jazyku OWL (Ontology Web Language) pak vˇenujeme celou podkapitolu. 20

3.2. JAZYKY A NÁSTROJE PRO MANIPULACI S ONTOLOGIEMI 3.2.1 Ontolingua Jazyk Ontolingua4 byl vyvinut na zaˇcátku 90. let. T. Gruberem a jeho spolupracovníky ze stanfordské Knowledge System Laboratory5 . Cílem tohoto jazyka je nabídnout dostateˇcnˇe mocný a zárovenˇ pˇrehledný nástroj, který by umožnoval ˇ sdílet ontologie v rámci odborných komunit používajících vzájemnˇe nekompatibilní znalostní systémy. Ontolingua je nadstavbou jazyka KIF (Knowledge Interchange Format)6 , který využívá syntaxe LISP. Základními konstrukty jazyka Ontolingua jsou definice tˇríd, relací a funkcí, pˇriˇcemž vymezující podmínky pro pˇríslušnost instancí jsou vyjádˇreny právˇe v KIF. Pˇríklad syntaxe jazyka Ontolingua: (Define-Class Sale-Offer (?X) "A For-Sale situation with a Specified-Potential-Customer" :Iff-Def (And (For-Sale ?X) (Exists (?Le) (Specified-Potential-Customer ?X ?Le))))

Tento pˇríklad zobrazuje definici "Nabídky prodeje". Celá tˇrída je vymezena jedinou dostaˇcující podmínkou Iff-def, jež obsahuje konjunkci dvou výrazu. ˚ Ontolingua byla od zaˇcátku koncipována jako „mezi-jazyk“ primárnˇe urˇcený k výmˇenˇe ontologických informací mezi systémy, které internˇe používají vlastní reprezentaci. Z toho vyplývají i omezené možnosti odvozování pˇrímo v tomto jazyce. Jednoduchý on-line editor jazyka Ontolingua je dostupný na stránkách webových služeb KSL (Stanford KSL Network Services)7 , kde si ho lze po pˇrihlášení jako anonymní uživatel vyzkoušet. 3.2.2 OCML Omezené možnosti jazyka Ontolingua vedly E. Mottu z Open University ve Velké Británii k návrhu jazyka OCML (Operational Conceptual Modelling Language)8 .OCML výraznˇeji podporuje pˇrímý vývoj programových aplikací, aniž by bylo nutno model pˇrekládat do jiného jazyka. Vývoj tohoto jazyka je tˇesnˇe propojen s tvorbou jeho interpretu implementovaného v prostˇredí CommonLISP. Základem interpretu jsou algoritmy pro Prologovské dokazování a dˇedˇení v hierarchii tˇríd; tˇrídy a jejich atributy jsou ovšem duslednˇ ˚ e chápány jako unární resp. binární relace, takže primární (vnitˇrní) reprezentací jsou Hornovy klauzule. Pˇríklad syntaxe jazyka OCML: (def-relation date-difference (?date-1 ?date-2 ?diff ?diff1)) 4. 5. 6. 7. 8.

21

3.2. JAZYKY A NÁSTROJE PRO MANIPULACI S ONTOLOGIEMI

Obrázek 3.1: On-line editor jazyka Ontolingua.

(def-rule date-difference ((date-difference ?date-1 ?date-2 ?diff ?diff1) if (and (date ?date-1 day ?d1 month ?m1 year ?y1) (date ?date-2 day ?d2 month ?m2 year ?y2) (not (== ?date-1 ?date-2)) (= ?diff1 (+ (* (- ?y2 ?y1) 365) (* 30 (- ?m2 ?m1)) (- ?d2 d1))) (> ?diff1 ?diff))))

Tento kód vypoˇcte rozdíl dvou dat. Relace samotná neobsahuje definici, ale je uvedena nepˇrímo pomocí pravidla zpˇetného zˇretˇezení. OCML si získal znaˇcný respekt, avšak vinou vázanosti na LISP jako implementaˇcním prostˇredí se moc nerozšíˇril. Webové editaˇcní roz22

3.2. JAZYKY A NÁSTROJE PRO MANIPULACI S ONTOLOGIEMI hraní pro OCML zprostˇredkovává systém WebOnto9 .

Obrázek 3.2: Editor jazyka OCML WebOnto.

3.2.3 SHOE SHOE (Simple HTML Ontology Extension)10 je prvním jazykem, který vznikl pro úˇcely pˇridání sémantiky k webovým stránkám. SHOE byl vyvinutý týmem J. Hendlera na University of Maryland. Tento jazyk umožnuje ˇ zaˇclenovat ˇ do zdrojového kódu webových stránek jednak metadata o objektech, kterých se tyto stránky týkají, jednak samotné ontologie definující sémantiku tˇechto metadat. Jako ukázku syntaxe jazyka SHOE si mužeme ˚ uvést nˇekolik definic kategorií (tj. tˇríd) a relací týkajících se kateder informatiky: 9. 10.

23


Anotace samotné stránky je pak obsažena v elementu HTML nazvaném instance:

Takto se vymezuje použitá ontologie:

Metadata o vlastníkovi stránky, vyjadˇrující napˇríklad skuteˇcnost, že je instancí tˇrídy GraduateStudent, nebo že pro nˇej druhý argument relace age nabývá hodnoty 52:

To, že se v SHOE instance implicitnˇe ztotožnují ˇ s fyzickými stránkami nebo jejich cˇ ástmi, má nezvyklý efekt. Webový objekt (stránka identifikovaná svým URL) do jisté míry splývá s objektem reálného svˇeta (ˇclovˇek, firma, výrobek...). S nadsázkou by se dalo rˇ íci, že „kdo nemá svou stránku, ten neexistuje“. Tento efekt byl v pozdˇejších webových jazycích eliminován zejména zobecnˇením pojmu „zdroje“ (v RDF, viz dodatek B), který už zdaleka nemusí mít povahu fyzické stránky HTML. 3.2.4 Ontobroker Jazyk Ontobtoker11 vnikl v pˇribližnˇe stejné dobˇe jako SHOE na univerzitˇe v Karslruhe. Tento jazyk opˇet vkládá sémantické anotace pˇrímo do kódu webových stránek, odlišná je však navrhovaná centralizovaná architektura, která pˇredpokládá existenci ontologického serveru, 11.

24

3.2. JAZYKY A NÁSTROJE PRO MANIPULACI S ONTOLOGIEMI na kterém jsou všechny ontologie spravovány pouze oprávnˇenými uživateli. Tím se zjednoduší vyhledávání v ontologiích, jelikož se nemusí náhodnˇe prohledávat web, ale jen registrované ontologické servery. Ontobroker má odlišný jazyk pro ontologie a anotace. Jazyk anotací je obohacením HTML o dodateˇcné atributy. Jazykem pro ontologie je propracovaný formalismus tzv. F-logic. Ukázka cˇ ásti ontologie v jazyce Ontobroker: Person :: Object. Researcher :: Person. Person [lastName =>> STRING; ...; publication =>> Publication]. FORALL Per,Pub Pub:Publication [author ->> Per] <-> Per:Person [publication ->> Pub]

První cˇ ást vyjadˇruje hierarchii tˇríd. Pro tˇrídu Person jsou definovány sloty, a to jak datotypové (lastName), tak objektové (Publication). Druhou cˇ ástí je ekvivalenˇcní axiom vyjadˇrující vztah dvou vzájemnˇe inverzních slotu. ˚ Odpovídající znalostní anotace muže ˚ pak být do kódu HTML vnoˇrena takto: IIIA - Artificial Intelligence Institute Richard

Pro webové použití jazyky SHOE a Ontobroker již zastaraly. Pro komerˇcní využití na firemních intranetech nabízí stále jazyk Ontobroker spoleˇcnost Ontoprise [3]. Kromˇe komerˇcních nástroju˚ od spoleˇcnosti Ontoprise jsem žádné volnˇe dostupné editory napsané pˇrímo pro Ontobroker nenašel. 3.2.5 RDF Schema Problémem jazyku˚ pro vyjádˇrení ontologií byla jejich nekompatibilita s RDF vytvoˇreným ˚ jak tuto komkonsorciem W3C [13]. Koncem 90. let minulého století se zaˇcal hledat zpusob, patibilitu zajistit. Postupnˇe se prosadil názor, že grafový model RDF je na rozdíl od stromového modelu XML dostateˇcnˇe otevˇrený pro vyjádˇrení sémantiky metadat prostˇrednictvím ontologií – zejména tím, že jednotlivá tvrzení jsou v RDF nezávislá na ostatních, a pˇritom je možné je propojovat pomocí URI zdroju. ˚ První ontologický jazyk orientovaný na RDF vznikl v roce 1999 pˇrímo na pudˇ ˚ e konsorcia 12 W3C [13] a byl pojmenován RDF Schema (RDFS) . V RDFS lze nadefinovat hierarchické struktury, na rozdíl od klasických ontologických jazyku˚ mu však chybí možnost preciznˇeji 12.

25

3.2. JAZYKY A NÁSTROJE PRO MANIPULACI S ONTOLOGIEMI specifikovat podmínky pˇríslušnosti ke tˇrídám a zcela postrádá datové typy. Jelikož byl tento jazyk pozdˇeji nahrazen novˇejšími jazyky pro webové ontologie, tak všechny editory, které jsem našel, byly ve stádiu pozastavení projektu a cˇ asto nebyly ani funkˇcní. 3.2.6 DAML+OIL V roce 2000 byl zahájen projekt DAML (DARPA Agent Mark-up Language)13 sponzorovaný vojenskou institucí DARPA14 . Tento projekt mˇel za cíl vytvoˇrit sémantický jazyk pro RDF s vˇetší vyjadˇrovací silou než má RDFS. S tím jak rostl význam RDF nastala potˇreba postavit nové jazyky na nˇekterém propracovaném logickém kalkulu, který by umožnoval ˇ konstrukci složitˇejších podmínek pˇri zachování výhodných vlastností pro výpoˇcty. Vznikl jazyk OIL (Ontology Inference Layer)15 postavený na deskripˇcní logice. Jeho cˇ ásteˇcným slouˇcením s jazykem, který vznikl z projektu DAML, vznikl jazyk s názvem DAML+OIL16 . Základem DAML+OIL jsou tˇrídy reprezentované bud’ svým jménem tj. URI (pojmenované tˇrídy) nebo urˇcitým logickým výrazem (anonymní tˇrídy). Pro tvorbu logických výrazu˚ vymezujících tˇrídy se používají konstruktory:

intersectionOf, unionOf, complementOf - booleovský výraz nad tˇrídami oneOf - tˇrída jako množina primitivních hodnot toClass, hasClass - tˇrída splnující ˇ univerzální resp. existenˇcní omezení na slot (tj. na tˇrídy, které jsou jeho hodnotami) hasValue - tˇrída splnující ˇ omezení na konkrétní hodnotu slotu (kombinace hasClass a oneOf) minCardinalityQ, maxCardinalityQ, CardinalityQ - tˇrída splnující ˇ omezení na kardinalitu slotu Konstruktory je možno libovolnˇe skládat. Vlastní náplnˇ ontologie tvoˇrí axiomy vybudované právˇe nad výrazy reprezentujícími tˇrídy. Typy axiomu˚ jsou tyto:

subClassOf - vztah obecnˇejší a speciálnˇejší tˇrídy 13. 14. 15. 16.

26


sameClassAs - ekvivalence tˇríd disjointWith - prázdný prunik ˚ tˇríd subPropertyOf - vztah obecnˇejší a speciálnˇejšího slotu (vlastnosti) samePropertyAs - ekvivalence vlastností inverseOf - vztah vzájemnˇe inverzních vlastností transitiveProperty - tranzitivita vlastnosti uniqueProperty - vlastnost je funkcí unambiguousProperty - inverzní vlastnost k dané vlastnosti je funkcí sameIndividualAs - totožnost individuí differentIndividualFrom - odlišnost individuí Zde je ukázka ontologie v jazyce DAML+OIL: ]> xyz Ontology to describe organizations and individuals participating in a government R&D program.

27

ˇ 3.3. OWL – SOU CASNÝ JAZYK WEBOVÝCH ONTOLOGIÍ

Nejprve jsou deklarovány jmenné prostory, které následuje hlaviˇcka daml:Ontology. Tˇrída Agency je deklarována jako podtˇrída tˇrídy Organization a jako ekvivalentní tˇrídˇe Agency ze starší verze téže ontologie. Hodnota dato-typové vlastnosti name je pro tˇrídu Agency deklarována pomocí lokálního omezení jako instance datového typu string. Hodnota objektové vlastnosti partOf je pro tˇrídu Agency deklarována jako instance téže tˇrídy Agency. V pˇríkladu vidíme, že elementy pocházejí z ruzných ˚ jmenných prostoru. ˚ Vztah RDF, RDFS a DAML+OIL mužeme ˚ chápat jako soustavu jazykových vrstev, ve které vyšší jazyk vždy dˇedí konstrukty z jazyka nižšího – ty pak ovšem není nutno znova definovat. Pˇredností takto vrstvené architektury ontologií je cˇ ásteˇcná zpˇetná kompatibilita. Pro jazyk DAML+OIL existuje výborný volnˇe dostupný editor Oiled17 , který bohužel bˇeží jen jako desktopová aplikace v jazyce JAVA a nedokáže pracovat on-line.

3.3

OWL – souˇcasný jazyk webových ontologií

Na základˇe užívání DAML+OIL vzniká pod hlaviˇckou W3C Ontology Working Group18 v roce 2002 první pracovní verze jazyka OWL (Web Ontology Language). Jazyk OWL rozšiˇruje RDF a RDF Schema, jde zde tedy opˇet o soustavu nˇekolika jazykových vrstev. Podívejme se, jak se tvoˇrí v jazyce OWL základní struktury, kompletní popis jazyka OWL lze najít v dokumentu Web Ontology Language Guide [2]. Na zaˇcátku ontologie je opˇet potˇreba definovat seznam jmenných prostoru˚ uvedené v tagu [17]. Definice jmenných prostoru˚ nám zabrání konfliktu stejnˇe pojmenovaných elementu˚ v ruzných ˚ ontologiích. Zjistíme pak, že každý element je z jiného jmenného prostoru a náleží jiné otologii, i když se s obˇema elementy pracuje zároven. ˇ 17. 18.

28


Obrázek 3.3: Editor Oiled pracující s jazykem DAML+OIL.

Pokud nebude následnˇe v dokumentu uvádˇen u elementu˚ žádný jmenný prostor nebo budeme uvádˇet jmenný prostor nasprostor, budou uvažovány elementy z této naší ontologie. Toto nám zajistí první dvˇe deklarace jmenných prostoru. ˚ Tˇretí deklarace urˇcuje základní URI tohoto dokumentu. Dále tam máme deklarace na jmenné prostory OWL, RDF, 29

ˇ 3.3. OWL – SOU CASNÝ JAZYK WEBOVÝCH ONTOLOGIÍ RDF Schema a XML Schema, se kterými se v OWL pracuje. Poslední deklarace ukazuje na možnost použití nˇejakého dalšího jmenného prostoru z již existující ontologie. Tag se uzavírá až na konci definice ontologie. Za definicí jmených prostoru˚ následuje hlaviˇcka uzavˇrená do tagu : v 1.0, 27.03.2008, 11:05 Naše ontologie Toto je naše ukázková ontologie pro diplovomou práci

Atribut about oznaˇcuje zdroj, který je tímto tagem popisován, vˇetšinou to bývá URI souˇcasného dokumentu. Tag owl:versionInfo udává verzi ontologie, která je v pˇredem dohodnutém tvaru pro následné automatické zpracování. Owl:priorVersion odkazuje na pˇredchozí verzi ontologie. a oznaˇcují titulek, respektive krátký popis ontologie. Již v definci jmenných prostoru˚ jsme užili jmenný prostor uzityprostor nyní pomocí tagu owl:imports naimportujeme i jeho struktury a vztahy. Po hlaviˇcce následuje seznam definic tˇríd a jejich vztahu. ˚ Tˇrídu jednoznaˇcnˇe popisuje její jméno a soubor vlastností jejích prvku. ˚ Tˇrídy mužeme ˚ definovat identifikátorem:

Toto nám o tˇrídˇe Student rˇ íká jen to, že existuje, nijak ji tato konstrukce nadále nepopisuje. Asi je pro úplnost potˇreba dodat, že v jazyce OWL již existují dvˇe základní tˇrídy owl:Thing a owl:Nothing. Tˇrída owl:Thing oznaˇcuje množinu všech individuí v ontologii, tzn. každá tˇrída v definované ontologie je podtˇrídou owl:Thing. Tˇrída owl:Nothing oznaˇcuje prázdnou množinu, takže je podtˇrídou každé definované tˇrídy. Tˇrídy v OWL lze definovat výˇctem prvku, ˚ který je koneˇcný: . .

V tomto pˇríkladu je definována tˇrída, která sdružuje individua oznaˇcující jednotlivé fakulty Masarykovy univerzity. V definici neuvádíme jméno dané tˇrídy, jedná se tedy o definici anonymní tˇrídy a nelze se na ní v ontologii odkazovat. Toto se muže ˚ hodit tvoˇríme-li 30

ˇ 3.3. OWL – SOU CASNÝ JAZYK WEBOVÝCH ONTOLOGIÍ napˇríklad tˇrídu vzniklou prunikem ˚ dvou jiných tˇríd, není již potˇreba pojmenovávat dané dvˇe tˇrídy, ale jen výsledný prunik. ˚ Pokud budeme chtít doplnit tˇrídu o jméno, staˇcí upravit úvodní tag takto:

Tˇrídy lze také definovat standardními množinovými operacemi. Tˇrída definovaná sjednocením tˇríd:

Tˇrída definovaná prunikem ˚ tˇríd:

Tˇrída definovaná doplnkem ˇ jiné tˇrídy:

U tohoto posledního pˇríkladu se pozastavíme. Je to definice studentu, ˚ kteˇrí nestudují na právnické fakultˇe. Je dobré v tomto pˇrípadˇe kombinovat doplnˇek s prunikem ˚ tˇrídy studentu. ˚ V opaˇcném pˇrípadˇe by nám totiž spadly do této tˇrídy i všechny ostatní individua ontologie, která nejsou studenty právnické fakulty, tedy i ti, kteˇrí nejsou studenti. Tímto jsme si zárovenˇ ukázali, jak jednoduše lze vnoˇrovat a kombinovat jednotlivé definice. Z popisu struktury ontologií z poˇcátku kapitoly víme, že tˇrídy a individua vytváˇrejí strukturu ontologie. Vlastnosti neboli sloty vnášejí do dokumentu tvrzení o tˇrídách a jejich prvcích. Vlastnost spojující dva objekty se definuje tagem owl:objectProperty a vlastnost dato-typová tagem owl:datatypeProperty. Pokud je vlastnost podmnožinou vlastnosti jiné definujeme ji napˇríklad takto: 31


Pokud chceme pˇriˇradit definiˇcní obor vlastnosti, tak a tím zajistit, že bude využívána jen konkrétními tˇrídami, nadefinujeme ji takto:

A koneˇcnˇe chceme-li nadefinovat obor hodnot. Jako parametr lze uvést tˇrídu nebo standardní datový typ z XML schema19 : . .

Pokud chceme definovat individua, musíme minimálnˇe uvést, do které tˇrídy individuum patˇrí, jelikož jsou individua prvky tˇríd: <student rdf:ID="39415"/>

Tato ukázka definuje individuum ze tˇrídy student urˇcené jednoznaˇcnˇe cˇ íslem 39415. Vˇetšinou ale asi chceme o individuu uvést více informací než jenom identifikátor: <student rdf:ID="39415"> <jmeno rdf:datatype="&xsd;normalizedString">Martin <prijmeni rdf:datatype="&xsd;normalizedString">Fajmon <studuje_fakultu rdf:resource:"#FI"/> <ma_pristup rdf:resource="#FI_hala/> 19.

32

ˇ 3.3. OWL – SOU CASNÝ JAZYK WEBOVÝCH ONTOLOGIÍ Kromˇe klasického definování tˇríd mužeme ˚ definovat anonymní tˇrídy splnující ˇ urˇcitá omezení. Tˇemto omezením se rˇ íká lokální omezení, protože se vztahují na vlastnost jen pˇri použití s konkrétní tˇrídou. Globální omezení se vztahují na vlastnost jako takovou, tedy jeli užita s libovolnou tˇrídou. Lokání omezení muže ˚ být definováno jako omezení rozsahu hodnot nebo jako omezení mohutnosti. V pˇrípadˇe definice jako omezení rozsahu hodnot muže ˚ být použita jako argument tˇrída a hodnoty pak jsou instance této tˇrídy, nebo je jako argument použit rozsah datového typu. Následující ukázka definuje tˇrídu prvku˚ takových, že všechny hodnoty této jejich vlastnosti mužou ˚ být jen v daném rozsahu:

Tento pˇríklad odpovídá tˇrídˇe individuí, která vyuˇcují pouze matematické pˇredmˇety. Podobnˇe lze nadefinovat tˇrídu tak, že alesponˇ jedna z hodnot vlastnosti je v požadovaném rozsahu:

Tento pˇríklad odpovídá tˇrídˇe individuí, která vyuˇcují matematický pˇredmˇet, ale klidnˇe také i jiné pˇredmˇety. Lze také nadefinovat tˇrídu individuí, jejichž alesponˇ jedna hodnota vlastnosti je rovna konkrétní hodnotˇe. Napˇríklad individua uˇcící pˇredmˇet odkazovaný jako #Vypoctova_logika:

Pokud chceme definovat tˇrídu, ve které požadujeme, aby nˇekterá vlastnost mˇela omezený poˇcet hodnot, použijeme omezení mohutnosti. Napˇríklad tˇrída studentu, ˚ kteˇrí mají zapsáno nejvýše 10 pˇredmˇetu: ˚ 10

Pokud chceme omezit poˇcet ne shora, ale zdola, použijeme místo owl:maxCardinality tag owl:minCardinality. Tyto tagy lze použít i spoleˇcnˇe a omezit tak poˇcet shora i zdola. 33

ˇ 3.3. OWL – SOU CASNÝ JAZYK WEBOVÝCH ONTOLOGIÍ Omezení mužeme ˚ definovat globálnˇe hned pˇri definici vlastnosti. Lze mezi nˇe zaˇradit i omezení definice definiˇcního oboru a oboru hodnot, které jsme ukazovali již výše. Podívejme se, jak nadefinovat omezení, které rˇ íká, že každému individuu z definiˇcního oboru pˇrísluší právˇe jedna hodnota z oboru hodnot. Napˇríklad: že každý zamˇestnanec je právˇe v jedné kanceláˇri a v jedné kanceláˇri smí být více zamˇestnancu: ˚

Tímto nadefinujeme vlastnosti ma_kancelar jako definiˇcní obor zamˇestnance a jako obor hodnot kanceláˇre. Omezením owl:FunctionalProperty pak rˇ ekneme, že každý zamˇestnance muže ˚ nabývat jen jedné hodnoty z kanceláˇre, takže má jen jednu kanceláˇr. Pokud chceme nadefinovat opak, tedy že každému individuu z definiˇcního oboru pˇrísluší právˇe více hodnot z oboru hodnot, ale tyto hodnoty nesmí být pro dvˇe individua stejná. Využijeme tag owl:InverseFunctionalProperty:

ˇ Ríkáme tím, že každý zamˇestnanec smí mít klidnˇe i více telefonních cˇ ísel, ale nesmí mít dva zamˇestnanci stejné cˇ íslo. V OWL lze také nadefinovat klasické inverzní, symetrické a tranzitivní relace:

Ještˇe se podívejme, jak se definují axiomy, které vyjadˇrují nˇekterá základní tvrzení o tˇrídách nebo vlastnostech. Pro tvorbu hierarchické struktury využijeme tagy rdfs:subClassOf a rdfs:subPropertyOf. Napˇríklad chceme-li rˇ íci, že všichni uˇcitelé jsou zárovenˇ zamˇestnanci školy: 34


Vyjádˇrení disjunknosti tˇríd se provádí takto:

Definujeme studenta magisterského programu, který je podtˇrídou studentu, ˚ nesmí však být zárovenˇ studentem bakaláˇrského nebo doktorského programu. Tyto jednoduché ukázky možností jazyka OWL urˇcitˇe nemají za cíl zahrnout úplnˇe vše, co tento jazyk nabízí nebo se stát jeho kompletním tutoriálem. Pokud Vás syntaxe a možnosti tohoto jazyka zajímají opravdu podrobnˇe, hledejte informace na stránkách W3C konsorcia [13] nebo v pˇrímo v pˇrehledu možností jazyka [2]. Jazyk OWL nabízí tˇri podjazyky, které nabízí inkrementálnˇe ruzné ˚ možnosti: •

OWL Full – obsahuje maximum, co jazyk OWL nabízí. Umožnuje ˇ i neomezené použití RDF konstrukcí. Tˇrídy mohou být zárovenˇ i individua. Jak se uvádí pˇrímo na stránkách W3C konsorcia [13] je velice nepravdˇepodobné, že nˇejaký reasoner bude plnˇe podporovat všechny možnosti OWL Full.

•

OWL DL – již pˇrináší jistá omezení. Nelze používat všechna RDF vyjádˇrení a tˇrída nesmí být zárovenˇ individuem. Pˇri definici datových typu˚ nesmí být použity elementy owl:inverseOf, owl:InverseFunctionalProperty, owl:SymetricProperty a owl:TransitiveProperty. V definicích axiomu˚ se nesmí vyskytovat žádné nedefinované cˇ ásti. Mohou se zde stále vyskytovat nˇekteré prvky deskripˇcní logiky pocházející z RDF. Existují reasonery, které OWL DL podporují.

•

OWL Lite – je to nejnižší úrovenˇ složitosti. Nabízí definovat taxonomii a jednoduchá omezení. Zakazuje používání anonymních tˇríd u vˇetšiny elementu, ˚ u kardinality lze omezit cˇ íslo jen na 0 nebo 1. Nelze používat elementy owl:oneOf, owl:unionOf, owl:complementOf, owl:hasValue, owl:disjointWith, owl:DataRange a owl:Nothing. Tato verze jazyka je cˇ asto používaná, jelikož je pro ní snadnˇejší vytváˇret nástroje podporující OWL a je jednodušší pravidla pˇrevádˇet do jiných onˇ tologických jazyku. ˚ Casto nˇejaké editory vyšší verzi ani nepodporují. Pokud chceme vytváˇret nˇejaké obecné ontologie, pˇrevoditelné do jiných nástroju˚ a jazyku˚ je lépe používat jen tuto základní verzi.

Na konferenci odborníku˚ konané koncem roku 2005 ve mˇestˇe Galway v Irsku se rokovalo o první verzi jazyka OWL a o problémech, které s touto verzí jazyka nejˇcastˇeji vznikají pˇri tvorbˇe aplikací pracujících s OWL. Výsledkem této konference byl návrh rozšírˇ it jazyk OWL DL o malou množinu pravidel. Pro toto malé rozšíˇrení byl pˇrijat název 35

3.4. VŠESTRANNÉ ONTOLOGICKÉ EDITORY A REASONERY OWL 1.1. Tato nová verze OWL usnadnila hlavnˇe vývoj reasoneru, ˚ které dnes vˇetšinou podporují OWL 1.1. Byly pˇridány tˇri deklarace, které sice nepˇridají jazyku OWL více vyjadˇrovacích schopností, ale uˇciní jazyk lépe srozumitelný pro cˇ lovˇeka (DisjointUnion, NegativeObjectPropertyAssertion, NegativeDataPropertyAssertion). Byly pˇridány nové konstrukty deskripˇcní logiky, rozšíˇreny možnosti popisu datových typu. ˚ Bylo také umožnˇeno, že název tˇrídy, vlastnosti nebo individua muže ˚ být stejný. Tzn. v dokumentu je dovoleno mít tˇreba individuum, tˇrídu i vlastnost pojmenovanou napˇríklad jako student.

3.4

Všestranné ontologické editory a reasonery

V této podkapitole se podíváme na editory ontologií, které nejsou napsáné pro nˇejaký hlavní jazyk, ale podporují více ontologických jazyku˚ a obsahují jiné nástroje duležité ˚ pro práci s ontologiemi. 3.4.1 Protégé Protégé [4] je platforma s volnˇe dostupným kódem, která nabízí nástroje pro tvorbu ontologií. V dobˇe psaní tohoto textu je poslední stabilní verze 3.3.1. Platforma Protégé je vyvíjena Stanfordským centrem pro výzkum biomedicínské informatiky20 na Stanfordské univerzitˇe. Jádro Protégé implementuje velkou množinu modelovacích struktur a akcí podporujících tvorbu, vizualizaci a manipulaci s ontologiemi v mnoha formátech. Protégé je rozdˇelen do dvou podprojektu˚ Protégé-Frames editor a Protégé-OWL editor. Obˇe tyto aplikace jsou naprogramovány v jazyce JAVA, a proto potˇrebují mít pro spuštˇení nainstalováno bˇehové prostˇredí pro jazyk JAVA. Protégé-Frames editor umožnuje ˇ vytváˇret ontologie s hierarchickým zaˇrazením tˇríd, které popisují urˇcitou doménu. Protégé-Frames editor pracuje s Open Knowledge Base Connectivity protocol (OKBC)21 , pomocí kterého se muže ˚ pˇripojovat k znalostnímu serveru, který je také souˇcástí distribuce. Pojd’me se zamˇerˇ it na Protégé-OWL editor, který pracuje s jazykem OWL. Pomocí Protégé-OWL editoru lze vytváˇret ontologie pro sémantický web. Protégé-OWL editor umožnuje ˇ tyto hlavní akce: •

Naˇcítání a ukládání otologií ve formátech OWL a RDF.

•

Editaci a vizualizaci tˇríd a vlastností, editaci individuí.

•

Definice pravidel i pomocí anonymních tˇríd.

•

Spouštˇení reasoneru˚ nad definovanými ontologiemi.

20. 21.

36

3.4. VŠESTRANNÉ ONTOLOGICKÉ EDITORY A REASONERY Protégé-OWL editor používá primárnˇe svuj ˚ formát souboru˚ s pˇríponou .pprj. Kromˇe tohoto formátu samozˇrejmˇe umí otvírat i OWL soubory s pˇríponou .owl. Do tˇechto dvou formátu˚ umí soubory i ukládat. Protégé-OWL editor obsahuje pro tvorbu ontologií pruvodce. ˚ Protégé nabízí pro programátory i své API pro práci s ontologiemi. Pokud máme ontologii vytvoˇrenu, umí Protégé automaticky vygenerovat šablony kódu v jazyce JAVA pro práci s danou ontologií. Souˇcástí distribuce Protégé-OWL je i webové rozhraní WebProtege, ve kterém lze prohlížet ontologie uložené na serveru a vytváˇret nebo editovat jednotlivé instance tˇríd v ontologii. Dalo by se rˇ íci, že je takto pˇres web zpˇrístupnˇena databáze, jejíchž metadata jsou nadefinována ontologií a dají se editovat záznamy. Editovat tˇrídy a vlastnosti v tomto rozhraní nejde.

Obrázek 3.4: Protégé-OWL editor.

3.4.2 SWOOP SWOOP je druhým všestranným editorem, který je zminován ˇ jako dobrý nástroj v mnoha cˇ láncích a publikacích o ontologiích. SWOOP byl vyvíjen v laboratoˇri MIND (Maryland Information and Network Dynamics Laboratory)22 Marylandské univerzity. Tato labora22.

37

3.4. VŠESTRANNÉ ONTOLOGICKÉ EDITORY A REASONERY toˇr vývoj zastavila a nyní je SWOOP vyvíjen jako Open Source. Aktuální stabilní verze je 2.2.1. SWOOP není rozhodnˇe zdaleka tak komplexní nástroj jako Protégé, nicménˇe základní editaci ontologií a pouštˇení reasoneru nad ontologiemi zvládne. Umí pracovat se soubory vlatního formátu s pˇríponou .swo, ale samozˇrejmˇe umí naˇcítat i formáty .owl, .rdf., .xml a .txt. SWOOP je také napsán v jazyce JAVA a musím rˇ íci, že se v mém prostˇredí (Windows Vista a JRE 1.6.0 update 3) choval dost nestabilnˇe. Napˇríklad z nˇejakých externích OWL souboru˚ ontologii nenaˇcetl vubec ˚ a pokud naˇcetl, tak se hned po naˇctení zasekl a pomohlo jen násilné ukonˇcení. Mohl jsem editaci tedy vyzkoušet jen po založení nové vlastní ontologie a v tomto pˇrípadˇe musím zase rˇ íci, že mi editace pˇrišla o hodnˇe intuitivnˇejší než v jiných editorech vˇcetnˇe Protégé. Editace je založena na zobrazení hypertextu a tudíž rozhraní nˇekdy dost pˇripomíná editaci ve webovém rozhraní. Pokud pˇrehlédneme zmínˇenou nestabilitu, která ale muže ˚ být zpusobena ˚ pomalejším vývojem (je tedy možné že ve starších verzích JRE nebo Windows bˇeží SWOOP bez problému) ˚ a bude v dalších verzích urˇcitˇe odladˇena, tak je SWOOP rozhodnˇe dobrý editor.

Obrázek 3.5: Editor SWOOP.

38

3.4. VŠESTRANNÉ ONTOLOGICKÉ EDITORY A REASONERY 3.4.3 Reasonery Jak jsme si již rˇ íkali v podkapitole 3.2, tak reasonery jsou softwarové nástroje, které dokáží odvodit vztahy v ontologii obsažené, ale výslovnˇe neuvedené. Pojd’me se struˇcnˇe podívat na nejznámˇejší reasonery pro jazyk OWL. Pellet23 je Open Source reasoner, který zvládne úrovenˇ jazyka OWL DL a plnˇe podporuje OWL 1.1. Je vyvíjen v jazyce JAVA a komerˇcnˇe podporován spoleˇcností Clark & Parsia LLC24 . Existuje on-line demo25 , kde si lze možnosti toho reasoneru vyzkoušet. Pellet napˇríklad umí zjistit jakou úrovenˇ jazyka (Lite, DL, Full) OWL ontologie využívá nebo zda je konzistentní. Dokáže zanalyzovat a zobrazit kompletní hierarchii tˇríd a k nim patˇrícím individuí nebo spouštˇet nad ontologií ruzné ˚ dotazy a zobrazovat výsledky. Pellet muže ˚ fungovat jako program v pˇríkazové rˇ ádce a nebo nabízí programátorum ˚ API pomocí nˇehož si lze vytvoˇrit libovolné uživatelské rozhraní. Pellet také nabízí pˇrímou integraci do editoru˚ Protégé a SWOOP. FaCT++26 je novou verzí puvodního ˚ reasoneru FaCT (Fast Classification of Termino27 logies) pro jazyk OWL DL. FaCT je Open Source klasifikátor deskripˇcní logiky napsaný v Common Lisp. Projekt spravuje Dmitry Tsarkov z univerzity v Manchesteru28 . Existuje server, kde FaCT bˇeží jako služba a lze k nˇemu pˇristupovat z klientských poˇcítaˇcu. ˚ FaCT++ využívá puvodní ˚ osvˇedˇcené algoritmy FaCT, ale je napsán v jazyce C++ a tím je jeho API pˇrístupnˇejší. FaCT++ plnˇe podporuje OWL 1.1 a možnosti má obdobné jako Pellet. Racer (Renamed Abox and Concept Expression Reasoner)29 je navržen jako serverová aplikace funkˇcní na Linuxu, Windows a Mac OS. V dobˇe psaní textu je ve vývoji verze RacerDLL pro jazyk JAVA. Na vývoji spolupracuje univerzita Motreal30 , Hamburská technická univerzita31 a Racer tým32 . Racer si zakládá hlavnˇe na velkých možnostech dotazování nad ontologiemi a využívá pro tyto úˇcely vlastní nRQL (new Racer Query Language) dotazovací jazyk. K reaosneru Racer existuje uživatelské rozhraní zvané RacerPorter, které se pˇripojuje pˇres web k zadané instalaci serveru Racer. Velice hezké srovnání výkonu tˇechto tˇrí reasoneru˚ lze najít na stránkách33 již výše zmínˇené laboratoˇre MIND.

23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.

39

3.5. PRAKTICKÉ VYUŽITÍ ONTOLOGIÍ

3.5

Praktické využití ontologií

Akademický výzkum ontologií pˇredbíhá praxi, která dospívá k využívání ontologií jen pozvolna. Výzkum jde tak rychle, že je klidnˇe možné, že již nˇejaké informace v dobˇe tisku tohoto textu ani nemusí být aktuální. Pokud se již nˇejaký projekt využívající ontologii v praxi objeví, tak cˇ asto nepracuje s nejnovˇejšími ontologickými jazyky a nemluvím ani o vazbˇe na aktuální vývoj sémantického webu. Není se ale cˇ emu divit. Nejprve je totiž potˇreba firmy z praxe pˇresvˇedˇcit, že má cenu investovat do nových technologií. Sice je fakt, že nemá cenu investovat, pokud stávající rˇ ešení funguje a vydˇelává. Ale co kdyby to nové rˇ ešení fungovalo lépe a vydˇelávalo ještˇe více? V tomto smˇeru jsou záslužné aktivity již zminovaného ˇ IDABC [11]. Praktické využití mají ontologie hlavnˇe v tˇechto oblastech: •

Znalostní management ve firmách. Aby organizace fungovala efektivnˇe, je tˇreba zajistit, aby se informace a znalosti neztrácely, ale vˇcas se dostávaly k tˇem pracovníkum, ˚ kteˇrí je mohou využít. S pomocí ontologie je možné zachytit vˇecnou podstatu znalostí, a tím jednak zabezpeˇcit jejich konzistenci, jednak usnadnit jejich vyhledání.

•

Elektronické obchodování – ontologie muže ˚ usnadnit vyhledání požadovaného produktu zákazníkem, ale také vyhledání potenciálního partnera nebo také zautomatizovat proces sjednání obchodních podmínek.

•

Zpracování pˇrirozeného jazyka – terminologické ontologie mohou napomáhat napˇr. pˇri pˇrekladu nebo automatické sumarizaci textu. ˚

•

Inteligentní integrace informací - ontologie muže ˚ sloužit jako zastˇrešení datových schémat distribuovaných zdroju˚ na vysoké úrovni abstrakce.

•

Pojmové vyhledávání informací jako vylepšení stávajících internetových vyhledávaˇcu. ˚

•

Sémantické webové portály konstruované polo-automaticky na základˇe metadat od poskytovatelu˚ informace.

•

Inteligentní výukové systémy.

40

Kapitola 4

Webový portál pro správu a distribuci ontologií Souˇcástí této práce je navrhnout rˇ ešení pro popis a reprezentaci znalostí. Pˇri pˇredchozím studiu nástroju˚ pro formální reprezentaci ontologií jsme si prošli stávající rˇ ešení, která jsou dostupné zdarma nebo mají otevˇrený zdrojový kód. Vysvˇetleme si nejprve nˇekolik základních pojmu˚ a postupu˚ potˇrebných pro volbu mého rˇ ešení.

4.1

Proˇc používat a vyvíjet Open Source rˇešení?

OSS (Open Source software) [10] je poˇcítaˇcový software s otevˇreným zdrojovým kódem. Otevˇrenost zdrojového kódu znamená jak technickou dostupnost kódu, tak legální dostupnost - licenci software, která umožnuje ˇ pˇri dodržení jistých podmínek uživatelum ˚ zdrojový kód využívat, napˇríklad prohlížet a upravovat. Souvisejícím tématem je svobodný software (free software). Tento pojem prosazuje Free Software Foundation1 pro podmnožinu OSS dostupnou pod svobodnou licencí, která musí oproti Open Source licenci splnovat ˇ ještˇe další podmínky, napˇríklad musí umožnovat ˇ uživatelum ˚ šíˇrit díla odvozená z puvodního ˚ programu. Každý software obsahuje chyby a pokud si myslíme, že ne, tak o nich akorát ještˇe nevíme. Výhodou OSS je to, že jelikož je zdrojový kód volnˇe dostupný a vˇetšinou stažitelný z internetu, tak muže ˚ pˇrípadné chyby hledat velká skupina lidí (nebo i automatických pomucek). ˚ Pokud je již OSS distribuován, je tedy vˇetší šance odhalení chyby než u komerˇcního software. Na druhou stranu zase komunity, které cˇ asto stojí za vývojem nˇejakého OSS, nevyužívají vždy doporuˇcené postupy pro vývoj software, které jsou (nebo by mˇely být) používány ˇ v komerˇcním vývoji software. Casto cˇ ásti OSS programují lidé, kteˇrí mají programování jen jako koníˇcka. Já trochu jako nevýhodu v OSS vidím cˇ asto v tom, že zpoˇcátku obsahuje asi více chyb než komerˇcní software, nebo je kód nepˇrehledný. Komunity toto rˇ eší tím, že pˇred vydáním ostré verze je velice dlouhý cˇ as dostupná beta verze, kterou lze testovat. Druhou nevýhodou je to, že útoˇcník muže ˚ najít chybu v kódu dˇríve než uživatelé a muže ˚ ji využít k útoku. Klady OSS ale pˇrevažují nad zápory. Dnes se považuje za obecnˇe výhodnˇejší, když jsou informace dostupné všem, i za tu cenu, že jsou dostupné útoˇcníkum. ˚ Alesponˇ u populárních programu˚ s velkou základnou uživatelu˚ a vývojáˇru˚ lze pˇredpokládat, že uživatelská strana má výraznˇe vˇetší prostˇredky (pˇredevším více cˇ asu kvalifikovaných lidí) než útoˇcník. Nejvˇetší výhodou OSS je tedy to, že je úplnˇe zdarma. Za OSS si nelze úˇctovat žádné li1.

41

4.2. DOMÉNOVÉ ONTOLOGIE cenˇcní poplatky. Lze si ovšem úˇctovat poplatky napˇríklad za poradenství nebo konkrétní implementaci a instalaci rˇ ešení u zákazníka. Další výhodou je to, že není uživatel vázán na jednu konkrétní spoleˇcnost, která software vyvinula. OSS si muže ˚ uživatel sám upravovat a spravovat nebo najít libovolného správce, který nemusí být smluvním dodavatelem výrobce. Vývoj OSS velice podporuje i Evropská unie. Považuje OSS jako praktický nástroj pro navrhování rˇ ešení, které podporují obecnou dostupnost v demokratické informaˇcní spoleˇcnosti. Pak je pro menší firmy jednodušší prosadit se na trhu a roste tím zdravá konkurence. Zárovenˇ je lépe realizovatelná interoperabilita. Více o doporuˇceních Evropské unie a programu IDABC jste se mohli doˇcíst v první kapitole. Obˇcané mají právo na volnou dostupnost informací od organizací z veˇrejného sektoru. Stejnˇe tak mají právo vˇedˇet, jak jsou tyto informace vytváˇreny, zpracovávány a uchovávány. Toto se dá chápat i tak, že mají obˇcané právo vidˇet zdrojové kódy softwarového rˇ ešení, které informace uchovává. OSS je tedy pro tento pˇrípad rˇ ešení, které je pˇrímo ideální, protože má volnˇe dostupný zdrojový kód. Bohužel cˇ asto doprovází zavedení Open Source rˇ ešení odpor ze strany uživatelu, ˚ kteˇrí se musí nauˇcit práci s jiným software. Vˇetšinou se zatím totiž používá všude ve státní správˇe komerˇcní rˇ ešení. Proto je potˇreba zavádˇet OSS pozvolna. Dobré je využívat OSS hlavnˇe pˇri vzniku nových projektu. ˚ Existuje však celá rˇ ada OSS licencí. Napˇríklad nejpoužívanˇejší GPL (General Public License) od Free Software Foundation ochranuje ˇ použití OSS v libovolném komerˇcním produktu. Proto je duležité ˚ pˇred zavedením OSS pˇredem zvážit aspekty z toho plynoucí. V mém rˇ ešení, které bude souˇcástí této diplomové práce, tedy budu z výše uvedených duvod ˚ u˚ využívat OSS pro vývoj rˇ ešení. Stejnˇe tak bude toto hotové rˇ ešení také dostupné jako OSS.

4.2

Doménové ontologie

Z 3. kapitoly víme, že doménové ontologie jsou daleko nejpoužívanˇejším typem ontologií. Jejich pˇredmˇetem je vždy urˇcitá specifická vˇecná oblast, vymezená šíˇreji (napˇr. celá problematika medicíny nebo fungování firmy) cˇ i úžeji (problematika urˇcité choroby, poskytování úvˇeru apod.). Budeme tedy tomuto vymezení rˇ íkat doména a ontologii, která popisuje objekty v zábˇeru tohoto vymezení, doménová ontologie [6]. V doménové ontologii se snažíme popsat objekty z dané domény. Základem jsou individua, jež potˇrebujeme popsat. Mezi individui v rámci dané domény pak cˇ asto potˇrebujeme vyhledávat. Stejnˇe tak potˇrebujeme najít, jaké jsou mezi nimi vztahy. Nˇejaké zdroje cˇ asto uvádí, že individua již nejsou souˇcástí ontologií, ale chovají se jen jako data, která jsou danými ontologiemi popisovány. Individua zaˇrazujeme do tˇríd, které jsou vˇetšinou uspoˇrádány hierarchicky. A toto hierarchické uspoˇrádání je asi nejduležitˇ ˚ ejší cˇ ást doménové ontologie. Samozˇrejmˇe opˇet pˇriˇrazujeme tˇrídám vlastnosti. Tyto vlastnosti zdˇedí individua z dané tˇrídy a k tˇemto individuích již pˇriˇrazujeme jednotlivé hodnoty. Ukažme si jednoduchý pˇríklad velmi malé cˇ ásti doménové ontologie. Na vrcholu hierarchie tˇríd máme vždy tu nejobecnˇejší tˇrídu, v tomto pˇrípadˇe Dopravní prostˇ redek. Jeli42

4.2. DOMÉNOVÉ ONTOLOGIE

Obrázek 4.1: Ukázka cˇ ásti doménové ontologie. kož je omezena ontologie na dopravní prostˇredky, nadtˇrídou tˇrídy Dopravní prostˇ redek už je jen tˇrída Thing. Tˇrídy Osobní automobil a Nákladní automobil jsou pomocí relací zaˇrazeny jako podtˇrídy nejvyšší tˇrídy Dopravní prostˇ redek. V tomto pˇríkladu máme na nejnižší úrovní tˇrídy Škoda Octavia a Škoda Fabia. Nˇejaké ontologie dovolují mít u každé tˇrídy jen jednu nadtˇrídu, ale existují i takové, které dovolují mít více nadtˇríd. Toto je první pˇríklad, žádná tˇrída nemá více jak jednu nadtˇrídu. Tˇrídy v této ontologii ještˇe mužeme ˚ popsat atributy. Každý atribut bude mít název a hodnotu. Atributy ukládají informace, které jsou specifické jen pro danou tˇrídu. Napˇríklad u tˇrídy Škoda Fabia mužeme ˚ mít tˇreba tyto atributy: Název: Škoda Fabia Poˇ cet dveˇ rí: 5 Poˇ cet stupˇ n˚ u pˇ revodovky: 5 ˇ Razení: manuální

Samozˇrejmˇe vše závisí na druhu domény, kterou ontologie popisuje a na úˇcelu využití a v neposlední rˇ adˇe i na autorovi ontologie. Ne každý by tˇreba doménovou ontologii vytvoˇril pro danou doménu úplnˇe stejnˇe. Záleží hlavnˇe na komplexnosti a úhlu pohledu, který má daná ontologie na danou doménu nabízet. Rozdˇelení ontologií na jednotlivé domény je velice výhodné a dá se rˇ íci, že i nutné. Nˇekteré termíny mají totiž v ruzných ˚ doménách ruzné ˚ významy, vlastnosti a atributy. Napˇríklad termín karta má v ruzných ˚ doménách ruzné ˚ významy. Budeme-li zpracovávat doménu o pokeru, bude mít význam hrací karty. V doménˇe o poˇcítaˇcích bude mít význam rozšiˇrující hardwarové karty a v doménˇe o bankovnictví se bude prezentovat jako kreditní karta. Proto je vždy duležité ˚ pˇri zpracování ontologie vˇedˇet, jakou doménu 43

4.3. TOP-LEVEL ONTOLOGIE daná ontologie popisuje. V jazyce OWL je proto duležité, ˚ aby byla každá doménová ontologie oznaˇcena vlastním jmenným prostorem. Tím pak zajistíme to, že napˇríklad vyhledávací služba pracující s více doménami rozliší správnˇe jeden termín.

4.3

Top-level ontologie

Víme, že oproti doménovým ontologiím zachycují top-level ontologie obecné zákonitosti, které platí napˇríˇc všemi doménami. Napˇríklad problematiky cˇ asu, vzájemné pozice objektu˚ (topologie), skladby objektu˚ z cˇ ástí apod. Pokud máme více doménových ontologií, tak lze využít tyto top-level ontologie jako základ taxonomické struktury každé další doménové ˇ ontologie. Rešení, které budeme tedy nadále v této práci uvažovat, bude umˇet pracovat i s top-level ontologiemi, na které se lze pak odkazovat v jednotlivých doménových ontologií.

4.4

Webový portál jako úložištˇe ontologií

Pˇredstavme si webový portál, který by sloužil jako úložištˇe pro ruzné ˚ at’ již doménové nebo top-level ontologie a poskytoval by tyto ontologie aplikacím tˇretích stran. Pˇri pˇredchozí studii nástroju˚ pro práci s ontologiemi v 3. kapitole jsme si pˇredstavili jazyky pro formální representaci ontologií a zárovenˇ jsme si ukázali nástroje pro editaci ontologií. Vidˇeli jsme, že klasické starší ontologické jazyky cˇ asto spravuje a nástroje pro nˇe vyvíjí jen jedna skupina sdružená okolo nˇejaké univerzitní organizace nebo dokonce komerˇcní spoleˇcnosti. Za poskytované technologie a ontologie si cˇ asto pak nechají platit. Toto je v rozporu s doporucˇ ením IDABC, kdy by mˇeli mít obˇcané zdarma pˇrístup k informacím. A dle mého názoru jsou i ontologie informacemi. Proto by mˇel tento webový portál být uvolnˇen jako Open Source software, aby ho mohly využívat i veˇrejné instituce na svých serverech. Stejnˇe tak by v tomto pˇrípadˇe mˇely být i poskytované informace, tedy uložené ontologie, volnˇe ke stažení všemi obˇcany EU. Tyto ontologie musí být pˇrístupny v takovém formátu, aby je obˇcané mohli pohodlnˇe prohlížet okem, ale aby je mohly automaticky stahovat i aplikace jiných institucí a firem. Pokud zvolíme tuto strategii, není problém pro instituci nebo firmu, která rˇ ešení takového webového portálu nasadí, vybírat poplatky napˇríklad za poradenství, jak zpracovat ontologie stažené z portálu. Nebo lze pak komerˇcnˇe vyvíjet nástroje a aplikace na míru pro jednotlivé firmy. Tyto nástroje by si automaticky stahovali vždy aktuální ontologie z daného webového portálu. Takže by to byla taková on-line služba, která by mˇela nejvˇetší smysl hlavnˇe pˇri kombinaci s jinými nástroji. Pˇri pruzkumu ˚ nástroju˚ pro práci s ontologiemi ˇ jsem zatím na podobné zdarma dostupné rˇ ešení v rámci Ceské republiky nenarazil. Existuje projekt OntoWeb [5], který však slouží jako úložištˇe informací a cˇ lánku˚ o ontologicíh a ne jako jejich distribuˇcní kanál. Jeho vývoj byl ukonˇcen a navázal na nˇej projekt Knowledge Web [7] se stejným zamˇerˇ ením. Portál by mohl sloužit jako univerzální úložištˇe znalostí na bázi ontologií. Portál bude pˇripraven pro aplikaˇcní moduly, funkce a algoritmy tˇretích stran, které budou moci data z ontologií zpracovávat. Jelikož bude uvolnˇen jako Open Source, nebude pak problém si ho libovolnˇe rozšiˇrovat o další funkce pro specifické aplikaˇcní problémy. 44

4.4. WEBOVÝ PORTÁL JAKO ÚLOŽIŠT Eˇ ONTOLOGIÍ Samozˇrejmˇe vytvoˇrení ideální ontologie v dané doménˇe nebo té, která by snad popisovala celý svˇet, je nemožné. Každý by za ideální ontologii považoval nˇeco jiného. Nad tím, jak správnˇe vytváˇret ontologie se vedou debaty a dalo by se rˇ íci, že k jednotnému rˇ ešení se asi ještˇe dlouho nedospˇeje. Ale toto téma je tak obsáhlé, že by dalo na celou samostatnou práci. Tvorba dobré a kvalitní ontologie vˇetšinou vyžaduje souˇcinnost mnoha subjektu. ˚ Náš portál tedy nesmí omezovat v dané doménˇe možnost mít více verzí ontologií pro jednu doménu. Každý stejnˇe pojmenovaný objekt pak klidné muže ˚ být v každé této verzi a každá verze muže ˚ být od jiného autora, který si za ní stojí. Uživatel, který bude tyto data využívat už si sám dokáže zvolit, která ontologie mu pro zpracování více vyhovuje. Myšlenka staví na tom, že ontologie uložené na portálu si budou vytváˇret sami uživatelé, kteˇrí se budou dˇelit do rolí. Nˇejací uživatelé, kteˇrí budou v roli administrátoru˚ budou moci nastavovat práva pro ostatní uživatele. Dále zde budou správci ontologií a nakonec ti, kteˇrí budou mít právo editace tˇreba jen jedné konkrétní ontologie. Anonymní uživatelé budou smˇet všechny ontologie jen prohlížet pˇrípadnˇe stahovat ve formátu OWL. Portál pro autory nebude nabízet jen importy hotových ontologií ve formátu OWL, ale i nˇejaké jednoduché prvky editace nejen v textové podobˇe. Portál bude nabízet ontologie pro aplikace znalostního managementu, elektronického obchodování, zpracování pˇrirozeného jazyka, integrace a kategorizace informací z distribuovaných zdroju, ˚ vyhledávání, sémantické weby, inteligentní výukové systémy. Prakticky témˇerˇ každý IT projekt rˇ eší individuální problém a principiálnˇe nemuže ˚ v rámci vlastních možností realizovat podpurný ˚ znalostnˇe-orientovaný systém, který by adekvátním zpuso˚ bem uplatnil velmi moderní a nyní již možné algoritmy znalostnˇe-orientovaných aplikací. Souˇcasnˇe však platí, že prakticky každý projekt, nezávisle na oboru lidské cˇ innosti, muže ˚ získat integrací takového systému bezprecedentní pˇridanou hodnotu, jež ovlivní zpusob ˚ práce s informacemi jak na úrovni jednotlivých uživatelu, ˚ tak na úrovni globální spoleˇcnosti. Samozˇrejmˇe pouhé vytvoˇrení a nabízení ontologií nestaˇcí. Pro podchycení zájmu koncových uživatelu˚ je tˇreba ontologie doplnit o popisy, které aplikace a jak mohou ontologii využívat, a nabídnout uživatelum ˚ nejen pˇrístup k ontologii jako takové, ale dát jim k dispozici již zpracované informace a existující algoritmy, funkce a moduly ve formˇe odpovídajících technických rozhraní, metodických popisu˚ a návodu. ˚ Zde už je prostor pro produkty a aplikace tˇretích stran, které se mohou k portálu pˇripojovat nebo ho sami rozšíˇrit o nové funkce a nasadit na vlastním serveru. Portál by mˇel být samozˇrejmˇe velice jednoduchý na ovládání pro autory ontologií. Tento požadavek splníme tím, že nebude nabízet žádné zbyteˇcné funkce, které nejsou potˇreba cˇ istˇe k editaci a zpˇrístupnování ˇ ontologií. Tím se také vyhneme tomu, že rˇ ešení bude dˇelat sice jen malou cˇ ást celku (ten zbytek obstarají aplikace tˇretích stran), ale bude ji dˇelat rychle a bezchybnˇe. Aby byl pˇrístup pro aplikace k ontologiím na portálu co nejrychlejší a nejjednodušší, budou ontologie stažitelné z portálu pod daným názvem pˇrímo. Z výkonnostního hlediska bude tedy lepší, pokud pˇri ukládání ontologie bude ihned vytvoˇren v adresáˇrové struktuˇre portálu soubor OWL, který bude pˇrímo pˇrístupný pˇres webový server. Formát OWL byl vybrán, protože má v dnešní dobˇe pro zpracování ontologií na webu nejvˇetší potenciál a 45

4.4. WEBOVÝ PORTÁL JAKO ÚLOŽIŠT Eˇ ONTOLOGIÍ

Obrázek 4.2: Schéma myšlenky ontologického portálu. je jednoduše zpracovatelný pro automatické nástroje. Dají se tedy jednodušeji programovat nadstavbové aplikace využívající ontologie z portálu. Tuto vlastnost starší klasické ontologické jazyky nenabízejí.

46

Kapitola 5

Identifikace požadavku˚ a návrh webového portálu 5.1

Technologie a architektura

V dnešní dobˇe je velkým trendem pˇrenášet puvodnˇ ˚ e desktopové aplikace na web. A novˇe psané aplikace se cˇ asto píší pˇrímo pro webové rozhraní. Webové rozhraní zatím nemá stejné možnosti jako uživatelské rozhraní napsané jako desktopová aplikace. Nicménˇe možnosti se stále rozšiˇrují a pˇricházejí nové webové technologie. Pˇrínosy webového rozhraní ale pˇrevažují nad jeho zápory. Hlavním pˇrínosem je to, že uživatel si nemusí aplikaci nosit sebou, ale má ji dostupnou na webu z libovolného poˇcítaˇce pˇripojeného na internet. S tím souvisí i další pˇrínos a sice, že ani vývojáˇr nemusí aplikaci distribuovat k uživateli na jeho poˇcítaˇc, ale spravuje ji jen na jednom centrálním serveru. Oprava chyb a instalace nových verzí je pak o hodnˇe rychlejší, jednodušší a levnˇejší. Posledním velkým pˇrínosem je jednodušší vývoj aplikací pro více platforem. Výstup aplikace je totiž v tomto pˇrípadˇe jako stránka HTML a prohlížeˇc HTML je v dnešní dobˇe na každé vyspˇelejší platformˇe. Po zhodnocení všech tˇechto pˇrínosu˚ byla jen potvrzena myšlenka z pˇredchozí kapitoly, že navrhované rˇ ešení bude komunikovat s uživatelem pˇres webové rozhraní. Návrhy jak desktopových, tak webových aplikací jsou typicky rˇ ešeny tˇrívrstvou architekturou. Na webových systémech lze jednotlivé vrstvy identifikovat velice snadno. Vrstvu nejnižší úrovnˇe tvoˇrí nˇejaký databázový server. Využívají se vˇetšinou klasické relaˇcní databázové platformy, ale stále více se pro nˇejaké speciální pˇrípady využívají objektové nebo XML databáze. Nejznámˇejšími a nejpoužívanˇejšími Open Source databázemi na webu jsou MySQL1 , Firebird SQL2 a Postgre SQL3 . Stˇrední vrstvu tvoˇrí aplikaˇcní servery a vlastní aplikace. Nejpoužívanˇejším Open Source aplikaˇcním serverem je Apache4 v kombinaci s moduly webových skriptovacích jazyku. ˚ Nejznámˇejšími skriptovacími jazyky pro Open Source platformy jsou PHP5 , JSP6 a Mono ASP.NET7 (velice kvalitní a funkˇcní port známého jazyka do Open Source prostˇredí). PHP je asi nejpoužívanˇejší, ale je pro vývoj webové aplikace nejménˇe robustní a málo bezpeˇcné, takže se hodí spíše pro menší projekty, které musí být naprogramované rychle. Poslední presentaˇcní vrstva je v tomto pˇrípadˇe nejˇcastˇeji tvoˇrena 1. 2. 3. 4. 5. 6. 7.

47

5.1. TECHNOLOGIE A ARCHITEKTURA internetovým prohlížeˇcem, kterým uživatel používá. 5.1.1 Presentaˇcní vrstva Jelikož bylo vybráno rˇ ešení, které bude fungovat pˇres webové rozhraní, podívejme se tedy nejprve na zvolené technologie na té nejvyšší prezentaˇcní vrstvˇe, které hrají pro koneˇcného uživatele tu nejvˇetší roli. Bohužel v tomto pˇrípadˇe je to jediná vrstva, kde si nemužeme ˚ zvolit klienta sami, ale volí si ho sám uživatel v podobˇe webového prohlížeˇce. Je tedy duležité ˚ navrhnout systém tak, aby podporoval co nejvˇetší množinu webových prohlížeˇcu. ˚ Bohužel toto není jednoduchý úkol, jelikož každý prohlížeˇc interpretuje obecné standardy jinak. Nˇekdy tedy nepomuže ˚ ani dodržování standardu˚ W3C [13], jelikož jsou prohlížeˇce, které tyto standardy neumí správnˇe interpretovat (napˇr. Internet Explorer). Navrhneme a implementujeme tedy portál tak, aby byl výsledný HTML kód validní a zárovenˇ byl správnˇe reprezentován ve tˇrech nejpoužívanˇejších prohlížeˇcích v aktuálních verzích (Windows Internet Explorer 7, Mozilla Firefox 2.0 a Opera 9). Po provedené studii možných verzí HTML a zjištˇení, jak které prohlížeˇce podporují ruzné ˚ verze HTML byla vybrána verze XHTML 1.0 Transitional [13], která je v souˇcasných prohlížeˇcích podporována nejlépe. Výsledný HTML výstup portálu by mˇel být tedy validní XHTML 1.0 Transitional. 5.1.2 Aplikaˇcní vrstva Aplikaˇcní vrstva by mˇela být plnˇe postavená na technologiích, které jsou zdarma. I když má z výše uvedených jazyku˚ nejvˇetší podporu ze strany vývojáˇru˚ PHP a je pro nˇej nabízen nejˇcastˇeji webový hosting, pˇresto v tomto pˇrípadˇe padla volba jasnˇe na technologii JSP. JSP je pomocný skriptovací jazyk založený na jazyce JAVA. Výsledný kód je nejprve pˇreložen do servletu, který je pak spuštˇen a poslán jako HTML výstup uživateli. Zde jsou hlavní duvody ˚ proˇc volba padla jasnˇe na JSP: •

V jazyce JAVA je napsáno nejvíce software a knihoven pro práci s jazykem OWL. JAVA tedy zaruˇcí do budoucna snadnou rozšiˇritelnost o nové funkce.

•

JSP je robustnˇejší a bezpeˇcnˇejší než nejpoužívanˇejší PHP. Lze využívat již stávající knihovny napsané pro aplikace v jazyce JAVA.

•

Od roku 2007 je JAVA publikovaná v rámci projektu OpenJDK i pod licencí GNU GPL 2, tedy i jako Open Source. JSP funguje jako modul v Open Source webovém serveru Apache.

•

Jsou dostupná kvalitní vývojová prostˇredí zdarma.

•

Snadná pˇrenositelnost mezi platformami.

Jen dodám, že po vyzkoušení nˇekolika vývojových prostˇredí pro JSP, která jsou dostupná zdarma, bylo nakonec vybráno jako nejlepší NetBeans IDE 6.18 . Pro naˇcítání a ukládání XML 8.

48

5.2. SPECIFIKACE A NÁVRH souboru˚ s ontologiemi, byla vybrána knihovna Jena9 , ze které se využije její OWL API. 5.1.3 Databázová vrstva Pro volbu technologie na databázové vrstvˇe byla jako jedno z nejduležitˇ ˚ ejších kritérií uvažována podpora ze strany JSP a samozˇrejmˇe, aby databázová platforma byla dobˇre udržovatelná a rozšíˇrená mezi uživateli. Podpora pˇripojení z jazyka JAVA je u všech tˇrí výše zmínˇených databázových platforem pro naše úˇcely dostaˇcující. Z hlediska jednoduché správy a rozšíˇrenosti se jevilo jako nejlepší využít MySQL. Sice nemá MySQL tolik možností jako Firebird SQL nebo Postgre SQL, ale rozhodnˇe je nejrozšíˇrenˇejší a nejvíce podporované ze strany vývojáˇru. ˚ Pro potˇreby našeho portálu je MySQL nejlepší volbou. Zde jsou hlavní du˚ vody: •

Open Source pro nekomerˇcní užití zdarma.

•

Funguje skoro na všech platformách.

•

Velká podpora ze strany vývojáˇru˚ a uživatelu, ˚ nainstalováno na každém webovém hostingu.

•

Oproti ostatním databázovým platformám, které jsou dostupné zdarma, je velice rychlé, což je pro webový portál vynikající vlastnost.

5.2

Specifikace a návrh

Pˇredtím než byl proveden vlastní návrh a implementace portálu bylo nejprve potˇreba analyzovat a specifikovat požadavky na jeho funkcionalitu. Nejprve byly analyzovány dostupné dokumenty IDABC10 , které obsahují doporuˇcení pro evropský interoperabilní rámec. Cílem bylo specifikovat požadavky tak, aby portál dodržoval tato doporuˇcení. Dále byla provedena identifikace potˇreb uživatelu˚ portálu a to jak z hlediska potˇreb pro uživatelské rozhraní, tak z hlediska funkˇcnosti. Vlastní analýza a návrh pak probíhaly pomocí standardních metodik objektového návrhu pomocí UML [7]. Bylo vyzkoušeno nˇekolik Open Source modelovacích UML nástroju. ˚ Nakonec byl jako nejvhodnˇejší vybrán software StarUML11 , který podporuje všechny potˇrebné typy diagramu˚ potˇrebné pro UML. O vícevrstvé architektuˇre navrhovaného systému jsme si již rˇ íkali výše v této kapitole. Byl vypracován diagram nasazení, který ukazuje, jak bude taková architektura vypadat. Vidíme ho na obrázku 5.1. Aby mohly být identifikovány uživatelské role a funkce portálu, byl vytvoˇren diagram pˇrípadu˚ užití (obrázek 5.2). Na základˇe diagramu užití byly identifikovány cˇ tyˇri základní uživatelské role: 9. 10. 11.

49

5.2. SPECIFIKACE A NÁVRH

Obrázek 5.1: Diagram nasazení. •

Neregistrovaný uživatel

•

Autor ontologie

•

Správce ontologie

•

Administrátor

Systém je tedy navržen tak, že bude rozlišovat, zda je uživatel registrován (pˇrihlášen), nebo si prohlíží portál jako neregistrovaný uživatel. U registrovaného uživatele se bude rozlišovat, zda má administrátorská práva nebo ne. Po dlouhém rozmýšlení bylo rozhodnuto, že pˇridˇelování ostatních dvou rolí bude nejlépe rˇ ešeno dynamicky. Každý registrovaný uživatel bude mít pˇridˇeleno právo spravovat nebo editovat danou ontologii (pro každou ontologii to muže ˚ být jinak) a dle toho se dynamicky bude pˇridˇelovat role uživateli u každé ontologie samostatnˇe. Datový model systému je ale navržen tak, že role lze do budoucna libovolnˇe pˇridávat. Pˇri analýze pomocí diagramu užití byly identifikovány následující požadavky funkcí: •

Prohlížení ontologií

•

Stažení ontologie v OWL

•

Procházení struktury ontologie

•

Editace ontologie 50


Obrázek 5.2: Diagram pˇrípadu˚ užití. •

Import z OWL souboru

•

Pˇridání nové ontologie

•

Registrace uživatele

•

Správa ontologie

•

Pˇriˇrazování autoru˚ k ontologii

•

Pˇriˇrazování dalších správcu˚ ontologii

•

Mazání uživatelu˚

•

Mazání ontologií

Pˇriˇrazení jednotlivých funkcí k uživatelským rolím je patrno z diagramu pˇrípadu˚ užití. Na základˇe požadavku˚ funkcionality byl sestaven diagram tˇríd (obrázek 5.3). Pro logickou funkcionalitu portálu postaˇcuje použití šesti základních tˇríd: •

Uživatel 51


Obrázek 5.3: Diagram tˇríd. •

Seznam uživatelu˚

•

Ontologie

•

Seznam ontologií

•

Model ontologie

•

Pˇrihlášení

V diagramu tˇríd jsou uvedeny i nejduležitˇ ˚ ejší metody jednotlivých tˇríd. Samozˇrejmˇe je možné, že pˇri vlastní implementaci pak mohou vzniknout nˇejaké další pomocné tˇrídy nebo metody, napˇríklad pro manipulaci s databází nebo s uživatelským rozhraním. Tyto tˇrídy a metody však nejsou pro logiku a popis systému duležité ˚ a budou sloužit cˇ istˇe jen jako programátorské prostˇredky. Jelikož je v portálu nejduležitˇ ˚ ejší problematika vkládání, editace a mazání ontologií, tak byl vypracován sekvenˇcní diagram, který tuto problematiku více ozˇrejmuje. Tento diagram je na obrázku 5.4. Pro všechny akce se pˇredpokládá podmínka, že daný pˇrihlášený uživatel má na tyto akce práva. Pˇri prvním vložení ontologie uživatel vyplní formuláˇr jehož hodnoty jsou nejprve zkontrolovány. Pokud jsou hodnoty v poˇrádku, tak teprve potom je vytvoˇrena nová instance 52

5.2. SPECIFIKACE A NÁVRH tˇrídy ontologie. Danou ontologii lze poté uživatelem editovat nebo pokud má uživatel práva administrátora, tak i mazat. Ontologie muže ˚ mít po svém vzniku ruzné ˚ stavy, které jsou vidˇet na stavovém diagramu ontologie na obrázku 5.5. Nejprve je novˇe vložená ontologie jako neveˇrejná. Teprve jakmile bude dostateˇcnˇe pˇripravena pro distribuci, je možné ontologii zveˇrejnit. Pokud se z nˇejakého duvodu ˚ shledá, že by nemˇela být ontologie dále zveˇrejnˇena, lze její zveˇrejnˇení zrušit a poté lze ontologii i smazat. Ruzné ˚ stavy muže ˚ mít i uživatel. Druhý vypracovaný stavový diagram na obrázku 5.6 nám ukazuje, že každý uživatel, který na portál vstoupí je nejprve anonymní. Uživatel se muže ˚ sám zaregistrovat a cˇ ekat až bude správcem otologie potvrzen jako uživatel, který se smí pˇrihlásit. Samozˇrejmˇe tento proces pˇredpokládá nˇejakou domluvu mezi novým uživatelem a správcem, aby mˇel správce duvod ˚ uživatele potvrdit jako registrovaného. Druhým možným zpusobem ˚ je ten, že muže ˚ uživatele rovnou vložit správce. V tomto pˇrípadˇe se uživatel stane registrovaným ihned. Pak už se uživateluv ˚ stav mˇení jen dle toho, zda se pˇrihlásí nebo odhlásí, dokud nebude z nˇejakého duvodu ˚ administrátorem smazán. Pro úplnost se ještˇe podívejme na fyzický datový model, který vznikl na základˇe této objektové analýzy. V tomto datovém modelu na obrázku 5.7 jsou vidˇet entity Pˇrihlášení, Uživatel a Ontologie, které pˇrímo korespondují s tˇrídami v diagramu tˇríd. Ostatní entity jsou entity pomocné. Entita Role v ontologii je pomocná entita pro vyjádˇrení role daného uživatele v dané ontologii. Pozastavme se u entity Editace, která slouží pro zaznamenání skuteˇcnosti, kdo a kdy editoval danou ontologii. Zárovenˇ se bude pomocí této entity hlídat, aby needitovali dva uživatelé jednu ontologii ve stejném cˇ ase.

53


Obrázek 5.4: Sekvenˇcní diagram zobrazující v cˇ ase životní cyklus ontologie.

54


Obrázek 5.5: Stavový diagram ontologie.

Obrázek 5.6: Stavový diagram uživatele.

55


Obrázek 5.7: Fyzický datový model.

56

Kapitola 6

Implementace 6.1

Základní popis systému

Webový portál „Ontoportál“ umožnuje ˇ distribuci ontologií ve formátu OWL. Pro návštˇevníky portálu zpˇrístupnuje ˇ uložené ontologie pˇrímo jako OWL soubory nebo pomocí uživatelského rozhraní, které umožnuje ˇ procházet strukturou ontologií. Pro autory ontologií nabízí portál možnost importu ontologií z OWL souboru, který si mohou autoˇri pˇripravit v jejich vlastním oblíbeném editoru. Zárovenˇ portál nabízí jednoduché rozhraní pro základní editaˇcní úkony, takže dokáže zastoupit jednoduchý OWL editor. Pokud chce uživatel data jen prohlížet nebo stahovat, není nucen se registrovat. Neregistrovanému uživateli je umožnˇeno procházet strukturu všech zveˇrejnˇených ontologií nebo je stahovat pˇrímo v OWL souboru. Upravovat uložené ontologie však smˇejí jen registrovaní uživatelé s danými právy. Samozˇrejmostí je funkce zveˇrejnˇení nebo zrušení zveˇrejnˇení dané ontologie. Takto lze novˇe vznikající ontologie zatím skrýt pˇred zraky neregistrovaných uživatelu. ˚ Stejnˇe tak je možno skrýt stávající ontologie napˇríklad bˇehem editace. Portál není omezen jen na jednu znalostní doménu, ale umožnuje ˇ ukládání libovolných ontologií z libovolných domén. V jednotlivých ontologiích se lze pomocí importu jiné ontologie odkazovat na objekty definované v této jiné ontologii. Tímto je tedy možné tvoˇrit i hierarchickou strukturu nad uloženými ontologiemi. Není tedy problém využívat v doménových ontologiích top-level domény a nebo danou doménu ještˇe rozdˇelit do menších poddomén. Portál importy ontologií do jiných ontologií nijak nehlídá, neomezuje ani neeviduje. Vše je tedy ponecháno na autorech ontologií, kteˇrí mají v tomto ohledu volnost.

6.2

Uživatelé

Portál rozlišuje, zda je uživatel pˇrihlášen nebo nepˇrihlášen. Nepˇrihlášení uživatelé se mohou pohybovat ve všech hlavních sekcích portálu. Pokud se uživatel pˇrihlásí, jsou mu v každé sekci zpˇrístupnˇeny nové funkce dle jeho souˇcasné role a práv. Pˇrihlášení uživatelé jsou tedy rozdˇeleni do tˇechto rolí: •

Administrátor má pˇrístup úplnˇe ke všem funkcím celého portálu. Do role administrátora muže ˚ jmenovat registrovaného uživatele jenom jiný administrátor. Administrátoru˚ muže ˚ být neomezený poˇcet. 57

˚ 6.3. REGISTRACE UŽIVATEL U •

Správce ontologie spravuje jednu nebo více ontologií. Role správce je pˇridˇelována dynamicky a je spjata s konkrétní ontologií. Tato role muže ˚ být pˇridˇelena uživateli jenom jiným správcem dané ontologie nebo administrátorem. Správce, který spravuje konkrétní ontologii, muže ˚ k této ontologii definovat jiné správce nebo její autory. Správcem muže ˚ být uživatel jen pro konkrétní ontologie, což znamená, že u ostatních práva správce nemá. Uživatel, který je správcem alesponˇ jedné ontologie, také muže ˚ registrovat nové uživatele, potvrzovat jejich vlastní registrace nebo vkládat nové ontologie. Po vložení nové ontologie systém nastaví automaticky správcem této ontologie uživatele, který ji vložil. Správce na rozdíl od administrátoru˚ nemá právo na pˇrístup k ontologiím, které nespravuje a nemá práva na mazání ontologií a uživatelu. ˚

•

Autor ontologie muže ˚ editovat a importovat jednu nebo více ontologií. Role autora je pˇridˇelována dynamicky a je opˇet spjata s konkrétní ontologií. Pˇridˇelena muže ˚ být opˇet jenom správcem dané ontologie nebo administrátorem. Autor ontologie nemá žádná práva na pˇridˇelování jiných autoru˚ nebo správcu, ˚ ani na registraci uživatelu˚ nebo pˇridávání a jinou správu ontologií. Jediné právo je tedy editace jedné nebo více ontologií, se kterými je autorství spjato.

•

Pˇ rihlášený uživatel je takový uživatel, který je zaregistrován a potvrzen jako uživatel, který se smí pˇrihlásit. Pokud tento uživatel nemá k žádné ontologii právo správce, autora nebo není administrátorem, tak je jen jediná funkce navíc, která ho odlišuje od nepˇrihlášeného. Takový uživatel má právo procházet i ontologie, které nejsou zrovna zveˇrejnˇeny. Mˇenit a upravovat nesmí nic, dokud nedostane vyšší práva.

Takto dynamicky postavenou strukturou uživatelských rolí není problém mít v systému uživatele, který bude mít napˇríklad k jedné ontologii práva správce, ale k druhé jen práva autora, kdežto ostatní bude moci jen prohlížet.

6.3

Registrace uživatelu˚

Registrace nových uživatelu˚ (budoucích správcu˚ nebo autoru˚ ontologií) muže ˚ probíhat dvˇema zpusoby: ˚ 1. Registraci provede stávající správce ontologie nebo administrátor. V tomto pˇrípadˇe se muže ˚ registrovaný uživatel ihned pˇrihlašovat a mohou mu být pˇridˇelována práva autora nebo správce ontologií. 2. Registraci provede sám nepˇrihlášený uživatel pomocí registraˇcního formuláˇre. V tomto pˇrípadˇe se uživatel smí pˇrihlásit, až mu bude registrace potvrzena stávajícím správcem ontologie nebo administrátorem. Obdobné je to s pˇridˇelováním práv správce nebo autora. Tento zpusob ˚ je dostupný proto, aby si mohl uživatel své kontaktní údaje vyplnit pˇresnˇe sám a nemusel je všechny pˇredávat stávajícímu správci. 58

6.4. JEDNOTLIVÉ SEKCE PORTÁLU Registrace uživatele tedy vždy vyžaduje nˇejakou pˇredchozí komunikaci se stávajícími uživateli portálu, které nový uživatel musí pˇresvˇedˇcit, že bude pro jejich komunitu užiteˇcný. Všechny kontakty na stávající správce a autory jsou dostupné i pro nepˇrihlášené uživatele, aby mohli pˇrípadnou komunikaci navázat. Tento zpusob ˚ zajišt’uje to, že se budou moci pˇrihlašovat opravdu povˇerˇ ení uživatelé, kteˇrí budou pˇrizváni ke spoluautorství ontologií na portálu uložených. Samozˇrejmˇe je toto rˇ ešení dostaˇcující i pro státní instituce nebo soukromé organizace, které nemusí mít zájem na registraci nových uživatelu. ˚ Pak staˇcí nové registrace nepotvrzovat nebo pˇrímo odkaz na podsekci s registraˇcním formuláˇrem z portálu odstranit.

6.4

Jednotlivé sekce portálu

Portál je rozdˇelen do pˇeti hlavních sekcí: •

Úvod

•

Ontologie

•

Uživatelský úˇcet

•

Autoˇri ontologií

•

Kontakt

Sekce „Úvod“ má pouze informativní charakter. Obsahuje úvodní informace o portálu a popis myšlenky, kterou portál realizuje. Informativní charakter má i sekce „Kontakt“, která obsahuje kontakt na provozovatele portálu. V tomto konkrétním pˇrípadˇe kontakt na autora této diplomové práce. Podívejme se na ostatní tˇri sekce, které jsou nejduležitˇ ˚ ejší a obsahují funkcionalitu portálu. ˚ 6.4.1 Sekce „Uživatelský úˇcet“ Nepˇrihlášený uživatel se v této sekci dozví informace o možnostech, které získá pˇrípadnou registrací a podmínky, za kterých se muže ˚ registrovat. V pˇrípadˇe, že se chce nepˇrihlášený uživatel sám zaregistrovat, je v této sekci dostupná podsekce „Požádat o založení úˇctu“, kde se uživateli zobrazí formuláˇr se vstupními poli login, heslo, jméno a e-mail. Pokud zadá všechny požadované údaje je registrace uložena a uživatel je informován o tom, že se smí poprvé pˇrihlásit, až mu bude úˇcet potvrzen. Pˇrihlášený uživatel zde najde podsekci „Muj ˚ kontakt“, kde si muže ˚ mˇenit kontaktní email a jméno. V podsekci „Mé heslo“ si muže ˚ uživatel zmˇenit stávající heslo, kterým se pˇrihlašuje do systému. 59

6.4. JEDNOTLIVÉ SEKCE PORTÁLU 6.4.2 Sekce „Autoˇri ontologií“ V této sekci má nepˇrihlášený uživatel dostupnou pouze jednu podsekci „Seznam autoru“, ˚ kde je zobrazena tabulka jmen všech potvrzených uživatelu˚ portálu s kontaktními e-maily. U každého uživatele je také zobrazeno, které ontologie spravuje, nebo u kterých je pˇriˇrazen jako autor. Pˇrípadný nastávající uživatel má tedy dostupné kontakty na všechny autory ontologie, která ho zajímá. Pokud se uživatel pˇrihlásí a má práva správce ontologie, zobrazí se mu v tabulce ještˇe loginy a systémová cˇ ísla daných uživatelu, ˚ možnost editace jejich údaju˚ a funkce potvrzení cˇ i zrušení potvrzení pro jednotlivé uživatele. Uživatel, který má práva administrátora, má ještˇe zpˇrístupnˇenu možnost jednotlivé uživatele vymazat a nastavení uživatelu˚ jako další administrátory. Zobrazený seznam uživatelu˚ se dá rˇ adit dle jména, poˇradí vložení (systémového cˇ ísla) nebo e-mailu. Zobrazené uživatele lze filtrovat, takže lze zobrazit jenom administrátory, správce ontologií, autory ontologií, nepotvrzené a potvrzené uživatele. Správce ontologie má v této sekci zpˇrístupnˇenu podsekci „Pˇridání nového autora“, kde se opˇet zobrazí formuláˇr se vstupními poli login, heslo, jméno a e-mail. V tomto pˇrípadˇe je po vložení uživatel automaticky potvrzen a hned se pak muže ˚ pˇrihlašovat a být pˇriˇrazován k ontologiím jako autor nebo správce. 6.4.3 Sekce „Ontologie“ Tato sekce je nejduležitˇ ˚ ejší a nejsložitˇejší sekce celého portálu, proto byl její popis zámˇernˇe ponechán až na konec. Pro nepˇrihlášené uživatele obsahuje seznam všech ontologií, které jsou v portálu uloženy. Seznam obsahuje název ontologie, verzi a pˇrípadnˇe jména jejích správcu˚ a autoru. ˚ Je zde opˇet možnost rˇ azení seznamu dle názvu nebo poˇradí vložení. U každé položky je pˇrímý odkaz „Zobrazit“, který ukazuje pˇrímo na OWL soubor dané ontologie. Pokud uživatel vybere kliknutím nˇejakou ontologii ze seznamu, zobrazí se menu, pomocí kterého lze procházet strukturu dané ontologie. Zde portál nabízí tyto možnosti: •

Základní informace – v této podsekci se zobrazují informace o importovaných ontologiích a jmenných prostorech, které ontologie využívá.

•

Tˇ rídy – seznam tˇríd v dané ontologii. Po otevˇrení stromovité položky v menu nebo kliku na tˇrídu v seznamu, lze vybrat jen jednu tˇrídu a zobrazit podrobnosti o této tˇrídˇe.

•

Objektové vlastnosti – seznam objektových vlastností, které jsou v ontologii nadefinovány. Po otevˇrení stromovité položky v menu nebo kliku na objektovou vlastnost v seznamu, lze vybrat jen jednu objektovou vlastnost a zobrazit podrobnosti o této vlastnosti. 60

6.4. JEDNOTLIVÉ SEKCE PORTÁLU •

Datotypové vlastnosti – seznam všech datotypových vlastností, které jsou v ontologii nadefinovány. Zobrazení podrobností o každé jednotlivé datotypové vlastnosti je obdobné jako v pˇredchozích pˇrípadech.

•

Individua – seznam všech individuí, která ontologie obsahuje. Opˇet lze zobrazit podrobnosti ke každému individuu.

Dodejme ještˇe, že všechny seznamy pˇri procházení struktury ontologií jsou rˇ azeny abecednˇe dle názvu˚ jednotlivých prvku. ˚ Pokud ontologie neobsahuje žádnou tˇrídu, není pak položka „Tˇrídy“ v levém menu rozevírací. Obdobnˇe je to s objektovými vlastnostmi, datovými vlastnostmi a individui. Bˇehem procházení struktury ontologie je poˇrád uživateli k dispozici její název, verze a popis. Pokud je uživatel pˇrihlášen, zobrazí se mu v seznamu ontologií i ontologie, které nejsou zveˇrejnˇeny. Novˇe se zobrazí u seznamu ontologií filtr na zobrazení jen zveˇrejnˇených nebo jen nezveˇrejnˇených ontologií. Pokud má pˇrihlášený uživatel k dané ontologii v seznamu právo autora nebo správce, zobrazí se u jednotlivé ontologie možnost „Upravit info“. Zobrazí se formuláˇr, kde lze upravit název, verzi a popis ontologie. S tím, že zmˇenˇené údaje budou automaticky zaneseny nejen do databáze, kde jsou uloženy základní informace o ontologii, ale i do hlaviˇcky OWL souboru dané ontologie. Pro autory ontologií je zde také u každé ontologie v seznamu možnost importu ontologie z OWL souboru. Zde se doporuˇcuje importovat jen ontologie, které byly vytvoˇreny v tomto portálu. Import se tedy doporuˇcuje používat jen v pˇrípadˇe obnovení ontologie ze zálohy nebo po úpravˇe ontologie vzniklé na tomto portálu externím editorem. Nedoporuˇcuje se importovat ontologie z jiných distribuˇcních kanálu, ˚ na ty se lze pomocí jedineˇcného URI bez problému˚ odkazovat. Nicménˇe není problém provést i import ontologie, která neobsahuje URI patˇrící pod tento portál. Je jen potˇreba dodat, že import probˇehne zdárnˇe jen pokud je importovaný OWL soubor validní ontologií. Pro správce ontologií ještˇe v seznamu pˇribude u každé ontologie, kterou spravuje možnost její zveˇrejnˇení nebo naopak zrušení zveˇrejnˇení. Správci také mají k dispozici funkci „Pˇridat novou ontologii“, kde se jim zobrazí formuláˇr pro vložení nové ontologie s poli název, verze a popis. Po vložení informací o nové ontologii do databáze je automaticky založen OWL soubor, který obsahuje dané informace v hlaviˇcce. V tomto momentˇe lze již OWL soubor stáhnout a není problém pak soubor upravit externím oblíbeným editorem a naimportovat zpˇet. Správce ontologie muže ˚ v seznamu ontologií u každé ontologie, kterou spravuje, pˇriˇrazovat jiné správce nebo autory ontologie. Administrátor muže ˚ jednotlivé ontologie mazat. 6.4.4 Editace ontologií Pˇri procházení struktury ontologie v sekci „Ontologie“ je kontrolováno, zda má pˇrihlášený uživatel právo editace ontologie. Toto právo má autor, správce nebo administrátor. Pokud uživatel toto právo má, nabídne systém pˇrechod do editaˇcního režimu funkcí „Zapnout 61

6.5. UŽIVATELSKÉ ROZHRANÍ editaˇcní možnosti“. Dojde pak k uzamˇcení editace dané ontologie pro ostatní autory, aby nedocházelo ke konfliktum ˚ editace. V jednotlivých seznamech pˇri procházení struktury ontologie se pak objeví jednoduché editaˇcní možnosti. Jedná se o tyto hlavní úpravy: •

Pˇridávání nových tˇríd, úprava vlastností stávajících tˇríd, mazání stávajících tˇríd.

•

Definice nových vlastností, úprava podrobností stávajících vlastností, mazání stávajících vlastností.

•

Pˇridávání individuí, mazání stávajících individuí.

Pokud uživatel ví, že již editaci dané ontologie dokonˇcil, mˇel by editaci ontologie ukonˇcit pomocí funkce „Ukonˇcit editaci“. Pokud editaci neukonˇcí a pˇrejde napˇríklad do jiné sekce portálu nebo úplnˇe opustí webové rozhraní, ontologie zustane ˚ stále v editaˇcním režimu a uzamˇcená pro editaci ostatními. Pro tyto pˇrípady portál kontroluje, zda pˇrihlášený uživatel má nˇejakou ontologii v editaˇcním režimu a pˇri pohybu po portálu mu tuto skuteˇcnost stále pˇripomíná a nabízí mu ukonˇcit editaˇcní režim. Pokud pˇresto uživatel portál opustí, má správce blokované ontologie nebo administrátor v seznamu ontologií možnost násilnˇe ukonˇcit editaˇcní mód ontologie.

6.5

Uživatelské rozhraní

Uživatelské rozhraní portálu využívá upravenou CSS šablonu, která využívá plnˇe rozložení prvku˚ pomocí CSS. Menu s hlavními sekcemi je v horní cˇ ásti. Formuláˇr pro pˇrihlášení uživatele je v pravé horní cˇ ásti. Pokud se uživatel pˇrihlásí, zobrazí se zde informace o pˇrihlášeném uživateli a tlaˇcítko pro odhlášení. Menu s podsekcemi se zobrazuje v levé cˇ ásti portálu. Pˇri procházení struktury ontologie má menu s hierarchií stromovitou strukturu. Výstup portálu v HTML byl vyvíjen primárnˇe v prohlížeˇci Mozilla Firefox 2.0 a následnˇe otestován v prohlížeˇcích Windows Internet Explorer 7 a Opera 9.

6.6

Instalace portálu na webový hosting

Instalace systému na webový hosting a jeho zprovoznˇení je velice jednoduché. Staˇcí si nejprve ovˇerˇ it, že hosting splnuje ˇ tyto nároky: •

databáze MySQL 5

•

webový server Apache Tomcat 61

•

JDK 6

Pokud máte vytvoˇren hosting, který tyto požadavky splnuje, ˇ staˇcí provést cˇ tyˇri jednoduché kroky k instalaci: 1.

62

6.6. INSTALACE PORTÁLU NA WEBOVÝ HOSTING

Obrázek 6.1: Uživatelské rozhraní portálu. 1. Zkopírovat obsah složky „ontoportal“ (pˇrípadnˇe rozbalit archív „ontoportal.zip“) do koˇrenového adresáˇre webového hostingu. 2. V souboru „ontoportal/sql/databaze.sql“ je obsažen databázový skript. Je potˇreba pˇripojit se k vytvoˇrené MySQL databázi a spustit tento skript. Vˇetšina hostingu˚ nabízí nástroj phpMyAdmin2 , kde pomocí funkce „Import“ daný soubor s SQL skriptem mužete ˚ spustit. Pˇri importu je tˇreba nastavit kódování importovaného souboru na „utf8“. 3. V souboru „WEB-INF/web.xml“ je potˇreba nastavit parametry pˇripojení k databázi takto: DB-server - adresa databázového serveru. DB-jmeno - název MySQL databáze, kterou bude portál využívat. DB-uzivatel - pˇrihlašovací jméno do databáze. 2.

63

6.6. INSTALACE PORTÁLU NA WEBOVÝ HOSTING

DB-heslo - heslo do databáze. 4. Ještˇe je potˇreba nastavit adresáˇr „/ontologies“, tak aby do nˇej mˇel webový server právo zápisu a mohl si tam ukládat ontologie ve formátu OWL. Toto lze provést napˇríklad pˇríkazem „chmod 777 ontologies“ v libovolném FTP klientovi. Po provedení tˇechto cˇ tyˇr kroku˚ by mˇel portál fungovat. Pro první pˇrihlášení je automaticky po instalaci vložen uživatel „admin“ s heslem „admin“ s právy administrátora. Je doporuˇceno ihned po instalaci toto heslo zmˇenit. Po instalaci je také vložena jedna ukázková ontologie. Nyní tedy již není problém zaˇcít vkládat další ontologie a uživatele. A naplnit tím obsah portálu.

64

Kapitola 7

Ontologie s problematikou odpadového hospodáˇrství Portál pro distribuci ontologií máme pˇripraven. Nyní vyzkoušejme jeho praktické využití. Ontologie se dají s úspˇechem využít i v problematice životního prostˇredí. Podívejme se nejprve na data a informace, které máme v životním prostˇredí k dispozici a mužeme ˚ zpracovávat.

7.1

Enviromentální informace a souvislost s ontologiemi

Informace o životním prostˇredí lze charakterizovat jako data, statistiky a jiné kvantitativní a kvalitativní údaje, které rozhodovací orgány vyžadují k hodnocení stavu a trendu˚ zmˇen prostˇredí, k formulaci a upˇresnování ˇ ekologické politiky a k úˇcelnému využívání prostˇredku˚ [12]. Struktura enviromentálních dat je velice nesourodá, protože se sbírají z mnoha ruzných ˚ zdroju. ˚ Sbírají se napˇríklad z ruzných ˚ monitoringu, ˚ pomocí analýz, simulací a modelování. Abychom mohli tato data vyhodnocovat a pˇrijímat na základˇe vyhodnocení urˇcitá rozhodnutí, musíme tˇemto datum ˚ rozumˇet a dostat z nich urˇcité informace, se kterými se již dá pracovat. Zatím neexistuje jednotící prvek a proto je vyhodnocování enviromentálních dat složitá, nákladná a cˇ asovˇe nároˇcná záležitost. Interoperabilita, zvláštˇe ta sémantická, je zde tedy opravdu duležitá. ˚ Informace o životním prostˇredí se stávají velmi duležitými, ˚ jelikož si vˇetšina obˇcanu˚ zaˇcíná uvˇedomovat duležitost ˚ zdravého životního prostˇredí. Aby se mohli sami obˇcané aktivnˇe podílet na šetrném zacházení s životním prostˇredím, tak je potˇreba, aby mˇeli informace o životním prostˇredí k dispozici. Toto je duležité, ˚ protože jedinˇe když budou mít obˇcané k informacím o životním prostˇredím pˇrístup, budou moci v tˇechto informacích hledat pˇrípadná pochybení na stranˇe orgánu˚ státní správy nebo soukromých subjektu, ˚ které nˇejakým zpusobem ˚ porušují zákony o životním prostˇredí. Pomocí nevládních organizací je pak možno na tyto porušovatele podávat žaloby a bránit se jejich chování. Funguje zde tedy zpˇetná kontrola ze strany obyvatel. Dodejme, že právo na volný pˇrístup obˇcanu˚ k informacím o životním prostˇredí je zakotveno na základˇe Aarhuské úmluvy [9] ve smˇernici Evropského spoleˇcenství 2003/4/ES. Smˇernice 2003/35/ES pak zajišt’uje úˇcast veˇrejnosti na rozhodovacím procesu a právní ochranˇe. V tomto procesu je samozˇrejmˇe také duležité ˚ to, aby mˇeli obˇcané a instituce pˇrístup k souˇcasným zákonum, ˚ pojmum ˚ a definicím o životním prostˇredí. Jen tak lze zajistit to, že mohou státní a soukromé instituce tyto zákony dodržovat. Na druhou stranu pak mohou obˇcané kontrolovat, zda tento zákon není porušován. Co kdyby byly tyto zákony, pojmy a 65

ˇ ˇ 7.2. INFORMA CNÍ ZDROJE O ODPADOVÉM HOSPODÁ RSTVÍ vztahy, které jsou v tˇechto zákonech zakotveny, dostupné pomocí ontologií? Znamenalo by to nejen pro obˇcany, ale i pro aplikace pˇrístup k tˇemto informacím. Tyto aplikace by pak ve spojení ontologie a dat získaných z monitorování mohly automaticky v tˇechto datech nacházet souvislosti, které obˇcan na první pohled nevidí nebo je nezachytí vubec. ˚ Jako velice zajímavá oblast pro zpracování se z tohoto hlediska jeví doména odpadového hospodáˇrství. Podívejme se tedy nejprve na zdroje informací o této doménˇe.

7.2

Informaˇcní zdroje o odpadovém hospodáˇrství

Pro zpracování domény odpadového hospodáˇrství je nejprve potˇreba provést analýzu stávající legislativy a ujasnit si pojmy z této domény. Jelikož zpracováváme doménu odpadoˇ vého hospodáˇrství dle legislativy Ceské republiky, zamˇerˇ íme se tedy proto hlavnˇe na zdroje v cˇ eštinˇe. Jako nejvýznamnˇejší zdroje informací o této problematice byly shledány tyto: 1. Ministerstvo životního prostˇ redí (http://www.env.cz) – na stránkách ministerstva životního prostˇredí lze najít kompletní servis informací z oblasti životního prostˇredí. Najdeme zde kompletní legislativu o životním prostˇredí, nejruznˇ ˚ ejší ˇ zprávy, dokumenty a prezentace o stavu životního prostˇredí v Ceské republice, aktuality a novinky. Souˇcástí webu ministerstva je i rubrika „Informaˇcní služby“, která obsahuje dokumenty ke stažení a tabulky specifického zamˇerˇ ení. Stránky ministerstva byly používány pˇri vývoji ontologie odpadového hospodáˇrství a využívány jako nejˇcastˇejší a nejkvalitnˇejší zdroj informací. Nejvíce informací je obsaženo v aktualizovaném znˇení zákona 185/2001 Sb. o odpadech a o zmˇenˇe nˇekterých dalších zákonu˚ z 15. kvˇetna 2001, který lze stáhnout ve formátu DOC ze stránek ministerstva. 2. EnviWeb (http://www.enviweb.cz) je velice vydaˇrený komerˇcní projekt kompletního informaˇcního portálu o životním prostˇredí. Souˇcástí tohoto projektu jsou i jiné doplnkové ˇ služby v oblasti životního prostˇredí, zejména poradenství v životním prostˇredí nebo softwarové služby. EnviWeb obsahuje kompletní pˇrehled legislativy. Jednotlivá znˇení zákonu˚ jsou ale k dostání jen v rámci programu „EnviParagraf“, který je registrem legislativy životního prostˇredí. Program je placený (takže nebyl v rámci práce vyzkoušen), ale z popisu je patrno, že nabízí bonusy jako full-textové prohledávání, on-line prubˇ ˚ ežnou aktualizaci a další. EnviWeb je velice obsáhlý projekt a lze tam najít hodnˇe informací také zdarma. Jde zejména o aktuální cˇ lánky, odkazy, databázi firem provozujících cˇ innosti související s životním prostˇredím, inzerci, kalendáˇr odborných akcí, burzu odpadu, ˚ slovník pojmu, ˚ ale tˇreba i diskusní fórum nebo fotogalerii. Z našeho hlediska je zajímavý zdaˇrilý katalog odpadu, ˚ který odpady cˇ lení dle cˇ eské vyhlášky. 3. Odpady iHNed.cz (http://odpady.ihned.cz) – tento portál se zabývá odpadovým hospodáˇrstvím a ekonomikou životního prostˇredí. Je podsekcí portálu iHNed.cz, který 66

ˇ TVORB Eˇ ONTOLOGIE O ODPADOVÉM HOSPODÁ RSTVÍ ˇ 7.3. POSTUP P RI je zpravodajským serverem hospodáˇrských novin. Najdeme zde hlavnˇe cˇ lánky a informaˇcní zdroje, které souvisí s odpady z ekonomického hlediska. Zajímavý je seznam odpadu. ˚ Kódování odpadu˚ v tomto seznamu odpovídá Zelenému, Žlutému a ˇ Cervenému seznamu OECD. 4. Eur-lex (http://eur-lex.europa.eu) poskytuje pˇrímý bezplatný pˇrístup k právu Evropské unie. Systém umožnuje ˇ nahlédnout do Úˇredního vˇestníku Evropské unie a obsahuje kromˇe jiného smlouvy, právní pˇredpisy, zvykové právo a návrhy právních pˇredpisu. ˚ Nabízí rˇ adu možností vyhledávání. Tento informaˇcní zdroj je zde uveden z duvodu ˚ jeho duležitosti, ˚ využíván bˇehem sestavování ontologie nebyl, protože obsahuje usnesení, které pˇrijala Evropská komise. Zákony v jednotlivých zemích, které jsou pˇrijímány na základˇe tˇechto usnesení, cˇ asto vše definují pˇresnˇeji, proto se budeme držet cˇ eského zákona. Jako informaˇcní zdroj o dˇení v legislativˇe o životním prostˇredí na pudˇ ˚ e Evropské unie je tento portál výborný.

7.3

Postup pˇri tvorbˇe ontologie o odpadovém hospodáˇrství

Podívejme se na krátký popis postupu, kterým byla ontologie o odpadovém hospodáˇrství vytváˇrena. Všechny názvy tˇríd a vlastností, které budeme v ontologii definovat, budeme uvádˇet tak, jak jsou definovány v zákonˇe. Nicménˇe ve vlastní ontologii jsou názvy bez diakritiky a bez mezer mezi víceslovnými pojmy. V pˇrípadˇe velice dlouhých názvu˚ jsou tˇrídy nadefinovány zkratkovitˇe. Názvy tˇríd budeme psát s velkým poˇcáteˇcním písmenem, názvy vlastností s malým. Vycházejme tedy ze zákona 185/2001 Sb. o odpadech a o zmˇenˇe nˇekterých dalších zákonu˚ (dále jen zákon). Tento zákon stanovuje pravidla pro pˇredcházení vzniku odpadu˚ a pro nakládání s nimi pˇri dodržování ochrany životního prostˇredí, ochrany zdraví cˇ lovˇeka a trvale udržitelného rozvoje, práva a povinnosti osob v odpadovém hospodáˇrství a pusob˚ nost orgánu˚ veˇrejné správy. Za odpad se považuje každá movitá vˇec, které se osoba zbavuje nebo má úmysl nebo povinnost se jí zbavit a pˇrísluší do nˇekteré ze skupin odpadu˚ uvedených v pˇríloze cˇ . 1 k tomuto zákonu. Vytvoˇrme tedy první základní tˇrídu „Odpad“ a do jejího popisu dejme tuto definici. Puvodcem ˚ odpadu˚ je právnická osoba, pˇri jejíž cˇ innosti vznikají odpady, nebo fyzická osoba oprávnˇená k podnikání, pˇri jejíž podnikatelské cˇ innosti vznikají odpady. Pro komunální odpady vznikající na území obce, které mají puvod ˚ v cˇ innosti fyzických osob, na nˇež se nevztahují povinnosti puvodce, ˚ se za puvodce ˚ odpadu˚ považuje obec. Oprávnˇenou osobou je každá osoba, která je oprávnˇena k nakládání s odpady podle tohoto zákona nebo podle zvláštních právních pˇredpisu. ˚ Nabízí se tedy vytvoˇrení nadtˇrídy „Osoba“. Tˇrídy „Puvodce ˚ odpadu“ a „Oprávnˇená osoba“ udˇelejme podtˇrídou tˇrídy „Osoba“. 67

ˇ TVORB Eˇ ONTOLOGIE O ODPADOVÉM HOSPODÁ RSTVÍ ˇ 7.3. POSTUP P RI 7.3.1 Skupiny odpadu˚ Podívejme se na pˇrílohu cˇ .1, ve které máme odpady rozdˇelené do skupin odpadu. ˚ Základních skupin je 16 s oznaˇcením Q1-Q16 a nabízí se zde tedy první rozdˇelení odpadu˚ do tˇríd. Toto kritérium dle zákona tedy bude stanovovat, co je a co není odpad. Movitá vˇec, která nebude pˇríslušet k žádné této tˇrídˇe, tedy odpad není. Vytvoˇríme tˇrídu „Odpad ze skupiny odpadu“, ˚ která bude podtˇrídou tˇrídy „Odpad“. Dále vytvoˇríme jednotlivé skupiny jako její podtˇrídy. Kód skupiny dáme jako její název a její specifikaci jako popis. 7.3.2 Katalog odpadu˚ Puvodce ˚ a oprávnˇená osoba jsou povinni pro úˇcely nakládání s odpadem odpad zaˇradit podle katalogu odpadu, ˚ který ministerstvo stanovuje vyhláškou 381/2001 Sb. Katalog odpadu˚ v pˇríloze této vyhlášky obsahuje rozdˇelení do 20 základních skupin oznaˇcených 0120, kde má každá stromovitˇe uspoˇrádanou hierarchii podskupin. Stromovitá struktura má tˇri úrovnˇe. Všechny nižší úrovnˇe mají kód úrovnˇe vyšší spojený mezerou s kódem vlastním, který je v rozmezí 01-99. Listy stromu, které pˇredstavují koncové a nejnižší skupiny katalogu mají tedy napˇríklad strukturu 10 02 13 Kaly a filtraˇ cní koláˇ ce z ˇ cištˇ ení plynu obsahující nebezpeˇ cné látky, kde 10 oznaˇcuje hlavní skupinu katalogu „Odpady z tepelných procesu“, ˚ 10 02 podskupinu „Odpady z prumyslu ˚ železa a oceli“ a 10 02 13 koncovou skupinu „Kaly a filtraˇcní koláˇce z cˇ ištˇení plynu obsahující nebezpeˇcné látky“. Vytvoˇrme tedy další tˇrídu „Odpad z katalogu odpadu“, ˚ kterou udˇelejme podtˇrídou tˇrídy „Odpad“ a jako podtˇrídy zanesme toto rozdˇelení jako hierarchickou strukturu. Kód bude opˇet názvem tˇrídy a dlouhá specifikace bude v popisu. Jelikož název tˇrídy v ontologii typu OWL by nemˇel zaˇcínat cˇ íslem a obsahovat mezery upravme tedy kód každého odpadu dle vzoru CAT_10_02_13. Tˇrídám „Puvodce ˚ Odpadu“ a „Oprávnˇená osoba“ pˇriˇradíme vlastnost „zaˇrazuje odpad dle katalogu“ a jako hodnoty bude mít „Odpad“. 7.3.3 Nebezpeˇcný odpad Puvodce ˚ a oprávnˇená osoba jsou povinni pro úˇcely nakládání s odpadem zaˇradit odpad do kategorie nebezpeˇcný, je-li: •

uveden v Seznamu nebezpeˇcných odpadu˚ stanoveným vyhláškou 381/2001 Sb.

•

smíšen nebo zneˇcištˇen nˇekterým z nebezpeˇcných odpadu˚ z vyhlášky 381/2001 Sb.

•

smíšen nebo zneˇcištˇen nˇekterou ze složek uvedených v Seznamu složek, které cˇ iní odpad nebezpeˇcným, uvedeném v pˇríloze cˇ . 5 zákona.

Podívejme se opˇet na vyhlášku 381/2001 Sb. Seznam nebezpeˇcných odpadu˚ obsahuje vždy kód z katalogu a název. Napˇríklad 05 01 04 Kyselé alkylové kaly. Katalog odpadu˚ 68

ˇ TVORB Eˇ ONTOLOGIE O ODPADOVÉM HOSPODÁ RSTVÍ ˇ 7.3. POSTUP P RI již máme v ontologii zanesen, vytvoˇríme tedy jen objektovou vlastnost „je uveden s seznamu nebezpeˇcným odpadu“ ˚ a projdeme zpˇetnˇe katalog a pˇriˇradíme tuto vlastnost všem odpadum, ˚ které jsou uvedeny v seznamu nebezpeˇcných odpadu. ˚ Tím splníme první bod. Dále vytvoˇríme tˇrídu „Nebezpeˇcný odpad ze seznamu“ a jako jeho podtˇrídy nadefinujme všechny tˇrídy z této ontologie, které mají vlastnost „je uveden s seznamu nebezpeˇcným odpadu“. ˚ Tím se nám stanou všechny odpady z katalogu, které mají tuto vlastnost podtˇrídou tˇrídy „Nebezpeˇcný odpad ze seznamu“. Dále vytvoˇrme objektovou vlastnost „je smíšen s nebezpeˇcným odpadem ze seznamu “, kterou pˇriˇradíme k tˇrídˇe „Nebezpeˇcný odpad smíšen s nebezpeˇcným odpadem ze seznamu“. Jako možné hodnoty pak pˇriˇradíme tˇrídu „Nebezpeˇcný odpad ze seznamu“. Tím jsme splnili druhý bod. Nyní se podívejme na seznam složek, které jsou v pˇríloze zákona a cˇ iní odpad nebezpeˇcným. Mají kódy C1-C51. Vytvoˇrme tedy tˇrídu „Nebezpeˇcná složka“ a jako její podtˇrídy nadefinujme všechny nebezpeˇcné složky. Jako název opˇet zvolme kód a specifikace bude v popisu tˇrídy. Nyní mužeme ˚ vytvoˇrit objektovou vlastnost „je smíšen s nebezpeˇcnou složkou“, kterou pˇriˇradíme k tˇrídˇe „Nebezpeˇcný odpad smíšen s nebezpeˇcnou složkou“. Jako možné hodnoty pak pˇriˇradíme tˇrídu „Nebezpeˇcná složka“. Splníme tím tˇretí bod. Ještˇe pro úplnost nadefinujme tˇrídu „Nebezpeˇcný odpad“ (bude opˇet podtˇrídou tˇrídy „Odpad“) a jako jeho podtˇrídy nadefinujme tˇrídy „Nebezpeˇcný odpad ze seznamu“, „Nebezpeˇcný odpad smíšen s nebezpeˇcným odpadem ze seznamu“ a „Nebezpeˇcný odpad smíšen s nebezpeˇcnou složkou“. Tímto krokem vytvoˇríme hierarchii nad tˇrídami nebezpeˇcného odpadu. Tˇrídám „Puvodce ˚ Odpadu“ a „Oprávnˇená osoba“ pˇriˇradíme vlastnost „zaˇrazuje mezi nebezpeˇcné“ a jako hodnoty bude mít „Odpad“. 7.3.4 Nebezpeˇcné vlastnosti odpadu V pˇrípadˇe, že puvodce ˚ nebo oprávnˇená osoba, která s odpadem nakládá, se domnívá, že odpad smíchaný s nebezpeˇcným odpadem nebo složkou, která ho cˇ iní nebezpeˇcným, nemá žádnou z nebezpeˇcných vlastností, mohou požádat o hodnocení nebezpeˇcných vlastností tohoto odpadu. Nebezpeˇcné vlastnosti odpadu˚ uvedené v pˇríloze cˇ . 2 zákona oznaˇcené kódem H1, H2, H3-A, H3-B, H12, H13 a H14 hodnotí právnická osoba nebo fyzická osoba povˇerˇ ená. Vytvoˇrme tedy tˇrídu „Nebezpeˇcná vlastnost“ a jako její podtˇrídy nadefinujme všechny nebezpeˇcné vlastnosti z pˇrílohy cˇ . 2. V tomto pˇrípadˇe máme sice pojem „vlastnost“ pˇrímo v názvu, ale bylo rozhodnuto, že z hlediska následného propojování bude lepší cˇ lenit odpad do tˇríd, které splnují ˇ tuto vlastnost než pˇrímo odpadu tuto vlastnost pˇriˇrazovat. Proto definujeme v rámci ontologie nebezpeˇcné vlastnosti jako tˇrídy a ne jako vlastnosti. Nyní již vytvoˇríme vlastnost „muže ˚ mít hodnocenou nebezpeˇcnou vlastnost“, kterou pˇriˇradíme tˇrídám „Nebezpeˇcný odpad smíšen s nebezpeˇcnou složkou“ a „Nebezpeˇcný odpad smíšen s nebezpeˇcným odpadem ze seznamu“ a jako hodnotu nadefinujeme tˇrídu „Ne69

ˇ TVORB Eˇ ONTOLOGIE O ODPADOVÉM HOSPODÁ RSTVÍ ˇ 7.3. POSTUP P RI bezpeˇcná vlastnost“. Tím vyjádˇríme, že tyto dva druhy odpadu˚ mohou mít hodnoceny nebezpeˇcnou vlastnost, která se vyskytuje v seznamu nebezpeˇcných vlastností. Vytvoˇríme tˇrídu „Osoba provˇerˇ ující nebezpeˇcné vlastnosti“, která bude podtˇrídou tˇrídy „Osoba“. A vytvoˇríme vlastnost „provˇerˇ uje nebezpeˇcné vlastnosti“, které dáme jako hodnoty nebezpeˇcné vlastností s kódy H1, H2, H3-A, H3-B, H12, H13 a H14 a jako definiˇcní obor „Osoba provˇerˇ ující nebezpeˇcné vlastnosti“. Tímto zajistíme vztah, že provˇerˇ ovat tyto nebezpeˇcné vlastnosti, muže ˚ jen tato osoba k tomu povˇerˇ ená. 7.3.5 Nakládání s odpady „Nakládání s odpady“ je pojem, který sdružuje cˇ innosti, pˇri kterých je s odpadem manipulováno. Zákon tedy pˇresnˇe definuje nakládání s odpady jako jejich shromažd’ování, soustˇred’ování, sbˇer, výkup, tˇrídˇení, pˇrepravu a dopravu, skladování, úpravu, využívání a odstranování. ˇ Zákon definuje, že s odpady se nakládá v zaˇrízení k tomu urˇceném. Pro pojem „Zaˇrízení“ tedy vytvoˇrme tˇrídu. Vytvoˇrme tˇrídu „Nakládáni s odpady“ a jako její podtˇrídy vytvoˇrme všechny zpusoby ˚ nakládání s odpadem, které jsou tyto: •

„Shromažd’ování odpadu“ ˚ - krátkodobé soustˇred’ování odpadu˚ do shromažd’ovacích prostˇredku˚ v místˇe jejich vzniku pˇred dalším nakládáním s odpady.

•

„Skladování odpadu“ ˚ - pˇrechodné umístˇení odpadu, ˚ které byly soustˇredˇeny (shromáždˇeny, sesbírány, vykoupeny) do zaˇrízení k tomu urˇceného a jejich ponechání v nˇem.

•

„Sbˇer odpadu“ ˚ - soustˇred’ování odpadu˚ právnickou osobou nebo fyzickou osobou oprávnˇenou k podnikání od jiných subjektu˚ za úˇcelem jejich pˇredání k dalšímu využití nebo odstranˇení.

•

„Výkup odpadu“ ˚ - sbˇer odpadu˚ v pˇrípadˇe, kdy odpady jsou právnickou osobou nebo fyzickou osobou oprávnˇenou k podnikání kupovány za sjednanou cenu.

•

„Úprava odpadu“ ˚ - každá cˇ innost, která vede ke zmˇenˇe chemických, biologických nebo fyzikálních vlastností odpadu˚ (vˇcetnˇe jejich tˇrídˇení) za úˇcelem umožnˇení nebo usnadnˇení jejich dopravy, využití, odstranování ˇ nebo za úˇcelem snížení jejich objemu, pˇrípadnˇe snížení jejich nebezpeˇcných vlastností.

•

„Využívání odpadu“ ˚ - cˇ innosti uvedené v pˇríloze cˇ . 3 k zákonu. Tento seznam byl zpracován, a jeho položky byly zaneseny jako podtˇrídy.

•

„Materiálové využití odpadu“ ˚ - náhrada prvotních surovin látkami získanými z odpadu, ˚ které lze považovat za druhotné suroviny, nebo využití látkových vlastností odpadu˚ k puvodnímu ˚ úˇcelu nebo k jiným úˇcelum, ˚ s výjimkou bezprostˇredního získání energie. 70

ˇ TVORB Eˇ ONTOLOGIE O ODPADOVÉM HOSPODÁ RSTVÍ ˇ 7.3. POSTUP P RI •

„Energetickým využitím odpadu“ ˚ - použití odpadu˚ hlavnˇe zpusobem ˚ obdobným jako paliva za úˇcelem získání jejich energetického obsahu nebo jiným zpusobem ˚ k výrobˇe energie.

•

„Odstranování ˇ odpadu“ ˚ - cˇ innosti uvedené v pˇríloze cˇ . 4 k zákonu. Tento seznam byl také zpracován a jeho položky byly zaneseny jako podtˇrídy.

Pro daný druh nakládání s odpadem musí mít puvodce ˚ nebo osoba oprávnˇena povolení od státu. Tˇrídám „Puvodce ˚ Odpadu“ a „Oprávnˇená osoba“ pˇriˇradíme vlastnost „má povolení nakládat odpadem“ a jako hodnoty bude mít „Odpad“. Tato vlastnost definuje s kterými druhy dopadu˚ má puvodce ˚ povolení nakládat. Vytvoˇrme ještˇe druhou vlastnost „má povolení pro nakládání“, kterou opˇet pˇriˇradíme tˇrídám „Puvodce ˚ Odpadu“ a „Oprávnˇená osoba“, ale jako hodnotu dáme tˇrídu „Nakládáni s odpady“. Tato vlastnost definuje, na jaké druhy nakládání s odpadem má puvodce ˚ povolení. Dodejme ještˇe, že zákon naˇrizuje upˇrednostnovat ˇ ty zpusoby ˚ nakládání s odpadem, které vedou ke znovuvyužití odpadu pˇred zpusoby, ˚ které vedou k jeho odstranˇení. 7.3.6 Doplnˇení ontologie Ontologie byla ještˇe doplnˇena o nˇekteré další základní pojmy, které zákon definuje. „Komunální odpad“ je veškerý odpad vznikající na území obce pˇri cˇ innosti fyzických osob, a který je uveden jako komunální odpad v provádˇecím právním pˇredpisu, s výjimkou odpadu˚ vznikajících u právnických osob nebo fyzických osob oprávnˇených k podnikání. Tato tˇrída byla vytvoˇrena jako podtˇrída tˇrídy „Odpad“. „Skládka odpadu“ ˚ je technické zaˇrízení urˇcené k odstranování ˇ odpadu˚ jejich trvalým a rˇ ízeným uložením na zemi nebo do zemˇe. Tento pojem byl definován jako podtˇrída tˇrídy „Zaˇrízení“. 7.3.7 Souhrn Po pˇreˇctení zákona, jeho pˇríloh a pˇriˇrazených vyhlášek byla vytvoˇrena velice rozsáhlá ontologie obsahující problematiku odpadového hospodáˇrství. Ontologie obsahuje 1106 tˇríd a 10 vlastností, které v tomto pˇrípadˇe pˇredstavují hlavnˇe vztahy mezi definovanými tˇrídami. Ontologie je ve formátu OWL a je k dispozici jako první ukázková ontologie po instalaci webového portálu pro distribuci ontologií, který byl vyvinut v rámci této práce. Až pˇrípadné nasazení v nˇejakých reálných aplikacích v praxi ukáže, co by v dané ontologii mohlo být nadefinováno jinak, cˇ i lépe. Ontologie samozˇrejmˇe muže ˚ být do budoucna rozšiˇrována a propojována s ontologiemi z jiných odvˇetví životního prostˇredí. Nabízí se úzké spojení s podobnou oblastí, kterou je problematika obalu. ˚ Stejnˇe zajímavá možnost je propojení ontologie s reálnými daty. Napˇríklad s daty o puvodcích ˚ odpadu˚ a oprávnˇených osobách. Šly by pak možná snadnˇeji provádˇet ruzné ˚ kontroly nebo vyhledávání souvislostí v tˇechto datech.

71

Kapitola 8

Závˇer Sémantická interoperabilita se stává v rámci Evropské unie velice diskutovaným tématem. Stále více informací si mezi sebou vymˇenují ˇ nejenom systémy státních a soukromých institucí v rámci jednoho státu, ale i systémy, které leží zemˇepisnˇe v jiných státech. S nástupem práva o volném pˇrístupu obˇcanu˚ k informacím o životním prostˇredí dostává sémantická interoperabilita ještˇe vˇetší význam i v této oblasti. Napomáhá totiž tomu, aby se obˇcané k tˇemto informacím z nejruznˇ ˚ ejších zdroju˚ dostali ve srozumitelné podobˇe. Ontologie, jako jeden z prostˇredku˚ sémantické interoperability, mají svuj ˚ rozmach stále ještˇe pˇred sebou. Jejich vývoj a zkoumání je stále ještˇe v poˇcátcích, a to zvláštˇe v oblasti životního prostˇredí. Dokazuje to i zatím nesjednocená terminologie. Výzkum ontologií na akademické pudˇ ˚ e stále pˇredbíhá jejich nasazování na skuteˇcné aplikace v praxi. Nejvˇetší pˇrínos této práce vidím v tom, že se snaží ontologie uplatnit i v praxi. V rámci práce byl implementován webový portál pro správu ontologií. Tento portál umožnuje ˇ distribuci ontologií, a tím tak napomáhá rozšíˇrení ontologií. Uložené ontologie nabízí zdarma ke stažení a tím otevírá možnost pro aplikace tˇretích stran, které si mohou nad tˇemito ontologiemi stavˇet vlastní algoritmy. Portál je uvolnˇen jako Open Source a je tedy otevˇrený pro další rozšiˇrování nebo nasazení ve státní správˇe. Jako nadˇejné rozšíˇrení do budoucna by se jevilo napˇríklad schopnost práce s jinými formáty kromˇe OWL nebo propojení s nˇejakým reasonerem. V rámci práce také vznikla rozsáhlá ukázková ontologie s problematikou odpadového hospodáˇrství. Až pˇrípadná praxe ukáže, co by se na této ontologii mohlo vylepšit a co doplnit. Jelikož je potenciál ontologií veliký, urˇcitˇe se do budoucna najde hodnˇe možností, jak tuto ontologii rozšíˇrit. Jako nejlepší se mi jeví propojení s reálnými daty z monitoringu a záznamu˚ o životním prostˇredí. Tato práce pro mˇe byla velikým pˇrínosem. Musel jsem nastudovat nejen problematiku ontologií, ale také se seznámit s technologií JSP pro vývoj webových aplikací, se kterou jsem do té doby nemˇel zkušenosti. Z mého hlediska práce splnila svuj ˚ hlavní cíl, kterým bylo posunout ontologie zase trochu blíže praxi.

72

Literatura [1] Peterka, J.: eArchiv, archiv cˇ lánku˚ a pˇrednášek Jiˇrího Peterky, . 1.1 [2] OWL Web Ontology Language Guide, The World Wide Web Consortium, . 3.3 [3] Ontoprise web, . 3.2.4 [4] Protégé web, . 3.4.1 [5] OntoWeb, . 4.4 [6] Association for the Advancement of Artificial Intelligence - Ontologies, . 4.2 [7] Knowledge Web, . 4.4, 5.2 [8] UML Resource Page, . 7.1 [9] Convention on access to information, public participation in decision-making and access to justice in environmental matters, 1998. 7.1 [10] Wikipedie, . 2.1, 4.1 [11] IDABC: European interoperability framework for pan-european eGovernment services, Office for Official Publications of the European Communities, 2004, ISBN 92-8948389-X. 1.2, 1.2, 1.3, 3.5 [12] Štefaník, M.: Informaˇcní a komunikaˇcní technologie na podporu komunikace s environmentálními informaˇcními systémy v Evropské unii, Masarykova univerzita, fakulta informatiky, diplomová práce, 2006. 1.1, 7.1 [13] The World Wide Web Consortium, . 2.2, 2.6, 3.2.5, 3.3, 5.1.1 [14] Svátek, V.: Ontologie a WWW, Katedra informaˇcního a znalostního inženýrství, VŠE Praha, 2001. 3, 3.1, 3.2 [15] IDABC web, . 1.2 [16] Hˇrebíˇcek, J.: Sémantická interoperabilita, rezentace k pˇrednášce se semináˇre z aplikované matematiky, 2007. 2.4 [17] Hradský, J.: Jazyk OWL a sémantický web, Masarykova univerzita, fakulta informatiky, bakaláˇrská práce, 2003. 3.3

73

Pˇríloha A

Obsah pˇriloženého CD Souˇcástí práce je i pˇriložené CD, které obsahuje tyto adresáˇre: •

/ontologie - ontologie s problematikou odpadového hospodáˇrství ve formátu OWL

•

/ontoportal - zdrojový kód webového portálu, který lze nainstalovat na webhosting, Javadoc, použité knihovny

•

/programy - základní programy a nástroje, které byly použity pˇri studiu ontologií a vývoji portálu

•

/text - text této diplomové práce v elektronické podobˇe ve formátu Docbook, LATEX a PDF

74

012345

Recommend Documents