ƒeské Vysoké U ení Technické v Praze Fakulta Elektrotechnická DIPLOMOVÁ PRÁCE Ontologie v E-Commerce

ƒeské Vysoké U£ení Technické v Praze Fakulta Elektrotechnická

DIPLOMOVÁ PRÁCE

Ontologie v E-Commerce

Praha 2004

Pavel Jisl

Prohlá²ení Prohla²uji, ºe jsem svou diplomovou práci vypracoval samostatn¥ a pouºil jsem pouze podklady (literaturu, projekty, SW atd.) uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu Ÿ 60 Zákona £.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V Praze dne 22.1.2004

Pavel Jisl

Pod¥kování Cht¥l bych pod¥kovat v²em lidem, bez kterých by tato práce nemohla vzniknout. V prvé °ad¥ vedoucímu diplomové práce, panu Vladimíru Ma°íkovi, a za podn¥tné konzultace panu Markovi Obitkovi. Mé pod¥kování dále sm¥°uje v²em osobám blízkým, a to hlavn¥ za morální podporu p°i studiu a tvorb¥ této práce.

Abstrakt

Práce se v¥nuje seznámením s pouºívanými datovými formáty v oblasti e-Commerce. Jsou popsány d·leºité formáty, vyuºívané p°i tvorb¥ jednotlivých datových formát·, zde se jedná hlavn¥ o jazyky XML, RDF(S) a OWL. Podrobný popis byl zam¥°en na podmnoºinu, která specikuje tvorbu a pouºívání produktových katalog·. P°i porovnání formát· cXML a xCBL byl kladen d·raz na porovnání zápisu shodných informací v jednotlivých datových elementech. Po získání znalostí o vyjád°ení informací byla diskutována moºnost p°evodu shodných dat a popis moºných problém·, které tento p°evod v jednoduché form¥ znemoº¬ují. Z diskuse byly vyvozeny záv¥ry, jak lze shodná data mezi formáty p°evád¥t a výsledkem byla implementace prototypu p°evad¥£e identických informací.

Abstract

The importance of e-Commerce is in growing importance of bussiness marketplaces. We discuss diculties with integrating dierent XML formats used for representing product catalogs. The rst part is about technologies, used for writing product catalogs. There is short description of XML-based languages - XML, RDF(S) and OWL. Next part describes two widely used standards of bussiness formats - cXML and xCBL, and special format OCF, used only for product catalogs. In the description it was taken care of interpreting the same information dierently described in dierent languages. After this there is discussion about posible chances of integrating and transforming the same information in dierent catalog formats. Using all previous knowledge the prototype of transformation tool of the same information was implemented.

4

Zadání diplomové práce • Seznamte se s problematikou ontologií, zejména pro oblast ECommerce. • Prove¤te pr·zkum pouºívaných nebo navrhovaných ontologií, vybrané ontologie porovnejte z hlediska vyjád°ení stejné informace. • Vyhodno´te moºnosti p°ekladu dat mezi r·znými ontologiemi. • Implementujte prototyp p°eklada£e identické informace, vyjád°ené ve vybraných ontologiích.

Obsah 1 Úvod

1

1.1 1.2

2 3

Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Seznámení s problematikou 2.1

2.2

4

Ontologie . . . . . . . . . . . . . . . . . . 2.1.1 Pojem ontologie . . . . . . . . . . . 2.1.2 Základní stavební kameny ontologií Datové formáty v E-Commerce . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Popis pouºitých jazyk· 3.1

4 4 5 6

9

Jazyk XML . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Historie . . . . . . . . . . . . . . . . . . . . 3.1.2 Vlastnosti . . . . . . . . . . . . . . . . . . . 3.1.2.1 Standardní formát pro vým¥nu dat 3.1.2.2 Jazyková podpora . . . . . . . . . 3.1.2.3 Konverze do dal²ích formát· . . . . 3.1.2.4 Kontrola struktury dokumentu . . 3.1.3 Základy jazyka XML . . . . . . . . . . . . . 3.1.3.1 Jazyk XML . . . . . . . . . . . . . 3.1.3.2 Denice typu dokumentu . . . . . 3.1.4 XML-Schema . . . . . . . . . . . . . . . . . 3.1.4.1 XPath . . . . . . . . . . . . . . . . 1

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

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

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

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

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

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

9 9 10 10 10 11 11 11 11 11 13 14

OBSAH 3.2

3.3

2 Jazyky RDF a RDFS . . . . . . . . . . . . . . 3.2.1 RDF . . . . . . . . . . . . . . . . . . . 3.2.2 RDFS . . . . . . . . . . . . . . . . . . Jazyk OWL . . . . . . . . . . . . . . . . . . . 3.3.1 Popis jazyka OWL . . . . . . . . . . . 3.3.1.1 Pouºití jmenných prostor· . . 3.3.1.2 Informa£ní hlavi£ka . . . . . . 3.3.1.3 Denice t°íd . . . . . . . . . . 3.3.1.4 Objektové a datové vlastnosti 3.3.1.5 Individua . . . . . . . . . . . 3.3.1.6 Omezení . . . . . . . . . . . . 3.3.1.7 Axiomy . . . . . . . . . . . . 3.3.2 OWL Lite, OWL DL, OWL Full . . . .

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

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

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

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

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

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

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

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

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

4 Popis vybraných formát· 4.1 4.2

4.3

Úvod . . . . . . . . . . . . . . . . . . . . cXML . . . . . . . . . . . . . . . . . . . 4.2.1 PunchOut . . . . . . . . . . . . . 4.2.1.1 Procurement PunchOut 4.2.1.2 PunchOut Chaining . . 4.2.1.3 Provider PunchOut . . . 4.2.2 cXML katalog . . . . . . . . . . . 4.2.3 Popis d·leºitých element· . . . . 4.2.3.1 ItemID . . . . . . . . . 4.2.3.2 ItemDetail . . . . . . . 4.2.3.3 IndexItemDetail . . . . 4.2.4 Záv¥r . . . . . . . . . . . . . . . . xCBL . . . . . . . . . . . . . . . . . . . 4.3.1 Popis d·leºitých element· . . . . 4.3.1.1 ProductCatalog . . . . . 4.3.1.2 CatalogHeader . . . . . 4.3.1.3 CatalogData . . . . . .

16 16 19 19 19 19 20 20 20 21 21 22 23

25 . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

25 25 26 26 26 28 28 29 29 32 32 33 34 34 34 34 37

OBSAH

4.4

3

4.3.2 Open 4.4.1 4.4.2

4.4.3

4.3.1.4 Pricing . . . . . 4.3.1.5 Product . . . . . Záv¥r . . . . . . . . . . . . Catalog Format . . . . . . . Open Catalog Protocol . . Formát OCF . . . . . . . 4.4.2.1 Element catalog 4.4.2.2 Element param . 4.4.2.3 Element product 4.4.2.4 Element category 4.4.2.5 Element attr . . 4.4.2.6 Element value . . Záv¥r . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Porovnání 5.1 5.2 5.3

5.4

Práce s poloºkami katalogu . . Porovnání d·leºitých element· Kategorizace zboºí . . . . . . 5.3.1 Kategorizace v cXML . 5.3.2 Kategorizace v xCBL . 5.3.3 Kategorizace v OCF . Zápis m¥ny a ceny . . . . . .

47 . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 P°evody mezi ontologiemi 6.1 6.2 6.3 6.4

6.5

37 38 40 41 41 41 42 43 43 43 44 44 46

Úvod . . . . . . . . . . . . . . . . . . Problémy . . . . . . . . . . . . . . . Dvouvrstvá integrace . . . . . . . . . Specikace pouºité procedury . . . . 6.4.1 Na£tení dokumentu . . . . . . 6.4.2 Tvorba OWL modelu . . . . . 6.4.3 Vyjád°ení identické informace Implementace . . . . . . . . . . . . .

47 47 48 48 48 50 50

52 . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

52 54 56 57 57 57 58 60

OBSAH 6.6 6.7

4 Dal²í vývoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Záv¥r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A Výstup aplikace: cXML v jazyku OWL

65

B Výstup aplikace: xCBL v jazyku OWL

68

C Výstup aplikace: soubor s mapováním

71

D Obsah p°iloºeného CD

73

Literatura

74

Seznam tabulek

77

Seznam obrázk·

78

Kapitola 1 Úvod Tato diplomová práce se zabývá ontologiemi, jejich pouºití v oblasti elektronického obchodování (E-Commerce) a moºnostmi p°evodu shodných informací, vyjád°ených v r·zných ontologiích. V první £ásti je seznámení s problematikou elektronického obchodování a s pouºívanými datovými formáty. Dále se práce zabývá popisem jazyka XML, jeho p°ínosu ke strukturovanému zápisu dat, publikovaných v síti Internet, a jeho moºnostem. Jsou popsány jazyky na n¥m zaloºené, pouºívané pro tvorbu produktových katalog·. Po seznámení se s pouºitými technologiemi jsou popsány dva nejd·leºit¥j²í datové formáty v oblasti e-Commerce a speciální jazyk pro zápis produktových katalog·. Popis je zam¥°en hlavn¥ na zápis informací, které jsou v jednotlivých formátech shodné, ale jinak zapsané. Po seznámení s t¥mito formáty následuje diskuse o moºnostech p°evodu identických informací. Jsou zde popsány problémy, které mohou nastat p°i p°evodu shodných informací. Na základ¥ t¥chto poznak· je popsána metoda p°evodu, podle které byl naimplementován prototyp p°evad¥£e t¥chto informací v jazyku Java.

1

1.1. Motivace

1.1

2

Motivace

S rozvojem moderních informa£ních technologií je moºné v posledních letech vypozorovat po£ínající orientaci výrobc· a obchodník· na tyto technologie. V¥t²ina rem zjistila, ºe nabídka sluºeb p°es Internet je pro n¥ jednodu²²í, ve své podstat¥ i levn¥j²í, a snáze najdou svou cílovou skupinu. Bez své domovské stránky a zaregistrování v internetovém katalogu jsou rmy mén¥ konkurenceschopné a mají na globálním trhu mén¥ ²ancí své zboºí prodat. To v²e je umoºn¥no pomocí internetových obchod·, které se dostávají aº k cílové skupin¥ zákazník·. Jiº je moºné si zboºí se v²emi informacemi jednodu²e prohlíºet, vybírat a nakoupit. Banky si tohoto sm¥ru v²imly a za velmi nízké poplatky umoº¬ují klient·m platit bezhotovostn¥ pomocí internetového bankovnictví. Výhody prodeje p°es Internet jsou z°ejmé. Zboºí je dostupné komukoli, kdo je k Internetu p°ipojen, není zde omezení regionální (jako t°eba u kamenných obchod·), a tak si nabídku m·ºe p°e£íst kdokoli kdekoli na sv¥t¥. Výhodou je jednoduchá aktualizace katalog·, kdy uºivatel vidí, kolik kus· je na sklad¥, kolik aktuáln¥ stojí nebo jaká je dostupnost. Výhodou je také operativní zm¥na prost°edí podle pot°eb uºivatel· (p°ístupnost webových stránek, ergonomie ovládání, rychlá zm¥na p°i nalezení chyby v programu). V²echny tyto p°edchozí my²lenky v²ak mají také své problémy. Je tedy nutné, aby se prodejci shodli na standardech, jak své výrobky budou nabízet. Prvním standardem, který vznikl na p·d¥ Organizace Spojených národ·, je EDI/FACT 1 (Electronic Data Interchange for Administration, Commerce and Transport. Vznikl v 60. letech 20. století mezinárodní organizace OSN2 , ISO3 a v ƒeské republice ƒSNI4 . Ov²em vzhledem ke sloºitosti a náro£nosti implementace tohoto standardu se za£ínají pouºívat otev°ené standardy zaloºené na formátu XML 1 UN/EDIFACT:

http://www.unece.org/trade/untdid/welcome.htm - CE/FACT: http://www.unece.org/cefact 3 ISO: http://www.iso.org/iso/en/ISOOnline.frontpage 4 ƒSNI: http://www.csni.cz 2 UN/ECE

1.2. Cíl práce

3

(eXtensible Markup Language ), které denují podmnoºinu pot°ebných dat a jejich implementace do remního softwaru není natolik sloºitá. To je umoºn¥no hlavn¥ existencí voln¥ ²i°itelných a jednodu²e dostupných knihoven pro práci s nimi. Tyto formáty v²ak za£alo na sob¥ nezávisle vyvíjet více rem a vzniklo n¥kolik nekompatibilních standard·. V²echny k zápisu vyuºívají XML, coº je výhodou, ov²em data v nich jsou zapsána r·zným zp·sobem. To p°iná²í dal²í nekompatibilitu v internetovém obchodování, protoºe prodejce m·ºe zvolit jakýkoli ze standard·, ale je moºné, ºe dal²í prodejce zvolí jiný a pak uº nemohou mezi sebou jednodu²e komunikovat.

1.2

Cíl práce

Cílem této práce je prozkoumat n¥kolik voln¥ dostupných datových formát·, které se pouºívají - nebo v blízké dob¥ pouºívat budou - v internetovém obchodování, porovnat zápis shodných informací a navrhnout moºnost p°evodu.

Kapitola 2 Seznámení s problematikou Tato £ást obsahuje seznámení s pouºívanými datovými formáty, s jejich historií a moºnostmi nasazení v prost°edí elektronického obchodu.

2.1

Ontologie

2.1.1 Pojem ontologie Ontologie je pojem, který pochází z losoe. V té se chápe jako nauka nebo soubor nauk o bytí nebo jsoucnu. Lze je také brát jako univerzální soustavu znalostí, popisující objekty, jevy a zákonitosti sv¥ta tak jak je. V oblasti informa£ních technologií ji bereme jako popis toho, co existuje. Vychází ze z denice T. Grubera:  ontologie je explicitní specikace konceptualizace  [4] a jejího roz²í°ení od W. Borsta:  ... formální specikace sdílené konceptualizace  [1]. V první denici je konceptualizace (tj. pojmy modelující £ást sv¥ta) specikována explicitn¥, tedy je n¥kde zapsána a je dostupná nejen autorovi. V druhé denici je jiº kladen d·raz na formalizaci, tedy pouºití jazyka s p°esn¥ denovanou syntaxí, a také na sdílení. Ontologie jiº není pouze záleºitost autora, ale vznikají spole£nou aktivitou a diskusí autor·, kte°í mají o vznik nebo roz²í°ení ur£ité ontologie zájem. Zjednodu²en¥ lze °íci, ºe ontologie ve znalostním inºenýrství jsou znalostní 4

2.1. Ontologie

5

modely, které popisují £ásti znalostního systému (modely). P°iná²ejí totiº slovník termín· a vztah· mezi nimi, kterými lze tyto modely denovat. V praxi se setkáváme s n¥kolika r·znými druhy ontologií.

• Doménové ontologie pokrývají znalost ur£ité £ásti sv¥ta • Generické ontologie pokrývají hlavní znalosti sv¥ta, p°iná²ejí jednoduché pojmy a koncepty pro v¥ci, jako jsou £as, stav nebo úloha. • Úlohové ontologie p°iná²ejí termíny specické pro ur£ité úlohy (nap°. ºe hypotéza náleºí do úlohové ontologie diagnózy).

2.1.2 Základní stavební kameny ontologií Základem ontologií jsou t°ídy (n¥kdy se také nazývá koncept, kategorie, pop°. rámec, coº je výraz pouºívaný spí²e v objektov¥-orientovaných jazycích), které ozna£ují mnoºiny konkrétních objekt·. T°ídy v pojetí ontologií jsou unární relace denované na domén¥ objekt·. Pokud jsou pro t°ídu ur£eny podmínky nutnosti a posta£itelnosti, pak se nazývají denované, jinak jako primitivní. Na mnoºin¥ t°íd je denována hierarchie (taxonomie). Individuum odpovídá konkrétnímu objektu reálného sv¥ta. Instance je termín ekvivalentní k individuu, ale ur£uje asociaci k ur£ité t°íd¥. Individua (na rozdíl od instancí) mohou být do ontologie vloºena i bez vazby na t°ídy. Vzhledem k zam¥°ení ontologií na popis koncept· (t°íd) n¥které jazyky nepodporují individua a pokud je pot°eba, pracuje se s ním jako se samostatnou t°ídou. Dal²í d·leºitou sloºkou ontologií jsou relace, tedy vztahy n -tic objekt·. Tyto relace jsou bu¤ libovolné logické podmínky, nebo p°eddenovaná omezení. Binární relace se nazývají slot nebo vlastnost (property ). Zvlá²tním typem relace jsou funkce, kdy jde o relace, u nichº je hodnota n -tého argumentu jednozna£n¥ ur£ena p°edchozími n−1 argumenty. Funk£ní slot se také nazývá atribut, pokud je denován pro v²echny instance t°ídy[9]. V ontologiích je moºné slot·m p°i°azovat vlastnosti. Pak je nazýváme jako meta-sloty. Nej£ast¥ji to je hierarchie, tedy vztah mezi nad°azeným a

2.2. Datové formáty v E-Commerce

6

pod°azeným slotem. Dal²ími meta-sloty jsou inverze, symetrie, tranzitivita, funk£nost nebo inverzní funk£nost. D·leºité vlastnosti jsou také deni£ní obor (domain) a obor hodnot (range).

2.2

Datové formáty v E-Commerce

Zde bych se rád v¥noval letmému seznámení s n¥kolika formáty, zaloºenými na XML v oblasti elektronického obchodu. Prvním z nich je cXML1 (commerce eXtensible Markup Language), vytvo°ený a udrºovaný rmou Ariba Inc. Jedná se o otev°ený, univerzální jazyk, jehoº hlavním cílem je tvorba katalog·, tzv. PunchOut protokolu (viz. kapitola 4.2.1) a platebních p°íkaz·. Zajímavým projektem je XML Common Business Library, ve zkratce xCBL2 . Stejn¥ jako i cXML i xCBL je otev°ený a voln¥ pouºitelný formát. O tento formát vytvo°ila a o jeho rozvoj se stará rma CommerceOne3 , na jejíº stránce je mnoho zajímavých informací o e-Bussinesu a e-Commerci. xCBL jako jazyk je postaven na standardu EDI/FACT, ale pro zápis je vyuºíván jazyk XML. Zápis je podobný jako v EDI/FACT a proto i p°evod mezi t¥mito dv¥ma formáty je snadný. Modulární systém pro tvorbu obchodních aplikací také nabízí konsorcium ebXML4 (Electronic Business using eXtensible Markup Language). Toto konsorcium nabízí ucelený standard, umoº¬ující rmám komunikovat a spolupracovat pomocí jednotného systému zpráv. Standard roz²i°uje standard EC/EDI o výhody komunikace ve formátu XML. ebXML je vyvíjeno konsorciem OASIS5 (Organisation for the Advancement of Structured Information Standards), coº je nezisková organizace, starající se o rozvoj e-bussines standard·. 1 cXML

- http://www.cxml.org - http://www.xcbl.org 3 CommerceOne - www.commerceone.com 4 ebXML: http://www.ebxml.org 5 OASIS: http://www.oasis-open.org 2 xCBL

2.2. Datové formáty v E-Commerce

7

Konsorcium W36 se v poslední dob¥ zam¥°uje také na sémantický web a ontologie pro práci s ním a vyvinulo standardní jazyk pro zápis ontologií. Tímto standardem je OWL7 , který vychází z jazyka DAML+OIL. OWL slouºí pro denici ontologií a s nimi souvisejícími bázemi znalostí. Tyto jazyky jsou zaloºeny na RDF (Resource Description Framework), jsou ale jsou spí²e my²leny pro pouºití v budoucnosti. Dal²í rmou, zabývající se vývojem formát· a zázemím pro elektronické obchodování, je RosettaNet8 . Tato rma navrhla celý komplex formát· a komunika£ních protokol·, které shrnula pod názem PIP - Partner Interface Processes. Celý postup návrhu, vlastní tvorby a zprovozn¥ní e-Commerce nebo e-Bussines serveru je na stránce RosettaNet velmi podrobn¥ popsáno. Samoz°ejmostí je podpora XML a otev°enost projektu. Vývojem formát· pro elektronické obchodování se jiº od roku 1979 zabývá konsorcium ASC X12 9 (Accredited Standards Committee), které bylo akreditováno ANSI institutem (American National Standards Institute). Toto konsorcium vyvíjí, udrºuje a publikuje standardy pro elektronickou vým¥nu dat (EDI) a to jak pro pouºití v USA (American National), tak pro OSN (UN/EDIFACT). Zajímavým po£inem je OCF - Open Catalog Format rmy MartSoft10 , který denuje jednoduché DTD pro práci s katalogy. Pomocí tohoto DTD lze reprezentovat, ukládat a p°ená²et obsah katalogu, který m·ºe obsahovat bu¤ jeden produkt, kategorii nebo podkategorii produkt· nebo celý produkt. Vzhledem k tomu, ºe se jedná o obecnou denici formátu, nedenuje kategorizaci produkt·. To z·stává na uºivateli. Na svých stránkách ale rma MartSoft nabízí p°evod z tohoto formátu do r·zných formát· katalog· jiných rem, nap°íklad do cXML, xCBL nebo do formátu pouºívaného rmou 6 W3

Consorcium - http://www.w3.org Ontology: http://www.w3.org/2001/sw/WebOnt/ 8 RosettaNet - http://www.rosettanet.org 9 ASC X12: http://www.x12.org 10 MartSoft - http://www.martsoft.com 7 Web

2.2. Datové formáty v E-Commerce

RosettaNet. Tato sluºba je nabízena na stránkách rmy MartSoft (viz. a 12 ), ale je z°ejm¥ placená.

11 http://www.martsoft.com/technology.htm 12 http://www.martsoft.com/products/ccc/

8 11

Kapitola 3 Popis pouºitých jazyk· 3.1

Jazyk XML

3.1.1 Historie Jazyk XML [11] (eXtensible Markup Language) je takzvaný zna£kovací jazyk, který slouºí pro obecnou denici formátu souboru. Dal²ími p°íklady t¥chto jazyk· je nap°. jazyk HTML, SGML nebo t°eba i jazyk, který se pouºívá pro tvorbu dokument· v programových balících TEXa LATEX. Jedním z prvních zna£kovacích jazyk· byl jiº zmín¥ný jazyk SGML (Standard Generalized Markup Language), který je denován v norm¥ ISO 8879 z roku 1986. Jeho moºnosti jsou velmi silné, lze samoz°ejm¥ denovat vlastní zna£ky (tagy) pomocí DTD (Document Type Denition, tedy denice typu dokumentu). Jeho komplexnost a velká roz²i°itelnost ov²em m¥la problém s jeho implementací a jednoduchostí pouºití, proto se p°íli² neroz²í°il. Tento jazyk byl vyuºit p°i tvorb¥ jazyka HTML (HyperText Markup Language), jehoº nejv¥t²í roz²í°ení umoºnil rozvoj Internetu a hlavn¥ jeho jednoduchost. V druhé polovin¥ 90. let bylo z°ejmé, ºe jazyk SGML je velmi dob°e navrºen, ale v praxi se vyuºívají jen jeho £ásti a proto jeho nejd·leºit¥j²í podmnoºina byla vybrána pro nový jazyk. Tento jazyk dostal název XML a o jeho standard se stará konsorcium W3 [16]. Je samoz°ejm¥ roz²i°itelný o nové 9

3.1. Jazyk XML

10

prvky pomocí DTD, ale jeho syntaxe je oproti SGML striktn¥j²í a mnoho parametr· nelze m¥nit. Tyto vlastnosti zap°í£inily ²iroké roz²í°ení jazyku XML do v²ech sfér Internetu, kde je t°eba uchovávat a zpracovávat mnoºství informacích. Jazyk XML se hodí stejn¥ k publikování dat na Internetu (jazyk XHTML, nový standard pro publikaci na WWW, který nahrazuje p°edchozí standardy HTML) jako pro uchovávání dat v databázích. Jeho výhodou je totiº zachycení d·leºitých informací o struktu°e uloºených dat.

3.1.2 Vlastnosti 3.1.2.1

Standardní formát pro vým¥nu dat

Jazyk XML je otev°ený formát, jehoº specikace je k dispozici zdarma pro kaºdého na stránce konsorcia W3. Tím je umoºn¥na jeho snadn¥j²í implementace oproti proprietárním datovým formát·m, jejichº specikace jsou obvykle pro vývojá°e nedostupné. Dal²í výhodou je, ºe celý jazyk XML je zapsán jako oby£ejný text a proto na jeho tvorbu a úpravu sta£í b¥ºný textový editor. Je samoz°ejmé, ºe plnohodnotné vyuºití v²ech vlastností umoºní pouze aplikace, která ho vytvo°ila, ale pro jednoduché úpravy je to výhoda.

3.1.2.2

Jazyková podpora

Jazyk XML byl od po£átku tvo°en jako multilinguální, o £emº sv¥d£í pouºitá jazyková sada ISO 10646. Tato jazyková sada je 32bitová, lze tedy do ní uloºit v²echny sv¥tové jazyky a ná°e£í. Lze tedy v dokumentu psát nejen £esky a n¥mecky, ale t°eba i japonsky a hebrejsky. Je samoz°ejmé, ºe 32bitová znaková sada je plýtváním místa, proto lze samoz°ejm¥ pouºít i standardní národní sady jako ISO 8859-2 nebo 16bitovou sadu UTF-8.

3.1. Jazyk XML

3.1.2.3

11

Konverze do dal²ích formát·

Dal²í výhodou jazyka XML je velmi jednoduchá konverze do jiných formát·. K této konverzi se pouºívá aplikace ²ablon. Nejjednodu²²í a asi nejznám¥j²í jsou ²ablony CSS, tedy kaskádové styly známé z HTML a XHTML. Ty lze ov²em pouºít jen pro formátování. Pro úplnou transformaci do jiného formátu se pouºívají speciáln¥ navrºené styly XSL (eXtensible Stylesheet Language). S tímto jazykem lze nap°. vypou²t¥t n¥které informace z dokumentu nebo generovat obsahy.

3.1.2.4

Kontrola struktury dokumentu

Vzhledem k moºnosti denice vlastních zna£ek je d·leºité, zda v na²em dokumentu pouºíváme zna£ky tak, jak jsme je nadenovali. To umoº¬uje soubor s DTD, kde je zapsané, jaké zna£ky pouºíváme, jaké mohou mít parametry a obsah. K tomu slouºí tzv. validity parser, který otestuje správnost XML souboru oproti zadanému DTD.

3.1.3 Základy jazyka XML 3.1.3.1

Jazyk XML

Jazyk XML je, jak jiº bylo zmi¬ováno, zna£kovacím jazykem (markup language ) a tyto zna£ky se nazývají elementy. Pomocí element· se pak ozna£ují d·leºité £ásti dokumentu. Elementy lze do sebe vno°ovat a tím zachytit strukturu dokumentu. V tabulce 3.1 je ukázka XML dokumentu s popisem.

3.1.3.2

Denice typu dokumentu

K vytvo°enému dokumentu je t°eba pro správnou £innost doplnit p°íslu²nou denicí typu dokumentu (DTD ), pak lze totiº automatizovat jeho validaci. P°i°azení DTD k dokumentu se provede vloºením °ádku (viz. 3.1)



12

3.1. Jazyk XML

XML dokument

popis



XML deklarace a specikace jazyka



p°ipojení DTD k dokumentu



ko°enový element



otevírací £ást párového elementu a atributy

Moje firma

text Moje rma je obsah elementu název



uzavírací £ást párového elementu



nepárový nebo prázdný element



uzav°ení ko°enového elementu

.. .

.. .

Tabulka 3.1: P°íklad XML dokumentu kde

katalog je název ko°enového elementu SYSTEM je klí£ové slovo, ur£ující, ºe následující atribut je URL souboru s DTD a ºe se jedná o denici privátní. Lze pouºít klí£ové slovo PUBLIC, které ukazuje, ºe se jedná o standardizované DTD a prohlíºe£ (nebo jiný nástroj) ji pak nemusí stahovat z Internetu. Po této denici následují dva atributy, první s ve°ejným identikátorem, druhý s URL pouºitého DTD. Denici lze samoz°ejm¥ také vloºit do XML souboru a tím nap°. upravit vloºená externí DTD. Ale vzhledem ke speciálnímu pouºití se zde touto moºností nebudu zabývat. V tabulce 3.2 je zobrazen ukázkový p°íklad souboru DTD, který popisuje elementy, které lze pouºít v p°íkladu 3.1. V této denici jsou pouºity symboly ?, * a +, ur£ující, kolikrát lze pod°ízený element v elementu pouºít. Zde je popis t¥chto element·:

13

3.1. Jazyk XML

denice ko°enového elementu element rma, lze pouºít element název a obecná data vý£tový typ, standardn¥ pouºito S.R.O.

Tabulka 3.2: Ukázka denice DTD

? - element nemusí být pouºit nebo m·ºe být pouºit jednou * - element nemusí být pouºit nebo m·ºe být pouºit n-krát + - element musí být pouºit alespo¬ jednou a | b - moºnost pouºití elementu a nebo elementu b

3.1.4 XML-Schema Vzhledem k tomu, ºe jednotlivé datové formáty jsou v r·zných aplikacích jazyka XML, musím se zde zmínit i o formátu XML-Schema [15], nebo´ v n¥m je zapsána denice formátu xCBL. XML-schémata byla vytvo°ena jako univerzální jazyk, který by m¥l nahradit v²echny existující jazyky pro popis struktury XML. Jeho denice je v²ak podle vývojá°· tak sloºitá, ºe se zatím moc neroz²i°uje. Moºnosti denice datových typ· jsou totiº tak veliké, ºe by si vyºádaly samostatnou denici. Lze nap°íklad ur£it typ také u element· a k dispozici jsou v²echny moºné datové typu, od numerických hodnot, p°es hodnoty logické, aº po r·zné typy

3.1. Jazyk XML

14

°et¥zc·, ale je samoz°ejm¥ moºné si denovat £i odvodit své vlastní typy. Lze si tak nap°íklad nadenovat element, u kterého bude ur£ená minimální a maximální délka °et¥zce nebo po£et desetinných míst u £ísel. V tabulce 3.3 je tedy vid¥t, jak v tomto jazyku nadenovat DTD pro p°íklad uvedený v tabulce 3.1. Jedná se samoz°ejm¥ o velmi jednoduchý ná£rt moºností jazyka XML-Schema, ale pro sloºit¥j²í denice je z mého pohledu jeho pouºití výhodn¥j²í neº pouºití DTD. To hlavn¥ z d·vodu, ºe denice v XML-Schema vypadá podobn¥ jako zápis v dokumentu, který ho pouºívá. Také dal²í moºnosti jsou robustn¥j²í, mohu zde zmínit nap°íklad moºnost nadenovat p°esné po°adí, v jakém mají být elementy pouºity (nap°. lze vyºadovat, ºe v elementu bude prvním elementem <jmeno> a druhým <prijmeni> a ne naopak), moºnost denice vý£tových (enumerate) typ·, union typ· a mnoho dal²ích vlastností, které usnadní autor·m práci s výslednými XML dokumenty.

3.1.4.1

XPath

XPath je standard konsorcia W3, který slouºí pro adresování £ástí XML dokumentu. Jeho pouºití vypadá podobn¥ jako odkazování v souborovém systému opera£ních systém·. Dále umoº¬uje r·zné manipulace s °et¥zci, £ísly a logickými hodnotami. XPath modeluje XML dokument jako strom uzl·. Za uzel se pak berou elementy, atributy a texty v elementech a atributech. Zde je zjednodu²ený popis (pro ná² p°ípad dosta£ující) nejd·leºit¥j²ích vlastností (pro podrobn¥j²í popis doporu£uji [14] a tutoriál [10]).

/AAA  vybírá ko°enový element (absolutní cesta) /AAA/BBB  vybírá v²echny elementy BBB, které jsou p°ímými potomky ko°enového elementu AAA //BBB  vybírá v²echny elementy BBB, které jsou kdekoli ve stromu /AAA/BBB/*  vybírá v²echny elementy, které jsou p°ímými potomky /AAA/BBB

3.1. Jazyk XML

15

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="katalog" type="katalogType" /> <xsd:complexType name="katalogType"> <xsd:sequence> <xsd:element name="firma" type="firmaType" minOccurs="1" /> <xsd:element name="platnost" type="xsd:string" /> <xsd:complexType name="firmaType"> <xsd:sequence> <xsd:element name="název" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:attribute name="id" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:attribute name="typ" type="typFirmy" fixed="S.R.O" /> <xsd:simpleType name="typFirmy"> <xsd:restricted base="xsd:string"> <xsd:enumeration value="S.R.O." /> <xsd:enumeration value="A.S." /> <xsd:enumeration value="V.O.S." /> Tabulka 3.3: P°íklad denice XML-Schématu k p°íkladu v tabulce 3.1.

3.2. Jazyky RDF a RDFS

16

/*/*/CCC  vybírá elementy CCC, které mají práv¥ 2 p°edky //*  vybírá v²echny elementy ve stromu /AAA/BBB[1]  vybírá prvního p°ímého potomka BBB elementu AAA /AAA/BBB[last()]  vybírá posledního p°ímého potomka BBB elementu AAA //@id  vybere v²echny atributy id //CCC[@id]  vybere v²echny elementy CCC, které mají atributy id //CCC[@*]  vybere v²echny elementy CCC, které mají jakýkoli atribut //CCC[@id='1234']  vybere v²echny elementy CCC, které mají atribut id rovný 1234

3.2

Jazyky RDF a RDFS

3.2.1 RDF RDF [12] (Resource Description Framework ) je jazyk, zaloºený na XML, který slouºí pro zápis metadat. P°i návrhu RDF byl kladen d·raz na moºnost automatizovaného zpracování informací obsaºených na Webu. Lze ho pouºít pro spoustu aplikací  od vyhledávacích agent·, p°es hodnocení obsahu (content rating) aº po popis ucelených WWW stránek. Datový model RDF je zaloºen na trojicích : subjektu, predikátu a objektu, které spole£n¥ utvá°ejí tvrzení (statement). Prvkem, který univerzáln¥ ukazuje na n¥jaký zdroj (kterým m·ºe být cokoli, na co se lze odkázat identikátorem), je zdroj (resource), který je jednozna£ne identikován pomocí URI 1 . Zdroj m·ºe vystupovat jak v roli subjektu, tak v roli objektu. Tímto objektem m·ºe být krom¥ zdroje také literál  primitivní datová hodnota. 1 Universal

Resource Identicator, zobecn¥ní b¥ºn¥ pouºívaných URL - Universal Resource Locator

17

3.2. Jazyky RDF a RDFS

subject

http://www.w3.org/Home/Lassila

Creator

predicate

http://www.w3.org/staffid/85740

Name

object

Ora Lassila

Email

[email protected]

Obrázek 3.1: Ukázka grafové representace RDF

Vlastní RDF umoº¬uje zapisovat data v r·zných reprezentacích. První moºností je znázorn¥ní pomocí grafu (obrázek 3.1). V této form¥ jsou subjekty a objekty znázorn¥ny jako uzly a predikáty jako orientované hrany. Dal²í moºností je zapsat data pomocí trojic v notaci N3 2 . V této notaci se data zapisují jako trojice na jedné °ádce, jak je ukázáno v obrázku 3.2. Poslední moºností je zapsat data pomocí XML. Pak se hovo°í o serializaci v XML, kdy jednotlivé prvky jsou °azeny za sebe do element· a atribut· XML. Pak získáme zápis, který je zobrazen v obrázku 3.3. Hlavní vlastnosti formátu RDF jsou:  moºnost zachycení sloºitých vztah· mezi zdroji  syntaxe zaloºená na XML  podpora slovník· metadat (nap°íklad Dublin Core3 , . . . ) 2 http://www.w3.org/DesignIssues/Notation3.html 3 Dublin

Core: http://dublincore.org, http://www.ics.muni.cz/dublin_core/

3.2. Jazyky RDF a RDFS

# Base: @prefix @prefix @prefix @prefix

rdf: s: : v:

18

. . <#>. .

v:Email "[email protected]" ; v:Name "Ora Lassila" . s:Creator . Obrázek 3.2: Graf 3.1 v zápisu N3

<s:Creator rdf:resource="http://www.w3.org/staffId/85740"/> Ora Lassila [email protected] Obrázek 3.3: Graf 3.1 zapsaný jako serializované XML

3.3. Jazyk OWL

19

 snadné automatizované zpracování a skladování v databázích  m·ºe být sou£ástí dokumentu, který popisuje, nebo samostatným dokumentem

3.2.2 RDFS RDFS4 (nov¥ se také vyskytuje název RDF Vocabulary Description Language ) je jazyk, roz²i°ující moºnosti jazyka RDF. Dopl¬uje do RDF t°ídy a binární relace, u kterých je moºné denovat jejich deni£ní obor a obor hodnot. Lze také denovat nad t°ídami a relace hierarchickou strukturu. Podrobn¥j²í informace o jazyku RDFS lze nalézt na stránce [13].

3.3

Jazyk OWL

Jazyk OWL5 (Web Ontology Language ) je jazyk, zaloºený na RDF, slouºící pro zápis ontologií. Roz²i°uje RDF a RDFS o dal²í elementy vztahující se k t°ídám a vlastnostem a tím z n¥j d¥lá plnohodnotný jazyk pro reprezentaci znalostí. Jazyk OWL se vyvinul z jazyka DAML+OIL, který vznikl spojením jazyka DAML6 (DARPA Agent Markup Language) a jazyka OIL7 (Ontology Inference Layer).

3.3.1 Popis jazyka OWL 3.3.1.1

Pouºití jmenných prostor·

Pokud chceme vyuºívat v na²em dokumentu elementy z jiných, jiº pouºitých ontologií, je nutné na za£átku vypsat jejich umíst¥ní s p°i°azením jména. Tím si zajistíme jistotu, ºe nedojde ke koniktu jmen u element·, 4 RDFS:

http://www.w3.org/TR/rdf-schema/ http://www.w3.org/2001/sw/WebOnt/ 6 DAML: http://www.w3.org/TR/daml+oil-reference 7 OIL: http://www.ontoknowledge.org/oil/ 5 OWL:

3.3. Jazyk OWL

20

které by byly denovány ve dvou (a samoz°ejm¥ i více) r·zných slovnících. Jejich seznam se zapisuje do ko°enového elementu .

3.3.1.2

Informa£ní hlavi£ka

Základní informace o souboru se zapisují do elementu owl:Ontology. V ní se denuje verze souboru, komentá°e a informace o p°edchozích verzích ontologií. Lze totiº nadenovat, ºe sou£asná ontologie je zp¥tn¥ kompatibilní s verzí p°edchozí (owl:backwardCompatibleWith), nebo ºe s p°edchozí verzí kompatibilní není (owl:incompatibleWith), m·ºeme ur£it p°edchozí verzi (own:priorVersion) a prohlásit ur£ité t°ídy nebo vlastnosti za p°ekonané a jejich za°azení v této verzi je z historických d·vod· a je moºné, ºe uº v dal²ích verzích za°azeny nebudou (owl:deprecatedClass, owl:deprecatedProperty).

3.3.1.3

Denice t°íd

T°ídy jsou základním stavebním kamenem ontologií a odpovídají jim hierarchicky uspo°ádané mnoºiny prvk· se shodnými vlastnostmi. T°ídy jsou popsány jménem (ale lze denovat i anonymní) a seznamem vlastností prvk· (nazýváme je také individua nebo instance t°ídy). T°ídy lze denovat n¥kolika zp·soby. Prvním je denice jen jménem. Tak získáme t°ídu, která nemá ºádné vlastnosti ani prvky, pouze existuje. Dal²í moºností je denice vý£tem prvk· pomocí owl:oneOf, kdy do tohoto elementu zapí²eme seznam prvk·. T°ídy lze obdobným zp·sobem denovat sjednocením (owl:unionOf), pr·nikem (owl:intersection) a dopl¬kem (owl:intersectionOf).

3.3.1.4

Objektové a datové vlastnosti

Objektové a datové vlastnosti jsou binární relace, spojující bu¤ dva objekty (objektová vlastnost) nebo objekt s datovou hodnotou (datová nebo datatypová vlastnost). Pokud je vlastnost objektová, pak

3.3. Jazyk OWL

21

je denována elementem owl:objectProperty, datové vlastnosti pomocí owl:datatypeProperty. Vlastnosti lze denovat stejn¥ jako t°ídy n¥kolika zp·soby. Prvním (nejjednodu²²ím) zp·sobem je prosté nadenování, tedy ºe vlastnost existuje. To je ale pro v¥t²inu aplikací nedostate£né, proto se vyuºívjí dal²í pomocné elementy. Prvním z nich je rdfs:subPropertyOf, která °íká, ºe vlastnost je podmnoºina vlastnosti jiné (mnoºina prvk· spl¬ujících jednu vlastnost je podmnoºinou mnoºiny prvk·, které spl¬ují vlastnost jinou). Dále je moºné nastavit deni£ní obor vlastnosti pomocí elementu rdfs:domain. Pak nemohou vlastnosti nabývat jiné prvky, neº prvky t°ídy, uvedené v tomto elementu. Obor hodnot lze omezit pomocí rdfs:range, kterým ur£íme t°ídu nebo datový typ, ze kterého budou hodnoty pocházet.

3.3.1.5

Individua

Individua nazýváme také instance nebo objekty a jsou to prvky t°íd. P°i denici v nejjednodu²²ím p°ípad¥ uvádíme pouze jméno individua, ale v b¥ºné praxi uvádíme o individuu více skute£ností. P°i denici individuí je nutné myslet na to, ºe je moºné, ºe se vyskytuje jiné individuum se stejným jménem, ale r·znými vlastnostmi (pop°. naopak, individuum se shodnými vlastnostmi, ale jiným jménem), pak vyuºijeme element· owl:sameAs (p°i pouºití vyjad°uje, ºe r·zná URI popisují ekvivalentní individua), owl:differentFrom (URI popisují r·zná individua) a pro ozna£ení více r·zných individuí lze vyuºít element owl:AllDifferent.

3.3.1.6

Omezení

V jazyku OWL je samoz°ejm¥ moºné denovat omezení nejen tak, jak bylo popsáno v sekci o t°ídách, ale také pomocí anonymní t°ídy, jejímiº prvky jsou instance spl¬ující omezení. Denice se provádí pomocí elementu owl:Restriction, který obsahuje jednotlivé poºadavky. Takto nadenované omezení se bere jako omezení lokální - vztahuje se na vlastnost pouze v p°ípad¥ jejího pouºití na konkrétní t°ídu. Omezení globální se naopak vztahují

3.3. Jazyk OWL

22

na vlastnost aplikovanou na jakoukoli t°ídu. Lokální omezení lze rozd¥lit na dva typy - omezení rozsahu hodnot (value constrains ) a omezení mohutnosti (cardinality constrains ). Rozsah hodnot se omezuje pouºitím element· owl:allValuesFrom  tedy v²echny hodnoty ur£ité vlastnosti mohou být pouze v daném rozsahu; owl:someValuesFrom  alespo¬ jedna z hodnot vlastnosti je v ur£eném rozsahu a owl:hasValue, kdy alespo¬ jedna hodnota vlastnosti se rovná zadané hodnot¥ v tomto elementu. Omezení mohutnosti (kardinality) se pouºívá, pokud chceme omezit po£et moºných hodnot ur£ité vlastnosti p°i denici t°ídy. Pro omezení kardinality shora (maximální po£et) se pouºívá owl:maxCardinality, pro omezení zdola (minimální po£et) owl:minCardinality a pro ur£ení p°esné hodnoty se pouºívá owl:cardinality. Tento element je v²ak v podstat¥ nadbyte£ný, protoºe ho mohou zastoupit elementy pro omezení zdola a shora. Jako datový typ p°i denici se pouºívá &xsd;nonNegativeInteger, která zajistí, ºe hodnota je celé nezáporné £íslo. Globálním omezením nazýváme takové omezení, které se vztahuje na vlastnost pouºitou na jakoukoli t°ídu. Pat°í sem krom¥ funkcionálních omezení také omezení deni£ního oboru a oboru hodnot (viz. 3.3.1.4). Funkcionální omezení (owl:FunctionalProperty) °íká, jaká je mohutnost vlastnosti. Vyjad°uje, ºe kaºdému individuu z deni£ního oboru p°íslu²í nejvý²e jedna hodnota z oboru hodnot. Pokud je na vlastnost aplikováno inverzní funkcionální omezení (owl:InverseFunctionalProperty), pak objekt ur£ený vlastností jednozna£n¥ denuje subjekt (individuum). Dal²ími omezeními je owl:inverseOf, denující inverzní vztah mezi vlastnostmi (nap°. p°edná²í je inverzní k poslouchá p°edná²ku ), owl:SymmetricProperty denuje symetrické relace a owl:TransitiveProperty °íká, ºe relace je transitivní.

3.3.1.7

Axiomy

Axiomy se pouºívají pro základní tvrzení o t°ídách (nebo vlastnostech). Nejd·leºit¥j²í tvrzení pro tvorbu hierarchických struktur je ele-

3.3. Jazyk OWL

23

ment rdfs:subClassOf, který °íká, ºe t°ída je podt°ídou jiné (obdobn¥ se pouºívá element owl:subPropertyOf, ale pro vlastnosti). Pokud jsou t°ídy shodné (mají stejnou mnoºinu individuí), pouºijeme element owl:equivalentClass (pro vlastnosti owl:equivalentProperty) a disjunkci t°íd denuje owl:disjointWith.

3.3.2 OWL Lite, OWL DL, OWL Full Jazyk OWL byl vyvinut ve t°ech verzích. Tyto verze se li²í v tom, jaké umoº¬ují vyuºívat jazykové konstrukce nebo pouºití t°íd, vlastností objekt· a individuí.

OWL Lite  Nejjednodu²²í verze jazyka OWL, která umoº¬uje denovat hierarchii a jednoduchá omezení. Dále zakazuje pouºití element· owl:oneOf, owl:unionOf, owl:complementOf, owl:hasValue, owl:disjointWith a owl:DataRange. Zakazuje také pouºití anonymních t°íd ve v¥t²in¥ element·. I p°es v²echna tato omezení umoº¬uje denovat nejd·leºit¥j²í vztahy, které by m¥la v¥t²ina programátorských nástroj· zvládnout.

OWL DL  (DL znamená Description Logic ). OWL DL nemá tolik omezení jako OWL Lite, ale oproti OWL Full p°iná²í omezení, jako nap°. vyºaduje odd¥lení t°íd, vlastností objekt·, datových element·, coº znamená, ºe t°ída zárove¬ nesmí být individuem. Mnoºiny vlastností (vlastnosti datového typu a objektové vlastnosti) musí být disjunktní - na datové vlastnosti nem·ºe být aplikovány elementy owl:inverseOf, owl:InverseFunctionalProperty, owl:SymmetricProperty a owl:TransitiveProperty. Dále nelze na transitivní vlastnosti, na jejich inverze nebo jim nad°azené vlastnosti, klást omezení kardinality. Axiomy musí být well-formed, nesmí ºádné jejich komponenty chyb¥t nebo p°ebývat, musí mít formát stromové struktury a musí se vyskytovat jako pojmenovaná individua.

3.3. Jazyk OWL

24

OWL Full  OWL Full se nebere jako podverze jazyka OWL, ale je to v podstat¥ jazyk celý. Lze vyuºít v²ech vlastností RDF bez omezení (nap°. owl:Class je to samé jako rdfs:Class).

Kapitola 4 Popis vybraných formát· 4.1

Úvod

Vzhledem k velké ob²írnosti formát· (viz. kapitola 2.2) jsem se rozhodl porovnat mezi sebou dva, cXML a xCBL a jako zajímavou alternativu také projekt Open Catalog Project. Pro porovnání jsem zvolil porovnání katalog·, protoºe z mého pohledu se jedná o jednu z nejzajímav¥j²ích £ástí. Katalog slouºí k nabídce zboºí dal²ím e-Bussines klient·m, ale lze je vyuºít také pro koncové zákazníky. V katalogu by m¥lo být zahrnuto nejen jaké zboºí se nabízí, jaká je jeho cena a popis, ale také kdo toto zboºí vyrábí, kdo ho dodává a jaké jsou moºnosti dodání. V t¥chto ohledech mi p°ijdou mnou vybrané datové formáty asi nejobsaºn¥j²í a vzhledem k dal²ímu vývoji také nejd·leºit¥j²í. Pokusím se tedy porovnat DTD a navrhnout moºný proces transformace pro p°evod katalogu z jednoho formátu do druhého.

4.2

cXML

Jak jsem se zmínil jiº v úvodní £ásti práce, cXML je formát zaloºený na XML a ve²keré d·leºité vlastnosti se denují v DTD. Formát cXML má

25

4.2. cXML

26

velmi obsáhlý katalog DTD, jeho velikost je okolo 65 kB, coº je p°ibliºn¥ 2000 °ádek. Ale rma Ariba nabízí DTD také rozd¥lené do men²ích celk·, které lze pouºívat jednotliv¥.

4.2.1 PunchOut Zde bych rád popsal jednu ze zajímavostí datového formátu cXML. Jedná se o protokol PunchOut. Je to jednodu²e implementovatelný protokol pro tvorbu interaktivní komunikace mezi partnery p°es Internet, která se provádí v reálném £ase zasíláním synchronních zpráv v jazyce cXML. Tím je umoºn¥na vým¥na aktuálních dat mezi aplikacemi a jednotný vzhled aplikací na vzdálených po£íta£ích. V následujících podkapitolách blíºe popí²u t°i existující druhy PunchOut.

4.2.1.1

Procurement PunchOut

Procurement1 PunchOut je alternativa ke statickým katalog·m. P°i pouºití této moºnosti lze stránky popsat jako interaktivní katalogy. Uºivatel místo toho, aby p°ímo vid¥l informace a ceny o produktech, stiskne tla£ítko, které ho p°enese na stránky katalogu dodavatele. Tam si uºivatel m·ºe prohlíºet informace o výrobcích, m·ºe si je vybírat a ur£it typ dodání. Po návratu z této aplikace se ve²keré informace o objednaném produktu objeví v uºivatelov¥ objednávce. To je zjednodu²en¥ zobrazeno v obrázku 4.1.

4.2.1.2

PunchOut Chaining

PunchOut Chaining2 je roz²í°ený Procurement PunchOut a to tak, ºe je moºné tyto PunchOuty z°et¥zovat. To umoº¬uje vlastnost cXML Path Routing. Lze tedy objednávky a dal²í zprávy PunchOut vracet obchod·m a dodavateli do fronty (viz. obrázek 4.2 a informovat v²echny zainteresované strany o kone£né objednávce. 1 procurement 2 chaining

 zprost°edkování  z°et¥zení

27

4.2. cXML

Obrázek 4.1: cXML: Interaktivní PunchOut sezení mezi uºivatelem a WWW stránkou dodavatele [23].

Obrázek 4.2: cXML: PunchOut Chaining [23].

4.2. cXML

28

Obrázek 4.3: cXML: Zasílání katalogu kupující organizaci [23].

4.2.1.3

Provider PunchOut

Provider3 PunchOut umoº¬uje p°enos komunikaci a p°enos sluºeb mezi aplikací, b¥ºící nap°. u dodavatele a jinou vzdálenou aplikací. Vzdálená aplikace pak m·ºe poskytovat sluºby jako je ov¥°ování kreditních karet nebo autorizace uºivatel·.

4.2.2 cXML katalog Katalogy v podání cXML jsou data, která nabízejí dodavatelé a organizace, pouºívající aplikace zaloºené na cXML (procurement application), mohou vid¥t nabízené zboºí a sluºby, které lze zakoupit. Tato procurement aplikace katalog p°e£te a uloºí ho do interní databáze (viz. obrázek 4.3). Po schválení katalogu kupující organizací, je tento katalog p°ístupný uºivatel·m, kte°í mohou vybírat poloºky a vytvá°et tak objednávky. Denice katalogu cXML (viz. [23]) je rozd¥lena do dvou hlavních element· - Supplier a Index. Element Supplier obsahuje v²echny d·leºité informace o dodavateli, tedy jeho adresu, kontaktí informace a moºnosti objednání. V elementu Index nalezneme ve²keré informace o nabízeném zboºí, tedy cenu, 3 provider

 dodavatel

4.2. cXML

29

mnoºství, výrobce a dal²í dopl¬kové informace.

4.2.3 Popis d·leºitých element· V této sekci je popis d·leºitých p°íkaz·, které se objevují v obrázcích 4.4 a 4.5. Nejvy²²ím elementem, který v²echny ostatní ohrani£uje je Index. Druhým nad°azeným elementem je element Supplier, který denuje informace o prodejci. Tuto informaci pak zve°ej¬uje nastavením hodnoty elementu SupplierID, na který se pak element Index odkazuje. Dal²í hladinou je IndexItem. V té mohou být elementy, které representují £innost, jakou má uºivatel p°i p°ijetí katalogu provést. Zde jsou t°i moºnosti £inností:

IndexItemAdd  vkládá nové poloºky nebo upravuje vlastnosti existujících poloºek v katalogu. Obsahuje elementy ItemID, ItemDetail a IntexItemDetail. IndexItemDelete  maºe poloºky z katalogu. Mazaná poloºka je identikována elementem ItemID. IndexItemPunchout  vkládá poloºku pro inicializaci komunikace PunchOut s WWW stránkou dodavatele. Má podobné vlastnosti jako IntexItemAdd, ale nevyºaduje informace o cen¥, ty jsou získány p°ímo ze stránky dodavatele. Obsahuje elementy PunchoutDetail a ItemID. 4.2.3.1

ItemID

Element ItemID jednozna£n¥ denuje zboºí, které p°íslu²í ur£itému dodavateli. Proto obsahuje dva elementy - SupplierPartID a SupplierPartAuxiliaryID. Pokud první z nich dostate£n¥ neidentikuje zboºí (nap°. lze zakoupit úpln¥ stejnou mechaniku CD-RW v krabici nebo pouze v igelitovém obalu - tj. stejné ozna£ení, pouze rozdíl v balení a cen¥), je nutné nadenovat je²t¥ druhý element.

30

4.2. cXML

Index loadmode

+ SupplierID + IndexItemAdd

?

+

Comments

IndexItem

+ IndexItemDelete

name type

+ IndexItemPunchout

IndexItemDetail

ItemID

SupplierPartID ?

* SearchGroup

ItemDetail

LeadTime

SupplierPartAuxiliaryID

? ?

Name

ExpirationDate

UnitPrice +

Money Description UnitOfMeasure

EffectiveDate

* SearchGroupData

+

* TerritoryAvailable

?

Currency alternateAmount alternateCurrency

Classification ManufacturerPartID

+ SearchDataElement name value

? ?

ManufacturerName URL

* Extrinsic

V grafu jsou zobrazeny symboly ?, * a +, ur£ující, kolikrát se daný element m·ºe pouºít. Jejich popis je na str. 12. Obrázek 4.4: cXML: Zjednodu²ený graf struktury elementu Index

31

4.2. cXML

Supplier corporateURL storeFrontURL

Name * SupplierLocation

SupplierID domain

+

OrderMethods

Address

+

?

OrderMethod

Contact

? OrderTarget

OrderProtocol

Obrázek 4.5: cXML: Zjednodu²ený graf struktury elementu Supplier

4.2. cXML

4.2.3.2

32

ItemDetail

Element ItemDetail obsahuje podrobné informace o zboºí. Musí obsahovat následující elementy:

UnitPrice  cena za jednotku zboºí, tento element obsahuje element Money a jeho podelementy currency, alternateCurrency obsahují typ m¥ny podle ISO normy 4217 [22]

UnitOfMeasure  denice jednotky zboºí podle standardu UN/CEFACT (doporu£ení 20) [18]

Description  slouºí k podrobnému popisu zboºí, m·ºe obsahovat element ShortName, tedy zkrácený popis Clasication  slouºí ke kategorizaci zboºí do skupin podle druhu zboºí Následující elementy jsou nepovinné, ale vhodné pro je²t¥ podrobn¥j²í popis zboºí:

ManufacturerPartID  identikace zboºí výrobcem ManufacturerName  jméno výrobce URL  www adresa výrobce, pop°. p°ímo zboºí Extrinsic  dopl¬ující informace ke zboºí 4.2.3.3

IndexItemDetail

Element IndexItemDetail denuje dopl¬ující informace o zboºí.

LeadTime  ur£uje dobu ve dnech, za kterou je moºné zboºí dodat ExpirationDate  ur£uje dobu, za kterou uº zboºí není platné (hodnoty podle normy ISO 8601 [20])

4.2. cXML

33

EectiveDate  ur£uje dobu, za kterou zboºí bude platné (hodnoty podle normy ISO 8601 [20])

SearchGroupData  slouºí ke specikaci informací, slouºících k vyhledávání

TerritoryAvailable  specikace zemí (ISO kódy zemí a/nebo kódy region· [17]), kde je zboºí dostupné

4.2.4 Záv¥r Jak je vid¥t, podpora tvorby katalog· v jazyku cXML je domy²lená do konce a snaºí se o zjednodu²ení návrhu pouze na nejnutn¥j²í kroky. Hlavní výhodu vidím v moºnosti ponechat katalog u prodejce a objednávat pomocí protokolu PunchOut z jeho katalogu. Katalog lze samoz°ejm¥ pouºívat i staticky, tedy tak, ºe se hodnoty z katalogu ukládají na server a p°i zm¥n¥ se obnoví.

4.3. xCBL

4.3

34

xCBL

Jazyk xCBL je op¥t zaloºen na XML, ale jeho denice nejsou zapsány v DTD jako u cXML, ale v jazyku XML-Scheme. Tento jazyk jsem zjednodu²en¥ popsal na stran¥ 13. Tento jazyk umoº¬uje p°ehledn¥j²í zápis formátu a toho je vyuºito v popisu jazyka xCBL. Pouºité elementy jsou popsány v jednotlivých souborech, pro kaºdý typ jeden. Celkem je t¥chto soubor· p°es 700 (v mnou pouºité verzi xCBL 4.0 beta) a zabírají tém¥° 4 MB disku. Ukázka denice jednoho z datového typ· (ProductIDType.xsd) je v tabulce 4.1. Oproti datovému formátu xCBL není dostupná p°íli² kvalitní dokumentace (cXML obsahuje 250ti stránkovou uºivatelskou p°íru£ku ve fromátu PDF, kde je v²e pot°ebné popsané). Tato dokumentace je v HTML a jedná se pouze o stru£ný popis element·. Pro p°ehlednost zápisu jsem vytvo°il hierarchický strom (obrázek 4.6), který zobrazuje hierarchii elementu ProductCatalog. Z obrázku je p°i porovnání se stromem katalogu v jazyku cXML (obrázek 4.4), ºe tyto dva katalogové formáty aº na n¥kolik odli²ností v názvech element· jsou tém¥° shodné. V dal²í £ásti se budu v¥novat popisu nejd·leºit¥j²ích element· tak, aby tyto shody byly patrné.

4.3.1 Popis d·leºitých element· 4.3.1.1

ProductCatalog

ProductCatalog je dokument, který se pouºívá k poskytování informací o zboºí (cena, popis, . . . ) mezi obchodními partnery. Lze ho ale vyuºít také k nastavení nestandardních atribut· zboºí a n¥kdy ho lze pouºívat jako nástroj vým¥ny nestandardních atribut· a kategorií zboºí.

4.3.1.2

CatalogHeader

CatalogHeader obsahuje administrativní informace o katalogu, jako je informace o dodavateli, poskytovateli katalogu a dal²ích, které se objevují

4.3. xCBL

35

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="rrn:org.xcbl:schemas/xcbl/v4_0/catalog/v1_0/catalog.xsd" xmlns:core="rrn:org.xcbl:schemas/xcbl/v4_0/core/core.xsd" targetNamespace="rrn:org.xcbl:schemas/xcbl/v4_0/core/catalog.xsd" elementFormDefault="qualified"> <xsd:import namespace="rrn:org.xcbl:schemas/xcbl/v4_0/core/core.xsd" schemaLocation="../../core/core.xsd"/> <xsd:complexType name="ProductIDType"> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="Type" type="BuyerSupplierCodeType" use="optional" default="Supplier"/> Tabulka 4.1: Ukázka denice datového typu ProductID (ProductIDType.xsd)

36

4.3. xCBL

ProductCatalog

CatalogHeader

CatalogSchema

CatalogID

CatalogData

Product

Pricing

CatalogDate CatalogPrettyName

Action

BaseProductNumber

CatalogLogoURL

ProductID

SchemaCategoryRefList

CatalogProvider

LeadTime

ProductIDExtension

PricingInformation

LeadTimeUOM

ExternalItemRef

SupplierAcount

ValidFrom

ProductIDStandard

DefaultLanguage

ValidUntil

CountryOfOrigin

IsReplacement

MinOrder

LotSize

ShortDescription

ProductName

ShortDescription

LongDescription

UOM

LongDescription

DefaultCurrency

ComparableUOM

CatalogContact

Manufacturer

ProductAttachement

ManuPartNumber

RelatedProduct

ObjectAttribute

Obrázek 4.6: xCBL: Zjednodu²ený graf struktury elementu ProductCatalog

4.3. xCBL

37

v 2katalogu.

CatalogID  unikátní identikátor katalogu CatalogDate  datum vytvo°ení katalogu CatalogProvider  specikuje poskytovatele katalogu. M·ºe obsahovat volitelný element Party nebo volitelný atribut ProviderID. Jeden z t¥cto element· (atribut·) musí být p°ítomen.

ValidFrom  specikuje dobu, od kdy je katalog platný ValidUntil  specikuje dobu, do kdy je katalog platný DefaultLanguage  specikuje defaultní jazyk, ve kterém je katalog poskytován. Hodnota se nastavuje atributem xml:lang, jehoº hodnota musí odpovídat specikaci RFC 1766 [21]

DefaultCurrency  specikuje defaultní m¥nu katalogu (podle normy ISO 4217 [22])

ShortDescription, LongDescription  krátký resp. dlouhý popis katalogu, lze pouºít více jazykových mutací, které se rozli²ují atributem xml:lang, jehoº hodnota musí odpovídat specikaci RFC 1766 [21]

4.3.1.3

CatalogData

Element CatalogData slouºí jako nad°azený element pro elementy, slouºící k p°esnému popisu zboºí. Obsahuje v sob¥ podelementy Product a Pricing.

4.3.1.4

Pricing

Element Pricing obsahuje v²echny ceny, p°i°azené jednotlivým produkt·m z jednotlivých cenových katalog·. Jeho podelement ProductIDRef

4.3. xCBL

38

resp. PriceCatalogIDRef je identikátor zboºí, kterému je cena p°i°azena resp. identikátor cenového katalogu, v n¥mº je zboºí za°azeno. Posledním podlelementem je ProductPrice, který jiº p°esn¥ popisuje cenu výrobku. Element je moºné opakovat, pokud je výrobku p°i°azeno více cen. Jeho podelementy:

Amount  cena výrobku (dekadické £íslo) PriceType  typ ceny Currency  ISO kód m¥ny (viz. [22]) UOM  jednotky zboºí dle [18] MinimumQuantity  ur£uje minimální po£et zboºí, které lze za ur£enou cenu odebrat

ShortDescription  krátký popis ceny ValidFrom  ur£uje, od kdy bude cena platná ValidUntil  ur£uje, do kdy bude cena platná PriceBasisQuant  ur£uje po£et zboºí, které je základem ceny (nap°. balí£ek po p¥ti kusech - zde bude uloºeno £íslo 5)

4.3.1.5

Product

V elementu Product nalezneme ve²keré elementy, které se p°ímo váºí ke zboºí. Jejich po£et je v²ak zna£ný (viz. obrázek 4.6), takºe v popisu vyberu jen ty z mého pohledu nejd·leºit¥j²í.

Action  ur£uje jaká akce se provede s katalogem. Tato hodnota se ur£uje nastavením atributu Value. Pokud je element prázdný, poloºky se p°idávají (Add), moºné hodnoty jsou: Add  p°idání do katalogu

4.3. xCBL

39

Update  obnovení Delete  vymazání Replace  p°epsání ProductID  unikátní identikátor zboºí ProductIDExtension  dodate£ný identikátor zboºí (viz. kapitola 4.2.3.1 o cXML)

ProductName  jméno zboºí. To lze uvést také v r·zných °e£ích pouºitím elementu vícekrát, ale s r·zným nastavením atributu xml:lang podle RFC 1766 (viz. [21]). Pokud není tento atribut nastaven, bere se jazyk angli£tina (en).

UOM  jednotky zboºí podle [18] Manufacturer  jméno výrobce nebo odkaz do elementu ListOfPartners LeadTime  doba, za kterou je moºné zboºí dodat. Je vyjád°ena v po£tu dní, pokud není ur£eno jinak elementem LeadTimeUOM, kterým lze nastavit £asové jednotky.

ValidFrom  udává datum, od kterého je zboºí dostupné ValidUntil  udává datum, od kterého bude zboºí nedostupné CountryOfOrigin  ISO kód (viz. [17]) zem¥ p·vodu zboºí MinOrder  minimální po£et zboºí, který lze odebrat. LotSize  ur£uje po£et zboºí, které lze objednat, jako by bylo jeden kus. Tedy, pokud bude LotSize=3 a MinOrder=5, pak zákazník bude muset odebrat 6 kus·.

ShortDescription, LongDescription  krátký resp. dlouhý popis zboºí.

4.3. xCBL

40

4.3.2 Záv¥r Jak je z p°edchozího popisu z°ejmé, formát xCBL je velmi silným popisným jazykem. Jeho katalog lze v podstat¥ pouºít na cokoliv, a´ uº zboºí nebo sluºby. To je v²ak vykoupeno vy²²í sloºitostí pouºití.

4.4. Open Catalog Format

4.4

41

Open Catalog Format

Open Catalog Format4 byl vytvo°en rmou MartSoft a slouºí k popisu produktových katalog· a k jejich ukládání a p°enosu. Pro komunikaci se pouºívá Open Catalog Protocol, také navrºený rmou MartSoft a implementovaný do jejich e-Commerce produktu IntuiCat 5 . Tento produkt v sob¥ obsahuje prost°edí IntuiCat pro práci s katalogy, databázi, schopnou ukládat do XML a WWW server. Toto °e²ení je navrºeno tak, aby bylo moºné vytvá°et hierarchické katalogy s d¥d¥ním atribut·, parametrizované a fultextové vyhledávání, spolupráci s lokálními a vzdálenými katalogy a vícedimenzionální pohled na data.

4.4.1 Open Catalog Protocol Open Catalog Protocol je zatím ve stádiu vývoje, ale plánuje se jeho standardizace konsorciem W3. Je to protokol zaloºený na XML, který umoº¬uje práci s komplexními daty katalog·. Skládá se z jazykov¥-nezávislé reprezentace dat katalogu, zaloºených na XML 1.0, a sady p°íkaz· pro práci s daty katalog·. Tento protokol lze p°irovnat k protokolu PunchOut, který vyuºívá cXML. Zjednodu²ený graf komunikace je v obrázku 4.7. Podrobn¥j²í popis v²ech p°íkaz· lze nalézt v [25].

4.4.2 Formát OCF Datový formát OCF, jehoº popis je v [24], je popsán bu¤ DTD dokumentem nebo XML Schématem. Jejich délka je velmi malá, v porovnání s cXML nebo xCBL, ale podle ukázkových p°íklad·6 , umíst¥ných na stránce rmy MartSoft, je jejich pouºití jednodu²²í a °ekl bych, ºe podobn¥ silné. Výhodou je také specikace Open Catalog Query Language (OCQL), které denuje dotazovací jazyk (op¥t zaloºený na XML), jehoº pomocí lze 4 http://www.oasis-open.org/cover/ocp.html 5 IntuiCat: 6 Ukázka

http://www.martsoft.com/products/index.html#INTUICAT OCF: http://www.martsoft.com/ocf/sample1-ocf2.ocf

42

4.4. Open Catalog Format

Open Catalog Format

Open Catalog Format

IntuiCat aplikace

IntuiCat aplikace

XML Parser

XML Parser Send/Receive Catalog Information OCP

Obrázek 4.7: OCP: Graf komunikace mezi katalogy. klást dotazy na katalogy. Jeho DTD je moºné nalézt op¥t v [24]. Na obrázku na stran¥ 45 je zobrazena hierarchická struktura hlavního elementu catalog. Z obrázku je dále patrné, ºe i p°es velkou jednoduchost návrhu lze tvo°it velmi sloºité, hierarchické katalogy. To je umoºn¥no opakováním nejd·leºit¥j²ích element·, které se v OCF vyskytují. To je schematicky zobrazeno te£kovanými ²ipkami.

4.4.2.1

Element catalog

Tento ko°enový element obsahuje podelementy param, category, product. Obsahuje atributy

id  identikátor katalogu name  jméno katalogu version  verze OCF, obvykle obsahuje £íslo 2.0

4.4. Open Catalog Format

4.4.2.2

43

Element param

Element param umoº¬uje nastavení d·leºitých informací o kategoriích nebo zboºí. Obsahuje atribut name, kde je uloºeno jméno a podelementy value a value-domain. Jméno elementu také m·ºe mít speciální význam. Pokud za£íná na 's-', myslí se tím parametry pro server (server-side), pokud na 'c-', tak klientské parametry (client-side) a parametry za£ínající na 'n-', jedná se o parametry sí´ové.

4.4.2.3

Element product

Element product m·ºe obsahovat parametry  param, atributy  attr a odkazy  link. Musí obsahovat atribut name, který ur£uje unikátní ID produktu. Dále m·ºe obsahovat atribut path, který ur£uje URL zboºí (pro doménu btb.martsoft.com je denováno URL jako ocp://btb.upyp.com/ /A/B/001). Dále element product obsahuje seznam atribut·, denovaných pro kategorii, a nastavuje jejich hodnoty. Pokud jsou jejich hodnoty prázdné, produkt tyto atributy nepouºívá. Elementy param a link nastavují parametry resp. odkazy na produkty.

4.4.2.4

Element category

Element category obsahuje strom kategorií. Tyto kategorie dále obsahují atributy, parametry, produkty a samoz°ejm¥ také dal²í podkategorie. Kaºdá z kategorií musí mít atribut name, který nastavuje jméno kategorie (nap°. pro po£íta£ové programy je název software). Lze dále nastavit unikátní identikátor kategorie (atribut id) a URL kategorie (atribut url). V elementu category se dále nastavuje seznam atribut· (jména a hodnoty - element attr), ale ne jejich hodnoty, ty nastavuje element product. Podelementem param lze nastavit speciální parametry kategorie a podelementem link URL jako odkaz na informace o kategorii.

4.4. Open Catalog Format

4.4.2.5

44

Element attr

Elementem attr lze nastavit vlastnosti produkt·. Obsahuje atribut name, kterým lze nastavit jméno, a atribut style. Jeho podelementy value a value-domain obsahují jednotlivé vlastnosti produkt·.

4.4.2.6

Element value

Elementem value jsou denovány typy pro atributy a parametry. Ty lze rozd¥lit do následujících skupin:

jednoduché hodnoty  nejjednodu²²í typy denované v OCF. Jsou p°eddenována £ísla integer, boolovské hodnoty (boolean), £ísla v plovoucí °ádové £árce (oat), jednotlivé znaky (char) a °et¥zce (string). P°:

vý£tové hodnoty  obsahují seznam jednoduchých hodnot intervalové hodnoty  obsahují ²kálu moºných hodnot prom¥nných. P°.:

uºivatelem denované  uºivatel si m·ºe nadenovat dal²í typy prom¥nných. Lze tak nap°íklad pouºívat hodnoty, vyjad°ující £as. P°.:

value

param

*

*

*

product

*

category

*

attr−map

*

link

*

Obrázek 4.8: OCF: Graf struktury elementu Catalog.

link

param

attr

*

value−domain

?

category

*

catalog

value−domain

?

attr

*

product

*

value

param

*

4.4. Open Catalog Format

45

4.4. Open Catalog Format

46

4.4.3 Záv¥r Denice jazyka OCF není tak striktní jako je u formát· cXML a xCBL, ale umoº¬uje autor·m vytvo°it produktový katalog p°esn¥ na míru poºadavk·m. Pro práci s katalogem bylo vytvo°eno n¥kolik dal²ích d·leºitých denic (jako je Open Catalog Protocol a Open Catalog Query Language ), které dal²í práci usnad¬ují. Výhodou je, ºe se ve v²ech p°ípadech jedná o jazyk XML, tudíº pro p°enos v²ech p°íkaz· protokolu OCP sta£í jakýkoli znakov¥ orientovaný protokol (nap°íklad HTTP nebo STP - Simple Trac Protokol). Podrobn¥j²í popis v²ech moºností OCP a OCF lze nalézt na stránce [24].

Kapitola 5 Porovnání 5.1

Práce s poloºkami katalogu

Jednou z d·leºitých v¥cí je práce s poloºkami katalogu. V tabulce 5.1 je porovnání p°íkaz·, slouºících k p°idávání a odebírání poloºek z resp. do katalogu. V cXML je p°idávání resp. odebírání °e²eno elementem ItemIndexItemAdd resp. ItemIndexItemDelete. V hierarchii pod t¥mito elementy následuje vlastní seznam zboºí. V jazyce xCBL je toto °e²eno tak, ºe kaºdé zboºí (product) má element Action, který p°idání (Add) nebo odebrání (Delete) nastavuje. Pokud je prázdný, bere se defaultn¥ akce p°idání zboºí.

Akce

cXML element

xCBL element

//ItemIndexItemAdd Add Vymazání z katalogu //ItemIndexItemDelete Delete P°idání do katalogu

Tabulka 5.1: Porovnání práce s katalogy

5.2

Porovnání d·leºitých element·

V tabulce 5.2 je porovnání d·leºitých element· jednotlivých formát·. V °ádcích tabulky je vºdy tu£n¥ jméno elementu a pod ním je cesta z ko°e47

5.3. Kategorizace zboºí

48

nového elementu podle standardu XPath. V tabulce jsou dále u element·, které mají ur£ený typ podle ur£ité normy, je tato norma zapsána. V¥t²inou jsou normy shodné, ale nap°íklad u ceny za jednotku zboºí formát OCF pouºívá sv·j vlastní typ, nadenovaný jako atribut elementu attr.

5.3

Kategorizace zboºí

Zboºí je výhodné za°adit do kategorií, do kterých logicky pat°í. Toto rozt°íd¥ní je výhodné pro vyhledávání poºadovaného zboºí, ale také pro orientaci zákazník·.

5.3.1 Kategorizace v cXML Datový formát cXML pouºívá pro kategorizaci element Classication, jehoº atribut domain ur£uje typ mapování kategorií. Je vyºadováno pouºití kategorií tak, jak je denuje standard UNSPSC v [19].

5136030000

5.3.2 Kategorizace v xCBL V xCBL jsou kategorie denovány pomocí elementu CatalogSchema. Pouºitím tohoto elementu se specikuje pouºitá verze (SchemaVersion) a druh katalogu (SchemaStandard), kterým je obvykle UNSPSC . Vlastní druh zboºí se pak denuje v elementu Product a má v atributu SchemaCategoryRef nastaven seznam kategorií, do kterého pat°í.



//Product/ProductName

ShortDescription //Product/ShordDescription //Product/Manufacturer

ProductPrice (ISO 4217) //Pricing/ProductPrice

UOM

//ItemDetail/Description

ShortName

//ItemDetail/Description/ShortName

//ItemDetail/ManufacturerName

UnitPrice (ISO 4217)

//ItemDetail/UnitPrice

UnitOfMeasure

LeadTime //Product/LeadTime

LeadTime

//IndexItemDetail/LeadTime

//Product/ValidFrom

ValidFrom

//Product/ValidUntil

datum, je zboºí

datum, je zboºí

//product/attr[@name="ExpirationDate"]

//product/attr[@name="EffectiveDate"]

datum, moºné z

pouºité jednotk

cena za jednotk

krátký výrobku krátký výrobku

jméno v

Pozná

//product/attr[@name="LeadTime"]

EA

(UN/CEFACT, dop. 20) P°íklad nastavení:

//product/attr[@name="UOM"]

12.0

P°íklad nastavení:

//product/attr[@name="Price"]

//product/attr[@name="ManufacturerName"]

//product/attr[@name="ShortDescription"]

nazev

P°íklad nastavení:

//product/attr[@name="Description"]

OCF element

Tabulka 5.2: Porovnání d·leºitých element· formát·

//IndexItemDetail/EffectiveDate

(ISO 8601)

EectiveDate

//ItemDetail/ExpirationDate

(ISO 8601)

ValidUntil

//Product/UOM

//ItemDetail/UnitOfMeasure

ExpirationDate

(UN/CEFACT, dop. 20)

(UN/CEFACT, dop. 20)

Manufacturer

ProductName

Description

ManufacturerName

xCBL element

cXML element

5.3. Kategorizace zboºí

49

5.4. Zápis m¥ny a ceny

50

5.3.3 Kategorizace v OCF Kategorizace zboºí se ve formátu OCF pouºívá element category, tyto elementy tvo°í hierarchickou stromovou strukturu, která denuje nad°azené a pod°azené kategorie. Jejich název je denován v atributu name a nad°azené kategorie jsou zapsány v elementu path. Jednotlivé zboºí je pak za°azeno v p°íslu²né kategorii, název zboºí je v atributu name a cesta stromem ke zboºí (tedy kategorie) jsou v path. Kategorie jsou také denovány pro jednotlivé zboºí dle standardu UNSPSD (viz. [19]). Ve výpisu 5.3 je ukázka £ásti souboru katalogu s práv¥ popsanými elementy. Element link umoº¬uje jednodu²e denovat k°íºové odkazy mezi kategoriemi.

<product name="3ae7c5" path="/Computer+Related/Software/Operating+Systems/3ae7c5"> 43160000 Tabulka 5.3: Kategorie v OCF

5.4

Zápis m¥ny a ceny

Pro zápis m¥n se vyuºívá standardní dvoupísmené kódy, ur£ené normou ISO 4217 [22]. Rozdíly mezi formáty cXML a xCBL p°ehledn¥ zobrazuje

51

5.4. Zápis m¥ny a ceny

<Money currency="USD">100

(a) cXML

100 USD

(b) xCBL

Tabulka 5.4: Zápis ceny a m¥ny v cXML a xCBL tabulka 5.4. Je patrné, ºe v cXML se pro zápis ceny pouºije pouze jeden element (Money) s atributem, u£ujícím m¥nu (currency). xCBL pouºívá pro ur£ení m¥ny i ceny speciální elementy. P°esto je zápis velmi podobný, vyuºívá se shodný formát m¥ny a hodnoty. OCF nemá speciální element nebo atribut pro specikaci ceny a m¥ny, to se provádí pomocí elementu attr, který má následující tvar: .

Kapitola 6 P°evody mezi ontologiemi 6.1

Úvod

K vlastnímu p°evodu je moºné p°istupovat n¥kolika metodami. Nejjednodu²²í metodou je navrhnout pro kaºdou dvojici datových formát· XSLT styly. Datové formáty pouºívané v sou£asné dob¥ jsou v²ak natolik obsáhlé, ºe ru£ní p°íprava transforma£ních ²ablon je velmi £asov¥ náro£ná. Pokud je navíc vyºadován obousm¥rný p°evod, pak £asová náro£nost tohoto vývoje roste kvadraticky - O(n2 ), tedy nap°. p°i 6 r·zných datových formátech je pot°eba 36 r·zných XSL ²ablon. Zajímavou metodu navrhuje [3]. Vyuºívá tzv. Semantic Hub, který obecn¥ popisuje v²echny pot°ebné informace, zapsané v jednotlivých formátech. Práce s tímto sémantickým hubem spo£ívá v návrhu dvojice XSL transforma£ních skript·, které p°evedou vstupní formát do formátu sémantického hubu, který obsahuje obecné vyjád°ení obsaºených dat. Z tohoto formátu sémantického hubu se pak provád¥jí zp¥tné XSL transformace do dal²ích formát·. Tento p°ístup zjednodu²uje práci, protoºe zde sta£í navrhnout pro kaºdý vstupní formát dva XSL styly, jeden do meziformátu a druhý zp¥t. Nevýhodou toho p°ístupu je, jak navrhnout obecné informace o formátech. Sémantický hub totiº musí obsáhnout ve²keré informace, uloºené v jednotlivých formátech, které umí zpracovat. Pokud vznikne nový datový for52

53

6.1. Úvod

mát, který bude obsahovat jiné informace, neº ty, které jsou uloºeny v sémantickém hubu, je nutné aktualizovat datový formát v sémantickém hubu. P°edchozí moºnost je dále moºné rozvinout tak, ºe se transforma£ní styly nenavrhují ru£n¥, ale generují. Pak se vyuºívá nástroj, který na£te oba dva soubory, zobrazí je v grackém prost°edí a vývojá° navrhne transformaci. Pak lze z nástroje transforma£ní styly vygenerovat a pouºít pro dal²í p°evody. Tímto se zabývá [8, 7]. Auto°i rozd¥lují p°ístupy ke tvorb¥ XSLT ²ablon do dvou typ·. Prvním p°ístupem je integrace jednou vrstvou (single-layer integration ). Zde se porovnávají p°ímo jednotlivé formáty a navrhují se XSLT ²ablony. ®

©

®

©

Ontologie

Ontologie

dokumentu

dokumentu

­

ª

­

Vrstva ontologií ª

Tvorba instancí ®

?

Normalizované trojice ­

© 

® -

?

©

Normalizované

Vrstva datových model·

trojice ª

­

ª

XSLT trasformace ®

?

©

®

Katalog

Syntaktická vrstva

ve formátu XML ª

Katalog 1

©

Katalog

ve formátu XML ­

?

­

ª

Katalog 2

Obrázek 6.1: Postup p°evodu katalog· pomocí vícevrstvé integrace Druhým p°ístupem je vícevrstvá integrace (multi-layer integration ), kdy je informace v souborech rozd¥lena do t°í vrstev: vrstvy syntaktické (syntax layer ), vrstvy datového modelu (data models layer ) a vrstvy ontologií (ontology layer ). Tento p°evod lze znázornit pomocí obrázku 6.1. Syntaktická vrstva odpovídá serializaci dokumentu v XML, tedy

6.2. Problémy

54

vlastní datový soubor. Vrstva datových model· je spojovník mezi syntaktickou vrstvou a vrstvou ontologií. Jedná se o abstraktní vyjád°ení vstupních dat, reprezentovaných v syntaktické vrstv¥, pomocí trojic object-property-object. Je také provedena normalizace vzhledem k pouºité ontologii, tak aby bylo moºné dále s elementy pracovat. Poslední vrstvou je vrstva ontologická. Jedná se o ontologii dokumentu, pouºité k reprezentaci produktu. V této vrstv¥ jsou jiº v²echny informace o produktu natolik detailní, ºe ve²keré transformace lze vyjád°it mapováním 1:1. Je tedy nutné zajistit, aby byly vztahy M:N (viz. podrobn¥ji 6.2) byly p°evedeny na 1:1.

6.2

Problémy

P°i p°evodu mezi r·znými formáty (v mém p°ípad¥ cXML a xCBL) je nutné se vypo°ádat s n¥kolika problémy. Jsou to hlavn¥ problémy, týkající se r·zných vyjád°ení a pojmenováním element· a jejich obsah·. Základní problémy jsou následující.

• Jsou pouºity r·zné terminologie pro ekvivalentní elementy. Ty sice popisují stejný obsah, ale jmenují se jinak. • Shodná informace je zapsána v r·zných formátech pomocí jiného vyjád°ení v XML. Jednou informace m·ºe být v samostatném elementu, ale v jiném p°ípad¥ tuto informaci m·ºe vyjad°ovat atribut elementu. • Informace m·ºe být vyjád°ena v r·zných konvencích a formátech. Lze ale narazit na shodný obsah ve stejné konvenci. U produktových katalog· se setkáváme se standardizovaným vyjád°ením UN/SPSC, který je pouºit v obou formátech, ale v cXML je kódován pomocí atributu value="SPSC" a v xCBL v elementu SchemaStandard s hodnotou "UNSPSC".

55

6.2. Problémy

• Je moºné se setkat s r·znými stupnicemi pro vyjád°ení po£tu výrobk·, jejich velikosti nebo ceny (mohou se objevit ceny nap°. v amerických dolarech nebo v eurech). • Názvy zboºí a jejich popisky je moºné zapsat v r·zných jazycích. Dal²ím velkým problémem p°i p°evodech mezi t¥mito formáty je, ºe je nutné navrhovat mapování nejen mezi jednotlivými elementy, ale také provést mapování z jednoho elementu na element· více. Jednoduchá ukázka je nazna£ena v tabulce 6.1 a 6.2.

Acme <Street>123 Anystreet Sunnyvale <State>CA 90489 United States

Tabulka 6.1: cXML a denice adresy

Acme <Street>Anystreet 123 90489 Sunnyvale US CA

Tabulka 6.2: xCBL a denice adresy

Z tabulky jsou patrné n¥které z rozdíl·, které jsem vý²e popisoval. U n¥kterých element· se oba formáty shodují, jako nap°. nebo . U dal²ích jsou hodnoty shodné, ale názvy element· r·zné (

v cXML a v xCBL). A v p°ípad¥ <Street> u cXML je nutné p°i p°evodu do xCBL jeho obsah rozd¥lit na £íslo domu a ulici, aby se jimi daly naplnit elementy <Street> a .

56

6.3. Dvouvrstvá integrace

6.3

Dvouvrstvá integrace

®

©

-

Datový model ­

6

#

#

ª

transformace

"

Ã

®

!

Datový model

­

6

®

#

!

"

Katalog v XML ª

Zdrojový katalog

?

Ã

zp¥tný p°evod

©

­

ª

Ã

abstrakce "

©

® # Ã XXX   XXp°ímá XX  XXXX  transformace  XX    " ! ­

!

?

©

Katalog v XML ª

Cilový katalog

Obrázek 6.2: Postup p°evodu pomocí dvouvrstvé integrace P°i vývoji prototypu p°eklada£e identických transformací jsem zvolil, obdobn¥ jako auto°i dokumentu [7], transformaci pomocí dvou vrstev, jak je znázorn¥no na obrázku 6.2. P°estoºe auto°i ve své práci navrhují je²t¥ pouºití vrstvy ontologické, její návrh by v²ak byl natolik sloºitý (nutnost pokrýt ve²keré vlastnosti, které jsou v r·zných formátech vyjád°eny), ºe tuto vrstvu neimplementují. První vrstvou jsou katalogy, zapsané v jazyce XML. Vlastnosti jednotlivých produktových katalog· jsou tedy pevn¥ dány jejich tv·rci a pouºívá se pouze p°i na£tení do p°evád¥cího programu. Druhou pouºitou vrstvou je vrstva datových model·. V této vrstv¥ jiº jsou provedeny úpravy, nutné pro jednoduchý p°evod mezi pouºitými formáty. Tato vrstva je získána pomocí transforma£ního procesu, kterému °íkáme abstrakce. Data, vyjád°ená v zadaných formátech, jsou zpracována pomocí vstupní procedury, která provádí d·leºité p°evody. Je nutné pokrýt ve²keré problémy, popsané v 6.2.

6.4. Specifikace pouºité procedury

57

Ve své práci jsem pouºil tvorbu modelu, který je zaloºen na jazyku OWL (kapitola 3.3). Jeho výhodou je moºnost práce s t°ídami a vlastnostmi a zápis vztah· mezi nimi. Toho lze s výhodou vyuºít práv¥ p°i tvorb¥ p°evodníku, protoºe n¥které vztahy lze zapsat pomocí konstrukcí jazyka OWL. U v¥t²iny dal²ích vztah· to v²ak nelze a je pot°eba navrhnout jednoduchá pravidla, jak vyjád°it vztahy mezi elementy.

6.4

Specikace pouºité procedury

Návrh pomocí ru£ního vývoje ²ablon XSLT je náro£ný, proto jsem se zam¥°il na vyuºití moºností jazyka OWL a automatizovaného p°evodu. Tento p°evod je spí²e poloautomatický, je nutné totiº nadenovat vztahy mezi elementy v jednotlivých formátech.

6.4.1 Na£tení dokumentu Prvním krokem je na£tení souboru do DOM 1 (Document Object Model ). DOM je aplika£ní rozhraní (API) pro práci s XML dokumenty, které denuje logickou strukturu dokumentu a umoº¬uje dynamicky p°istupovat k jednotlivým £ástem dokumentu, m¥nit jeho obsah a strukturu. Je nadenováno standardní rozhraní, pro p°ístup a manipulaci. Toto rozhraní je nezávislé na platform¥ a programovacím jazyku, lze ho tedy vyuºít v²ude, kde je naimplementováno (nap°. je obsaºeno ve v²ech nov¥j²ích internetových prohlíºe£ích). Výhodou je, ºe dokument v DOM modelu je zobrazován jako strom (viz. 4.5 na stran¥ 31), £ehoº lze vyuºít v p°ístupu k °e²ení problému.

6.4.2 Tvorba OWL modelu P°evod na£teného dokumentu do RDF stru£n¥ popisuje [6]. P°i procházení stromu generuje RDF trojice, vytvá°ející popis XML dokumentu v jazyce RDF. Autor v²ak nevytvá°í RDF trojice pro v²echny XML elementy, 1 http://www.w3.org/DOM/

6.4. Specifikace pouºité procedury

58

ale pouze pro ty, které nesou informace d·leºité pro vyjád°ení dat v katalogu. Zde je v²ak otázka, jak rozhodnout, které elementy nesou nezbytné informace, a které lze vynechat. Mnou navrºený postup vychází z p°edchozího postupu, ale tvorba modelu probíhá v jazyce OWL. Stromová struktura DOM modelu se prochází do hloubky. Pro kaºdý uzel z procházeného DOM stromu je provedena p°íslu²ná akce.

• Pokud je nalezen element, je vytvo°ena t°ída (owl:Class) identikovaná jménem elementu. Zárove¬ je vytvo°ena objektová vlastnost (owl:ObjectProperty, kterou je ur£eno zano°ení t°ídy ve struktu°e dokumentu. Doménou objektové vlastnosti pak je t°ída, který je ve struktu°e nad°azená (obsahuje aktuáln¥ vytvo°enou t°ídu) a oborem hodnot aktuální t°ída. V tomto p°ípad¥ nelze pouºít axiomu rdfs:subClassOf (viz. 3.3.1.7), protoºe se zde nejedná o d¥di£nost nebo podmnoºiny, ale o t°ídy, které popisují kaºdá n¥co jiného. • Pokud je nalezen atribut, náleºící k elementu, je vytvo°ena datová vlastnost (owl:DatatypeProperty). Její doménou (rdfs:domain) je element, kterému náleºí, a oborem hodnot (rdfs:range) je v na²em p°ípad¥ °et¥zec (xsd:string).

6.4.3 Vyjád°ení identické informace Pro vyjád°ení identické informace op¥t vyuºíváme moºností jazyka OWL. Tato £ást p°evodu v²ak není pln¥ automatická, je pot°eba ru£ního zásahu £lov¥ka. Je totiº nutné vy°e²it n¥kolik moºností vyjád°ení informace.

• Pokud elementy obsahují shodné informace, vyjád°ené ve shodné form¥ (nejsou pot°eba transformace obsahu), m·ºeme obsah zdrojového prvku zkopírovat do prvku cílového.


6.4. Specifikace pouºité procedury

59

rdfs:domain="cxml:Name" trf:destination="xcbl:Name1" trf:select=""/> • Pokud jsou informace vyjád°ené ve form¥ 1:M (jako nap°. v tabulce 6.2 je vyjád°ena ulice a £íslo popisné, kdy v cXML jsou tyto informace v jednom elementu a v xCBL ve dvou elementech), pak je nutné informaci rozd¥lit. Zde je vyuºit zápis obdobný zápisu v transforma£ním jazyku XSL.

• Pokud jsou informace vyjád°ené v r·zných veli£inách, je nutné provád¥t numerické p°epo£ty hodnot. P°íklad ukazuje, jak získat z m¥ny USD (americký dolar) cenu v EUR (vycházím z kurzu, kdy 1 AUD je 0.8 EUR).



6.5. Implementace

6.5

60

Implementace

Vlastní program je implementován v programovacím jazyce Java 2 ve verzi 1.4 rmy Sun3 , který je voln¥ dostupný pro vývojá°e. Vyuºity jsou dále balíky pro práci s DOM modelem Xerces 4 , který je vyvíjen komunitou, utvo°enou kolem projektu Apache5 . Tento balík je vyuºit pro na£ítání XML dokument· do DOM modelu a pro dal²í práci s takto na£teným dokumentem. Pro tvorbu OWL modelu je vyuºit projekt Jena 6 (Jena - A Sematic Web Framework for Java), vyvíjený skupinou Sémantického webu v laborato°ích Hewlett-Packard7 . Tento projekt umoº¬uje pracovat s jazyky pro sémantický web (RDF(S), OWL, DAML) a to ve v²ech notacích a serializacích (RDF trojice, N3 notace a XML serializace). Výhodou je jeho otev°enost a podpora diskusní skupinou Jena-dev8 . Aplikace v tuto chvíli umoº¬uje na£tení souboru v jazyce cXML nebo xCBL (obrázek 6.3). Po na£tení lze zobrazit okno (obrázek 6.4), ve kterém uºivatel vybírá elementy, které nesou shodnou informaci, a k nim volí akci, která se má p°i p°evodu provád¥t. Výsledkem práce s aplikací je soubor v jazyce RDF, kde jsou jednotlivé mapovací vztahy zapsány. Tento soubor je pak vstupem aplikace, která provádí vlastní p°evod z jednoho formátu do druhého. Tato aplikace jiº implementována není, vzhledem k £asovým a implementa£ním problém·m.

6.6

Dal²í vývoj

Dal²í vývoj aplikace by sm¥°oval k umoºn¥ní úplného p°evodu informací z jednoho formátu do formátu druhého a zp¥t, samoz°ejm¥ s moºností vyuºí2 Java:

http://java.sun.com http://www.sun.com 4 Xerces2: http://xml.apache.org/xerces2-j/index.html 5 Apache: http://www.apache.org 6 Jena: http://jena.sourceforge.net a http://www.hpl.hp.com/semweb/ 7 Hewlett-Packard: http://www.hp.com/ 8 Diskusní skupina Jena-dev: http://groups.yahoo.com/group/jena-dev/ 3 Sun:

6.6. Dal²í vývoj

61

Obrázek 6.3: Vzhled aplikace po na£tení soubor·

vat i jiné zdrojové formáty. To by bylo moºné zajistit tvorbou modelu v ontologické vrstv¥ (obrázek 6.1), kdy by informace o produktech byly v atomické form¥ (tedy tak, jak se na n¥ dívá zákazník nebo výrobce). Dále by bylo nutné aplikaci vylep²it ve smyslu automatizace p°evodu. V tuto chvíli je ve²kerá práce p°i výb¥ru element·, vyjad°ujících shodnou informaci, na uºivateli, který p°evod provádí. Výhodou by bylo vyuºití heuristik nebo jiných metod z um¥lé inteligence tak, aby aplikace uvaºovala, které elementy by mohly obsahovat shodné informace. Oblastí pro zlep²ení je samoz°ejm¥ mnoho, v tuto chvíli jde o prototyp, který je schopen vyjád°it shodnou informaci za pomoci uºivatele.

6.6. Dal²í vývoj

Obrázek 6.4: Vzhled aplikace pro mapování jednotlivých element·

62

6.7. Záv¥r

6.7

63

Záv¥r

V této práci jsem se se seznámil s pouºívanými a navrhovanými ontologiemi, pouºívanými v oblasti e-Commerce. Jednalo se hlavn¥ o ty, které jsou v tuto chvíli pouºívané a za kterými stojí silné rmy, zabývající se podporou elektronického obchodování. Pro p°iblíºení problému jsou stru£n¥ popsány standardy, pouºívané pro zápis nebo práci s t¥mito formáty. Jedná se hlavn¥ o popis datových formát· XML, XML Schema a OWL. Tento popis je d·leºitý hlavn¥ z hlediska zápisu dat, v²echny formáty jsou totiº implementovány v jazyce XML. Dále jsem provedl pr·zkum dvou nejd·leºit¥j²ích formát·, vyuºívaných v oblasti elektronického obchodování, a to cXML a xCBL. Vzhledem k objemnosti t¥chto standard· jsem zvolil jejich podmnoºinu, která denuje produktové katalogy. Jako alternativa je dále popsán formát OCF, který je ur£en pouze pro tvorbu katalog·. V tomto pr·zkumu jsem se zam¥°il hlavn¥ na prvky, které vyjad°ují obdobný obsah, a jak tento obsah vyjad°ují. Porovnal jsem moºnosti p°evodu shodných informací mezi formáty cXML a xCBL. Diskutoval jsem pouºívané metody p°evodu a na základ¥ poznatk·, získaných z literatury, jsem navrhl metodu, jak formáty p°evád¥t. Naimplementoval jsem prototyp p°eklada£e identických informací v jednotlivých formátech. Program, napsaný v programovacím jazyce Java, umoº¬uje uºivateli vytvo°it vlastní mapování mezi elementy pouºitých datových formát·. Jedná se o prototyp, který v tuto chvíli nepodporuje ve²keré moºnosti, ale umoº¬uje specikovat vztahy mezi informacemi v jednotlivých formátech. Pokud by v²ak vývoj pokra£oval, je moºné vyuºít tento program pro poloautomatický p°evod dat. V této práci byl p°evod r·zn¥ vyjád°ených informací sm¥°ován do oblasti elektronického obchodování. Vzhledem k p°echodu k internetovému obchodnictví, a také k postupné globalizaci trhu, jiº není moºné, aby si obchodní partne°i nemohli vym¥¬ovat data. A to p°esto, ºe se m·ºe jednat o rmy konkuren£ní. V tuto chvíli není problém získat zboºí rychleji, a moºná i levn¥ji, z jiného sv¥tadílu, coº umoº¬uje práv¥ Internet a moºnost vým¥ny dat.

6.7. Záv¥r

64

Nutnost automatizovaného (pop°. poloautomatizovaného) p°evodu se ale objevuje ve v²ech oblastech, kde je t°eba zpracovávat data z r·zných zdroj·. Tomu m·ºe navrºený zp·sob p°evodu pomoci, pokud bude moºné získat p°esné specikace pouºitých formát·. Výhodou je také v posledních letech p°esun k jazyku XML, který za£íná být vyuºíván jako standard pro zápis strukturovaných dat.

Dodatek A Výstup aplikace: cXML v jazyku OWL OntoTest 65

66



67



Dodatek B Výstup aplikace: xCBL v jazyku OWL OntoTest 68

69



70



Dodatek C Výstup aplikace: soubor s mapováním
72

j.0:destination="xcbl:CountryCode"/> <j.0:select>substring-after(cxml:Street,' ') <j.0:select>substring-before(cxml:Street,' ')

Dodatek D Obsah p°iloºeného CD Adresá° program  adresá° obsahuje zdrojové kódy programu, spustitelný program a po°ebné knihovny pro b¥h.

Adresá° soubory  adresá° obsahuje ukázkové soubory, pouºívané v této práci.

Adresá° dp  adresá° obsahuje zdrojový kód diplomové práce a výstupní text ve formátu PDF a PS.

73

Literatura [1] Borst, W. N.: Construction of engineering Ontologies for Knowledge Sharing and Reuse. PhD Dissertation, University of Twete, Enschede, The Netherlands, 1997. [2] Fensel, D. Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce [online]. . [3] Fox, J. Generating XSLT with Semantic Hub [online].

. [4] Gruber, T. R.: A Translation Approach to Portable Ontology Specications. Knowledge Acquisition5(2) (1993) [5] Hradský, J. Jazyk OWL a sémantický web [online]. Bakalá°ská práce, Masarykova univerzita, Fakulta informatiky, 2003. . [6] Klein, M. Interpreting XML via RDF Schema [online].

. [7] Omelayenko, B., Fensel, D. A Two-Layered Integration Approach for Product Information in B2B E-commerce [online]. .

74

LITERATURA

75

[8] Omelayenko, B., Fensel, D. An analysis of B2B catalogue integration problems [online]. . [9] Svátek, V. Ontologie a WWW [online].

. [10] Nic, M., Jirát, J. XPath Tutorial [online].

. [11] W3 Konsorcium. Extensible Markup Language (XML) 1.0 (Second Edition) [online]. . [12] W3 Konsorcium. Resource Description Framework (RDF) Model and Syntax Specication [online]. . [13] W3 Konsorcium. RDF Vocabulary Description Language 1.0: RDF Schema [online]. . [14] W3 Konsorcium. XML Path Language (XPath) Version 1.0 [online]. . [15] W3 Konsorcium. XML Schema Part 0: Primer [online]. . [16] W3 Konsorcium. WWW stránka W3 Konsorcia [online]. . [17] UNECE UNECE Recommendation N◦ 3 - Code for the Representation of Names of Countries [online]. .

LITERATURA

76

[18] UNECE UNECE Recommendation N◦ 20 Codes for Units of Measure Used in International Trade [online]. . [19] UNSPSC United Nations Standard Products and Services Code [online]. . [20] W3 Konsorcium Date and Time Formats [online]. . [21] W3 Konsorcium ISO 639 Language Codes [online].

. [22] xe.com ISO 4217 Type Currency Symbol list [online]. . [23] cXML Commerce XML [online]. . [24] MartSoft An Overview of Open Catalog Format [online]. . [25] MartSoft Open Catalog Protocol 1.0 (OCP) Semantics [online]. . [26] CommerceOne XML Common Business Library [online]. .

Seznam tabulek 3.1 3.2 3.3

P°íklad XML dokumentu . . . . . . . . . . . . . . . . . . . . . 12 Ukázka denice DTD . . . . . . . . . . . . . . . . . . . . . . . 13 P°íklad denice XML-Schématu k p°íkladu v tabulce 3.1. . . . 15

4.1

Ukázka denice datového typu ProductID (ProductIDType.xsd) 35

5.1 5.2 5.3 5.4

Porovnání práce s katalogy . . . . . . . Porovnání d·leºitých element· formát· Kategorie v OCF . . . . . . . . . . . . Zápis ceny a m¥ny v cXML a xCBL . .

6.1 6.2

cXML a denice adresy . . . . . . . . . . . . . . . . . . . . . . 55 xCBL a denice adresy . . . . . . . . . . . . . . . . . . . . . . 55

77

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

47 49 50 51

Seznam obrázk· 3.1 3.2 3.3

Ukázka grafové representace RDF . . . . . . . . . . . . . . . . 17 Graf 3.1 v zápisu N3 . . . . . . . . . . . . . . . . . . . . . . . 18 Graf 3.1 zapsaný jako serializované XML . . . . . . . . . . . . 18

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

cXML: Interaktivní PunchOut sezení mezi uºivatelem a WWW stránkou dodavatele [23]. . . . . . . . . . . . . . . . . cXML: PunchOut Chaining [23]. . . . . . . . . . . . . . . . . . cXML: Zasílání katalogu kupující organizaci [23]. . . . . . . . cXML: Zjednodu²ený graf struktury elementu Index . . . . . . cXML: Zjednodu²ený graf struktury elementu Supplier . . . . xCBL: Zjednodu²ený graf struktury elementu ProductCatalog OCP: Graf komunikace mezi katalogy. . . . . . . . . . . . . . . OCF: Graf struktury elementu Catalog. . . . . . . . . . . . . .

27 27 28 30 31 36 42 45

6.1 6.2 6.3 6.4

Postup p°evodu katalog· pomocí vícevrstvé integrace Postup p°evodu pomocí dvouvrstvé integrace . . . . . Vzhled aplikace po na£tení soubor· . . . . . . . . . . Vzhled aplikace pro mapování jednotlivých element· .

53 56 61 62

78

. . . .

. . . .

. . . .

. . . .

. . . .