VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
SDÍLENÍ DAT MEZI INFORMAČNÍMI SYSTÉMY ZALOŽENÉ NA ONTOLOGIÍCH
DIPLOMOVÁ PRÁCE MASTER‘S THESIS
AUTOR PRÁCE AUTHOR
BRNO 2009
BC. LUKÁŠ HÁK
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
SDÍLENÍ DAT MEZI INFORMAČNÍMI SYSTÉMY ZALOŽENÉ NA ONTOLOGIÍCH DATA SHARING BETWEEN INFORMATION SYSTEMS BASED ON ONTOLOGIES
DIPLOMOVÁ PRÁCE MASTER‘S THESIS
AUTOR PRÁCE
BC. LUKÁŠ HÁK
AUTHOR
VEDOUCÍ PRÁCE SUPERVISOR BRNO 2009
ING. RADEK BURGET, PH.D.
3
Abstrakt Tato práce popisuje sdílení dat mezi informačními systémy založené na ontologiích. V první kapitole vysvětluje základní pojem ontologie a používané názvosloví. Dále rozebírá používané základní technologie, ontologické jazyky a částečně vysvětluje také sémantický web. Ve 3. kapitole jsou vypsány používané nástroje a pluginy pro práci s ontologiemi. Další kapitoly popisují vytvořené ontologie potřebné pro inzerci aut. Konkrétně ontologii s auty, prodejci a adresami. Na závěr je vysvětlen navrhnutý nástroj pro převod existujících dat v XML na zápis inzerce v jazyce OWL.
Abstract This thesis describes data sharing between information systems based on ontologies. In the first chapter shows up the term ontology and used terminology. Then this thesis analyses used basic methods, onthological languages and partially describes semantic web. In the third chapter are write out utilities and plugins which are used for working with ontologies. The other chapters describe created ontology which are useful for car-selling. Especially ontology with cars, sellers and addresses . At the end of the thesis is explained suggested instrument to transfer existing XML to recording advertising in OWL language.
Klíčová slova Ontologie, XML Schema, RDF, RDFS, RDF Schema, DAML+OIL, OWL, Protégé, KAON, Magpie
Keywords Ontology, XML Schema, RDF, RDFS, RDF Schema, DAML+OIL, OWL, Protégé, KAON, Magpie
Citace Lukáš Hák: Sdílení dat mezi informačními systémy založené na ontologiích, diplomová práce, Brno, FIT VUT v Brně, 2009
Sdílení dat mezi informačními systémy založené na ontologiích
Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením Ing. Radka Burgeta, Ph.D. Další informace mi poskytli Ing. Pavel Bílek ze společnosti Autosoft a Ing. Miroslav Krejčí ze společnosti Teas. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. …………………… Lukáš Hák 18.4.2009
Poděkování Rád bych zde poděkoval vedoucímu mé práce Ing. Radku Burgetovi Ph.D. za uskutečněné konzultace, rady a věcné připomínky k mé práci. V neposlední řadě také Ing. Pavlu Bílkovi ze společnosti Autosoft a Ing. Miroslavu Krejčímu ze společnosti Teas za vyjádření podpory a přislíbení pomoci při nasazení produktu této práce v komerčním sektoru.
© Lukáš Hák, 2009. Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.
Obsah Obsah...................................................................................................................................................1 1 Úvod...................................................................................................................................................3 2 Teorie ontologie.................................................................................................................................4 2.1 Pojem a definice ontologie..........................................................................................................4 2.1.1 Pojem ontologie...................................................................................................................4 2.1.2 Ontologická oblast...............................................................................................................4 2.1.3 Typy ontologií.....................................................................................................................5 2.1.4 Struktura ontologií...............................................................................................................5 2.2 Základní technologie...................................................................................................................6 2.2.1 XML....................................................................................................................................6 2.2.2 XML Schema.......................................................................................................................6 2.2.3 RDF.....................................................................................................................................8 2.3 Ontologické jazyky...................................................................................................................10 2.3.1 RDF Schema......................................................................................................................10 2.3.2 DAML+OIL.......................................................................................................................10 2.3.3 OWL..................................................................................................................................12 2.3.4 Další způsoby zápisu.........................................................................................................14 2.4 Struktura OWL dokumentu.......................................................................................................14 2.4.1 Hlavička.............................................................................................................................14 2.4.2 Třídy..................................................................................................................................15 2.4.3 Vlastnosti...........................................................................................................................18 2.5 Sémantický web........................................................................................................................19 2.6 Nasazení ontologií v praxi.........................................................................................................20 3 Nástroje pro ontologie......................................................................................................................22 3.1 Protégé......................................................................................................................................22 3.2 Kaon..........................................................................................................................................23 3.3 Magpie......................................................................................................................................24 3.4 Semanticworks..........................................................................................................................25 3.5 Další nástroje............................................................................................................................26 4 Návrh ontologie pro inzerci aut........................................................................................................28 4.1 Motivace pro tvorbu..................................................................................................................28 4.2 Textový popis............................................................................................................................28 4.3 Importované ontologie..............................................................................................................29 4.4 Hierarchie tříd...........................................................................................................................29 1
4.5 Vlastnosti s objekty...................................................................................................................32 4.6 Datové vlastnosti.......................................................................................................................33 4.7 Příklad s individuem.................................................................................................................33 5 Návrh ontologie pro prodejce...........................................................................................................35 5.1 Textový popis............................................................................................................................35 5.2 Hierarchie tříd...........................................................................................................................35 5.3 Vlastnosti s objekty...................................................................................................................36 5.4 Datové vlastnosti.......................................................................................................................36 5.5 Příklad s individuem.................................................................................................................36 6 Návrh ontologie pro adresy..............................................................................................................38 6.1 Textový popis............................................................................................................................38 6.2 Hierarchie tříd...........................................................................................................................38 6.3 Datové vlastnosti.......................................................................................................................38 6.4 Příklad s individuem.................................................................................................................39 7 Převod XML na OWL......................................................................................................................40 7.1 Popis zdroje dat.........................................................................................................................40 7.2 Obecný návrh systému..............................................................................................................41 7.3 Implementace parseru...............................................................................................................42 7.4 Příklad konverze.......................................................................................................................44 8 Závěr................................................................................................................................................46 Literatura............................................................................................................................................47 Seznam příloh.....................................................................................................................................48 Příloha 1. Struktura hlavní databáze. .................................................................................................49 Příloha 2. Návrh ontologií..................................................................................................................52 Příloha 3. Transformační skript z XML..............................................................................................58 Příloha 4. CD se zdrojovými soubory.................................................................................................62 Příloha 5. Popis datového typu Base64..............................................................................................63
2
1
Úvod
Tato práce představuje jednak teoretický základ pro výměnu dat mezi informačními systémy na základě ontologií. Další část práce již pak řeší danou problematiku prakticky. Pro řešení tohoto tématu mě přiměla neexistence jednotného formátu dat pro výměnu mezi SW v autobazarech a inzertními portály. Sám vlastním internetový portál www.sportovnivozy.cz , který se zabývá inzercí nových i ojetých sportovních aut a výsledek této práce bych rád implementoval do svého systému a také nabídnul ostatním společnostem, zabývajících se inzercí automobilů nebo vývojem SW pro autobazary. Vlastní ontologie představuje velký přínos, neboť dodává datům jednotnou sémantiku, oproti klasické výměně dat přes XML. Mým cílem je tedy vytvořit po dohodě s dalšími portály jednotnou ontologii, pomocí které by se formátem OWL přenášela data potřebná pro inzerci automobilů. Aktuálně používá každý inzertní portál i každý výrobce SW svůj formát dat a potřebné propojení je tedy velmi pracné a obsahuje také značnou chybovost v reprezentaci přijímaných dat. Po nasazení této ontologie by se tento proces velmi výrazně zjednodušil. Stačilo by totiž připravit pouze jeden jediný skript pro synchronizaci nabídky se všemi autobazary. Struktura teoretického úvodu je následující. Na začátek je vysvětlen vlastní pojem ontologie a ontologické oblasti a popsány jejich vlastnosti a způsoby využití. Dále následuje popis použitých základních technologií jako XML, XML Schema či RDF. Po tomto nezbytném úvodu již následují přímo ontologické jazyky. Podrobně je zde popsán jazyk OWL, ve kterém bude následně tato ontologie také zapsána. Zabývám se zde i sémantickým webem, jeho historií, postupným zaváděním a popisem vrstev. Závěr druhé kapitoly patří aktuálním informacím o nasazení různých ontologií v praxi a také jsou zde rozebrány možnosti širšího nástupu ontologií v budoucnu. Ve třetí kapitole je uveden seznam používaných nástrojů a pluginů pro zápis a využívání ontologií. Více je zde rozebrán nástroj Protégé, ve kterém vytvářím praktické ontologie pro inzerci aut. Není zapomenuto ani na opensource nástroj Kaon, či rozšíření pro internetové prohlížeče s názvem Magpie. Poslední popisovaný nástroj je komerční produkt Semanticworks od firmy Altova. Následuje již pouze seznam další používaných nástrojů bez podrobnějšího popisu. Ve čtvrté kapitole se již věnuji vlastnímu produktu této diplomové práce a to je ontologie pro inzerci aut. Jsou zde popsány všechny importované ontologie, vlastní hierarchie tříd, vlastnosti s objekty a také datové vlastnosti. Na závěr je uveden příklad s jedním individuem. Dvě následující kapitoly popisují další nutné ontologie, vytvořené na základě potřeby v hlavní ontologii. První je ontologie s prodejci aut a další je ontologie s adresami. Struktura těchto ontologií je popsána podobně jako u hlavní ontologie a jsou zde také uvedeny příklady s individui. Protože přechod na naší ontologii nebude revoluční, ale postupný, bylo potřeba se zabývat problémem převodu existujících XML souborů na požadovaný OWL formát. Tento problém řeší sedmá kapitola. Na začátku je rozebrán jeden z nejčastějších způsobů XML zápisu dat pro inzerci aut. Poté je popsán návrh implementace daného parseru. Následuje popis vlastní implementace i s popisem funkce pro hledání duplicit individuí v ontologii z centrální databáze. Na konec je uveden příklad takové konverze na datech portálu Sportovnivozy.cz. V samotném závěru jsem shrnul přínos této diplomové práce. Možnost nasazení v praxi a způsob rozšíření v budoucnosti.
3
2
Teorie ontologie
2.1
Pojem a definice ontologie
2.1.1
Pojem ontologie
Pojem ontologie pochází z filosofie, kde je chápán jako nauka o bytí, či soustava znalostí popisující objekty, jevy a zákonitosti světa tak jak jsou. V této práci se budu však zabývat informatickou ontologií. Samotná ontologie je předmět ontologického inženýrství a sémanticky popisuje to co existuje v reálném světě. Jedná se tedy o sémantický systém. Definic pojmu ontologie existuje celá řada. Zajímavá je definice od T. Grubera, zakladatele a duchovního otce informačních ontologií. Tato definice zní: „ontologie je explicitní specifikace konceptualizace“. Konceptualizace značí kolekci pojmů, označující určitou část světa. Musí být explicitní, tedy nejen pouze v hlavě autora, ale dobře specifikována. [6] Mezi další požadavky ontologií patří formalizace, což znamená použití jazyka s přesně definovanou syntaxí. Ontologie musí být výsledkem práce celé skupiny jisté zájmové komunity. Tedy nikoliv pouze individuální, ale musí být sdílená. Tento požadavek je v praxi často nedodržován a vznikají tedy různé ontologie na tu samou doménovou oblast. Musí být také časově, prostorově i personálně opakovaně použitelné. Účelově jsou ontologie použité pro podporu porozumění mezi experty, komunikaci mezi počítačovými systémy a zlehčení návrhu znalostně doménově orientovaných aplikací. V odborném textu se lze setkat s pojmem znalostní ontologie, což je vlastně pouze upřesňující výraz pro klasické ontologie. Tedy značí, že každá ontologie vyjadřuje určitou znalost. Oblasti a konkrétní aplikace mohou být různorodé. Pro potřeby této diplomové práce jsem si zvolil ontologii inzerce osobních vozidel.
2.1.2
Ontologická oblast
Ontologickou oblast většinou chápeme jako objekt, lze si ale pod tímto názvem představit obecně i jakýkoliv jev. Tato oblast lze myšlenkově rozložit na jednodušší a pro poznání lépe přístupnější suboblasti. Tyto suboblasti tvoří v celku ontologickou soustavu. Tento postup rozdělování nazýváme analýza a lze rozložit hierarchicky. Například pokud zvolíme za objekt automobil, lze jej rozložit na nejvyšší úrovni na motor, podvozek, interiér, karosérii. Na nejnižší úrovni jako nejelementárnější mechanické a chemické procesy v motoru, činnost a funkce tlumičů, a jiné. Pokud je soustava hierarchická, studují se obvykle postupně jednotlivé vrstvy a následně jejich vzájemné vztahy. Redukovaná ontologická oblast dané soustavy je pak chápána jako soubor atributově popsaných entit - suboblastí a vztah mezi nimi. Pro každou entitu soustavy určíme, které atributy u ní akceptujeme a které vztahy. Redukovaná ontologická oblast se rozčlení na redukovanou ontologickou soustavu a je modelem myšlené ontologické soustavy. Pro popis topologie redukované ontologické soustavy lze použít neorientovaný graf a říkáme mu schéma. V něm je každý z redukovaných subobjektů znázorněn symbolem své typové příslušnosti a kvantitativními údaji příslušných atributů. Podobným způsobem jsou znázorněny i cesty pro interakce subobjektů. [1] Mezi další zajímavé pojmy patří „ontologický závazek“. Ten nám říká, že se autoři rozhodli přijmout závazek k určitému subjektu používat pro vyjádření pojmů prvky a strukturu dané přijímuté ontologie. Dalším problémem ontologické oblasti je její rozsah. Při tvorbě ontologie je občas potřeba provádět selekci a zařazovat pouze ty pojmy, které mají jasnou vazbu na pojmy z jádra ontologie. Používá se také rozdělení ontologie do více nezávislých modulů, které se mezi sebou vhodně propojí do výsledné celkové ontologie. Často se řeší kompromis mezi použitelností a znovupoužitelností.
4
Čím je ontologie nezávislejší na konkrétní návrhové aplikaci, tím je bohužel méně efektivnější její přímé využití. [6]
2.1.3
Typy ontologií
Základní členění může být na formální, poloformální či neformální, dále ontologie členíme podle předmětu formalizace a to na [6]: • Doménové ontologie jsou nejčastějším typem. Jejich předmětem bývá vždy jistá specifická oblast, která může být široce zaměřena, například na celý segment motoristické inzerce, tedy i na nákladní vozy, terénní vozy, osobní vozy, motocykly, či pouze na jistou podoblast, například inzerce sportovních vozidel. • Generické ontologie zachycují obecné zákonitosti, které platí napříč různými doménovými ontologiemi. Jedná se například o problematiku času, topologie objektů, determinismu. • Úlohové ontologie jsou znalostní úlohy a jejich řešení se zaměřením na odvozování. Může se to týkat diagnostiky, zhodnocení či plánování. • Aplikační ontologie v sobě zahrnují většinou všechny předchozí typy ontologií. Jedná se o výběr modelů pro konkrétní oblast a aplikaci.
2.1.4
Struktura ontologií
Struktura znalostních ontologií bývá ve většině nástrojů stejná, avšak značně se liší použitá terminologie. Je tedy třeba si před prací s takovýmito nástroji ujasnit význam klíčových slov. Vlastní nástroje pro práci s ontologiemi jsou blíže popsány ve 3. kapitole. Nyní vysvětlím jednotlivé pojmy a strukturu ontologií. Třída může značit také koncept, kategorii či rámec. Třída je základ ontologií a značí množinu konkrétních objektů se stejnými vlastnostmi či strukturou. Oproti třídám v objektově orientovaných modelech zde neexistují metody. Na množině tříd může existovat hierarchie, lze využít také stromovou strukturu, či použít vícenásobnou dědičnost. Individua neboli instance. Je to konkrétní objekt reálného světa z dané třídy. Ontologie avšak primárně slouží k popsání sémantiky třídy, nikoliv konkrétního objektu. Relace nebo také funkce, sloty, vlastnosti, role či atributy. Obdobně jako v databázových systémech jsou podstatnou složkou vztahy. Mohou být specifikovány pomocí logických podmínek, či jako předdefinovaná lokální nebo globální omezení. Lze vytvářet také hierarchii relací, tedy například relace „je-automobil“ je nadřazený relaci „je-sportovní-automobil“. Meta-sloty, omezení na sloty, facety. V ontologiích je možné vztahům přiřazovat vlastnosti. Těmto vlastnostem říkáme meta-sloty. Nejčastější vlastností je hierarchie nadřazeného a podřazeného slotu. Což je v podstatě tranzitivní binární relace. Mezi další vlastnosti patří například metainformace o slotu, tedy definiční doménový obor a obor hodnot, zapsané podle konkrétních tříd. Může se jednat o globální omezení, tak i o lokální omezení na konkrétní třídě přes svůj definiční obor. Jde o omezení oboru hodnot, či o kardinalitu. Primitivní hodnoty a datové typy. Argumenty relací nemusí být pouze další objekty, ale také primitivní hodnoty. Jedná se o dato-typové relace a jejich obor hodnot býva většinou klasického typu, tedy textový, číselný, daný intervalem či výčtem. Například číslo 6 je instancí datového typu integer. Sloty v ontologiích mohou nabývat více hodnot najednou, to je rozdíl oproti klasickému objektově orientovanému modelování. Pokud použijeme jednoznačné sloty typu „má-rok-výroby“, kde je možná pouze jedna hodnota, pak jej explicitně deklarujeme jako funkční. Axiomy a pravidla je možné zařazovat do ontologií vedle klasických výrazů, které explicitně vyjadřují příslušnost k určité třídě. Jedná se o logické formule vyjadřující například ekvivalenci tříd či relací, disjunknost, rozklad třídy na podtřídy, apod. Klasická pravidla mají mnohem omezenější sémantiku. Souhrnné informace se umísťují většinou do hlavičky v ontologiích. Obsahují jednak znalostní konstrukty, pak i další souhrné informace jako odkazy na importované ontologie. Může se
5
jednat i o popis dokumentu, údajích o autorovi, času a datumu vytvoření, použitém nástroji, apod. Tyto údaje nemají vliv na logickou interpretaci ontologie. [6]
2.2
Základní technologie
2.2.1
XML
XML je obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C.[3] Je označován jako metajazyk, protože umožňuje definici konkrétních jazyků, aplikací XML. Uživatel si může sám nadefinovat používané elementy, jejich možné atributy, standardní hodnoty, způsoby vnořování nebo omezení datových typů. Tímto vytváříme nový jazyk. Příkladem takovéhoto jazyka je XHTML, což je aplikace XML pro zápis HTML. Dalším příkladem může být grafický formát SVG nebo transformační stylový jazyk XSLT. Dokument XML obsahuje značkování, které odpovídá pravidlům určeným ve standardu XML a také má správnou strukturou definovanou DTD nebo schématem. Lze ale vytvořit dokument, který nemá určené DTD nebo schéma. V takovém případě stačí, pokud vyhovuje základním požadavkům na vnořování elementů a použití XML konstrukcí. Měl by obsahovat jeden a více elementů. Elementy jsou do sebe vnořovány, tedy je-li počáteční tag vnořen v určitém elementu, musí tam být vnořen i koncový element. Kromě kořenového elementu má tedy každý element svého rodiče a tedy tvoří stromovou strukturu. V podstatě hlavní podmínkou kladenou na dokumenty je správné vnořování a správná syntaxe. Tedy zápis tagů do lomených závorek, uvozování všech atributů uvozovkami či apostrofy a podobně. Pro lepší kontrolu nad obsahem dokumentu je třeba omezit elementy, které mohou být použity a specifikovat jejich vnořování. K tomu slouží definice typu dokumentu (dále DTD). Je v něm možné kontrolovat správnou strukturovanost a také validitu. Validující parsery nás upozorní na chybu při zápisu struktury daného dokumentu. Například na element, vyskytující se na špatném místě, na chybějící atribut, použití neznámého atributu nebo elementu. Lze takto snadno zjistit, zda všechny dokumenty odpovídají zadané struktuře a můžeme pro jejich další zpracování využít konkrétní nástroje. [5]
2.2.2
XML Schema
Definice struktury XML dokumentu pomocí DTD je jednoduchá, ale má celou řadu omezení. Tvůrci standardu XML Schema se snažili tyto omezení odstranit. Mezi zásadní výhody schémat oproti DTD patří: • Podpora jmenných prostorů. • V případě násobnosti elementů lze kontrolovat možný počet opakování. • Definice struktury je také v XML a pro návrh schémat lze tedy také použít běžné nástroje a editory XML. • Schémata umožňují definovat datové typy a velmi přesně specifikovat omezení možných hodnot.
• • • • •
Bohužel ale existují i nevýhody těchto XML schémat [5]: Slabší podpora v aplikacích. Podstatně složitější mechanizmus. Nemožnost určení kořenového elementu. V DTD se určuje pomocí hlavičky DOCTYPE. Nelze rozdělit definici struktury na interní a externí část. Nelze definovat entity ani parametrické entity.
6
Jak již bylo řečeno, mezi výhody schémat patří možnost definice datových typů. Dělí se na primitivní vestavěné typy popsané ve specifikaci a odvozené typy popsané ve schématech. Z těchto typů lze také odvodit typy nové. Veškeré datové typy jsou definovány na základě prostoru hodnot, množiny hodnot, které mohou nabývat, a lexikálního prostoru, tedy jakými znaky jsou tyto hodnoty reprezentovány. Jeden typ může mít více lexikálních reprezentací [2].
Obr. 2.3. Hierarchie vestavěných číselných typů [2].
7
Obr. 2.4. Hierarchie vestavěných řetězcových typů [2].
2.2.3
RDF
Resource Description Framework (dále RDF) je nástroj pro reprezentaci faktů (vztahů). Oproti klasické stromové struktury v XML je grafový model RDF pro ontologie mnohem vhodnější a dostatečně otevřený pro vyjádření sémantiky. V RDF jsou jednotlivá tvrzení nezávislá na ostatních a přitom je možné je vhodně propojovat pomocí URI zdrojů. Složitější struktury vyžadují rozbití do trojic subjekt-predikát-objekt a následuje serializace do struktury XML. Struktura RDF se používala historicky i pro sémantický web, zejména v jeho počátcích, kde byl označován jako „síť sémantických metadat zapsaných pomocí RDF“. [6] Tvrzení složené z již zmiňované trojice subjekt-predikát-objekt je tedy základním stavebním kamenem jazyka RDF. Zdrojem může být samostatná webová stránka, celý webový portál, nebo i dokument mimo internet a může se vyskytovat v roli subjektu i objektu. Predikáty odpovídají požadovaným vlastnostem subjektu a objekt hodnotou těchto vlastností. Objektem může být mimo zdroje také primitivní datová hodnota, viz kapitola 2.1.4. Způsob zápisu datového modelu RDF není striktně předepsán, může se tedy jednat například o grafickou reprezentaci, zápis formou výrazů, nebo zápis založený na XML. Obálka RDF obsahuje údaje o jmenných prostorech a informace o tvůrci. V elementu description se nachází vlastní tvrzení, kde atribut about odkazuje na subjekt, název subelementu odpovídá predikátu a obsah tohoto subelementu odpovídá objektu. Specifikace RDF umožňuje zapsat tvrzení efektivněji, tedy například do elementu description zapsat více subelementů. Pokud naopak chceme přiřadit tutéž vlastnost různým zdrojům, můžeme je sdružit do kolekce. Hodnoty metadat lze také ukládat přímo do atributů místo do subelementů. V model RDF se vyskytuje také možnost reifikace. Jde o hierarchii tvrzení, kdy jistou kolekci tvrzení obaluje další tvrzení, které lze chápat jako zdroj, a udává věrohodnost zbylých tvrzení. Nevýhodou je podstatné zkomplikování všech formálních vlastností.
8
RDF lze vyjádřit i pomocí grafu a to ohodnoceným orientovaným multigrafem. Dva uzly lze spojit jednou i více hranami. Ovály se využívají pro zdroje, hrany pro vlastnosti a obdelníky obsahují hodnoty vlastností. Zdroje mohou mít více vlastností a literály se vyskytují jen jako objekty. Hrany jsou vyznačeny pomocí URI. Příklad RDF grafu je na obr. 2.1. [7]
Obr. 2.1. Příklad RDF multigrafu [7]. Příklad tvrzení v RDF je v následující tabulce: Subjekt http://www.sportovnivozy.cz/index.php?idvyrb=622&akce=detail Predikát
http://www.sportovnivozy.cz/ontologie#TypKaroserie
Objekt
http://www.sportovnivozy.cz/ontologie#Kabriolet
V tomto tvrzení je řečeno, že subjekt, zde URI konkrétního inzerovaného sportovního vozu, má objektovou vlastnost s typem karoserie a hodnotou této vlastnosti je objekt značící, že se jedná o kabriolet, opět zapsaný pomocí URI. Místo tohoto objektu by šla použít primitivní textová hodnota, ale takto je to jednoznačnější. Existují také jiné způsoby serializace trojic v RDF, ty se ale v důsledku dominance XML používají jen málokdy. Jako příklad lze uvést Notation_3, neboli častěji uváděný jako N3. Jedná se o ne-XML serializaci, zkratkovitý zápis RDF modelů, který je jednoduše čtený lidmi. Příklad zápisu pomocí N3: @prefix dc:
.
dc:title "Tony Benn"; dc:publisher "Wikipedia" Zjednodušená forma N3 se nazývá Turtle (Terse RDF Triple Language), která však není standardizovaná a nesahá za působnost RDF [18]. Příklad zápisu pomocí Turtle [19]: 9
@prefix : . @prefix rdf: . :a :b [ rdf:first "apple"; rdf:rest [ rdf:first "banana"; rdf:rest rdf:nil ] ] . N-Triples je řádková forma zápisu: "NY" Mezi méně používané patří zápis NTRIX. Zde se využívá větné skladby, uvedeme si tedy trojici v tomto zápisu: „Autorem této knihy je Jaroslav Vrchlický“ „Jaroslav Vrchlický je autorem této knihy“ „Kniha je autorizována Jaroslavem Vrchlickým“
2.3
Ontologické jazyky
2.3.1
RDF Schema
Tento sémantický jazyk orientovaný na RDF vznikl již v roce 1999. Představuje nástavbu RDF s použitím hlavních konstrukcí objektových systémů a to třídy a binární sloty s definičním oborem a oborem hodnot. Nad třídami i sloty lze vytvářet hierarchii. Přímo v RDF lze zdroje přiřazovat jednotlivým třídám z RDF Schema (dále RDFS) pomocí atributu „type“. RDFS splňuje hlavní požadavky vývojářů sémantického webu a to například definování hierarchických struktur neboli témat. Oproti klasickým ontologickým jazykům mu chybí definování lokálních omezení a tedy příslušnosti ke třídám, dále postrádá disjunktní tvar a datové typy [6].
2.3.2
DAML+OIL
V roce 2000 byl zahájen projekt DAML, který byl z části financován vojenskou organizací DARPA, a na jeho tvorbě se podíleli významní výzkumníci sémantického webu v čele s Timem B. Lee. Cílem bylo vytvořit sémantický jazyk pro RDF s větší vyjadřovací silou než má RDFS. Tento jazyk zahrnoval celou řadu konstruktů pro vymezení vztahů tříd a hodnot slotů. Ontology Inference Layer (dále OIL) je jazyk založený na propracovaném logickém kalkulu a umožňuje konstrukci složitějších podmínek při zachování výhodných vlastností pro výpočty. Použitý kalkul je deskripční logika. Sloučením jazyka DAML a OIL vznikl nový jazyk DAML+OIL. Základem tohoto jazyka jsou třídy, které jsou reprezentovány buď svým jménem pomocí URI, pak se jedná o pojmenované třídy, nebo logickým výrazem, poté jde o anonymní třídy. Pro tvorbu logických výrazů vymezujících třídy se používají konstruktory uvedené v Tab. 2.1. Konstruktory je možno libovolně skládat, a tak vytvářet složité výrazy. Obsah ontologie tvoří axiomy vystavěné nad výrazy reprezentujícími třídy. Přehled axiomů je uveden v Tab. 2.2. Název konstruktoru
Popis
intersectionOf unionOf complementOf
Booleovský výraz nad třídami
oneOf
Třída jako množina primitivních hodnot
toClass
Třída splňující univerzální resp. existenční omezení na slot (tj. na 10
hasClass
třídy, které jsou jeho hodnotami)
hasValue
Třída splňující omezení na konkrétní hodnotu slotu (kombinace hasClass a oneOf)
minCardinalityQ maxCardinalityQ CardinalityQ
Třída splňující omezení na kardinalitu slotu Tab 2.1. Konstruktory tříd v DAML+OIL [6]
Název axiomu
Popis
subClassOf sameClassAs disjointWith
vztah obecnější a speciálnější třídy ekvivalence tříd prázdný průnik tříd
subPropertyOf samePropertyAs inverseOf transitiveProperty uniqueProperty unambiguousProperty
vztah obecnější a speciálnější vlastnosti (slotu) ekvivalence vlastností vztah vzájemně inverzních vlastností tranzitivita vlastnosti vlastnost je funkcí inverzní vlastnost k dané vlastnosti je funkcí
sameIndividualAs differentIndividualFrom
Třída splňující omezení na kardinalitu slotu totožnost individuí odlišnost individuí Tab 2.2. Typy axiomů v DAML+OIL [6]
Následuje krátky příklad ontologie vládní podpory vědy a výzkumu v jazyce DAML+OIL. ]> xyz Ontology to describe organizations and individuals participating in a government R&D program. 11
Po deklaraci jmenných prostorů následuje hlavička ontologie element daml:Ontology. Prázdná hodnota jeho atributu „rdf:about“ odkazuje na dokument, v němž je tato deklarace obsažena. Poté uvádíme výraz vymezující třídu. Třída Agency je deklarována jako podtřída třídy Organization, a jako ekvivalentní třídě Agency ze starší verze stejné ontologie. Hodnota dato-typové vlastnosti name je pro třídu Agency deklarována pomocí lokálního omezení restriction jako instance datového typu string. Obdobně hodnota objektové vlastnosti partOf je pro třídu Agency deklarována jako instance téže třídy Agency, tedy agentura může být součástí jedině jiné agentury. Používá se zde jednotný způsob zápisu tvrzení o určité třídě. Axiomy jsou syntakticky začleněné do elementu odpovídajícího třídě. Je zde také patrné, že jednotlivé elementy XML pocházejí z různých jmenných prostorů a to konkrétně: rdf:, rdfs: a daml:. Což lze chápat jako vrstvenou jazykovou architekturu, kde vyšší jazyk dědí konstrukty z jazyka nižšího, které není poté nutné znovu definovat. Jedním z důvodů proč se to takto používá je i částečná zpětná kompatibilita. Pokud je například jistá webová služba schopná pracovat se sémantikou na úrovni RDFS, pak lze použít alespoň základní sémantickou analýzu až do této vrstvy, nebo získat explicitní hierarchii tříd. Ztratí se pouze nejvyšší sémantika zapsaná pomocí DAML+OIL.
2.3.3
OWL
Na základě zkušeností s jazykem DAML+OIL vznikl jazyk Web Ontology Language (dále OWL). Rozvíjí se pod hlavičkou W3C Ontology Working Group. Byl vytvořen na základě potřeby automatizovaného získávání informace bez účasti člověka. Jazyk používá explicitní definici termínů ve slovnících a vztahy mezi nimi. Narozdíl od RDF, RDFS, XML má OWL mnohem větší vyjadřovací sémantickou sílu. Ontologie zde dokáže formálně a explicitně popsat význam použitého názvosloví. OWL používá oproti RDFS navíc případové a požadavkové dokumenty, obsahující bližší detaily použité ontologie. OWL byl navržen přímo jako webový ontologický jazyk. OWL se jako jazyk dělí na 3 samostatné části použitelné pro různé skupiny vývojářů a uživatelů a to [7]: • OWL Lite obsahuje pouze základní hierarchii tříd a prosté omezení. Podporuje kardinalitu o mohutnosti 0 nebo 1. Kvůli jednoduchosti tohoto jazyka lze také jednodušeji vytvářet nástroje pro práci s tímto jazykem. Má také nižší formální složitost než jeho složitější verze. • OWL DL je určen pro vývojáře, kteří požadují velkou sémantickou schopnost zároveň s požadavkem na malou výpočetní složitost. Všechny závěry jsou 100% vypočítatelné a zaručuje také bezespornost, tedy že všechny výpočty skončí v konečném čase. Lze využít veškerou konstrukci jazyka OWL, avšak s danými omezeními. Zkratka DL je zde užita ve významu description logics (logika popisu). • OWL Full má maximální výraznost a syntaktickou volnost, ale nezaručuje výpočetní náročnost. Je dovolena rekurze. Tedy například třída může být kolekce individualit a zároveň i samotná individualita v jejich správě. Tvorba nástrojů pro plnou podporu tohoto jazyka je velmi náročná. Ontologie v jazyce OWL se skládá z hlavičky a vlastního obsahu. Hlavička obsahuje odkazy na další ontologie a číslo verze. Vlastní obsah je složen ze sady axiomů definující třídy, individua, vlastnosti a vazby mezi nimi.
12
OWL dovoluje pracovat s pojmenovanými i anonymními třídami. Pojmenovaná třída je identifikována pomocí Uniform Resource Identifier (dále URI). To je důležitá podmínka pro korektní využívání ontologií v oblasti otevřeného webu. Anonymní třída odpovídá logickému výrazu nad pojmenovanými či také anonymními třídami. Pro jakoukoliv dvojci tříd lze vyslovit tyto axiomy: subsumpce, ekvivalence a disjunktnosti. Nejčastěji se používá axiom subsempce dvou pojmenovaných tříd, který odpovídá v běžném chápání speciálnější či obecnější třídě. Nebo také subsempce pojmenované a anonymní třídy, vymezené pomocí hodnoty určité vlastnosti. Příkladem anonymní třídy může být třída objektů, které mají vlastnost prodávající vzhledem k alespoň jedné instanci třídy autobazar. Pojmenovanou třídu auto prodávané autobazarem pak můžeme definovat jako ekvivalent průniku třídy auto a výše zmíněné anonymní třídy. Oproti třídám musí být individuum definováno pomocí URI vždy. Existence individua není závislá na přiřazení do určité třídy. Může být přiřazena nejen k jedné, ale i k více třídám současně. Axiomy umožňují sledovat odlišnost, nebo naopak shodu, dvou individuí s různými názvy. Individua však nejsou běžnou součástí ontologií a používají se výhradně tehdy, je-li třeba s jejich pomocí definovat určitou třídu. Například pokud chceme třídu převod auta vymezit jako množinu transakcí převedených pomocí jistého zákona sbírky, musíme tento zákon v ontologii definovat jako individuum, které je instancí třídy zákon . Nebo v případě vlastnosti emisní norma lze definovat jako individua jednotlivé normy EURO 0 až 6, patřící do třídy norma. Také vlastnosti jsou definovány pomocí URI. Logicky se jedná o binární relace nad množinou individuí. Ani vlastnosti tedy nejsou definovány v rámci určité třídy. Axiomy vlastností mohou vymezovat definiční obor a obor hodnot a také obecné matematické charakteristiky, tedy zda se jedná o tranzitivní, symetrické či funkční relace. Nebo také vztah subsempce, ekvivalance či inverzity dvojice vlastností. V jazyku OWL platí také klasická dědičnost. Vyplývá to z logické podstaty ontologií. Omezení hodnot vlastností se dědí z obecnější třídy na speciálnější. Dědí se také matematické charakteristiky i obory argumentů obecnějších vlastností na vlastnosti speciálnější. Základní syntaxí OWL je XML, nikoli však nativní. Mezi stromovou strukturu XML a strukturu OWL je totiž v současné verzi vložena úroveň jazyka RDF, včetně jeho vlastní sémantické nadstavby RDFS. Vztah OWL a RDF je dvojí. OWL sémanticky rozšiřuje RDF a RDF je syntaktickým prostředkem pro zápis OWL. RDFS umožňuje zavést nad zdroji a vlastnostmi hierarchickou strukturu tříd. Je to totiž také ontologický jazyk, ale oproti OWL se liší chudším vyjadřovacím aparátem a nedokonalou formální sémantikou. Pro lepší pochopení následuje příklad definující zmíněnou třídu auto prodávané autobazarem. Jedná se tedy pouze o část celé ontologie v jazyce OWL v syntaxi XML/RDF: ... Definice této pojmenované třídy je založena na ekvivalenci vůči anonymní třídě, která je vymezena subsumpcí vůči dalším dvěma třídám. Z množinového hlediska se jedná o průnik. V tomto příkladu se nachází tři jmenné prostory a to RDF, RDFS a OWL. V RDF umožňují atributy ID a resource odkazovat na zdroj. RDFS pro subsumpci tříd a OWL. Výhodou takovéhoto vrstveného 13
přístupu je to, že aplikace, které znají RDFS, ale neznají OWL, mohou získat alespoň částečnou informaci. Z pohledu syntaxe je každá ontologie v OWL korektním souborem tvrzení RDF. Trojice Zdroj–Vlastnost–Hodnota jsou ovšem v XML syntaxi RDF nepříliš dobře viditelné a v případě OWL někdy ani nemají samostatně význam. Naštěstí je uživatel při tvorbě ontologie od syntaxe zpravidla odstíněn, používá-li některý z existujících grafických nástrojů, viz 3. kapitola. Výše použitá ontologie v příkladu může sloužit pro zobrazování nabídky aut různých autobazarů či soukromých prodejců, jedná se tedy o inzerci aut. Inteligentní vyhledávací služba poté při zadání dotazu na vyhledání vozidel, které prodávají pouze autobazary, najde záznamy vyhovující přesně zadání, tedy objekty patřící do třídy auto prodávané autobazarem, ale také informaci o autobazaru, který prodává dané auto. Inzertní portály tedy nemusí používát jednotnou strukturu informací, předdefinovanou například pomocí DTD nebo XML Schema. Ani není třeba pro každý katalog s nabídkou aut sestavovat obalový program, tzv. Wrapper, který by strukturu konvertoval. Stačí pokud dané inzertní portály budou dodržovat zobrazování informací podle společné ontologie. Riziko chybného mapování je mnohem menší. [9]
2.3.4
Další způsoby zápisu
Mezi další jazyky pro popis hierarchie tříd a jednoduché sémantiky patří například i UML. Nepoužívá se v něm přímo pojem ontologie, ale má k němu velmi blízko. UML je v současnosti nejpoužívanějším modelovacím nástrojem, používaným při návrhu informačních systémů. Klasické ontologie ve svých třídách nezahrnují metody pro vyjádření zodpovědnosti za určitou funkci systému, ale je v nich kladen důraz na logické vztahy mezi třídami a tedy lze vyjádřit rozsáhlejší sémantiku, než graficky pomocí asociací v UML. UML je tedy vhodnější pro programový návrh samotné aplikace a klasické ontologie se hodí pro popis dané domény, nezávisle na návrhu konkrétní aplikace. Další podstatný rozdíl je v tom, že instance jsou v klasické podobě ontologie chápány jako reálné objekty světa a příslušnost k jedné nebo více tříd je pouze jejich vlastnost, která může být změněna. Oproti tomu v UML je instance přímo přiřazena konkrétní třídě, na kterou je silně vázaná. Přesto lze i v praxi UML také použít pro zápis jisté formy semi-formální ontologie. Dalším alternativním možným zápisem ontologií jsou takzvané Topic Maps. Jejich základním konstruktem je téma, zastupující určitý předmět. Těmto tématům se přiřazují konkrétní informační zdroje, které se značí jako výskyty. Různá témata mohou být mezi sebou propojena pomocí asociací a k odlišení témat se stejným názvem se používá rozsah působnosti. Hierarchii tříd a instancí zde lze vybudovat pomocí příslušných asociací, například nadtřída-podtřída či třída-instance. Zvláštností je, že jak třídy, tak instance jsou tématy. Nevýhodou je menší vyjadřovací schopnost. Jedinou možností odvozování je slučování témat. [6]
2.4
Struktura OWL dokumentu
Struktura OWL dokumentu zachycuje jednotlivé pojmy ontologie. Obvykle obsahuje jednu hlavičku a následuje definice tříd, vlastností a případně také individuí.
2.4.1
Hlavička
Hlavička dokumentu ontologie obsahuje některé důležité informace o ontologii. Může obsahovat také komentáře, informace o verzích dokumentu, nebo o vnořených ontologiích. Následuje příklad hlavičky OWL dokumentu: An example OWL ontology 14
Derived from the DAML Wine ontology at http://ontolingua.stanford.edu/doc/chimaera/ontologies/wines.d aml Substantially changed, in particular the Region based relations. Wine Ontology
2.4.2
Třídy
Třída je základním hierarchickým prvkem ontologie. Je to uspořádaná množina prvků, které spolu určitým způsobem souvisejí. Tyto prvky se nazývají instancemi nebo individui třídy. Třídu jednoznačně popisuje její název, zapsaný pomocí URI, a soubor prvků. Existuje několik způsobů, jak může být třída definována: • • • • •
Identifikátorem třídy, neboli URI reference Výčtem prvků, které budou tvořit instance třídy Omezením vlastností Sjednocením nebo průnikem dvou a více definicí tříd Doplňkem definice třídy
2.4.2.1 Třídy definované identifikátorem Taková třída je definována pouze uvedením svého jména. Neobsahuje tedy žádné prvky ani vlastnosti. Následuje příklad takovéto třídy: 2.4.2.2 Třídy definované výčtem prvků Třída definovaná výčtem prvků je tzv. třída anonymní. Na takovou třídu se nelze přímo odkazovat, ale má využití ve složitějších konstrukcích jako sjednocení či průniky. V následujícím příkladu je třída WineColor definovaná výčtem prvků White, Rose a Red. Hodnotou vlastnosti owl:oneOf je seznam individuí, která se stanou instancemi třídy. Příklad třídy definované výčtem prvků:
15
2.4.2.3 Třídy definované omezením vlastností Třída definovaná omezením vlastností je speciálním typem definice třídy. Popisuje anonymní třídu všech individuí, která budou odpovídat podmínkám omezení. Existují dva typy omezení: omezení hodnoty a omezení kardinality. Obecný formát definice třídy omezením vlastností vypadá následovně: (řádek s omezením hodnoty nebo kardinality) Omezení hodnotou mohou využívat tří základních OWL vlastností, viz tabulka 2.3. OWL vlastnost owl:allValuesFrom
Popis Popisuje třídu všech individuí, pro která daná vlastnost nabývá pouze hodnot definovaných omezením. Může to být i třída. owl:someValuesFrom Popisuje třídu všech individuí, pro která alespoň jedna hodnota dané vlastnosti nabývá hodnoty definované omezením. owl:hasValue Popisuje třídu všech individuí, pro která daná vlastnost nabývá hodnoty definované omezením. Tedy pouze jedna konkrétní hodnota. Tab. 2.3. Základní OWL vlastnosti. Následující příklad ukazuje definici třídy definované omezením vlastnosti hasSugar, která musí nabývat hodnoty Sweet, tu bychom pak mohli použít například při definici třídy sladkých vín: Obdobně je tomu u definování tříd omezením kardinality. Zde také existují tři owl vlastnosti, které lze při omezování kardinality využít, viz následující tabulka 2.4. OWL vlastnost owl:maxCardinality
Popis Popisuje třídu všech individuí, pro která daná vlastnost nabývá maximálně počtu hodnot definovaných omezením owl:minCardinality Popisuje třídu všech individuí, pro která daná vlastnost nabývá alespoň počtu hodnot definovaných omezením. owl:Cardinality Popisuje třídu všech individuí, pro která daná vlastnost nabývá přesně počtu hodnot definovaných omezením. Tab 2.4. OWL vlastnosti pro omezování kardinality. Následující příklad ukazuje definici třídy definované omezením vlastnosti madeFromGrape na kardinalitu 1. Tedy víno vyráběné z jednoho typu hroznů. Příklad takovéto třídy: 1 16
2.4.2.4 Třídy definované průnikem Další možností jak definovat třídy je pomocí množinových operací nad třídami. K definici třídy průnikem se využívá OWL vlastnosti owl:intersectionOf. První je třída Wine, jejími instancemi jsou všechna vín. A třída definovaná omezením vlastnosti hasColor na hodnotu White , tedy všechna bílá vína. Příklad třídy definované průnikem: 2.4.2.5 Třídy definované sjednocením Třída definovaná sjednocením bude obsahovat prvky, které náleží alespoň do jedné ze tříd, na které aplikujeme sjednocení. K tomu se využívá vlastnosti owl:unionOf. Následující příklad obsahuje definici třídy WineDescriptor pomocí sjednocení prvků dvou tříd WineTaste a WineColor: 2.4.2.6 Třídy definované doplňkem Definice třídy pomocí doplňku se od předchozích dvou definicí liší tím, že lze použít pouze jednu třídu, ke které budeme tvořit doplněk. Výsledkem tedy může být velmi velká třída, obsahující obrovské množství prvků. V ontologii o vínech se takto definovaná třída nevyskytuje, pravděpodobně by neměla význam. Pro úplnost uvedu příklad, kdy pomocí doplňku ke třídě WhiteWine definuji “abstraktní“ třídu, jejíž prvky jsou všechna ostatní vína, tedy Rose a RedWine. Využiji přitom vlastnosti owl:complementOf. Příklad třídy definované doplňkem: Kromě výše popsaných možností definic tříd existují možnosti, jak upravit definice tříd pomocí dalších tvrzení. K tomu lze využít následující vlastnosti: •
rdfs:subClassOf – označuje, že prvky definované třídy jsou podmnožinou prvků jiné nadřazené třídy. 17
• •
owl:equivalentClass – označuje, že množina prvků jedné třídy je přesně stejná jako množina prvků jiné třídy. owl:disjointWith – označuje, že množina prvků jedné třídy neobsahuje žádné společné prvky s množinou prvků jiné třídy.
2.4.3
Vlastnosti
Vlastnosti jsou jistým druhem binárních relací, díky kterým lze ke třídám a jejich prvkům přidávat tvrzení a spojení mezi jednotlivými objekty a datovými typy. Vlastnost která spojuje dva objekty bývá označována jako objektová vlastnost a lze ji definovat elementem owl:ObjectProperty. Vlastnost, která spojuje určitý objekt s nějakým datovým typem označujeme jako dato-typová vlastnost a definujeme ji pomocí elementu owl:DatatypeProperty. Obecně má definice vlastnosti následující formát: Další podmínky a typy vlastnosti Při definici vlastností využívá OWL následujících konstruktorů: •
•
•
•
RDFS konstruktory: a. rdfs:subPropertyOf b. rdfs:domain c. rdfs:range Vztahy mezi vlastnostmi: d. owl:equivalentProperty e. owl:inverseOf Globální omezení kardinality: f. owl:FunctionalProperty g. owl:InverseFunctionalProperty Logické charakteristiky h. owl:SymmetricProperty i. owl:TransitiveProperty
2.4.3.1 Vztahy mezi vlastnostmi Konstruktor owl:equivalentProperty označuje, že dvě vlastnosti mají naprosto stejné prvky, tedy hodnoty. Neznamená to však, že vlastnosti jsou stejné, mohou mít jiný význam. Konstruktor owl:inverseOf se používá k označení vztahů v obou směrech, tedy doplnění jedné relace opačným případem. V následujícím příkladu je definována objektová vlastnost producesWine a inverzní vlastnost hasMaker. Příklad inverzní vlastnosti: 2.4.3.2 Globální omezení kardinality Konstruktor owl:FunctionalProperty označuje funkcionální vlastnost, která může mít pouze jednu jedinečnou hodnotu pro každou instanci. K vymezení hodnoty se často využívá konstruktorů rdfs:domain a rdfs:range. Jako příklad uvedeme objektovou vlastnost hasColor. Tím že je označena funkcionální vlastností vlastně říkáme, že její hodnotou může být pouze jeden prvek ze třídy WineColor, víno má pouze jednu barvu: 18
Inverzní funkcionální vlastnost owl:InverseFunctionalProperty omezuje vlastnost v opačném směru. Neříká, jaký může být objekt vlastnosti, ale vymezuje hodnotu subjektu. 2.4.3.3 Logické charakteristiky Symetrická vlastnost, definovaná konstruktorem owl:SymmetricProperty označuje, že pokud dvojice prvků (a,b) je instancí dané vlastnosti, pak také dvojice (b,a) je instancí dané vlastnosti. V praxi to znamená, že konstruktory rdfs:domain a rdfs:range vymezující hodnotu vlastnosti bývají stejné. Transitivní vlastnost, definovaná konstruktorem owl:TransitiveProperty označuje, že pokud dvojice prvků (a,b) je instancí dané vlastnosti a také dvojice prvků (b,c) je instancí dané vlastnosti, pak také platí, že dvojice (a,c) bude instancí dané vlastnosti [10].
2.5
Sémantický web
Praktické využití ontologie lze spatřit v sémantickém webu. Jeho počátky sahají do roku 2001, kdy se tvůrci současného webu shodli, že dnešní web je v podstatě jen neustále narůstající hromada stránek bez explicitní sémantiky a ve které je obtížné se vyznat či rychle vyhledat požadovanou znalost. Řešení viděli v rozšíření sémantického webu, kdy webové služby a další aplikace budou moci automaticky zacházet s informacemi a navzájem komunikovat pomocí důvěrného sdílení.
Obr. 2.5. Ukázka propojení zdrojů na internetu. 19
Hlavním předpokladem sémantického webu je standardizovaný popis webových zdrojů, tedy textových informací, obrázků, zvuků a videí. Všechny tyto zdroje mají být popsány metainformacemi a musí zapadnout do globálního sémantického webu. Požadovanou informaci uživatel pak získá jednoduchým dotazem. Výsledkem sémantického webu je veliká přesnost při vyhledávání. Bez sémantického webu je problém při vyhledávání více významových slov, či zkratek. [7] Sémantický web je navržen jako souhrn několika na sebe navazujících vrstev. Jedno z možných schémat je vidět na obrázku 2.2. Adresování je založeno na URI. Univerzální syntaktický základ je XML. Další vrstva je RDF, sloužící jako primární datová struktura pro uchovávání faktů. Ještě výše jsou ontologie, které dávají faktům sémantiku a mohou být zapsány například pomocí jazyka OWL. Ontologie mohou sloužit jako nástroj pro odvozování, ale mají omezené možnosti. Lze implementovat algoritmy pro testování jejich konzistence a příslušnosti individuí ke třídám. Z ontologií nelze vyvozovat nová fakta, kromě těch, která vychází z příslušnosti individuí k jejich třídám. Proto se vytváří další pravidlová vrstva, která vychází ze zkušeností s deduktivními databázemi a také ze zkušenostmi s věcnými pravidly v informačních systémech, aktivovanými pomocí událostí. Poslední vrstva zabezpečuje věrohodnost nalézaných i odvozovaných informací. [9]
Obr. 2.2. Schéma vrstev sémantického webu [9].
2.6
Nasazení ontologií v praxi
Množství aplikací ontologií nasazených dlouhodobě, tedy nejen například po dobu trvání určitého výzkumného projektu spolufinancovaného EU, v praxi stále výrazně zaostává za objemem teoretického a aplikačního výzkumu. Přesto pozvolna roste zájem komerčních i neziskových organizací, který je asi nejlépe patrný na statistikách prakticky orientovaných konferencí o sémantických technologiích – americké Semantic Technology Conference i evropské ESTC [16]. Lze říci, že nejlépe si, z hlediska všeobecného přijetí, vedou rozsáhlé doménové ontologie s jednoduchou strukturou a bez ambicí na rozsáhlejší automatické odvozování (např. medicínské či produktové taxonomie), a také poměrně malé ontologie, které jsou však spojeny s velkým objemem dat distribuovaně uložených v rámci sémantického webu (např. FOAF). Jednou z možných průlomových aplikací v prostředí velkých firem je připravované řešení managementu znalostí ve firmě Vodafone. Možnosti ontologií pro integraci informací a konkurenční zpravodajství jsou dlouhodobě zkoumány i dalšími telekomunikačními společnostmi. Mezi ně patří France Télécom, který se podílí na testování nástrojů sémantického webu, nebo British Telecom, jehož vývojové centrum přišlo s vlastním nástrojem pro konkurenční zpravodajství využívajícím ontologie – Data Foundry. Mezi další místa opakovaného nasazení ontologií patří instituce státní správy, kulturní organizace, například muzea, mediální agentury, průmyslové podniky (např. automobilky a výrobci letadel), firmy pracující v oblasti lidských zdrojů apod. Topic Maps se uplatňují např. jako základ dynamicky upravovaného informačního portálu norského ministerstva kultury. Samostatnou kapitolu 20
by si zasloužily aplikace lingvistických ontologií (např. WordNetu) při zpracování přirozeného jazyka, a tzv. extrakčních ontologií při získávání znalostí z WWW. Obecně je poměrně pomalý nástup ontologií jako běžného technologického řešení do praxe spojen se specifiky znalostních technologií jako takových: formalizované znalosti jsou (na rozdíl od jednoduchých dat) obtížně převoditelné do jednotné podoby, pro jejíž zpracování lze efektivně vyvinout hromadně šířený softwarový nástroj. Každý projekt zahrnující ontologie je proto do značné míry jedinečný a vyžaduje nasazení expertů s předchozími zkušenostmi jak s technologickým řešením tak i s věcnou oblastí. Na druhé straně však mají již vzniklé ontologie, při dodržení některých zásad naznačených i v tomto textu, solidní naději na opakované a dlouhodobé využívání [16]. Ontologie, konkrétně výhody sémantického webu, využívá také společnost Vodafone a to pro vyhledávací nástroje, například pro hry, pozadí či zvonění. Používají formát RDF. Po jejím nasazení se zlepšila přesnost vyhledávání a zmenšil se o 50% počet zobrazených stránek, což znamenalo snížení nevhodné zátěže serveru. Zároveň se však zvýšil samotný prodej těchto položek. Celkově tedy nasazení RDF znamenalo pro společnost Vodafone zvýšení úspěšnosti prodeje. Mezi další společnosti které zavádějí ontologie se řadí Nokia, která využívá výhody sémantického webu na svém diskusním fóru dostupném na adrese: forum.nokia.com. Také společnost Oracle zabývající se databázovými technologiemi již od verze 10.2 podporuje ontologie. Lze například provádět konverze nebo načítání RDF dat. RDF se ukládá nativně. Pro nalezení grafických závislostí lze použít funkci RDF_Match [17].
Obr. 2.6. Ukázka ukládací struktury RDF v Oracle [17].
21
3
Nástroje pro ontologie
Všechny ontologické jazyky lze editovat v klasickém textovém editoru, nebo v XML editoru. Přesto je lepší používat specializované nástroje pro tvorbu ontologií. V této kapitole zmíním asi nejpoužívanější jazyk Protégé, ze kterého lze exportovat do libovolného ontologického jazyka. Dalším zajímavým opensource nástrojem je Kaon, řešící ontologickou strukturu pro podnikové informační systémy. Lze vyzkoušet také nástroj Magpie, který řeší integraci ontologické znalosti do obecné HTML stránky za pomocí pluginu do nejznámějších internetových prohlížečů.
3.1
Protégé
Protégé je volně šiřitelný editor ontologií a rámcové báze znalostí. Platforma Protégé podporuje dva typy modelování ontologií, takzvané: Protégé-Frames a Protégé-OWL editory. Ontologie lze exportovat do mnoha formátů, hlavně však do RDF(S), OWL a XML Schema. Aplikace je založena na jazyce Java, je plně rozšiřitelná, s podporou pluginů. Což z ní vytváří základ pro rychlé vytváření prototypů a vývoje aplikací. V současné době má komunita zabývající se tímto editorem přes 66 tisíc členů vývojářů z akademické, vládní i soukromé sféry. Ti jej využívají k řešení znalostí při oblastech, jako: biochemie, shromažďování inteligence a modelování společnosti [7].
Obr. 3.5. Nástroj Protégé. Funguje na mnoha různých platformách: Win, MacOs, Linux, Unix. Funkcionalita Protégé může být rozšiřována implementací tzv. pluginů (přídavných modulů). Některé slouží pro vizualizaci ontologií (např. OWLViz plugin), import, export, validaci, zpracování přirozeného jazyka apod. Z praktického hlediska může být Protégé např. využito v lékařství - je možné vizualizovat, prohlížet velké a komplexní ontologie, porovnávat je co do jejich obsahu apod. Mezi důležité vlastnosti tohoto nástroje patří: •
Rozšiřitelný znalostní model. 22
• • • •
Přízpůsobitelné GUI (pomocí pluginů), od verze Protégé 4.0 Alpha možné měnit layout prostředí a grafický vzhled. Možný export i import ontologií zapsaných v různých formátech: XML, CLIPSu, HTML, OWL, RDF, Turtle, N-Triple, N3. Integrace s jinými aplikacemi: možné propojení Protégé s externími programy za účelem využití ontologie v inteligentních aplikacích (odvozování, klasifikace). Využití API pro přístup k ontologiím a programové manipulaci s nimi.
Prostředí Protégé má za sebou celkem bohatou historii. První verze, kterou vytvořil Mark Musen, byla zpřístupněna roku 1987. Původně to byl menší nástroj zaměřený na získávání znalostí (knowledge acquisition tool) pro pár specializovaných programů např. pro oblast lékařství. Od té doby se prostředí neustále vyvíjí. Stabilní verzí je verze 3.3.1 K dispozici je už i verze Protégé 4.0 Beta, která je jiná po stránce GUI a nabízí nové funkcionality. Jednou z nich je například možnost mít otevřených více ontologických modelů, v dřívějších verzích toto nebylo možné. Původním cílem bylo usnadnit práci znalostním inženýrům při vývoji tzv. znalostních bází. Obrázek 3.4 ukazuje souvislost mezi Protégé a znalostní aplikací obsahující bázi znalostí. Protégé není expertní systém ani program, který přímo slouží k jejich tvorbě, ale pomáhá vytvářet jejich jednu hlavní část - bázi znalostí. Tím, že bude báze znalostí vytvářena odděleně od tvorby znalostní aplikace, je možné ji lépe udržovat, spravovat [15].
Obr. 3.4. Protégé a znalostní báze [15].
3.2
Kaon
Jde o soubor nástrojů pro tvorbu a využívání ontologií vyvinutý na universitě v Karlsruhe pod opensource licencí. Ukázku pracovní plochy lze vidět na obr.3.1. Hlavní částí je tzv. Kaon API, což je hlavní aplikační rozhraní, zpřístupňující primární datovou vrstvu ontologie. Jeho základem je relačnědatabázová technologie. Jeho rozhraní lze nastavit pro ontologické inženýrství s operacemi nad třídami a transakční zpracování. Další volbou je zobrazení metadat RDF. Lze přistupovat i ke klasickým relačním databázím a na jejich základě vytvářet schéma ontologie. Nad tímto API rozhraní 23
lze následně spouštět celá řada dalších připravených nadstavbových aplikací, například pro tvorbu samotných ontologií, nebo generování webových portálů na základě ontologií. Také učení ontologií z textu nebo extrakci metadat z relačních databází.
Obr. 3.1. Uživatelské prostředí nástroje KAON.
3.3
Magpie
Knowledge Media Institut na Open University v Londýně vyvinul zajímavý nástroj s názvem Magpie pro sémanticky obohacené brouzdání sémanticky značenými webovými dokumenty. Magpie umožňuje identifikaci a filtrování konceptů, jež jsou předmětem uživatelova zájmu. Jedná se o plugin do Internet Exploreru nebo Mozilly umožňující integraci ontologické znalosti do obecné HTML stránky. Ukázka práce s tímto pluginem je vidět na obrázku 3.2. Před samotným označováním a vyhledáváním je třeba zvolit základní ontologii, protože obecná HTML stránka jí neobsahuje. Ukázkové ontologie jsou obsaženy v pluginu po instalaci. Demonstrační video s ukázkou použití tohoto nástroje je na [20].
24
Obr. 3.2. Ukázka integrace pluginu Magpie do Internet Exploreru verze 6 [20].
3.4
Semanticworks
Tento nástroj je navržen pro pohodlné vytvoření a editaci RDF schémat a ontologií OWL všech verzí. K tomuto účelu je vybaven standardním XML editorem, známý z editoru Altova XML Spy, dále nástrojem, který načte schéma, ontologii a vybere z ní třídy, vlastnosti, instance a ontologie. Veškerá data jsou zobrazena do tabulek a pomocí tlačítek lze plynule přejít do prohlížeče grafu RDF. Během editace nástroj sám stahuje definice použitých schémat a ontologií z internetu [11].
25
Obr. 3.3. Ukázka nástroje Semanticworks [11].
3.5
Další nástroje
Jednodušší a tudíž méně časově a paměťově náročný editor s důrazem na webové adresování a kombinování více ontologií je SWOOP, vzniklý na univerzitě v Marylandu. Mezi komerčními nástroji dnes patří k hlavním konkurentům TopBraid Composer od firmy TopQuadrant, OntoStudio (nástupce OntoEdit) od firmy Ontoprise. Tvorba Topic Maps je podporována zejména nástroji firmy Ontopia jako je OKS (Ontopia Knowledge Suite).
26
Obr. 3.6. Nástroj SWOOP [17]. Vzhledem k rostoucímu počtu dostupných ontologií se stále častěji nabízí možnost nevytvářet ontologii na zelené louce, nýbrž využít některou z ontologií již na webu dostupných. Analogicky k nedávné historii webových katalogů vs. vyhledávačů mají za sebou již svůj konec pasivní knihovny ontologií typu DAML Library. Popularitu si získávají indexovací a vyhledávací služby jako je Swoogle, případně novější OntoSelect či Watson zpravidla umožňují vyhledávat jak ontologie, tak i jimi anotované dokumenty. Zatímco Swoogle svým pojetím silně připomíná vyhledávač Google (s rozšířenou verzí algoritmu PageRank, nazvanou OntoRank), OntoSelect klade důraz na možnost vícejazyčného vyhledávání, a Watson na automatické hodnocení kvality nalezených ontologií a na možnost jejich kombinování. S vyhledáváním ontologií úzce souvisí jejich vzájemné mapování, které je často podmínkou integrovatelnosti nezávisle vzniklých aplikací. Hlavní webový rozcestník pro tuto oblast uvádí více než dvacet nástrojů pro zcela či částečně automatické mapování ontologií, vesměs se ale jedná spíše o experimentální prototypy. Ze specializovaných nástrojů pro učení ontologií z textů je třeba zmínit především Text2Onto a OntoGen, v obou případech se jedná o volně šířené nástroje [16].
27
4
Návrh ontologie pro inzerci aut
Tato ontologie by měla vystihovat co nejpřesněji doménu pro inzerci nových i ojetých aut. Jak již bylo řečeno v teoretickém úvodu, měla by být ontologie pro určitou doménu jistým kompromisem profesionálů z dané oblasti a to proto, aby jí všichni používali a nevznikly tak konkurenční ontologie. V rámci této diplomové práci jsem vytvořil návrh této ontologie. V České Republice zatím podobná ontologie pro inzerci aut neexistuje a jedná se tedy o úplně první návrh. Tato ontologie bude následně konzultována se všemi zainteresovanými firmami a na základě domluvy budou provedeny změny.
4.1
Motivace pro tvorbu
Dostáváme se tedy k pomyslnému důvodu pro vytváření ontologií. Současný stav je takový, že každý prodejce či inzertní portál používá své vlastní rozhraní a synchronizace nabídek probíhá pomocí XML souborů, kde jsou uloženy kompletní nabídky těchto vozidel, včetně informací o prodejcích. Bohužel neexistuje standardní rozhraní a tak se setkáváme s různými typy, názvy či vlastnostmi. Takovýto způsob zápisu je obtížně pochopitelný pro člověka a ještě hůře pro samotné počítače, protože v nich neexistuje sémantika. Inzertní portály tedy musí vytvářet desítky různých synchronizačních skriptů pro různé formáty. A problémy s nimi mají i vyhledávací roboti. Výhoda ontologií je zřejmá. K danému vozu bude existovat pouze jediné individuum. Inzertní portály si budou tyto individua pouze lokálně stahovat a ukládat do paměti. Budou probíhat noční aktualizační skripty. Takže například změna ceny pro prodávajícího bude velmi jednoduchá. Změní jí pouze jednou a změny se do pár hodin projeví všude. Další obrovskou výhodou bude oddělení ontologie s prodejci. U konkrétního vozu bude pouze objektová vlastnost s odkazem na konkrétního prodejce. Ontologie s prodejci bude použitelná i v jiné oblasti, například pro účely katastrálního úřadu či finančního úřadu. Takže oprávněný úředník bude mít okamžitě k dispozici pro daného prodejce jak soupis nemovitostí, informace o financích, tak i aktuálně prodávané vozy, či již prodané vozy. A tyto informace budou pochopitelné na základě vnořené sémantiky i pro počítačové systémy. Ostatně toto je důvod vytváření všech ontologií do různých doménových oblastí. Podčástí je také vytváření sémantického webu. Hlavním předpokladem sémantického webu je standardizovaný popis webových zdrojů, tedy textových informací, obrázků, zvuků a videí.
4.2
Textový popis
Ontologie dostala název auta a vytvořena byla v jazyce OWL, tedy kompletní název souboru je auta.owl. Tento název je vyhovující, protože podobný duplicitní název v celém internetu neexistuje. Obsahuje vytvořenou hierarchii tříd s auty podle značek a modelů. Mezi objektové vlastnosti patří typ karoserie, poháněná náprava, palivo či objekt prodejce. Datové vlastnosti vystihují například barvu vozu, cenu i s popisem, datum vložení, najeté kilometry, objem motoru, doplňující popis, výbavu, typ modelu, výkon v kilowatech a rok výroby. Zvláštní datovou vlastností je typ pro vkládání obrázků. Zde jsou připraveny dvě možnosti, jednak pro vkládání přímo do datového souboru přes formát base64Binary a také pro vkládání pouze přes URL odkaz na danou fotku. Podrobnosti k těmto vlastnostem budou uvedeny v kapitole 4.5.
28
4.3
Importované ontologie
Do této ontologie jsou importovány další potřebné samostatné ontologie a to ontologie s prodejci a ontologie s adresami. Všechny tyto ontologie také neexistovaly a musel jsem je vytvořit. Ontologie s prodejci je popsána v 5. kapitole. Obsahuje detailní informace o konkrétním prodejci. V ontologii s auty existuje objektová vlastnosti s odkazem na konkrétního prodejce z této ontologie. Na ontologii s prodejci navazuje ontologie s adresami, ta bude popsána v 6. kapitole.
4.4
Hierarchie tříd
Základní třídou je třída Auto, která má jako podtřídy značky různých automobilek. Pro každou značku poté existují další podtřídy s různými modely. Tato hierarchie je ukázána na obr 4.1. Jedná se z pochopitelných důvodů pouze o částečnou ukázku. Kompletní seznam značek a modelů je již vytvořen v této ontologii, která je součástí 2. přílohy. Aktualizace těchto tříd bude prováděna centrálně, avšak za asistence a dohody všech zúčastněných stran.
29
Obr. 4.1. Ukázka části hierarchie třídy auto. Specialitou a odlišností od současného stavu ve všech inzertních portálech je postupné zanořování těchto tříd, tedy hlubší hierarchie. Je to velká výhoda, pokud chce uživatel nalézt pouze konkrétní model auta, nebo ho zajímá celá modelová řada. V těchto případech nemusí složitě vyhledávat přes volitelné pole typu vozu nebo přes výkon vozu, ale stačí mu vybrat pouze konkrétní modelovou třídu. Ukázka je patrná u modelové řady 1 a 3 značky BMW, viz obrázek 4.3.
30
Obr. 4.3. Ukázka hlubší hierarchie tříd. Následují již třídy vytvořené pro popis jednotlivých vozů. Konkrétně se jedná o třídu karoserie, která obsahuje navzájem disjunktní podtřídy s jednotlivými typy. Další třídou je třída s palivem. Zde již jednotlivé podtřídy nejsou disjunktní. Disjunktní jsou pouze podtřídy benzín a nafta. Je to logické, protože naftový agregát může obsahovat v budoucnu pomocný vodíkový pohon. Poslední zajímavou třídou je poháněná náprava s navzájem disjunktními podtřídy s popisem poháněné nápravy.
31
Obr. 4.2. Ukázka hierarchie ostatních tříd. Následuje ukázka zápisu třídy Benzín, která je podtřídou třídy Palivo a je odloučená od třídy Nafta.
4.5
Vlastnosti s objekty
Objektové vlastnosti mají zcela jiný charakter než u běžných objektově orientovaných jazyků. Zde mají vyšší význam. Nejsou tedy vloženy do některé třídy, ale jsou přiřazovány k různým třídám, do různých domén. Totéž platí i pro datové vlastnosti. Důležitý údaj je rozsah, který udává ze které třídy může být daný přiřazený objekt.
32
První objektovou vlastností je hasKaroserie, která udává typ karoserie. Protože přiřazení této vlastnosti konkrétnímu autu vyžaduje přidání konkrétního objektu reálného světa, musel jsem pro všechny typy karoserie vytvořit vlastní individuum. Podobná situace nastala s objektovou vlastností pro palivo či pro poháněnou nápravu, vybírá se vždy z předpřipravených individuí. Poslední objektová vlastnost hasProdejce vyžaduje přiřazení konkrétního prodejce z ontologie prodejců. Doména je opět nastavena pouze pro auto.
4.6 • • • • •
• •
• • • • •
•
•
•
Datové vlastnosti hasBarva – Určuje barvu vozu v textové podobě. hasCena – Cena vozu v Kč a v číselné podobě. hasCenaPopis – Textový popis ceny. Může se zde zobrazovat také detailní informace o použitém leasingu a podobně. Nebo možnost slevy. hasDatumVlozeni – Přesné datum a čas vložení vozu do nabídky. hasDatumZmena – Datum poslední změny vozu. Tato vlastnost je primárně určena pro synchronizační automaty, kde roboti ihned vidí, zda došlo u auta k aktualizaci ceny, údajů nebo fotografií. hasImageBinary – Vlastnost pro přímé uložení obrázku do ontologie. Podrobněji bude popsána níže. hasImageURL – Slouží pro textové uložení URL s fotkou. Pro velké zatížení primárního serveru je potřeba aby si každý inzertní portál uložil fotografie lokálně na svůj server a prováděl pouze aktualizaci. hasNajeto – Uvádí počet najetých kilometrů. Pro převod z mil je třeba použít konstantu 1.60934. Tato konstanta je určena podle [12]. hasObjem – Určuje objem motoru v krychlových centimetrech. Hodnota se zaokrouhluje na celočíselnou hodnotu. hasPopis – Textový doplňující popis vozu. Zde lze uvádět počet majitelů, servisování vozu, celkový stav, či podmínky prodeje. hasTyp – Doplňující typ vozu. Jedná-li se například o vůz Subaru Impera, pak typ může obsahovat doplňující popis modelu, tedy například WRX Sti. hasVaha – Pohotovostní váha vozu v celých kilogramech. Tedy nikoliv celková váha vozu, jak se běžně chybně uvádí. Zde se jedná o váhu vozu bez užitkové hmotnosti, tedy bez posádky a zavazadel. hasVybava – Ve starých systémech se uvádí kompletní výbava, což bývá nadbytečná informace. Cílem je vkládat pouze nadstandardní výbavu oproti zcela sériovému základnímu vozu. hasVykon – Uvádí se výkon vozu v kilowatech. Další velmi častou jednotkou pro uvádění výkonu je metrická koňská síla (PS). Pro převod se využívá tento vzorec: 1 kW = 1,35962 k. Konstanta je určena podle [13]. hasVyrobeno – Rok výroby vozu. Nikoliv tedy rok uvedení do provozu.
Pro uložení fotografií přímo v datové části využíváme vlastnost hasImageBinary, která je datového typu base64Binary, který umožňuje zápis informací uložených v binární podobě. Nese informace uložené metodou Base64 podle doporučení http://www.w3.org/TR/2004/REC-xmlschema2-20041028/datatypes.html#RFC2045 . Popis tohoto datového typu je uveden v 5. příloze.
4.7
Příklad s individuem
Následuje ukázka zápisu individua a to konkrétně nabídky ojetého vozu Audi S3.
33
<S3 rdf:about="#auto000001"> 210 2000 Modrá Dohodou 1. Majitel, nebouraný. 18.2.2009 Klima, xenony. 45000 2.0 650000 2004 Podstatné je zde uvedení, že daný vůz patří do třídy S3 a tedy vnoření do stejnojmenného tagu. Každé individuum musí mít jedinečný identifikátor. V OO systémech bývá podobný identifikátor nazýván Object ID. Jsou zde vidět jak jednoduché datové vlastnosti, tak i objektové vlastnosti s druhem paliva, či karoserií. K těmto vlastnostem se přiřazují již dříve vytvořené individua z konkrétních tříd. Prodejce je identifikován taktéž odkazem na jiné individuum, v tomto případě z jiné ontologie.
34
5
Návrh ontologie pro prodejce
Na tuto ontologii se odkazuje ontologie s auty, kde individuum z této ontologie určuje prodávajícího konkrétního vozu. Jedná se ale o univerzální ontologii a bude použitelná i v jiných doménách. Proto jsem jí také oddělil od ontologie s auty.
5.1
Textový popis
Základní třída je Prodejce. Na rozdíl od ontologie s auty nemá tato třída žádné podtřídy. Další třídou je Typ, který určuje, zda je prodejce právnickou osobou, či fyzická osoba podnikatel nebo nepodnikatel. Třída Forma rozděluje prodejce na autobazary, autosalóny, autopůjčovny, dovozce nebo soukromého prodejce. Mezi objektové vlastnosti se řadí výběr typu a formy. Další důležitá objektová vlastnost je hasAdresa, která požaduje individuum z externí ontologie s adresami. Mezi datové vlastnosti se řadí datum založení účtu prodejce, název firmy, jméno, příjímení, email, login či telefon.
5.2
Hierarchie tříd
Třída Typ obsahuje již zmiňované typy prodejců. Všechny jsou navzájem oddělené a jeden prodejce nemůže nabývat více typů. Forma určuje typ prodávajícího. Na rozdíl od předchozí třídy je v této povoleno být členem ve více podtřídách, kromě soukromého prodejce. Tedy autosalón může být zároveň také autopůjčovnou.
Obr. 4.4. Hierarchie tříd ontologie s prodejci. Ukázka zápisu omezení pro typ prodejce: 35
5.3
Vlastnosti s objekty
Objektové vlastnosti jsou zde 3 a to hasAdresa pro určení individua z ontologie adres. Dále již zmiňované hasForma a hasTyp. Ukázka zápisu objektové vlastnosti hasForma, rozsah je nastaven na třídu Forma a je určená pro doménu Prodejce:
5.4 • • • • • • •
Datové vlastnosti hasDatumZalozeni – Přesné datum založení účtu s prodejcem. hasEmail – Kontaktní email. hasNazevFirmy – Úplné jméno firmy podle obchodního rejstříku. hasJmeno – Jméno soukromého prodejce či jednatele firmy. hasPrijimeni – Příjmení soukromého prodejce či jednatele firmy. hasTelefon – Telefon či mobil, vlastnost je textová, lze zapsat v libovolném formátu a dokonce i více telefonních čísel. hasLogin – Přihlašovací login prodejce do systému. Ukázka zápisu datové vlastnosti hasNazevFirmy: Doména je nastavena pouze pro třídu Prodejce a datový typ je String.
5.5
Příklad s individuem
Ukázka individua prodejce novik Pavel +420601222999 14.4.2005 Autosklo s.r.o. [email protected] Novák 36
Jsou zde jak datové vlastnosti, tak i zmiňované objektové vlastnosti pro výběr typu či formy prodejce. Důležitou objektovou vlastností je hasAdresa, která ukazuje na externí ontologii a výběr konkrétní adresy z individuí.
37
6
Návrh ontologie pro adresy
Jedná se opět o univerzální ontologii, v našem případě použitou pro ontologii s prodejci pro určení adresy. Lze jí ale použít v libovolné jiné doméně. Její využití je velmi široké.
6.1
Textový popis
Hlavní částí je třída s adresami. Na nejvyšší úrovni se určuje stát, dále je to město a mezi další podtřídy by se mohlo jednat o čtvrtě města. Objektové vlastnosti zde neuvádím, v budoucnu by se některé mohly vytvořit. Mezi datové vlastnosti patří například určení ulice, čísla domu, poštovního směrovacího čísla či textový URL odkaz na google mapu.
6.2
Hierarchie tříd
Hlavní členění třídy Adresa je na státy, následují města a v budoucnu také čtvrtě měst. Všechny podtřídy jsou navzájem oddělené. Pokud budeme chtít použít pro jednoho prodejce více adres, využijeme 2 nezávislých individuí s adresami.
Obr. 4.5. Hierarchie tříd v ontologii adres.
6.3 • • • •
Datové vlastnosti hasUlice – Textová vlastnost se jménem ulice. hasCisloDomu – Celočíselná vlastnost s číslem popisným. hasPSC – Celočíselný typ, poštovní směrovací číslo. hasGoogleMapURL – Textový URL odkaz s přímou adresou na mapový server společnosti Google. Ukázka zápisu celočíselné vlastnosti hasCisloDomu:
38
6.4
Příklad s individuem
Ukázka individua adresy z Ostravy: 34101 41 Dvorská
39
7
Převod XML na OWL
Protože přechod na ontologie nebude zřejmě revoluční, ale postupně zaváděný, je třeba připravit nástroj pro převod existujících dat v XML na zápis inzerce v jazyce OWL. Tento vytvořený konvertor bude vhodný například pro autobazary, aby mohly do nového systému přidávat svojí nabídku vozů přes stávající XML formát. Je to ovšem pouze dočasný stav, než přejdou na přímý převod do jazyka OWL. Vytvořím tedy převodní nástroj v jazyce PHP.
7.1
Popis zdroje dat
Protože většina českých autobazarů využívá k exportu software Autosoft, nebo alespoň používá jejich formát zápisu XML, vytvořím nástroj pro tento formát. Následná úprava na jiný formát bude velmi jednoduchá. Aktualizační XML soubory jsou k dispozici ke stažení ve zkomprimovaném formátu ZIP. Název souboru se odvíjí od uživatelského jména na serveru AutoSoft.cz, nebo libovolného jména v případě nepoužití Autosoftu. Pro každou třídu XML lze pomocí speciálního jazyka přesně formálně definovat, jaké elementy lze v dokumentu použít, jaké mohou mít atributy a obsah. Těmto jazykům se říká jazyky pro definování schématu dokumentu. Historicky nejstarší a nejznámější je DTD (Document Type Definition), nebo v současnosti častěji používané XML schémata (viz kapitola 2.2.2.). V našem případě však většina XML souborů obvykle není formálně definovaná a předávají se formou komentovaných ukázek, viz následující příklad. Zkrácená ukázka zápisu vozu v XML: A05887 29.9.2008 osobni <manufacturer>Porsche <model>911 Carrera 4S 997 black <state>D inz_benzin km 32800 2006 <engine_power>261 <engine_volume>3824 kabriolet 2 <pocet_mist>4 <stk>09/2010 inz_used <price_base>2299300 <price_currency_code>CZK <doplnkova_vybava>DVD <note>aktuální cenu naleznete na www.malovany.cz <not_crashed>Nehavarový <user_info10> <equipment> <equipment_id>eq_abs 40
<equipment_id>eq_xenon 46568 http://www.autosoft.cz/madiracing/A05887_1.JPG <main>1 56031 http://www.autosoft.cz/madiracing/A05887_2.JPG <main>0 Formát druhého nejpoužívanějšího programu TEAS je velmi podobný, avšak zásadně se liší způsob vkládání obrázku. Jak je patrné na ukázce, tak formát Autosoftu vkládá fotografie jako URL odkazy. Formát TEASu je vkládá přímo do XML jako typ base64Binary (viz 5. příloha).
7.2
Obecný návrh systému
Je potřeba navrhnout jednak parser pro současný formát XML a poté následný export do formátu jazyka OWL. Aby nedocházelo k duplicitě při vytváření individuí je třeba kontrolovat, zda-li se již dané individuum nenachází v hlavním OWL souboru. Protože by bylo procházení tohoto souboru časově velmi náročné, navrhnul jsem vytvořit centrální databázi aut a i prodejců z tohoto souboru, například v MySQL. Kontrola duplicit aut či prodejců bude fungovat na principu volání například php skriptu, který provede porovnání s databází a odpoví. V této databázi je vyhledávání duplicit velmi rychlé. V budoucnu by mohla existovat paralelní záložní databáze na jiném serveru. Návrh této databázové struktury je v příloze 1. Diagram nasazení celého systému je na obr. 7.2.
Obr. 7.2. Diagram nasazení celého systému. 41
Nyní popíši činnost systému. Autobazary mají možnost exportovat svá data jak ve starším formátu XML, tak i již v sémantickém OWL. V případě použití XML se využije komponenta synchronizačního serveru pro parsování XML. Následně provede systém kontrolu zda se již daný vůz nenachází v ontologii aut a provede vložení, aktualizaci nebo smazání nabídky. Pro rychlejší vyhledávání se používá databázový server, který dané vozy kontroluje a vyhledává duplicity a změny. Přes tento databázový server se již přímo vytváří daná ontologie aut i prodejců. V současné době se nachází popis ontologie i všechna individua v jednom souboru. V budoucnu bude tento soubor rozdělen na dvě části, takže individua se budou nacházet v samostatném souboru. Fotografie se předávají formou url odkazů. V databázi budou uložena pouze metadata těchto fotografií a tedy jejich velikost, datum vytvoření a podobně. Podle těchto metadat lze určit potřebu případné aktualizace fotografií. Pro lepší dostupnost se obrázky kopírují z odkazů od prodejců přímo do souborového serveru. V diagramu je patrná pouze logická cesta vedoucí přes databázi, protože odkazy se sice kopírují přímo od autobazarů, ale to se děje automaticky a autobazary nemají přímý přístup do tohoto souborového serveru. Aby bylo možné využívat možností ontologií naplno, je třeba použít také ontologii adres. Ta bude potřeba v budoucnu vytvořit například s pomocí katastrálního úřadu, který by prováděl aktualizaci adres přes jejich geografický informační systém. Ontologie adres by se mohla vytvářet automaticky z jejich databázového serveru. Inzertní portály poté vezmou owl soubor prodejců a aut, owl soubor adres a obrázkové soubory s fotografiemi, které pomocí owl parseru převede do interních databází a zobrazí nabídku všech vozů pro potenciální uživatele. Tyto data se mohou zobrazovat například pomocí html ve webových prohlížečích. Tuto synchronizaci mohou inzertní portály spouštět v noci, nebo také několikrát denně. Inzertních portálů může být napojeno obecně neomezené množství. Nyní se již dostáváme k vlastní výhodě ontologií a to je jednotnost těchto dat, které jsou platné pro všechny inzertní portály. A tím mám na mysli jak vlastní data s konkrétními nabídkami vozů, tak i metadata. V současné době není problém narazit v nabídkách portálů na vozy, které jsou již prodány. Nebo například na rozdílnost cen vozů a dalších údajů. Totéž platí i pro kontaktní údaje u prodejců. Staré adresy, neplatné emaily a jiná telefonní čísla.
7.3
Implementace parseru
Ze zdrojového XML souboru získám data pomocí obsluhy koncového tagu a podle konverzní tabulky. Příklad: if(eregi($nazev, "manufacturer")) { $znacka=$data2; $znackaXML=$data2; } if(eregi($nazev, "color")) { $barva=htmlspecialchars(barva($data2)); } if(eregi($nazev, "typkar")) { $karoserie=karoserie($data2); } if(eregi($nazev, "id")) { $importID=$data2; } Při vytváření individua je potřeba kontrolovat z centrální databáze vozů, zda-li se zde vůz již nevyskytuje. V případě existence se podle datumu kontroluje aktuálnost údajů a případná korekce. Pro toto byla vytvořena funkce owlKontrolaIndividua:
42
function owlKontrolaIndividua($importID) { $result7=MySQL_Query("SELECT * FROM AUTO WHERE ID_IMPORT='$importID' "); if (mysql_num_rows($result7)==0) { return false; //auto neexistruje } else { return true; //auto jiz existuje - nutna kontrola aktualizace! } } Následná změna rozlišení fotografií a případné vložení vodoznaku loga Sportovnivozy.cz se provádí pomocí následující funkce: function resizePicture($filename,$mimetype,$MAX_WIDTH,$MAX_HEIGH,$vodoznak) { if (isJpegFile($mimetype)) { list($ow, $oh) = getimagesize($filename); if ($MAX_WIDTH/$MAX_HEIGH > $ow/$oh) { $trimHeigh = true; } else { $trimHeigh = false; } if ($trimHeigh) { $new_h = $MAX_HEIGH; $new_w = round($ow/$oh * $MAX_HEIGH); } else { $new_w = $MAX_WIDTH; $new_h = round($oh/$ow * $MAX_WIDTH); } $dest = ImageCreateTrueColor($new_w,$new_h); $source = imagecreatefromjpeg($filename); imagecopyresampled($dest, $source, 0,0,0,0, $new_w, $new_h, $ow, $oh); //vlozeni vodoznaku if ($vodoznak) { $watermark='img/web/vodoznak.gif'; $imagesize_watermark = getimagesize($watermark); if ($imagesize_watermark && $imagesize_watermark[2] <= 3) { $img_watermark = ($imagesize_watermark[2] == 2 ? i imagecreatefromjpeg($watermark) : ($imagesize_watermark[2] == 1 ? imagecreatefromgif($watermark) : imagecreatefrompng($watermark))); imagecopymerge($dest, $img_watermark, imagesx($dest) - $imagesize_watermark[0] 5, imaesy($dest) - $imagesize_watermark[1] - 5, 0, 0, $imagesize_watermark[0], $imagesize_watermark[1], 50); } } imagedestroy($source); //uvolnim zabranou pamet //kvalita 92 (kdyz se neuvede, tak je 75 procent) imagejpeg($dest, $filename,92); imagedestroy($dest); //uvolnim zabranou pamet chmod($filename,0644); return true; } else { return false; 43
} } Podstatná je podmínka pro určení poměru stran obrazu, podle které se poté obraz zmenší a převzorkuje. Pro vložení vodoznaku se využívají php funkce pro prolínání obrázků. V tomto případě nastavíme polohu pro vložení grafického gif souboru. V neposlední řadě se určuje výsledná kvalita jpeg obrázku. Po zkušenostech jsem se rozhodl pro kvalitu 92%, která je rozumným kompromisem mezi kvalitou a velikostí. Pro převod datového typu Base64Binary na obrázek se využívá php funkce base64_decode: if((eregi($nazev, "b64")) and ($pocetFotek<$pocetFotekMax)) { $pocetFotek=$pocetFotek+1; file_put_contents("$adresar/$pocetFotek.jpg", base64_decode($data2)); }
7.4
Příklad konverze
Za účelem testování byly ontologie nahrány na můj portál Sportovnivozy.cz: • • •
http://www.sportovnivozy.cz/owl/auta.owl http://www.sportovnivozy.cz/owl/prodejci.owl http://www.sportovnivozy.cz/owl/adresy.owl
Jako databáze vzorových aut posloužila taktéž transakční databáze mého portálu. Funkce pro převod v následujícím příkladu využívá tato data. Bylo také vytvořeno testovací rozhraní na adrese: http://www.sportovnivozy.cz/index.php? akce=xhaklu00 . Toto slouží pro vyzkoušení vzorového převodu XML na jazyk OWL. Jsou zde k dispozici i duplicitní záznamy, aby bylo předvedeno i chování systému v případě naleznutí duplicit. Tato funkce využívá napojení na vzorovou databázi. Zdrojem je testovací soubor data.zip respektive data.xml a výstupem soubor export.owl. Vstupní data: http://www.sportovnivozy.cz/owl/data.xml Výstupní data: http://www.sportovnivozy.cz/owl/export.owl Prodejce byl zvolen z importované ontologie: &Ontology1235324081467;prodejce0001 Rád bych zde upozornil, že se jedná pouze o testovací rozhraní, vytvořené speciálně za účelem této diplomové práce. V létě tohoto roku budu dané ontologie konzultovat s ostatními portály a výrobci SW. Následně vytvořím již ostrou verzi těchto skriptů, které budou pokrývat veškerou funkčnost. V té době již bude známa stabilní podoba potřebných ontologií.
44
Obr. 7.1. Ukázka rozhraní pro transformaci XML do OWL na portálu Sportovnivozy.cz.
45
8
Závěr
Cílem mé diplomové práce bylo prozkoumat možnosti sdílení dat mezi informačními systémy založené na ontologiích. Konkrétně jsem se zaměřil na možnosti použití v oblasti inzerce motorových vozidel. Protože se jedná o relativně novou a v praxi nepříliš používanou oblast, bylo třeba se hlouběji zaměřit na teorii. V této práci jsem tedy teoreticky shrnul vše od vlastního pojmu ontologie, typy a strukturu ontologií, přes základní využívané technologie XML, XML schema a RDF. Až po vlastní ontologické jazyky RDF schema, DAML+OIL a OWL. Protože v praktické části vytvářím vlastní ontologii pomocí jazyka OWL, tak jsem se na tento jazyk zaměřil více i v této úvodní teoretické části a podrobněji popsal jejich třídy a vlastnosti. Stručně jsem se také zmínil o evolučním nasazování sémantického webu a využívání ontologií v praxi. Hlavní částí této diplomové práce bylo praktické vytvoření ontologie pro inzerci aut. Proto bylo potřeba vytvořit také pomocné ontologie s prodejci a s adresami. Aby byly tyto ontologie použitelné i pro současný stav na trhu, bylo potřeba vymyslet celý systém pro správu těchto ontologií a také pro možnou konverzi dat z XML do jazyka OWL. Zde vidím hlavní přínos této práce. Doufám, že tato práce najde praktické využití. V létě tohoto roku budou tyto ontologie upravovány po konzultaci s předními inzertními portály. Práce na tomto tématu mě velmi zaujala, bavila a byla pro mne velkým přínosem a budu v této oblasti rád pokračovat, protože věřím v její budoucí úspěšnost v praxi.
46
Literatura [4] [5] [8] [7] [1] [18] [11] [10] [2] [6] [9] [16] [12] [13] [19] [3] [20] [17] [14] [15]
Bertino E., Catania B., Zarri G. P.: Intelligent Database Systems. 1. vyd. Great Britain, London: Addison-Wesley, 2001, 458 s. ISBN 0-201-87736-8 Bráza J.: XML praktické příklady. 1. vyd. Praha: Grada Publishing, 2003, 212 s. ISBN 80-2470699-7 Crofts N.: Ontologies. Semantic Web and Libraries (26th Library Systems Seminar). Dokument dostupný online na URL: http://www.ifnet.it/elag2002/papers/pap9.html (16.12. 2008) Hanyáš P.: Sémantický web, bakalářská práce, Brno, FIT VUT v Brně, 2007, 41 s. Křemen J.: Modely a systémy. 1. vyd. Praha: Academia, 2007, 100 s. ISBN 978-80-200-1477-1 Pavlovič J., BC:xtalas:RDF. Dokument dostupný online na URL: https://kore.fi.muni.cz:5443/ wiki/index.php?title=BC:xtalas:RDF&printable=yes (27.3. 2009) Petrák J.: Altova SemanticWorks. Dokument dostupný online na URL: http://zapisky.info/? item=altova-semanticworks-2006 (22.2. 2009) Radek Stuchlík.: Ontologie a sémantický web, diplomová práce, Brno, FIT VUT v Brně, 2007. Skonnard A., Gudgin M.: XML. 1. vyd. Praha: Grada Publishing, 2006, 344 s. ISBN 80-2470972-4 Svátek V.: Ontologie a sémantický web. Dokument dostupný online na URL: http://nb.vse.cz/~svatek/onto-www.doc (9.12. 2008) Svátek, V., Labský, M.,: Objektové modely a znalostní ontologie. Dokument dostupný online na URL: http://nb.vse.cz/~svatek/obj03fi.pdf (15.12. 2008) Svátek V., Vacura M.: Ontologické inženýrství. Dokument dostupný online na URL: http://nb.vse.cz/~svatek/dkon07final.pdf (3.3. 2009) Wikipedia: Mile. Dokument dostupný online na URL: http://en.wikipedia.org/wiki/Mile (27.2. 2009) Wikipedia: Koňská síla. Dokument dostupný online na URL: http://cs.wikipedia.org/wiki/KoC5%88sk%C3%A1_s%C3%ADla (28.2. 2009) W3C Team, Turtle - Terse RDF Triple Language. Dokument dostupný online na URL: http://www.w3.org/TeamSubmission/turtle/ (1.4. 2009) Interval.cz – Co je XML?. Dokument dostupný online na URL: http://interval.cz/clanky/co-jexml/ (5.10. 2008) Magpie On-Demand Semantic Services. Dokument dostupný online na URL: http://projects.kmi.open.ac.uk/magpie/movies/iui2004/magpie-demo1.html (10.3. 2009) The Semantic Web In Practice. Dokument dostupný online na URL: http://www.w3.org/2005/Talks/0915-semweb-em (12.2. 2009) XML Schema. Dokument dostupný online na URL: http://xml.ic.cz/chapter5.html (28.2. 2009) Znalostní technologie. Dokument dostupný online na URL: http://lide.uhk.cz/fim/ucitel/fshusam2/lekarnicky/zt1/zt1_kap03.html (2.3. 2009)
47
Seznam příloh Příloha 1. Struktura hlavní databáze. Příloha 2. Návrh ontologií. Příloha 3. Transformační skript z XML do OWL. Příloha 4. CD se zdrojovými soubory. Příloha 5. Popis datového typu Base64.
48
Příloha 1. Struktura hlavní databáze. #CREATE DATABASE `OWL_AUTA` DEFAULT CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE ZNACKA ( ZKRATKA VARCHAR(64) NOT NULL, PRIMARY KEY (ZKRATKA) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE MODEL ( ZKRATKA VARCHAR(64) NOT NULL, ZNACKA_ZKR VARCHAR(64) NOT NULL, PRIMARY KEY (ZNACKA_ZKR,ZKRATKA), FOREIGN KEY (ZNACKA_ZKR) REFERENCES ZNACKA (ZKRATKA) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE PALIVO ( ZKRATKA VARCHAR(64) NOT NULL, POPIS TEXT NOT NULL, PRIMARY KEY (ZKRATKA) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE KAROSERIE ( ZKRATKA VARCHAR(64) NOT NULL, POPIS TEXT NOT NULL, PRIMARY KEY (ZKRATKA) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE KOLA ( ZKRATKA VARCHAR(64) NOT NULL, POPIS TEXT NOT NULL, PRIMARY KEY (ZKRATKA) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE AUTO ( ID DECIMAL(6, 0) NOT NULL, UZIVATEL_ID DECIMAL(6, 0) NOT NULL, ZNACKA_ZKR VARCHAR(64) NOT NULL, MODEL_ZKR VARCHAR(64) NOT NULL, PALIVO_ZKR VARCHAR(64) NOT NULL, KAROSERIE_ZKR VARCHAR(64) NOT NULL, TYP VARCHAR(64) NOT NULL, BARVA VARCHAR(64) NOT NULL, VYROBENO DECIMAL(4, 0) NOT NULL, NAJETO DECIMAL(6, 0) NOT NULL, OBJEM DECIMAL(6, 0) NOT NULL, VYKON DECIMAL(4, 0) NOT NULL, CENA DECIMAL(9, 0) NOT NULL, CENA_POPIS VARCHAR(128) NOT NULL, VYBAVA TEXT NOT NULL, POPIS TEXT NOT NULL, 49
DULEZITOST DECIMAL(3, 0) NOT NULL, DATUM_VLOZ DATE NOT NULL, ZRYCHLENI100 FLOAT NOT NULL, ZRYCHLENI200 FLOAT NOT NULL, VAHA DECIMAL(4, 0) NOT NULL, MAXIMALKA DECIMAL(3, 0) NOT NULL, KOLA_ZKR VARCHAR(64) NOT NULL, PRIMARY KEY (ID), FOREIGN KEY (ZNACKA_ZKR) REFERENCES ZNACKA (ZKRATKA), FOREIGN KEY (MODEL_ZKR) REFERENCES MODEL (ZKRATKA), FOREIGN KEY (PALIVO_ZKR) REFERENCES PALIVO (ZKRATKA), FOREIGN KEY (KAROSERIE_ZKR) REFERENCES KAROSERIE (ZKRATKA), FOREIGN KEY (KOLA_ZKR) REFERENCES KOLA (ZKRATKA), FOREIGN KEY (UZIVATEL_ID) REFERENCES UZIVATEL (ID) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; CREATE TABLE UZIVATEL ( ID DECIMAL(6, 0) NOT NULL, LOGIN VARCHAR(64) NOT NULL, HESLO VARCHAR(64) NOT NULL default '', JMENO VARCHAR(64) NOT NULL, PRIJMENI VARCHAR(64) NOT NULL, ADRESA TEXT NOT NULL, TELEFON VARCHAR(64) NOT NULL, EMAIL VARCHAR(64) NOT NULL, ROLE_ID DECIMAL(2, 0) NOT NULL, DATUM_VLOZ DATE NOT NULL, POTVRZEN BOOLEAN NOT NULL, JE_FIRMA BOOLEAN NOT NULL, DATUM_POSL DATE NOT NULL, PRIMARY KEY (ID), FOREIGN KEY (ROLE_ID) REFERENCES ROLE_UZIVATELE (ID) )TYPE = MYISAM CHARACTER SET utf8 COLLATE utf8_czech_ci; ALTER TABLE AUTO ADD AUTOSOFT VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE AUTO ADD VIDITELNOST BOOLEAN NOT NULL DEFAULT TRUE; ALTER TABLE AUTO ADD KREDIT DECIMAL(8, 0) NOT NULL DEFAULT 0; ALTER TABLE AUTO ADD SUPERSPORT BOOLEAN NOT NULL DEFAULT FALSE; ALTER TABLE AUTO ADD IP_VLOZ VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE AUTO ADD REZERVA VARCHAR(256) NOT NULL DEFAULT ''; commit; ALTER TABLE UZIVATEL ADD DATUM_INFO DATE NOT NULL DEFAULT '2007-0101'; ALTER TABLE UZIVATEL ADD DATUM_INFO2 DATE NOT NULL DEFAULT '2007-0101'; ALTER TABLE UZIVATEL ADD IP_VLOZ VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE UZIVATEL ADD IP_POSL VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE UZIVATEL ADD TEAS VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE UZIVATEL ADD AUTOSOFT VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE UZIVATEL ADD AUTOSOFT2 VARCHAR(256) NOT NULL DEFAULT ''; ALTER TABLE UZIVATEL ADD REZERVA VARCHAR(256) NOT NULL DEFAULT ''; commit; 50
INSERT INTO PALIVO VALUES('Benzín',''); INSERT INTO PALIVO VALUES('Nafta',''); INSERT INTO PALIVO VALUES('Hybridní pohon',''); INSERT INTO PALIVO VALUES('Elektrický pohon',''); INSERT INTO PALIVO VALUES('Vodíkový pohon',''); INSERT INTO KAROSERIE VALUES('Kupé',''); INSERT INTO KAROSERIE VALUES('Kabriolet',''); INSERT INTO KAROSERIE VALUES('CC',''); INSERT INTO KAROSERIE VALUES('Sportovní kombi',''); INSERT INTO KAROSERIE VALUES('Sportovní hatchback',''); INSERT INTO KAROSERIE VALUES('Sportovní limuzína',''); INSERT INTO KOLA VALUES('Přední',''); INSERT INTO KOLA VALUES('Zadní',''); INSERT INTO KOLA VALUES('4x4','');
51
Příloha 2. Návrh ontologií. Vlastní ontologie jsou příliš rozsáhlé a je zde uvedena pouze ukázka ontologie s prodejci. Kompletní ontologie včetně hlavní ontologie pro inzerci aut jsou k dispozici na přiloženém CD. ]>
52
54
!-http://www.semanticweb.org/ontologies/2009/1/Ontology1235324081467.owl#Fyzická_nepod nikatel --> !-http://www.semanticweb.org/ontologies/2009/1/Ontology1235324081467.owl#Fyzická_podni katel -->
55
<Soukromý_prodejce rdf:about="#forma_soukromy_prodejce"/> novik Pavel +420601222999 14.4.2005 Autosklo s.r.o. [email protected] Novák
56
57
Příloha 3. Transformační skript z XML. V této 3. příloze je k nahlédnutí pouze malá, ale podstatná, část transformačního skriptu. Další potřebné funkce a převodní číselníky jsou k dispozici na přiloženém CD. "; //funkce pro XML parser... function obsluhapocatecnihotagu($parser, $nazev, $atributy) { global $data2; $data2=""; } function obsluhakoncovehotagu($parser, $nazev) { global $data2,$znacka, $pocetFotek,$barva,$karoserie,$importID,$palivo,$model, $modelXML,$znackaXML,$typ,$typXML,$objem,$rok,$najeto,$vykon,$cenaPopis,$cena,$vybava, $popis,$adresar,$firmaID,$rowPrava,$row_prodejce,$jeSportovni,$hlavniFoto,$urlFotky, $najetoNasobit; $data2 = iconv("UTF-8", "CP1250//TRANSLIT",$data2); misto Windows-1250, mozna zmenim...
//Windows-1250 -- puvodne
if(eregi($nazev, "manufacturer")) { $znacka=$data2; $znackaXML=$data2; } if(eregi($nazev, "color")) { $barva=htmlspecialchars(barva($data2)); } if(eregi($nazev, "typkar")) { $karoserie=karoserie($data2); } if(eregi($nazev, "id")) { $importID=$data2; } if(eregi($nazev, "fuel")) { $palivo=palivo($data2); } if(eregi($nazev, "engine_volume")) { if ($data2 != "") { $objem=$data2; } } if(eregi($nazev, "rok_vyroby")) { $rok=$data2; } if(eregi($nazev, "engine_power")) { if ($data2 != "") { $vykon=$data2; } } if(eregi($nazev, "tachometr")) { if ($data2 != "") { $najeto=$data2*$najetoNasobit; } } // if(eregi($nazev, "vat-expel-text")) { $cenaPopis=$data2; } if(eregi($nazev, "price_base")) { if ($data2 != "") { $cena=round($data2); } } // if(eregi($nazev, "extra")) { $vybava=$vybava.$data2.", "; } if(eregi($nazev, "doplnkova_vybava")) { $vybava=htmlspecialchars($data2); } // if(eregi($nazev, "remark")) { $popis=$popis.$data2.", "; } if(eregi($nazev, "note")) { $popis=htmlspecialchars($data2); }
58
if(eregi($nazev, "model")) { $model=htmlspecialchars($data2); $modelXML=htmlspecialchars($data2); } if(eregi($nazev, "type")) { if ($typXML=="") { $typXML=htmlspecialchars($data2); } } if(eregi($nazev, "tachometr_unit")) { if ($data2=="mil") {$najetoNasobit=1.60934;} else {$najetoNasobit=1.0;} } if (eregi($nazev, "url")) { //omezim pocet fotek podle spravneho maxima dle prodejce $pocetFotekMax=$rowPrava[7]; if (($pocetFotek<$pocetFotekMax)) { $pocetFotek=$pocetFotek+1; $urlFotky[$pocetFotek]=$data2; } } if((eregi($nazev, "main")) ) { //nastavim spravnou hlavni fotku if ($data2=="1") {$hlavniFoto=$pocetFotek;}; //echo $hlavniFoto; } //vlozeni auta do databaze if(eregi($nazev, "car")) { //abych mohl provadet kontrolu i podle vykonu, karoserie a tak.... $znacka=znacka($znacka); $model=model($model); //pribude jeste parametr *sportovni automobil* primo v programu Autosoft! if ($jeSportovni) { //pokud vuz neni sportovni, nepokracuj s vkladanim... //jeste udelat omezeni na pocet maximalnich aut... if ($modelXML=="Ostatní") {$modelXML="";} if ($cenaPopis=="Cena") {$cenaPopis="";} if ($model=="Ostatní modely") { $typ="$modelXML "; } if ($znacka=="Ostatní značky") { $typ="$znackaXML $modelXML "; } $typ=$typ.$typXML; if (!ctype_digit($rok)) {$rok=1900;} $cisloAuta=$importID; $datum = date("Y-m-d"); // $dotaz = "INSERT INTO AUTO // VALUES($cisloAuta, $row_prodejce[0],'".addslashes($znacka)."','".addslashes($model)."','".addslashes($palivo)."','".addsla shes($karoserie)."','".addslashes($typ)."','".addslashes($barva)."',$rok,$najeto,$objem,$vykon, $cena,'".addslashes($cenaPopis)."','".addslashes($vybava)."','".addslashes($popis)."',1,'$datum','','',0,0, '','$importID','new',TRUE,0,FALSE,'','') // "; //echo $dotaz; $text = " <$modelXML rdf:about='#auto_$importID'> $vykon $objem $barva 59
$popis $datum $vybava $najeto $typ $cena $rok "; error_log($text, 3, dirname(__FILE__).'/owl/export.owl'); echo nl2br(htmlspecialchars($text)); //break; //konec jednoho auta } nulujHodnoty(); } } function znaky($parser, $data) { global $data2; $data2 .= $data; } //*****konec funkci pro xml parser... echo "Vytvořený OWL soubor: Export.owl
"; $jmenosouboruZIP=dirname(__FILE__)."/owl/data.zip"; if (!file_exists($jmenosouboruZIP)) {echo "Neexistuje soubor $jmenosouboruZIP"; logujAutosoft("Neexistuje soubor $jmenosouboruZIP\n"); continue;} /* $zip = new ZipArchive; if ($zip->open($jmenosouboruZIP) === TRUE) { $zip->extractTo(dirname(__FILE__).'/owl/'); $zip->close(); }*/ $jmenosouboru=dirname(__FILE__)."/owl/data.xml"; if (!file_exists($jmenosouboru)) {echo "Neexistuje logujAutosoft("Neexistuje soubor $jmenosouboru\n"); continue;}
soubor
$jmenosouboru";
nulujHodnoty(); //$parser=(xml_parser_create("ISO-8859-1")); $parser=(xml_parser_create("UTF-8")); xml_set_element_handler($parser, "obsluhapocatecnihotagu", "obsluhakoncovehotagu"); xml_set_character_data_handler($parser, "znaky"); //zmena typu xml z win-1250 na utf-8 60
$souborPom = fopen($jmenosouboru, "r+"); FSeek($souborPom, 30); FWrite($souborPom, "utf-8\"?> "); fclose($souborPom); if(!($soubor=fopen($jmenosouboru, "r"))) { die("Nelze otevřít soubor ".$jmenosouboru."!"); } else { while ($d = fread($soubor, 4096)) { //kvuli cestine $d = iconv("Windows-1250", "UTF-8",$d); if(!xml_parse($parser, $d, feof($soubor))) { die("<script language=\"JavaScript\"> window.alert('Chyba XML v souboru ".$jmenosouboru." na řádku ".xml_get_current_line_number($parser).".\\n\\nKód chyby: ".xml_get_error_code($parser)."'); "); } } } echo "
"; xml_parser_free($parser); //a korektne uvolnim... //break; ?>
61
Příloha 4. CD se zdrojovými soubory. Na přiloženém CD se nachází: • • • •
Vlastní návrhy ontologií. Transformační skripty a všechny potřebné funkce. Návrh struktury relační databáze pro synchronizaci ontologií. Vzorový XML soubor jako příklad pro transformaci.
62
Příloha 5. Popis datového typu Base64. Datový typ Base64 používá pro ukládání tabulku 64 hodnot, ve které se vyskytují základní alfanumerické znaky a znak =, který se používá pro speciální účely. Postup převodu je následující: zápis v binární podobě se rozdělí po 6 bitech, následně se převede do dekadického tvaru a v tabulce se vyhledá příslušná hodnota. Například: Binární zápis 10010010 01011101 01000001 je rozdělen na sekvenci 100100 100101 110101 000001 a následně převeden do dekadického tvaru 36 37 53 1. Odpovídající zápis podle tabulky base64 (viz Tab. Příloha 5.1.) je kl1B [14].
Tab. Příloha 5.1. Tabulka base64 pro převod [14].
63
