Využití Topic Maps pro zlepšení navigace na webu

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství

Využití Topic Maps pro zlepšení navigace na webu Bakalářská práce

Jiří Kotlín

Vedoucí práce: Ing. Jiří Kosek červenec 2007

Anotace Cílem této bakalářské práce je navrhnout a prototypově implementovat řešení využívající Topic Maps pro navigaci na webových stránkách. Jejím výsledkem je pak aplikace postavená na spojení tohoto relativně nového mezinárodního standardu pro organizování znalostí a populárního řešení poskytování webových stránek softwarovou architekturou LAMP. Ta je založena na spojení osvědčeného open source softwaru - operačního systému Linux, webového serveru Apache, databáze MySQL a programovacího jazyka PHP. První kapitoly se zabývají převážně popisem problému a s ním souvisejících témat. Další pak komplexním řešením včetně navržení ontologie, tvorby mapy témat, návrhu a zprovoznění celé aplikace. Součástí práce je i nastínění možných problémů, jejich řešení a popis možné budoucnosti aplikace.

Annotation The primary goal of this Bachelor`s thesis is to project and tentatively implement application which uses Topic Maps for website navigation. It`s result will be application based on this relatively new standard for knowledge integration and popular software bundle LAMP, which is a combination of operating system Linux, web server Apache, database server MySQL and programming language PHP. The first part of my thesis consists mostly of explaining the problem and related theory. The second describes comprehensive application development including ontology, topic map and whole application engineering. Noticed is also putting this application into service, some possible problems and theirs solutions.

Poděkování Na tomto místě bych rád poděkoval všem tvůrcům volně dostupného softwaru, který v této práci i při svých ostatních každodenních činnostech využívám. Především pak Johannesu Schmidtovi za zhotovení PHP softwaru pro práci s mapami témat a jeho vstřícné odpovědi na mé dotazy. Rovněž celé komunitě lidí okolo Topic Maps za jejich práci a množství volně dostupných materiálů k této problematice. Dále pak vedoucímu mé práce, panu ing. J. Koskovi za cenné rady i za jím vyučované předměty, které jsem absolvoval. Samozřejmě i všem dalším učitelům Vysoké školy ekonomické v Praze za znalosti získané během studia. V neposlední řadě také Veronice V. za opravy gramatických chyb a všem dalším kamarádům za cenné podněty i připomínky ke vznikající aplikaci.

Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a použil pouze literaturu uvedenou v přiloženém seznamu. Nemám námitek proti půjčení práce se souhlasem katedry ani proti zveřejnění práce nebo její části.

V Praze dne 20. srpna 2007

Jiří Kotlín

Obsah 1. Úvod ..................................................................................................................................... 7 2. Základní pojmy ..................................................................................................................... 9 2.1. Internet a WWW ....................................................................................................... 9 2.2. Značkovací jazyky ................................................................................................... 10 2.2.1. HTML ........................................................................................................... 10 2.2.2. XML ............................................................................................................. 12 2.3. GNU - svobodný software ....................................................................................... 15 2.4. Webový server ......................................................................................................... 15 2.4.1. Linux ............................................................................................................ 16 2.4.2. Apache .......................................................................................................... 17 2.4.3. PHP ............................................................................................................... 18 2.4.4. MySQL ......................................................................................................... 19 3. Ontologie ............................................................................................................................ 20 3.1. Prezentace ontologie ................................................................................................ 20 3.2. Ontologie navigace .................................................................................................. 21 4. Topic Maps ......................................................................................................................... 23 4.1. Model mapy témat ................................................................................................... 23 4.1.1. Mapa témat ................................................................................................... 24 4.1.2. Témata .......................................................................................................... 25 4.1.3. Vztahy .......................................................................................................... 26 4.1.4. Výskyty ........................................................................................................ 26 4.2. Slučování map témat ............................................................................................... 26 4.3. Vytvoření mapy témat ............................................................................................. 27 5. Aplikace .............................................................................................................................. 32 5.1. Topic Map Engine ................................................................................................... 32 5.1.1. Quaax TM .................................................................................................... 32 5.2. TMAPI .................................................................................................................... 33 5.2.1. PHPTMAPI .................................................................................................. 33 5.3. Návrh aplikace ......................................................................................................... 33 5.4. Administrační rozhraní ............................................................................................ 34 5.4.1. Zpracování XTM souboru ............................................................................ 36 5.5. Navigace .................................................................................................................. 38 5.5.1. Přepsání HTML souborů .............................................................................. 42 5.5.2. Generování navigace .................................................................................... 43 5.6. Systémové požadavky ............................................................................................. 46 5.6.1. Software ....................................................................................................... 46 5.6.2. Hardware ...................................................................................................... 46 5.7. Instalace aplikace .................................................................................................... 47 6. Závěr ................................................................................................................................... 48 Literatura ................................................................................................................................ 50

6

Kapitola 1 Úvod Problémem současné informační společnosti již není informace získat, ale umožnit uživateli jejich získání ve správných souvislostech a rozumném čase. Podle známé poučky se objem elektronicky uchovávaných informací každé dva roky zdvojnásobí. S touto záplavou dat se snaží vyrovnat i tvůrci jednotlivých webových stránek ve snaze co nejlépe zorganizovat data v nich uložená a poskytnout uživateli efektivní a intuitivní formu navigace. Samotné vyhledávání v textovém obsahu stránek je vzhledem k velkému počtu homonym a synonym každého jazyka i rostoucímu objemu informací na internetu velmi neefektivní. Snad každý známe množství irelevantních výsledků, které většinou produkuje. Pro uchovávání obsahu jednotlivých stránek se v posledních letech hojně využívají různé redakční systémy CMS (content management system), ve kterých je většinou celý obsah webových stránek uložen v nějaké databázi. Následné dynamické generování internetových stránek uživateli poskytne různé formy navigace i způsoby využití jejich obsahu. Ani tento přístup ale není samospasitelný. Jednotlivé redakční systémy i jejich verze se výrazně liší, jsou vázány na konkrétní technologie, které se rovněž mohou v čase měnit, případně zaniknout. Navíc sebelepší redakční systém jednoho dne přestane svými možnostmi konkrétním webovým stránkám postačovat a přicházejí různé úpravy. Takže je často vázán již nejen na technologie, ale i na osobu konkrétního programátora. Současný princip fungování internetových stránek se v rostoucí záplavě informací a nových technologií jeví jako zcela nedostatečný. Příliš slibně to zatím nevypadá ani s akademickým řešením formou sémantického webu. Ten se především díky své složitosti zatím nedočkal výraznějšího použití a potýká se svým základním problémem nedostatku aplikací pro jeho využití i neochotou jednotlivých autorů webových stránek jeho principy implementovat. Jako alternativa sémantického webu se začíná objevovat relativně nová technologie - Topic Maps. Jejich poměrně jednoduchý princip byl odvozen z fungování osvědčeného způsobu organizování informací formou rejstříků na konci knih a na rozdíl od sémantického webu je od samého počátku vyvíjen převážně na základě praktických požadavků. Nejedná se o komplexní řešení konkrétní situace, nýbrž o jakýsi obecný princip organizace informací. Ve skutečnosti jsou Topic Maps jediným mezinárodně uznávaným standardem pro organizování informací, což jim dává vysokou jistotu budoucího rozvoje a stability. V dokumentech, které popisují princip fungování Topic Maps, se můžeme dočíst prakticky samou chválu. Sám tvůrce nejstaršího značkovacího jazyka SGML Charles Goldfrab nazval tuto technologii GPS informačního vesmíru. Aktuálně je již několik let hotový formát zápisu Topic Maps pomocí značkovacího jazyka XML, který umožňuje jejich snadnou integraci na webu. Pro správu informací na svých webových stránkách je začínají používat i větší firmy

7

1. Úvod (Borland, US Department of energy). Současně existuje relativně velké množství komerčních i nekomerčních technologií a programů pro jejich podporu a využití. Situace ve spojitosti s aktuálně nejpoužívanějším programovacím jazykem pro tvorbu dynamických webových stránek PHP je ale dosti odlišná. Německý programátor Johannes Schmidt sice nedávno přepsal určité standardy pro podporu Topic Maps do programovacího jazyka PHP, ale žádné aplikace na nich postavené dosud nevznikly (nebo jsem na ně v době psaní této práce já ani J. Schmidt nenarazil). Neochota tvůrců webových stránek stavět své aplikace na spojení této nové technologie a osvědčeného jazyka PHP podle mého názoru vyplývá ze třech hlavních důvodů. Prvním důvodem je bezpochyby neexistence PHP aplikací i návodů na využití spojení Topic Maps a PHP. Dalším důvodem je pravděpodobně velké množství zmíněných redakčních systémů i již hotových a osvědčených technologií pro správu obsahu webových stránek. V neposlední řadě může být toto zpoždění oproti jiným programovacím jazykům, pro které již existují řešení využívající Topic Maps (JSP, ASP), zapříčiněno relativně vysokým podílem lidí, kteří PHP využívají jen pro elementární úkoly svých webových stránek a od nichž se rychlé vstřebání nových technologií bez rozsáhlé podpory nedá očekávat. Po seznámení s principem fungování Topic Maps jsem si za téma své bakalářské práce zvolil právě jejich využití na webu. Jejím cílem je vytvořit aplikaci, která bude pomocí Topic Maps a dalších technologií (PHP, MySQL, Apache) poskytovat efektivní navigaci webovým stránkám. Věřím, že výsledná aplikace, jako jedno z prvních praktických řešení, napomůže rozvoji budoucího využití spojení Topic Maps s programovacím jazykem PHP. Navržený postup ověřím v praxi prototypovou implementací zhotovené navigace na příkladu webových stránek vedoucího mé práce a několika dalších. Současně se pokusím aplikaci co nejvíce přizpůsobit jejímu snadnému budoucímu nasazení a zveřejním ji včetně zdrojových kódů, aby byla volně k dispozici všem, kteří by ji chtěli využít, případně jako inspirace tvůrcům podobných aplikací.

2003 3. revoluce 1997 2. revoluce 1991 1. revoluce

sémantický

univerzální

jednotný

HTTP

XML

Topic Maps?

Obrázek 1.1. Topic Maps jako třetí revoluce výměny informací? zdroj: [17]

8

Kapitola 2 Základní pojmy V této kapitole uvedu stručné vysvětlení základních pojmů souvisejících s mou prací. Zvláštní pozornost přitom zaměřím na jednotlivé technologie a produkty, které jsou v této práci přímo používané.

2.1. Internet a WWW Počátky internetu se datují do 60. let dvacátého století. Tehdy si americká vládní agentura při ministerstvu obrany ARPA dala za cíl vyvinout decentralizovanou počítačovou síť, ve které by mezi sebou mohli počítače komunikovat i po zničení některých z nich. [15] V roce 1969 spustili síť ARPANET, která z počátku spojovala jen dvě americké univerzity. Pravidelný provoz ARPANETu byl zahájen roku 1971 a s rostoucím příklonem k vojenství se z ARPA stala DARPA (Defence Advanced Research Project Agency). V roce 1983 byl jeden z komunikačních protokolů ARPANETu TCP/IP přijat jako vojenský standard USA. To znamenalo výrazný posun, neboť softwarové technologie byly před příchodem TCP/IP výhradně majetkem výrobců hardwaru, byly značně odlišné a znemožňovaly tak spolupráci různých síťových systémů. Protokoly TCP/IP byly od samého počátku vyvíjeny zcela veřejně a jednotlivé standardy byly zveřejňovány ve formě RFC (Request For Comments) dokumentů. Zhruba ve stejné době se poprvé začíná objevovat výraz Internet jako otevřená počítačová síť, v níž byl ARPANET jednou ze součástí. Postupně se k internetu připojovalo stále více institucí, především universit. Na rapidním rozšíření internetu i do komerčních sfér měla v devadesátých letech minulého století zásadní vliv služba WWW (World Wide Web). V roce 1989 představil Tim Berners-Lee nový způsob výměny informací - hypertextové dokumenty. Jednalo se o textové dokumenty, které obsahovaly odkazy na další dokumenty na jiných počítačích. Původním účelem WWW bylo propojit více počítačů a umožnit tak fyzikům ve švýcarském CERNu sdílet data v nich uložená. Později byly hypertextové dokumenty doplněny o obrázky, další multimedia a funkčnost. V roce 1991 vznikl nejpoužívanější formát zápisu hypertextových dokumentů – HTML (Hypertext Markup Language). Díky své jednoduchosti se jazyk HTML velmi rychle rozšířil a s ním se rozšířil i internet daleko za brány univerzitního a vojenského prostředí. Již v roce 1990 předvedl Tim Berners-Lee první prototyp webového serveru a 6. 8. 1991 spustil první webové stránky na adrese http://info.cern.ch/. Dalším stavebním kamenem služby WWW je přenosový protokol HTTP (Hypertext Transfer Protocol). Tento protokol slouží ke komunikaci klienta s webovým serverem. Spojení je krátkodobé a funguje na principu dotaz – odpověď. Uživatel pošle dotaz na webový server, většinou k tomu použije speciální software – webový prohlížeč (browser), následně dostane zpět odpověď ze serveru. Má-li uživatel další dotaz, musí se navázat 9

2. Základní pojmy další spojení. Aby bylo možné v dotazech jednoznačně lokalizovat jednotlivé internetové zdroje, má každý objekt přístupný na internetu svou vlastní unikátní adresu ve formě URL (Uniform Resource Locator). Jedná se o řetězec znaků s následující strukturou pro schéma HTTP [4]: http://«počítač»:«port»/«cesta»?«dotaz»#«fragment» Počítač v URL označuje adresu webového serveru. Port uvádíme, pouze když se liší od výchozího portu 80. Cesta značí jméno souboru se stránkou, případně ještě adresář, ve kterém se stránka na serveru nachází. Dotaz za otazníkem většinou předává parametry dynamicky generovaným stránkám a fragment je odkaz na konkrétní část hypertextového souboru. Pokud URL obsahuje pouze schéma a adresu serveru (případně ještě adresář), závisí na konfigurací webového serveru, jakou stránku ukáže jako úvodní. V roce 1994 bylo založeno mezinárodní konsorcium W3C (World Wide Web Consortium), jehož zaměstnanci společně s veřejností vyvíjejí protokoly a další standardy pro WWW, vydávají směrnice a snaží se tak rozvíjet WWW do jeho plného potenciálu. Konsorciu předsedá Tim Berners-Lee.

2.2. Značkovací jazyky Značkovací jazyky obsahují současně vlastní text i instrukce pro jeho zpracování. Tyto instrukce se v nich vyskytují v podobě příkazů (command) nebo značek (tag). Dělíme je na dvě základní skupiny – výkonné a popisné. Výkonné obsahují instrukce na úrovni programovacího jazyka a často umožňují velmi detailně popsat vzhled dokumentu například pro tisk. Nejznámějšími představiteli těchto jazyků jsou TeX a PostScript. Jazyky popisné se začaly vyvíjet z důvodu špatné kompatibility výkonných jazyků. Někdy jsou nazývány také jako obecné značkovací jazyky a jejich smyslem je popsat logickou strukturu textu. [19] Asi prvním známým značkovacím jazykem byl GML (Generalized Markup Language), vyvinut byl ve firmě IBM pro uchovávání a následné využití právních textů. Autoři GML se museli vypořádat s nekompatibilitou jednotlivých systémů a situaci vyřešili vytvořením obecného značkovacího jazyka. Jeho nástupce SGML (Standard …) byl roku 1986 definován v ISO normě 8879. Jednalo se o velmi komplexní jazyk, který umožňoval například definici vlastních značkovacích jazyků pomocí DTD (Document Type Definition – definice typu dokumentu), nebo naopak používat řadu nepravidelností pro ušetření paměti. Právě jeho komplexnost zabránila většímu rozšíření tohoto jazyka. Nejpoužívanější SGML aplikací je bezpochyby jazyk HTML, za jazyk webu třetího tisíciletí je považován relativně nový jazyk XML.

2.2.1. HTML První verze jazyka HTML, kterou vyvinul Tim Berners-Lee jako součást WWW, je označována číslem 0.9 a umožňovala rozčlenění textu do několika kategorií zvýraznění, použití obrázků a tvorbu odkazů na jiné dokumenty. Od té doby se syntaxe HTML neustále vyvíjí a definice jazyka je také zpětně ovlivňována výrobci jednotlivých prohlížečů, kteří se zejména v počátcích HTML snažili prosadit svá jednotlivá vylepšení jazyka za standard. Tyto snahy výrobců prohlížečů vedly ke značným rozdílům v zápisu HTML. Jako reakci na snižování kompatibility vydala komunita IETF (Internet Engineering Task Force) v roce 1994 standard HTML 2.0. Jednalo se 10

2. Základní pojmy o první verzi HTML, která odpovídala syntaxi SGML. V roce 1996 byla konsorciem W3C vydána další podstatná verze - HTML 3.2. Ta byla jakýmsi kompromisem ambiciózní verze HTML 3.0, kterou tehdejší výrobci prohlížečů nebyli schopni plně implementovat. Přínosem této verze byly především lepší formátovací možnosti a tabulky. Velkým posunem vpřed bylo vydání verze HTML 4.0 18. prosince 1997. Ta podporovala některé novinky jako třeba použití rámů (frames). Za její největší přínos bývá označován posun zpět k původnímu významu HTML, kterým bylo definovat strukturu textu a čistě grafické prvky definovat v externě připojeném stylu. Na Štědrý den roku 1999 byla vydána specifikace HTML 4.01, která opravuje chyby z HTML 4.0 a zavádí některé nové tagy. V této fázi byl vývoj jazyka HTML považován za ukončený a do budoucnosti se počítalo pouze s novějším jazykem XHTML (Extensible Hypertext Markup Language). Ten byl poprvé specifikován verzí 1.0 z ledna 2000. XHTML v sobě kombinuje syntaxi jazyků HTML a XML a je označováno, na rozdíl od svých předchůdců, za aplikaci XML. Většina tagů je názvově shodná s tagy z HTML, ale pravidla zápisu jsou trochu odlišná a musejí být striktně dodržována. V praxi to znamená například nezobrazení chybně zapsaného dokumentu, čímž chtěli tvůrci dosáhnout validních dokumentů pro snadnější zpracování různými zařízeními. Právě nevalidní zápis HTML, způsobený autory www stránek bez znalostí syntaxe HTML i benevolentními prohlížeči, které zobrazí prakticky cokoliv, je největší brzdou dalšího rozvoje dostupnosti internetu z různých alternativních zařízení. Verze XHTML 2.0 je zatím ve vývojovém stádiu a na rozdíl od XHTML 1.0 a pozdější verze 1.1 se u něho nepředpokládá zpětná kompatibilita s HTML. Sedmého března 2007 byla založena nová pracovní skupina HTML s cílem představit do konce roku 2010 novou syntaxi HTML 5.0 s podstatnými rozšířeními, takže blízká budoucnost HTML i XHTML je zatím poměrně nejasná. Jak jsem již uvedl, HTML se rozšířilo především díky své velmi jednoduché syntaxi. Části dokumentu uzavíráme mezi takzvané tagy (značky uzavřené mezi menšítko a většího), které určují jejich význam. Část dokumentu obklopená tagy se nazývá element dokumentu a může obsahovat další vnořené elementy. Tagy jsou většinou párové, u párových rozlišujeme počáteční a koncové s lomítkem před názvem tagu. Existují i nepárové tagy, které neobklopují žádný text. Dále mohou tagy obsahovat atributy s dalšími informacemi a instrukcemi pro zpracování. Tagy můžeme rozdělit na strukturální, sémantické a stylistické. Strukturální tagy označují strukturu dokumentu a patří mezi ně například jednotlivé úrovně nadpisů, odstavce, odrážky. Sémantickou značkou je například titulek stránky (title), sémantické tagy obecně popisující povahu dokumentu. Stylistické značky určují výsledné zobrazení prvku na monitoru počítače, je doporučeno tyto značky zapisovat do externích stylů a formátovat pouze základní HTML značky, čímž oddělíme obsah od vzhledu dokumentu a dosáhneme větší kompatibility v alternativních prohlížečích i zařízeních. Od verze HTML 2.0 má každá verze HTML své vlastní DTD, které musí být od verze HTML 4.01 povinně uvedeno na prvním řádku pomocí takzvaného DOCTYPE. DTD definuje, jaké tagy se mohou v dokumentu použít i v jakých vzájemných souvislostech mohou být použity, s jakými atributy atd. HTML 4.01 definuje tři druhy DTD – transitional, strict a frameset. Transitional DTD povoluje používat všechny typy značek kromě rámců (frames, stránka je v prohlížeči rozdělena na více rámců s jednotlivými stránkami). Verze Strict nedovoluje používat jakékoliv značky definující vzhled dokumentu. DTD typu Frameset používáme, pokud je stránka rozdělena na víc rámců. Za DOCTYPE následuje většinou párový tag HTML, který obaluje celý dokument a reprezentuje tak vlastně jeho začátek a konec. V něm prvním vnořeným tagem je hlavička (head), obsahující metadata jako titulek stránky, použité kódování, kontakt na autora, odkazy na připojené externí soubory a další. Pod hlavičkou následuje tělo dokumentu (body), obsahující samotný obsah html dokumentu. Kromě tagů může zápis HTML

11

2. Základní pojmy obsahovat i další elementy jako jsou například komentáře, zápisy skriptovacích jazyků, direktivy pro jednotlivé prohlížeče. Následuje pro ilustraci příklad zápisu velmi jednoduché HTML stránky:

Titulek stránky <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="language" content="CZ-SK"> <meta name="doc-publisher" content="Pepa Novák"> <meta name="owner" content="[email protected]"> <meta name="description" content="Popisek stránky pro vyhledávače."> <meta name="keywords" content="klíčové slovo, další klíčové slovo">
Nadpis první úrovně

Text odstavce a odkaz na VŠE.

HTML je jazyk interpretovaný, po dokončení se stránka nijak nepřekládá a většinou ani jinak neupravuje, z webového serveru je přes protokol http dopravena do uživatelova prohlížeče ve stejné textové podobě jako vidíme v příkladu nahoře. Úloha prezentace dokumentu zůstává na uživatelově prohlížeči. Důsledkem vývoje jednotlivých typů prohlížečů se v nich mohou stejné dokumenty zobrazovat odlišně, to platí i pro různé verze stejného prohlížeče od jednoho výrobce. Každý složitější HTML dokument je proto dobré vyzkoušet v nejpoužívanějších prohlížečích.

2.2.2. XML Stejně jako HTML vzniklo XML (eXtensible Markup Language) ze značkovacího jazyka SGML a je vyvíjeno konsorciem W3C. Primárním účelem XML je výměna dat a publikace dokumentů. [19] Jazyk HTML si sice získal velkou oblibu, ale brzy se ukázalo, že jeho pevně daná skupina značek nestačí pro účely vyhledávání a efektivní výměny dat. Naopak z velmi komplexního jazyka SGML se používala jen malá část jeho možností. XML tedy vzniklo výběrem těch nejdůležitějších částí SGML. Na rozdíl od HTML, které je aplikací SGML, je tedy XML jakousi 12

2. Základní pojmy podmnožinou tohoto značkovacího jazyka. Zůstává nám možnost definice vlastních sad značek, a tedy i vlastního DTD. Zároveň kvůli standardizaci existují pro různá odvětví i účely již hotové sady značek. Vzhled v XML definujeme pouze použitím externě připojených stylových jazyků, což zajistí jasné oddělení obsahu dokumentu od způsobu jeho interpretace. Nejjednodušší formátování lze obstarat styly CSS (Cascading Style Sheets), které se často používají i při formátování HTML stránek. Pro náročnější aplikace můžeme využít jazyk XSLT (eXtensible Stylesheet Language). Ten se skládá z takzvaných formátovacích objektů pro abstraktní popis vzhledu a nástrojů pro transformaci XSLT (XSL Transformations). Nejnovější verze XSLT 2.0 již obsahuje i definici vlastních funkcí pro zpracování. Dává nám tak velmi efektivní možnosti rozšíření a úprav dokumentu před jeho zobrazením, nebo transformací do jiného typu dokumentu. Asi největší výhodou XML je možnost zobrazení jednoho XML dokumentu na různých zařízeních. Oproti různým firemním formátům není XML vázáno na žádnou platformu ani technologii, jeho syntaxe je velmi jednoduchá a každému zdarma k dispozici. Navíc jako asi první formát dbá i na potřeby neanglických jazyků, jelikož jeho základní znakovou sadou je univerzální znaková sada USC obsahující všechny jazyky (v případě jednojazyčných dokumentů můžeme ale pro ušetření místa použít libovolnou znakovou sadu). Syntaktická pravidla jsou u XML na rozdíl například od HTML velmi striktně vyžadována, což v kombinaci s výše uvedenými vlastnostmi vede k podstatně lehčímu a levnějšímu vývoji efektivních aplikací, než je tomu u většiny jiných formátů. Stejně jako HTML se syntaxe jazyka XML skládá z elementů vyznačených pomocí tagů. Dokument vyhovující pravidlům popsaným v DTD, nebo jiném XML schématu nazýváme validním dokumentem. Syntakticky správně zapsaný XML dokument označujeme jako správně strukturovaný (well-formed). Každý správně strukturovaný XML dokument začíná deklarací XML, která obsahuje verzi XML, použitou znakovou sadu a případně informaci o možnosti samostatného čtení bez DTD (standalone). Celý obsah dokumentu musí být obalen v jednom kořenovém elementu. Názvy elementů rozlišují malá a velká písmena (je možné použít i diakritiku, ale některé programy pro zpracování XML jí nepodporují). Každý element musí být uzavřen a to včetně prázdných elementů. Počáteční elementy mohou obsahovat atributy, jejich hodnota musí být vždy uzavřena v uvozovkách nebo apostrofech. Elementy do sebe mohou být navzájem vnořeny, nesmí se ale překřižovat (vnořený element musí být vždy celý uvnitř jiného elementu). Komentáře můžeme vkládat kamkoliv do dokumentu, kromě vnitřku zápisu jednotlivých tagů. Komentáře dále nesmějí obsahovat dvě pomlčky za sebou. Pro zápisy delších textů se speciálními znaky se používá sekce CDATA. Příklad zápisu ceníku s jednou položkou ve formátu XML:

<motorka> <popis> Superbike 998 Matrix silniční Ducati <motor>

13

2. Základní pojmy dvouválec, 4V kapalinou 998 ccm Desmodromic <maxvykon>90,5kW kW při 9.500 ot/min <maxmoment>97Nm při 7.550 ot/min <starter>elektrický <parametry> 198 kg <delka>1410 mm <maxrychlost>235 km/h 554 000 Kč

XML rovněž umožňuje vytváření interních odkazů v rámci jednoho dokumentu a externích odkazů na jiné dokumenty. Pro tvorbu odkazů slouží v XML tři standardy – XPath, XPointer a XLink. XPath (XML Path Language) je jazyk z dílny W3C, umožňující adresovat jednotlivé části dokumentu. Dokument je zde chápán jako stromová struktura jednotlivých, do sebe vnořených elementů. Speciálním výrazem XPAth můžeme vybrat konkrétní element a pracovat s jeho hodnotami a atributy. XPointer (XML Pointer Language) je patentován firmou Sun Microsystems a umožňuje dotazem vybrat určité části dokumentu. Třetí typ odkazů XLink (XML Linking Language) je samostatný jazyk pro tvorbu odkazů vyvinutý firmou W3C. Jednotlivé odkazy v něm zapisujeme formou URL, za kterou lze uvétst ještě XPointer zpřesňující odkaz na určitou část dokumentu. Další zajímavou možností XLink je možnost vytvoření odkazu mezi více než dvěma zdroji a doplnění odkazů o metadata pro další zpracování. Ačkoliv je struktura XML většinou velmi jednoduchá, v rámci standardizace a pro usnadnění práce programátorům vzniklo několik rozhraní, které nám XML dokumenty zpracují a jejich obsah zpřístupní v příjemné formě. Nejpoužívanějšími rozhraními pro čtení XML jsou SAX a DOM. SAX (Simple API for XML) prochází dokument postupně a v programu voláme funkce podle toho, na co SAX zrovna v dokumentu narazil. SAX najde uplatnění hlavně tam, kde není potřeba náhodného přístupu k částem dokumentu a důraz je kladen na rychlost a paměťovou nenáročnost zpracování. Nevýhodou SAXu je nutnost zpracování dokumentu během jednoho sekvenčního průchodu. DOM (Document Object Model) je založen na objektové reprezentaci dokumentu. Dokument načte celý a zpřístupní nám ho jako stromovou strukturu, kde každému uzlu stromu odpovídá jeden XML element. V dokumentu se pak pohybujeme podle potřeb, můžeme modifikovat, mazat, nebo zakládat nové uzly stromu. DOM najde uplatnění tam, kde je potřeba složitějšího zpracování XML dokumentů a volného pohybu po dokumentu. Nevýhodou tohoto rozhraní jsou pomalejší zpracování dokumentu a vyšší paměťové nároky. Obě rozhraní jsou dostupná pro většinu programovacích jazyků.

14

2. Základní pojmy

2.3. GNU - svobodný software Myšlenka takzvaného svobodného softwaru vznikla v roce 1983, když programátor Richard Stallman založil projekt GNU s cílem vyvinout operační systém se svobodnou licencí. [15] Licence většiny softwaru jsou navrženy tak, že nám přímo zakazují jeho volné sdílení a úpravy. Smyslem Obecné veřejné licence GNU (General Public Licence) je naopak zajištění volnosti pro sdílení a úpravy volného softwaru. Tato licence se vztahuje na většinu softwaru nadace Free Software Foundation a na jakékoliv jiné programy, jejichž autor se rozhodne tuto licenci používat. Volný software ale neznamená zdarma, i programy pod touto licencí mohou jejich autoři poskytovat za peníze. Pro volný software jsou charakteristické 4 svobody (http://www.gnu.org/): 1.) Svoboda používat ho za jakýmkoliv účelem. 2.) Svoboda studovat fungování programu a možnost uzpůsobit si ho svým potřebám. 3.) Redistribuovat kopie podle svobodné vůle. 4.) Vylepšovat program a zveřejňovat vylepšení ve prospěch celé komunity. Předpokladem druhé a čtvrté svobody je přístup ke zdrojovému kódu programu, který nám jeho tvůrce musí v případě potřeby zajistit. Svobodný software by neměl být zaměňován s také často používaným pojmem Open Source, oba projekty mají poněkud odlišnou filosofii a princip fungování. Pokud chce uživatel šířit kopie svobodného softwaru, musí tak činit rovněž pod touto licencí a příjemce těchto kopií informovat o jejich právech a svobodách. Při šíření modifikací je nutno upravenou verzi programu označit jako modifikaci a nepoškodit tak v případě problémů reputaci autora původní verze softwaru. Kvůli ochraně jednotlivých autorů i samotné Free Software Foundation nejsou na svobodný software poskytovány žádné záruky, ani v případě újmy vzniklé jeho užíváním. Prakticky celý tento projekt zhotovím a otestuji na svobodném softwaru, všechny součásti budoucí aplikace budou licencovány pod GPL nebo podobnými licencemi. Nejedná se o z nouze ctnost způsobenou mou aktuální finanční situací. Věřím, že právě ve svobodném softwaru je budoucnost. Celá aplikace bude navíc nevázaná na žádnou komerční technologii ani konkrétního výrobce, takže nemůže nastat efekt zvaný Vendor Lock-in (dodavatel ukončí vývoj klíčové technologie a přesun na jinou stojí nemalé náklady, případně je nemožný).

2.4. Webový server První webový server představil Tim Berners-Lee v rámci projektu WWW roku 1990. Základní princip fungování webových serverů se od té doby prakticky nezměnil. Webový server dostane od klienta, většinou se jedná o webový prohlížeč, požadavek ve formě URL a odpoví zasláním HTML, nebo jiného dokumentu. Celá komunikace probíhá přes protokol HTTP. Webový server je tedy počítač připojený k nějaké síti a speciální software na něm nainstalovaný, je odpovědný za vyřizování HTTP požadavků od klientů. Součástí odpovědi ze serveru je i takzvaný stavový kód, ten oznamuje výsledek požadavku (2xx požadavek v pořádku vyřízen, 3xx přesměrování, 4xx chyby s vyřízením požadavku, 5xx vnitřní chyby serveru). Webový server má dvě možnosti získání obsahu odpovědi na relevantní dotazy klientů – statický a dynamický obsah. Statickým obsahem rozumíme fyzické HTML soubory uložené na disku serveru, jejich nezměněný obsah nám server zašle v odpovědi. V případě dynamického obsahu se HTML soubor pro odpověď vytváří až po zhodnocení dotazu na webovém serveru ve spolupráci s dalším softwarem (databáze, skriptovací jazyky). Poskytování statického obsahu je sice méně hardwarově i softwarově náročné na server, ale pouze statické HTML stránky již dávno nestačí rostoucím potřebám současných interaktivních webových prezentací.

15

2. Základní pojmy Zásadní otázkou každého provozovatele webového serveru je výběr vhodného softwaru pro jeho provoz. Existují desítky programů na provoz webových serverů. Nejpoužívanějšími servery současnosti jsou Apache Server vydávaný skupinou Apache Group a IIS (Internet Information Server) od společnosti Microsoft. Podle měření společností Netcraft, uznávaného odborníka v oblasti internetových průzkumů, využívá Apache okolo 60% webových serverů. Není se čemu divit, Apache je velmi kvalitní software a navíc je poskytován zcela zdarma (na rozdíl od IIS). Ve své práci budu používat velmi populární spojení svobodného softwaru pro tvorbu dynamických webových stránek, které je známé pod zkratkou LAMP. Skládá se z operačního systému Linux, webového serveru Apache, databáze MySQL a programovacího jazyka PHP (poslední dobou je uváděn programovací jazyk Python nebo Perl). Ačkoliv jsou všechny součásti LAMP poskytovány zcela zdarma, jedná se o velmi stabilní a bezpečné řešení webového serveru. Nabízí nepřekonatelné možnosti škálovatelnosti a je k němu na internetu rovněž zdarma dostupné velké množství dokumentace, návodů, rad atd. V následujících kapitolách popíši základní vlastnosti jednotlivých aplikací architektury LAMP.

Obrázek 2.1. Celkový počet aktivních serverů, červen 2000 - červen 2007, zdroj: http://news.netcraft.com/

2.4.1. Linux Operační systém Linux je uskutečněním původního záměru projektu GNU. [6] První verzi Linuxu naprogramoval finský student Linus Torvalds jako operační systém (základní softwarové vybavení počítače, nezbytné pro jeho provoz) založený na unixovém systému Minix. Jeho cílem bylo vyvinout nový operační systém pro procesory Intel 386. Prozíravé využití licence GNU GPL umožnilo zapojení mnoha programátorů do jeho dalšího vývoje, zároveň zabránilo budoucímu využití jejich kolektivní práce pro jinak licencovaný operační systém. Později se do vývoje Linuxu zapojily i velké firmy jako IBM a Hewlet Packard. Především díky práci jednotlivých programátorů z celého světa, jejich různým úpravám a vylepšením, prošel Linux velmi rychlým vývojem a je také dostupný prakticky pro všechny typy současných počítačových architektur. Dnešní verze Linuxu mohou konkurovat špičkovým operačním systémům. Vzhledem k zapojení různých programátorů i firem je k dispozici mnoho verzí Linuxu – takzvaných distribucí. Jednotlivé distribuce mají stejný základ (Linuxové jádro + knihovny a nástroje GNU), odlišné

16

2. Základní pojmy u nich je naopak balení (instalátor) a složení (výběr programů, jednotlivá rozšíření a další úpravy). Jako hlavní výhody Linuxových operačních systémů jsou uváděny jejich minimální pořizovací náklady, nezávislost na dodavateli, vysoká míra bezpečnosti a škálovatelnosti. Svou aplikaci budu vyvíjet na velmi oblíbené linuxové distribuci Debian, vzhledem ke stejnému základu jednotlivých distribucí budou popisované postupy použitelné prakticky na jakékoliv linuxové distribuci. Jelikož všechny ostatní softwarové součásti architektury LAMP jsou dostupné skoro pro všechny současné operační systémy, aplikace nebude vyloženě vázána na Linux. Některé zde popsané postupy, zejména konfigurace a používání jednotlivých funkcí webového serveru Apache, se ale mohou u jednotlivých operačních systémů značně lišit.

2.4.2. Apache [2] Historie dnes nejpoužívanějšího webového serveru Apache je datována do poloviny devadesátých let. Od roku 1991 vyvíjela společnost NCSA (National Center for Supercomputing Applications) na University of Illinois webový server HTTPD. Po odchodu hlavního vývojáře Roberta McCoola byl projekt roku 1994 ukončen. Uživatelé serveru si začali sami vytvářet různá vylepšení a opravy, pro synchronizaci své práce založili skupinu Apache Group. První veřejně distribuovaná verze (0.6.2) byla vydána v dubnu 1995. Apache Group se následně transformovala na nevýdělečnou skupinu programátorů spolupracujících výlučně přes internet. Na vývoji serveru se může podílet prakticky kdokoliv – stačí zaslat svou verzi rozšíření, pokud je schválena, stane se součástí další verze serveru. Apache není licencován pod GNU GPL, ale pod svou vlastní licencí. Ta například nevyžaduje zveřejňování zdrojových kódů jednotlivých úprav, ale rovněž zaručuje právo software upravovat a dále redistribuovat. Verze serveru Apache 2.0, vydaná v roce 2002, je kompletně předělaná a neobsahuje již skoro nic z původního serveru HTTPD. Nejnovější verze je 2.2.4 z ledna 2007. Jedná se o opravy různých chyb verze 2 a další vylepšení. Pro spuštění serveru již nemusíme provozovat unixový operační systém, instalace jsou dostupné pro většinu současných operačních systémů. Apache je od svého počátku vysoce konfigurovatelný server s modulárním rozhraním. Každý programátor znající programovací jazyky Perl nebo C si může napsat svůj vlastní rozšiřující modul, k dispozici je tedy mnoho doplňkových modulů pro různé účely. Nastavení serveru se provádí poměrně jednoduchými úpravami konfiguračního souboru http.conf. Další výhodou je výborná podpora skriptovacích jazyků PHP, Perl, Python a Tcl, které mohou být spouštěny jako samostatný modul, nebo v režimu CGI (protokol propojující webový server s externí aplikací). Další možností tvorby dynamických stránek je využití zabudovaných příkazů a jejich spuštění na straně serveru, takzvané SSI (Server Side Includes). Pomocí run-time prostředí Tomcat je možno na serveru provozovat javovské serverlety a JSP (Java Server Pages) technologie. Apache je jeden z prvních serverů podporujících provoz virtuálních webových serverů, což mu umožňuje obsluhovat mnoho webových serverů z jedné instalace. Z dalších rysů serveru stojí rozhodně za zmínku například různé podpory autentizace, integrovaný proxy server, přepisování URL, snadno přizpůsobitelné záznamové protokoly, šifrování, podpora poslední verze protokolu HTTP 1.1 a další. Poslední verze webového serveru Apache je včetně kompletní dokumentace dostupná na adrese http://httpd.apache.org/. Kromě oficiálních webových stránek projektu existuje nespočetně dalších neoficiálních, včetně nejrůznějších diskusních fór a emailových konferencí, které jsou často zdrojem užitečných informací i hotových řešení pro tento webový server.

17

2. Základní pojmy

2.4.3. PHP PHP (Hypertext Preprocessor) je dnes jeden z nejpoužívanějších skriptovacích jazyků pro tvorbu dynamicky generovaných HTML stránek. [11] V roce 1994 si programátor Rasmus Lerdorf přepsal pro ulehčení webovému serveru svůj skript na počítání přístupu k webovým stránkám z interpretovaného programovacího jazyka Perl do kompilovaného C. Systém se zalíbil i ostatním uživatelům, Rasmus ho zanedlouho doplnil o dokumentaci, podstatně rozšířil a vydal pod názvem Personal Homepage Tools (PHP 1.0). Následující rok spojil PHP se svým vlastním překladačem do strojového kódu FI (Form Interpreter) a zveřejnil PHP/FI 2.0 jako jednoduchý programovací jazyk, který se zapisoval přímo do souboru s HTML stránkou. Ve spolupráci s dvěma izraelskými programátory (Zeev Suraski a Andi Gutmans) celý systém zrychlil, přizpůsobil i pro operační systém Windows, podstatně rozšířil o mnoho nových funkcí a v roce 1998 zveřejnili PHP 3.0. Tentokrát již pod názvem Hypertext Preprocessor. [10] Verze 4.0 z května 2000 je ještě rychlejší a stabilnější díky založení na Zend Engine, lze jí také provozovat i jako modul Internet Information Serveru. Tato verze měla také již přímo zabudovanou podporu sessions (ukládání informací o uživateli na serveru, umožňují obejít krátkodobost http spojení). [12] Poslední zásadní verze PHP 5.0 byla vydána v roce 2004, rovněž se spoustou novinek. Kromě svého založení na novém Zend Engine 2 přináší zejména kompletní přepracování objektového modelu a vylepšenou podporu objektově orientovaných metodologií včetně návrhových vzorů. Chyby jsou v PHP 5 zpracovávány, podobně jako v Javě, vyhazováním výjimek (exception). Téměř kompletně byla přepracována podpora XML, nově můžeme používat XSLT transformaci pomocí libxslt, jednoduché zpracovávání pomocí SimpleXML a metodu DOM vyhovující standartu W3C. Stávající podpora databázového systému MySQL byla vylepšena a přibyla rovněž podpora jednoduchého databázového systému SQLite. Jedná se o interpretovaný jazyk, který je zpracováván na straně serveru. Od verze PHP 2 se jeho příkazy zapisují přímo do HTML souborů, při volání jsou přeloženy modulem serveru, nebo skriptem CGI. Výsledkem je vygenerovaný výstup, který je zaslán webovému klientovi. PHP kód zapisujeme vždy mezi dva tagy, existují 4 způsoby zápisu, použitelné jsou v závislosti na nastavení používané verze. Podle nastavení webového serveru jsou příkazy mezi těmito tagy zpracovávány, zbytek HTML je ponechán beze změn. Příklad zápisu jednoduchého PHP skriptu ve struktuře HTML stránky:

PHP příklad

PHP má v sobě implementovánu rozsáhlou knihovnu příkazů a funkcí pro nejrůznější účely, které podporují většinu internetových standardů. Zobrazení na výstupu obstarává příkaz echo. V současné době je ale doporučeno oddělovat kód a vzhled aplikace. To se provádí zejména u

18

2. Základní pojmy složitějších aplikací, na kterých pracuje větší tým lidí, převážně pomocí šablon. V ideálním případě jsou příkazy echo (resp. ekvivalentní příkazy print) úplně odstraněny. Výhodou oddělení aplikační logiky od zobrazení je jasnější kód a snazší modifikace celé aplikace pro všechny členy týmu (designéři versus programátoři). Syntaxe PHP je založená na stylu zápisu několika programovacích jazyků (primárně Perl a C). Správa paměti je v tomto programovacím jazyce automatická, takže pro většinu programátorů je naučení PHP otázkou několika hodin nebo dnů. Většina nastavení se provádí editací konfiguračního souboru php.ini. Od verze 4 je PHP dostupné pro všechny nejpoužívanější operační systémy, současně došlo k abstrahování od rozhraní www serveru, takže stejně napsané aplikace v PHP jsou funkční na různých typech serverů. Podle měření společnosti Netcraft bylo v dubnu 2007 PHP využito na více jak dvou milionech domén a na 1 208 663 IP adresách.

Obrázek 2.2. Využití PHP duben 2003 - duben 2007, zdroj: http://www.php.net/usage.php PHP je licencováno pod GNU GPL, různé typy instalací včetně zdrojových kódů a dokumentace jsou dostupné na oficiálních stránkách http://www.php.net/. K dispozici je rovněž asi nejširší podpora ve formě různých neoficiálních stránek, diskuzí, skriptů a návodů.

2.4.4. MySQL [10] MySQL je v současnosti nejrozšířenější relační databázový systém (více jak 11 milionů instalací), vyvíjí ho od roku 1995 švédská firma MySQL AB. Dostupný je na adrese http:// www.mysql.com jako svobodný software, k dispozici je ale i jeho placená komerční verze včetně technické podpory. Databáze je v relačních databázích tvořena jednotlivými relacemi, ty si můžeme představit jako tabulky. Každý sloupec tabulky má název a reprezentuje určitý datový typ, v řádcích tabulek jsou naopak uloženy jednotlivé záznamy. Databáze nám umožňuje velmi efektivně skladovat, prohledávat, třídit, ukládat a získávat data. MySQL server kontroluje přístup k datům, umožňuje současnou práci více uživatelů s databází. Pro komunikaci s databází používá MySQL server standardizovaný dotazovací jazyk SQL (Structured Query Language). Jako hlavní výhoda MySQL je uváděna především jeho rychlost (i za cenu značného zjednodušení oproti jiným databázovým systémům), přenositelnost, nízké náklady a snadné ovládání.

19

Kapitola 3 Ontologie Pojem ontologie má svůj původ již v nejstarší řecké filosofii. [14] Skládá se ze dvou řeckých slov - TO ON (jsoucí) a LOGOS (myšlení, slovo, řeč). Ontologie je tedy jakýmsi rozhodnutím o tom, co a jak věci jsou, a toto rozhodnutí je záležitostí myšlení. [7] Od 90. let se ontologie začíná objevovat jako označení specifického informatického pojmu, jako explicitně specifikovaná konceptualizace. Konceptualizace znamená systém pojmů modelujících určitou část světa, explicitně specifikovaná značí její explicitní vyjádření - nezůstává jen skryta v hlavě jejího autora. Jako hlavní přínosy ontologií jsou uváděny především podpora porozumění mezi lidmy, podpora komunikace mezi počítačovými systémy, a také usnadnění návrhu znalostně-orientovaných aplikací. V našem případě nám ontologie pomůže specifikovat strukturu statického webu a následně vytvořit co nejlepší navigaci znalostmi v něm uloženými. Tvorbou ontologie zároveň přijímáme ontologický závazek, v další práci budeme používat prvky a strukturu navržené ontologie. Je důležité, aby ontologie měla optimální tvar a vyhovovala způsobu jejího využití - tvorbě účinné navigace na statickém webu. Také se musíme snažit o kompromis mezi použitelností a znovupoužitelností navržené ontologie, měla by být co nejméně závislá na připravované aplikaci i na konkrétním webu, pro který navigaci zhotovujeme.

3.1. Prezentace ontologie Výslednou ontologii znázorním pouze graficky, podle [7] by se tedy nechala označit jako semiformální ontologie. Pro tvorbu ontologie použiji editor Protégé 2000, dostupný na adrese http:// protege.stanford.edu, pro grafickou reprezentaci jeho plugin OntoViz. V případě potřeby zápisu ontologie nějakým formálním jazykem s přesně definovanou syntaxí má tento editor možnost exportu do několika takovýchto jazyků. Pro potřeby této aplikace bude ale postačovat semiformální grafický model (celá ontologie bude zatím poměrně jednoduchá, takže není zapotřebí vyvíjet automatické zpracování). V následujícím textu popíši prvky, které bude tato ontologie používat a uvedu jejich grafické vyjádření. Částečně jsem vycházel z [9], pro větší vypovídací hodnotu jsem některá grafická znázornění generovaná pluginem OntoViz ještě upravil. Třídy (classess) jsou základním stavebním prvkem většiny znalostních ontologií, reprezentují skupiny konkrétních objektů. Graficky je budu znázorňovat rámečkem obsahujícím jméno třídy a vlastnosti třídy (viz. dále). Individua (instances) jsou naopak konkrétní objekty z reálného světa patřící do definovaných tříd. Ontologie slouží primárně k popsání tříd a vztahů mezi nimi. Ve svém návrhu ontologie navigace žádné konkrétní instance vyznačovat nebudu. Množina všech tříd je hiearchicky uspořádána do takzvané ISA hiearchie. Rodičovské třídy tak mohou 20

3. Ontologie obsahovat další, více specifické, podtřídy. Graficky je ISA vztah znázorněn šipkou s popiskem ISA. Sloty popisují vlastnosti tříd. Mohou nabývat různých typů hodnot: String (textový řetězec), Number (číslo), Boolean (logická hodnota nabývající True (pravda), nebo False (nepravda)), Enumerated (může nabývat některé z výčtu uvedených hodnot), Instance (vyjadřuje vztah mezi instancemi, musí rovněž obsahovat seznam povolených tříd, ze kterých mohou instance pocházet). Sloty budu znázorňovat jako atributy uvnitř zobrazení konkrétní třídy. Vyjímku budou tvořit sloty hodnoty Instance, které budou znázorněny šipkou mezi konkrétními objekty. Seznam povolených tříd (range) slotů hodnoty Instance budu implicitně předpokládat o maximálním rozsahu jedné třídy. Mohutnost slotu (cardinality) definuje kolik hodnot může slot nabývat. Pokud má mohutnost 0, nemůže nabýt pro konkrétní třídu žádné hodnoty. Pokud má hodnost 1, nabývá právě jedné hodnoty. Rovněž může mít udán rozsah minimální a maximální mohutnosti - například mohutnost typu M,N značí, že slot může mít minimálně M a maximálně N hodnot. Mohutnost budu vyznačovat jen u slotů s hodnotou Instance zápisem k ukazateli šipky. U slotů s hodnotou jiného typu než Instance mohutnost neznačím a předpokládám, že má mohutnost 1.

3.2. Ontologie navigace Při vytváření ontologie navigace na webu jsem se částečně inspiroval [8]. Na jednotlivé webové místo (website), v našem případě stránky, kterým vytvářím navigaci, budu pohlížet jako na neuspořádanou množinu samostatných HTML souborů. Již vytvořenou navigaci, hypertextové spoje mezi soubory, ani strukturu adresářů či souborů nebudu brát v úvahu. U každé website znám její URL, název, a šablonu. Název a šablona slouží pro vnitřní potřeby aplikace, jejich konkrétní funkci popíší později. Z celé neuspořádané množiny HTML souborů lze vybrat shluky HTML souborů, tvořících jako celek jednotlivé dokumenty. Webové místo je tedy složeno z jednotlivých dokumentů, reprezentovaných jejich úvodními HTML stránkami. U jednotlivých hlavních dokumentů známe povinné atributy: název, datum vytvoření, typ dukumentu, platnost dat a URL. Typ dokumentu nám poslouží pro další zpracování či odlišení různých druhů dokumentů. Platnost dat značí, jestli jsou informace uvedené v dokumentu nadále relevantní, popřípadě zda je dokument stále udržován aktuální. Vícestránkové dokumenty obsahují kromě úvodní stránky ještě další HTML stránky, které tvoří další obsah dokumentu. U těchto stránek známe povinné atributy: nadpis, URL a typ stránky. Každý Dokument má svého autora, popřípadě více autorů. U autora budeme uchovávat jeho jméno (nebo přezdívku pokud nechceme na webu zobrazovat skutečná jména) a e-mailovou adresu jako kontaktní prostředek pro spojení s autorem. Jednotlivé dokumenty pojednávají o nějakém Tématu. Každý dokument může souviset i s více tématy a okruhy témat jsou hiearchicky uspořádané. Pro generování souvisejících věcí budou právě témata klíčovým prvkem, který pomůže roztřídit informace na webu uložené. U každého tématu známe jeho název, eventuelně téma jemu nadřazené. Všechna témata jsou uspořádána do souvislé ISA hiearchie s jedním kořenem, jímž je abstraktní třída Téma. Abstraktní třídy v ontologiích nemohou obsahovat žádné přímé instance, ty mohou obsahovat pouze jejich potomci (nejsou-li rovněž abstraktní). Dokumenty mohou pojednávat pouze o potomcích této abstraktní třídy.

21

3. Ontologie

website

ISA

- URL STRING - název STRING - šablona STRING

autor

téma - název STRING

1

- jméno STRING - mail STRING

0, N patri_do

slozena_z

na

1, N

ps

al

p

d oje

na

v

o a_

na

j e_

1, N

an ps

dokument

na

_v

0, N obsahuje

STRING 0, N -- nadpis URL STRING - platnost BOOLEAN - datum NUMBER - typ ENUMERATED

ine zm

1

obsah

0, N - nadpis STRING - URL STRING - typ ENUMERATED je_obsahem

Obrázek 3.1. Diagram ontologie navigace. Do návrhu ontologie navigace přirozeně nezahrnuji všechny možnosti a atributy, které by mohla účelná navigace po konkrétních webových stránkách vyžadovat. V případě potřeby může být ontologie rozšířena, nebo může požadavek logicky splnit přímo aplikace, která bude navigaci generovat. Tato ontologie obsahuje pouze základní třídy a jejich atributy. Ty by měly postačovat k popsání struktury webových stránek a následnému zhotovení navigace po nich.

22

Kapitola 4 Topic Maps [18] Český překlad názvu technologie Topic Maps je "mapy témat". [17] [16] Počátky vývoje map témat můžeme datovat do roku 1991. Skupina autorů, později nazvaná Davenport Group, si dala za cíl vyvinout systém umožňující elektronickou správu a sdílení softwarových manuálů. Pro vyznačení obsahu dokumentu vzniklo SGML DTD, dnes známé jako DocBook. Jeden z problémů, se kterými se Davenport Group musela vyrovnat, bylo spojování rejstříků z různých dokumentací. Prvotní pokus byl vyřešit tento problém pomocí HyTime (Hypermedia/Timebased Structuring Language), v této době (1993) už tvůrcům ale dochází možnosti daleko přesahující pouhé modelování rejstříků a vzniká první idea Topic Maps. zakládají odbornou komisi ISO/IEC JTC1 SC34, která v roce 2000 uznává mapy témat za mezinárodní standard ISO/IEC 13250: 2000 Topic Maps. Tento standard specifikoval základní koncept Topic Maps, ale jeho syntaxe nebyla pevně daná a byla založena na spojení SGML a HyTime. Vzhledem k jejímu založení na značkovacím jazyku SGML, který slouží primárně k formálnímu popisu struktury dokumentů, nemohla být efektivně použita pro organizování informací. Počátkem roku 2000 byla založena nezávislá organizace TopicMaps.org, která si dala za cíl definovat Topic Maps založené na syntaxi XML a docílit tak jejich lepší integrace na webu. V březnu 2001 vydávají formu zápisu map témat nazvanou XTM 1.0 (XML Topic Maps) [20]. Ta byla zahrnuta do zrevidovaného standard ISO/IEC 13250: 2003 [5]. Takto by se nechal stručně charakterizovat vývoj mezinárodního standardu pro sdílení a prezentaci znalostí Topic Maps. V následujícím textu popíši jeho základní model, principy a konstrukce. Jelikož zatím neexistují kompletní české překlady jednotlivých standardů, budu české názvy používat jen u již přeložených pojmů z [18], všechny výrazy budou ještě doplněny při prvním použití originálním anglickým názvem pojmu.

4.1. Model mapy témat Jelikož mapy témat vznikly na principu fungování rejstříků v knihách, jejich model obsahuje dvě vrstvy. Vrstva informací (information layer) je označována také jako "spodní vrstva", jedná se o vrstvou informačních zdrojů. Ta by se nechala přirovnat k samotnému obsahu knihy. Většinou má elektronickou podobu, ale není to podmínkou. V našem případě bude touto vrstvou soubor statických dokumentů nahraných na www serveru, pro který chceme vytvořit navigaci. Naopak za "horní vrstvu" bývá označována vrstva znalostí (knowledge layer), ta funguje na principu rejstříku na konci knihy. Znalostní vrstva obsahuje témata (topics) a vztahy (associations). Téma reprezentuje v mapě témat vždy nějaký předmět, jejich význam je obdobný jako význam jednotlivých pojmů v rejstříku. Vztahy zase reprezentují vztahy mezi těmito předměty. 23

4. Topic Maps Vrstva informací a vrstva znalostí jsou propojeny výskyty (occurrences), které spojují téma a nějaký související informační zdroj. Výskyty hrají roli čísel stran u jednotlivých položek rejstříku knihy. napsal kniha spisovatel mìsto narozen v znalostní vrstva vrstva informací

Obrázek 4.1. model mapy témat

4.1.1. Mapa témat [5] Mapa témat může existovat v mnoha podobách. Může být zapsaná v nějakém souboru, uložená v databázi, jako datová struktura uvnitř běžícího programu, dokonce i duševně - uložená v mysli člověka. Všechny tyto podoby jsou jen různými způsoby reprezentace datového modelu, který popisuje norma ISO/IEC 13250. Pojem mapa témat je pouze technický význam souboru jednotlivých témat, vztahů a úhlů pohledu, ty dohromady tvoří základní uzly mapy témat (Topic Map nodes). Pro zápis mapy témat do souboru s nějakou syntaxí existuje několik formátů, ve své práci budu používat bezpochyby nejznámější formát XTM 1.0. XTM soubory mají výhodu široké podpory aplikací pro práci s mapami témat a jsou také relativně snadno zpracovatelné, vzhledem ke svému založení na XML. Jejich syntaxe je definovaná v [20], kde jsou zároveň popsány požadavky na zpracovávání XTM souborů. Tyto požadavky definují takzvanou konzistentní mapu témat (consistent Topic Map), ve které existuje ke každému předmětu právě jedno téma a neexistují duplikátní výrazy ani jiné důvody pro sloučení jednotlivých uzlů mapy témat. Ačkoliv je mapa témat pouze technický pojem, může jí samotnou zastupovat nějaké téma. O takovéto mapě témat se můžeme vyjadřovat, nebo jí přiřazovat metainformace.

24

4. Topic Maps

4.1.2. Témata Téma (topic) je symbol zastupující v mapě témat vždy právě jeden předmět. Předmětem může být cokoliv nehledě na to, jestli to reálně existuje, nebo má nějaké další vlastnosti. Přesněji řečeno předmětem je cokoliv, o čem se autor rozhodne vyjadřovat. Rozhodnutí co označit jako téma v konkrétní mapě témat závisí na autorovi a jeho zhodnocení potřeb aplikace, struktury informací a budoucího používání konkrétních témat. Proces vytvoření tématu je nazýván reifikace (anglicky reification, český překlad by mohl být zvěcnění [7] ). Cokoliv je reifikováno se stává předmětem vytvořeného tématu a můžeme se o tom vyjadřovat v rámci mapy témat. Jelikož cokoliv může být reifikováno, můžeme předmětem tématu učinit i všechny další konstrukce mapy témat - vztahy, výskyty, názvy témat (topic name). Jednotlivá témata mohou být uspořádána podle typů do tříd a instancí (viz. kapitola 2.1). Téma může být potomkem jedné nebo více tříd témat, nazývaných také jako typy témat. Pokud nemá téma nastaven typ je bráno jako téma výchozího typu "topic". Důležitým prvkem pro rozlišení témat jsou jejich indikátory (subject indicator). Jejich význam spočívá v jednoznačné identifikaci předmětu daného tématu v mapě témat. Pokud je předmět informační zdroj, je dostupný počítačovému systému a je adresovatelný (většinou přes URL), tak samotná jeho adresa může být použita jako indikátor (subject locator). Pokud předmět není informačním zdrojem, jeho identita může být vyjádřena pouze nepřímo. V tomto případě používáme identifikátor předmětu (subject identifier). Výhoda takovýchto indikátorů je jejich srozumitelnost pro počítač i pro člověka. Nevýhodou je naopak možnost, že jednotliví tvůrci budou ve svých mapách témat používat absolutně odlišné indikátory. To by znemožnilo, nebo přinejmenším velmi ztížilo, jejich slučování. Pro tyto účely vznikají PSI (published subject indicator). Jedná se o zveřejněné sady indikátorů předmětů, které mají posílit právě slučování a map témat a sdílení předmětů z nich. Existují tři typy charakteristik tématu: název tématu, výskyt tématu a jeho role ve vztazích. Každé téma může mít žádnou nebo několik takovýchto charakteristik. Tyto charakteristiky mohou být platné pouze v určitém kontextu - mají explicitně nastavenou oblast platnosti (scope) jako množinu témat, pro kterou daná charakteristika platí. Pokud charakteristika nemá nastavenou oblast platnosti, implicitně předpokládáme neomezenou oblast platnosti (unconstrained scope). Charakteristika s neomezenou oblastí platnosti platí za všech okolností. Využití oblastí platnosti je mnoho - můžeme například nastavit tématu název platný v určitém jazyce, omezit platnost výskytu pouze na určitý obor, nebo obdobně omezit platnost vztahu mezi tématy. Oblast platnosti je také nástrojem odstraňujícím dvojsmysly z mapy témat, které vznikají například v důsledku homonymních názvů. Další zajímavá možnost využití oblastí platnosti, kterou jsem ještě nezmínil, je dynamicky změnit pohled na celou mapu témat v závislosti na uživateli a jeho požadavcích na informace, zaměření, jeho znalostech, jazykových schopnostech atd. První zmíněná charakteristika tématu je jeho název. Každé téma může mít žádný nebo více názvů. Každý název obsahuje jeden základní název (base name), který může mít další variantní názvy (variant name). Základní název je vždy typu string, je předmětem omezení nazvaného topic naming constraint = v jedné mapě témat nesmí existovat více témat se stejným základním názvem ve stejné oblasti platnosti. Variantní název poskytuje většinou alternativu k základnímu, která je optimalizována pro nějaký způsob použití - např. zobrazení, řazení. Způsob použití variantního názvu specifikuje soubor témat nazvaný parametry (parameters). Další dvě charakteristiky témat popíši podrobněji v následujících kapitolách.

25

4. Topic Maps

4.1.3. Vztahy Vztah (association) vyjadřuje vztah mezi jedním, dvěma nebo více tématy. Každé z témat ve vztahu je členem vztahu a hraje určitou roli. Role ve vztahu, kterou téma hraje, patří mezi charakteristiky tématu a může proto mít nastavenou oblast platnosti. Vztahy nejsou orientované a jejich orientaci nahrazují právě role vztahu, které vysvětlují vliv na jednotlivá témata jako členy vztahu. Vztah můžeme chápat spíše jako tvrzení, které platí nezávisle na úhlu našeho pohledu. Každý vztah je právě jednoho typu (assocciation type). Typ vztahu je buď explicitně zadán jako téma, nebo je vztah výchozího typu "assocciation" PSI. Právě možnost členit vztahy podle typů a následně zjistit soubor témat se stejným vztahem k určitému tématu nám dává možnost vybudovat intuitivní a efektivní navigaci rozsáhlými množinami informačních zdrojů. Vztahy rovněž poskytují mnoho informací o jednotlivých tématech a dělají tak z mapy témat zdroj znalostí, aniž by musela být propojena s vrstvou informací.

4.1.4. Výskyty Výskyt (occurrence) spojuje téma s jedním nebo více informačními zdroji, které nějak souvisí s předmětem tohoto tématu. Většinou se jedná o výskyt mimo mapu témat, který je adresován například použitím URL do vrstvy informací. Vrstva informací tedy nemusí být při tvorbě nebo úpravách mapy témat nijak pozměňována. Výskyty mohou ale být i uvnitř mapy témat, takovéto výskyty jsou přímo zapsané v mapě témat jako textový řetězec (resource data). Stejně jako každá charakteristika tématu, může mít i výskyt zadanou oblast platnosti. Další vlastností výskytu je jeho typ (occurrence type). Každý výskyt má nastaven právě jeden typ, který je buď zadán explicitně jako téma popisující typ výskytu, nebo je výskyt implicitně typu "occurrence" PSI.

4.2. Slučování map témat Slučování (merging) je jednou ze základních potřeb ovlivňujících vznik map témat. Podle [20] je procesem slučování buď sloučením dvou map témat, nebo sloučení dvou témat. Spojení dvou map témat může být zapříčiněno zápisem direktivy pro spojení MergeMap (ta odkazuje přes XLink na externí soubor s mapou témat) nebo jakýmikoliv potřebami aplikace, která pracuje s mapami témat. Při sloučení by měly být všechny témata zastupující stejný předmět spojeny do jednoho, duplicitní vztahy odstraněny a jejich charakteristiky sloučeny, rovněž s odstraněním duplicit. Spojování v rámci jedné mapy témat by mělo být zajištěno automaticky při jejím zpracování a aktualizacích. Shodnost předmětů dvou témat může být vyhodnocena na základě alespoň jednoho shodného indikátoru, nebo pokud reifikují stejný adresovatelný předmět, nebo mají shodné základní jméno ve stejném úhlu pohledu. Pokud chceme zajistit bezproblémové sloučení map témat, je vhodné zkontrolovat jednotnost indikátorů, nebo v obou mapách použít stejné sady PSI. Mapa témat, ve které neexistují žádné vnitřní důvody pro slučování, může být označena za konzistentní mapou témat. Možnost slučování dělá z map témat jedinečný nástroj pro sdílení znalostí z různých zdrojů. Již dnes je používáno například k propojování webových portálů založených na mapách témat. Za účelem propojení vzdálených map témat je rovněž vyvíjen speciální protokol TMRAP (Topic

26

4. Topic Maps Maps Remote Access Protocol). Ten je založen na přenosu přes protokol HTTP a prototypově implementován v produktech společnosti Ontopia.

4.3. Vytvoření mapy témat Každá mapa témat obsahuje svou vlastní, rovněž hierarchicky uspořádanou, ontologii. Transformace již navržené ontologie navigace (viz. kapitola 3) do mapy témat je přímočarý proces, který spočívá ve vyjádření tříd a instancí tématy. Sloty jednotlivých instancí vyjádřím pomocí charakteristik těchto konkrétních témat (názvy, role ve vztazích, výskyty). Některé z těchto charakteristik ještě reifikuji, aby se s nimi nechalo v rámci mapy témat i budoucí aplikace lépe pracovat. Reifikace těchto charakteristik je také velmi užitečná při použití editorů map témat, které nám podle ní poskytnou intuitivní navigaci a umožní logické plnění mapy témat. V zájmu co největší kompatibility použiji standardní PSI a pro ostatní neadresovatelné subjekty URL z anglické verze encyklopedie Wikipedia. XTM soubor vytvořím podle pravidel popsaných v [20], pro jeho zápis je možno použít prakticky jakýkoliv editor, XML editor se zvýrazňováním a kontrolou XML syntaxe, nebo přímo editor pro tvorbu XTM souborů (Ontopoly, Topic Map Designer, Empolis K42 a další). Syntaxe XTM souborů je poměrně jednoduchá a v praxi se mi nejvíce osvědčil zápis této mapy témat v jednoduchém editoru se zvýrazněním XML syntaxe. Používání XTM editorů i sofistikovanějších XML editorů je vzhledem k malému množství opakujících se konstrukcí v mé mapě témat zbytečně zdlouhavé, nicméně může napomoci odhalení chyb a bude pravděpodobně lépe pochopitelné pro začínajícího uživatele. Kontrolu správnosti zápisu syntaxe a dalších požadavků na mapu témat nechám až na aplikaci, která bude XTM soubor zpracovávat. V úvahu připadá možnost automatického vytváření na základě například metadat informačních zdrojů, vytvoření takového algoritmu by ale bylo poměrně složité a musel bych se spoléhat na správně zapsaná metadata od jejich tvůrců. V případě správných metadat v hlavičkách všech HTML souborů by se nechala vytvářet jednotlivá témata za použití nadpisu jako základního názvu. Identita předmětu by byla složena z názvu a cesty k souboru, ostatní meta informace z hlavičky (autor, vytvoření, jazyk a další) by mohla být použita jako charakteristiky vytvořených témat. Složitější, možná i nemožné, by bylo automatické vytváření jednotlivých vztahů mezi informacemi z těchto zdrojů. Zajímavější a bezpochyby efektivnější by bylo využití automatizovaného procesu v případě, že by informační zdroje byly uloženy například v relační databázi. Z relační databáze by se jednotlivé vztahy popřípadě nechaly odvozovat, meta informace testovat a jednoduše tak zabránit omezení topic naming constraint (stejná základní jména ve stejné oblasti platnosti u různých témat). Některé automatické i manuální postupy zpracování dalších typů informačních zdrojů jsou popsány v [17]. Mnoho takovýchto postupů i dalších zdrojů informací k problematice map témat je k dispozici v mailinglistu ISO/IEC 13250 Topic Maps (http://www.infoloom.com/mailman/listinfo/topicmapmail) nazvaném topicmapmail. Zajímavé je rovněž využití počítačové lingvistiky NLP (Natural language processing), pomocí které je údajně dosahováno dobrých výsledků při automatickém zpracovávání absolutně nestrukturovaných dokumentů do map témat. Aby mohly ostatní části aplikace s mapou témat pracovat, musí být dodržen ontologický závazek, být dodržována shodná pojmenování některých základních konstrukcí v mapě témat. V úvahu připadá i budoucí mezinárodní použití této aplikace, proto jsem tyto klíčové konstrukce pojmenoval v anglickém jazyce. V XML dokumentech se velmi často používá element xml:base, který definuje základní cestu (schéma, počítač, port) a v ostatních adresách v dokumentu se

27

4. Topic Maps cesta zapisuje pouze relativním odkazem (cesta, dotaz, fragment). Je tak docíleno úspory místa a snadného znovupoužití dokumentů při případném přesunu na jiný server. V této aplikaci bude u každé mapy témat atribut xml:base uchovávat adresu serveru a sloužit pro další zpracování. Dalším požadavkem na vyhovující mapu témat, kromě základních konstrukcí aplikace, atributu xml:base a samozřejmě validní syntaxe, je aby byla uložena v kódování UTF-8. To je základním kódováním pro zpracování XML souborů v PHP pomocí DOM. Pro lepší pochopení bude ukázková mapa témat včetně popisků a návodu k používání součástí každé distribuce budoucí aplikace. Pro ilustraci uvádím část kódu XTM souboru. Ten zachycuje informace o webové stránce, jednom jejím dokumentu a jeho jednostránkovém obsahu, dále obsahuje jedno téma zmíněné v hlavním dokumentu.

<subjectIdentity> <subjectIndicatorRef xlink:href="#id0"> Mojestranky.cz <parameters> obrazky\moje_logo.gif <parameters> sablona_nazev

28

4. Topic Maps <subjectIdentity> <subjectIndicatorRef xlink:href="http://en.wikipedia.org/wiki/Cooking"/> Vaření <subjectIdentity> kynuté buchty <parameters> 2007-01-01 12:00:00 <subjectIdentity> příprava těsta <parameters> 1.

29

4. Topic Maps <member> <member>

Velmi pohodlné vytváření i prohlížení map témat umožňují produkty společnosti Ontopia. Jejich časově omezená verze je po registraci zdarma dostupná ke stažení na oficiálních stránkách společnosti http://www.ontopia.net.

Obrázek 4.2. Omnigator - software na prohlížení map témat od společnosti Ontopia.

30

4. Topic Maps Většina XML editorů umožňuje zobrazení stromové struktury XML dokumentu a vkládání jednotlivých uzlů. Tyto editory jsou rovněž velmi dobře použitelné pro tvorbu map témat ve formátu XTM. Užitečná je i vestavěná automatická validace oproti DTD.

Obrázek 4.3. XML editor - XML Mind (http://www.xmlmind.com/xmleditor/). Jako nejrychlejší způsob zápisu se mi však osvědčilo použití obyčejného editoru se zvýrazněním XML syntaxe. Toto zvýraznění napomůže odhalit překlepy v kódu. Po zapsání základních konstrukcí a seznámení se s jejich syntaxí můžeme zapisovat velmi rychle přímo XTM kód.

Obrázek 4.4. Unicode vývojářský editor - PSPad (http://www.pspad.com). 31

Kapitola 5 Aplikace V této části práce navrhnu aplikaci, která bude pomocí vhodných technologií zpracovávat XTM soubory a následně poskytovat navigaci webovým stránkám. Postup ověřím v praxi, zároveň nastíním některé možné nedostatky a problémy, případně jejich možná řešení. První verze bude prozatím i s dalšími soubory dostupná na adrese http://topic-maps-cms.poslouchej.com/, v budoucnu bych chtěl na rozvoji této aplikace nadále pracovat. Celý projekt bude licencován pod licencí GNU GPL. Jeho uživatelé i tvůrci podobných aplikací budou tedy moci těžit z výhod této svobodné licence, které jsem popsal v kapitole GNU – svobodný software.

5.1. Topic Map Engine Základem většiny aplikací využívajících mapy témat je takzvaná Topic Map Engine. Ta zprostředkovává základní operace jako procházení, dotazování, validaci, načítání a ukládání mapy témat. Existuje poměrně hodně komerčních i nekomerčních Topic Map Engines pro různé programovací jazyky i platformy, ale pro PHP existuje aktuálně jen jedna – QuaaxTM.

5.1.1. Quaax TM QuaaxTM je projekt vyvíjený Johannesem Schmidtem z německé firmy t8d. Jedná se o svobodný software, který, jak mi Johannes Schmidt v emailu sdělil, bohužel nebyl zatím pravděpodobně využit v praxi. QuaaxTM poskytuje standardizované rozhraní pro přístup a manipulaci s daty z mapy témat, využívá PHP 5 a MySQL. Postaven je na rozhraní pro programování aplikací TMAPI (viz. další kapitola), což mé aplikaci zajistí jistou míru standardizace a přenositelnosti. Pro uložení mapy témat vyhovující ISO 13250 je využita MySQL databáze s tabulkami ve formátu InnoDB. Tento formát umožňuje mimo jiné transakční zpracování požadavků, které pomůže snadněji udržovat integritu uložené mapy témat. Nevýhodou může naopak být nedostupnost tohoto formátu na poměrně značné části webhostingů a také jeho nejasná budoucnost. První nevýhoda je zapříčiněna trochu většími systémovými požadavky na provoz většího množství MySQL databází s tabulkami ve formátu InnoDB. Druhá pak stávajícím majitelem firmy Innobase Oy, která vyvíjí formát InnoDB, firmou Oracle. Panují obavy, že v budoucnu dojde ke zpoplatnění tohoto databázového systému. Zatím je ale InnoDB součástí standardní distribuce MySQL. V případně jeho zpoplatnění jsou možnosti jeho nahrazení jiným formátem podporujícím transakce v MySQL (Falcon), případně jiným databázovým systémem (PostgreSQL, FireBird a další).

32

5. Aplikace Poslední verze QuaaxTM 0.3 je dostupná na adrese http://quaaxtm.sourceforge.net. Instalace tohoto Topic Map Engine spočívá ve vytvoření struktury databáze, zapsání přístupových práv k této databázi do konfiguračního souboru a změnou cesty ke skriptům (pokud chceme mít QuaaxTM jinde než v adresáři nazvaném quaax). Systémové požadavky na provoz QuaaxTM jsou již zmíněná databáze s podporou formátu InnoDB a PHP od verze 5 vzhledem k jeho podpoře objektově orientovaného přístupu.

5.2. TMAPI API (application programming interface) znamená volně přeloženo rozhraní pro vytváření aplikací, nejčastěji má podobu nějakého souhrnu funkcí, procedur, nebo tříd knihovny, které může programátor při své práci využívat. [3] TMAPI se snaží programátorům v programovacím jazyku Java poskytnout jednotné API pro zpracovávání a manipulaci s daty v mapách témat. Definuje set základních rozhraní, která musí být jemu vyhovující aplikací implementována, ale i další dodatečná rozhraní, které může vyhovující aplikace používat. Hlavním cílem TMAPI je eliminovat rozdíly v jednotlivých přístupech ke zpracovávání map témat a posílit přenositelnost aplikací pracujících s mapami témat. Jeho tvůrci se podle vlastních slov snaží: "Udělat pro mapy témat to, co udělali SAX a DOM pro XML.".

5.2.1. PHPTMAPI Implementaci TMAPI pro jazyk PHP zhotovil již zmiňovaný tvůrce QuaaxTM Johannes Schmidt. Jeho PHPTMAPI bylo poprvé vydáno 27. 6. 2006 a dává si za cíl poskytnout vývojářům v PHP jednoduchou a standardizovanou možnost používání map témat. Rozhraní je realizováno použitím takzvaných objektových rozhraní (interface), která jsou k dispozici v PHP 5. [11] Třída (class) je v PHP speciální konstrukcí obsahující data i funkce pro práci s nimi. Instance již nadefinovaných tříd nazýváme objekty. [12] Rozhraní je vlastně jakousi kostrou třídy. Definuje její strukturu, ale neprovádí ani neobsahuje žádný kód, pouze názvy metod (tříd, rozhraní) a jejich argumenty. Výsledná třída pak tuto šablonu implementuje. Pokud voláme metodu, která není v žádném z implementovaných rozhraní, skript skončí chybou. Rozhraní se definuje klíčovým slovem interface a pro jeho použití za názvem třídy uvádíme frázi implements. Jedna třída může implementovat i více rozhraní. Tímto principem nám PHPTMAPI nadefinuje názvy jednotlivých metod a zajistí, že nebudeme volat nenadefinované třídy. Rozhraní z PHPTMAPI jsou následně implementována třídami QuaaxTM. V případě nutnosti předělání aplikace na jiný Topic Map Engine, rovněž postavený na TMAPI, by tak bylo zapotřebí jen minimálního úsilí. Aktuální verze PHPTMAPI 1.0 je dostupná, včetně dokumentace a celkového diagramu tříd tohoto api, na adrese http://phptmapi.sourceforge.net/. Zdrojové kódy jsou rovněž součástí instalačního balíčku QuaaxTM.

5.3. Návrh aplikace Základem aplikace budou již popsané API PHPTMAPI a Topic Map Engine QuaaxTM. Mapa témat se strukturou navigace bude uložena v MySQL databázi. Ta aplikaci zajistí dostatečnou rychlost při dotazování a procházení mapy témat. Aplikace bude rozdělena do dvou relativně funkčně oddělených částí. 33

5. Aplikace První částí bude jakési administrační rozhraní. V něm se budou zpracovávat XTM soubory, administrátor webu zde bude nahrávat mapy témat ve formátu XTM 1.0 při aktualizacích, nebo jiných změnách obsahu webu a dále provádět další nastavení celé aplikace. Zpracované XTM soubory budou připravené v databázi ve formátu vyhovujícím ISO 13250. Druhá část aplikace bude obstarávat dynamické generování navigace a její zobrazování v HTML souborech. Požadavky na tuto část budou především generovat účelnou navigaci na webu a co nejméně pracné zakomponování této navigace do HTML souborů na výstupu z webového serveru.

MySql ( ISO 13250 )

QuaaxTM + PHPTMAPI Aplikace

navigace

XTM 1.0

HTML

Obrázek 5.1. Schematické znázornění struktury aplikace.

5.4. Administrační rozhraní Jelikož se jedná jen o prvotní implementaci, nebudu v administračním rozhraní prozatím řešit otázky jako autentizace a současná práce více uživatelů. Přihlašování vyřeším jednoduchou autentizací zabudovanou přímo v protokolu HTTP a samotnou funkčnost aplikace prozatím omezím jen na možnost nahrání souboru s mapou témat, jeho následného zpracování a několik dalších užitečných funkcionalit. Náhled na administrační rozhraní je na obrázku 5.2. Základní skript, sloužící pro přihlášení a obsluhu administračního rozhraní klientem, je v souboru tm-cms_admin.php v kořenovém adresáři aplikace. Ostatní soubory potřebné pro tuto část aplikace jsou nahrané v adresáři tm-cms\. Důležitý je zejména soubor tm-cms_config.php, jehož editací je realizováno základní nastavení celé aplikace. V něm je možno změnit výchozí přihlašovací jméno a heslo (admin, admin1234) do administračního rozhraní, změnit přístupové údaje k databázi a provádět další užitečná nastavení. Jeho struktura a způsob použití je popsáno v kapitole Instalace aplikace.

34

5. Aplikace Budoucí aplikaci bych rád prezentoval komunitě lidí okolo Topic Maps, proto jsem již první verzi administračního rozhraní zhotovil ve dvou jazykových verzích. Jednotlivé překlady jsou dostupné v souboru tm-cms\tm-cms_languages.inc. Jeho jednoduchou editací si budou moci uživatelé i bez znalosti programování vytvářet své vlastní jazykové verze. Pro výběr jazyka slouží rozbalovací menu v levém horním rohu aplikace. Aktuálně je dostupná česká a anglická verze administračního rozhraní. Z důvodu co nejpohodlnějšího používání této části aplikace jsem se rozhodl při jejím budování využít dnes velmi populární technologii AJAX. Ta je založena na skriptovacím jazyku JavaScript, který běží na straně klienta. Odpadají tedy hardwarové i softwarové nároky na straně serveru a JavaScript je dostupný prakticky ve všech současných prohlížečích. Ve spojení s objektem XMLHttpRequest pro odesílání požadavků a přijímání odpovědí je AJAX schopen komunikovat se skripty na straně serveru. Tento objekt je dnes rovněž implementován skoro ve všech moderních prohlížečích. Pomocí modelu stránky W3C DOM, kterým je stránka reprezentována v prohlížeči, je JavaScriptu umožněno obsah stránky dynamicky měnit. V mé aplikaci umožní technologie AJAX pracovat v administračním rozhraní bez neustálého načítání stránky, bude uživatele průběžně informovat o průběhu jednotlivých zpracování a hlídat některé zásadní události. Jednotlivé soubory s mapami témat musí být nahrané ve složce ke zpracování tm-cms\xtm. Pro jejich nahrání je možno využít jakéhokoliv správce souborů, případně formulář v levém horním rohu aplikace. Před použitím formuláře je nejprve potřeba nastavit složce tm-cms\xtm příslušná práva pro zápis. Pokud práva nejsou správně nastavena, místo zmíněného formuláře se zobrazí pouze varování o nemožnosti nahrávání souborů přes prohlížeč. Dalším omezením při nahrávání souborů přes prohlížeč je maximální velikost nahrávaných souborů a maximální velikost odesílaných formulářů metodou POST (upload_max_filesize a post_max_size v nastavení PHP). Informace o nižší z uvedených hodnot je uvedena nad formulářovým oknem pro výběr souboru. Jelikož JavaScript nemá z bezpečnostních důvodů právo manipulovat se soubory, je formulář se souborem odesílán do vnořeného rámce (iframe). Tím je umožněno nahrání souboru bez nutnosti obnovení stránky. V průběhu nahrávání, které je závislé hlavně na rychlosti uživatelova připojení, je zobrazen obrázek simulující načítání a po skončení je uživatel informován o výsledku akce. Pokud adresář tm-cms\xtm existuje a je čitelný, je jeho obsah viditelný v levé části aplikace pod formulářem pro nahrávání souboru. Skript pro zobrazení jeho obsahu je JavaScriptem automaticky opakovaně volán, takže zobrazený obsah adresáře je stále aktuální. Uživatel tak například může nahrávat a mazat soubory pohodlněji svým správcem souborů a v aplikaci vidí stále aktuálně dostupný obsah složky bez nutnosti obnovovat stránku. U souborů jsou k dispozici tlačítka pro smazání a zpracování. Po stisknutí tlačítka pro smazání je soubor odstraněn (pokud jsou vhodně nastavena práva). Tlačítko zpracovat startuje zpracování souboru. To se zobrazí v dialogovém okně napravo. Jeho průběh je popsán v následující samostatné kapitole. Pod dialogovým oknem pro zpracování souborů s mapami témat je k dispozici rozbalovací menu pro odstranění mapy témat z Topic Map Engine. Jelikož toto odstranění může trvat v závislosti na počtu objektů v mapě témat poměrně dlouho, je po jeho spuštění celá aplikace uzamčena. K uzamčení aplikace dojde i při startu zpracování souboru s mapou témat. V uzamčené aplikaci není možno spouštět žádné nové akce a před opuštěním stránky je zobrazen varovný dialog s možností setrvání na stránce dokud aktuálně prováděná akce neskončí. Tímto způsobem nedojde ke spuštění nové akce, nebo přerušení akce aktuálně prováděné a porušení

35

5. Aplikace konzistence v Topic Map Engine. Po dokončení zpracování je aplikace opět odemčena a připravena pro další práci. Poslední viditelnou funkční součástí aplikace je statistika. Ta se nachází v pravém dolním rohu a zobrazuje údaje o počtu map témat, témat, vztahů a výskytů uložených v Topic Map Engine. Je obnovena vždy po novém zpracování souboru, nebo po odstranění mapy témat z Topic Map Engine. Od původního záměru automatické aktualizace jako u zobrazení obsahu adresáře pro zpracování jsem upustil. Sice byly velmi efektně vidět změny v Topic Map Engine během zpracování, ale doba zpracování se díky dalším souběžně spouštěným dotazům na Topic Map Engine a následně i na databázi rapidně zhoršila.

Obrázek 5.2. Administrační rozhraní při zpracování XTM souboru.

5.4.1. Zpracování XTM souboru Po zvolení souboru ke zpracování v administračním rozhraní je tento soubor nejprve otestován oproti svému DTD (musí být k souboru standardně přiřazeno), definice typu dokumentu pro XTM 1.0 je dostupná na adrese http://www.topicmaps.org/xtm/1.0/xtm1.dtd. Jestliže zpracovávaný soubor není XML souborem, nebo není validní vůči svému DTD, zpracování je ukončeno a oznámení zobrazeno na výstupu ve formě seznamu chyb ve zpracovávaném dokumentu. V opačném případě je sice soubor schválen oproti svému DTD, chyby v podobě překlepů ale odhalit nelze. Proto je vždy lepší projít nově přidané stránky a zkontrolovat výsledek. Pro zpracování souboru použiji XML API DOM, které je součástí PHP od verze 5. Důvodem výběru DOM je poměrně složité DTD a vazby v XTM dokumentech, rozhraní DOM umožní pohodlné načtení a manipulaci s dokumentem jako celkem. Po načtení jsou z dokumentu vybrány

36

5. Aplikace jednotlivé uzly s mapami témat. Ponechávám možnost zpracovat a uložit do Topic Map Engine více map témat. V případě provozování několika nesouvisejících webů na jednom www serveru by tedy šla využít jedna instalace aplikace, případně sdílet jednu databázi pro několik virtuálních serverů. Pravidla zpracování XTM souborů jsou popsána v [20] jako požadavky na rozeznání stejných a ekvivalentních zápisů jednotlivých konstrukcí mapy témat, zpracování variantních názvů, automatického spojování a odstranění duplicit. Některé z pravidel jsou přímo součástí fungování TMAPI a QuaaxTM. Prvním požadavkem na rozeznání stejných zápisů je porovnávání textových řetězců ve formátování Unicode (ISO 10646). Plná podpora Unicode bude implementována až v PHP 6. V databázi je použit systém kódování Unicode UTF-8, ten je současně defaultním pro rozhraní DOM v PHP. V ostatních částech aplikace by měly být textové řetězce překódovány z výchozího kódování PHP (závislé na nastavení v php.ini) na UTF-8. Dalším požadavkem je porovnávání URL podle RFC dokumentů jednotlivých schémat. V pravidlech rovnosti jsou také definovány případy, ve kterých lze název tématu, okruh platnosti, vztahy a výskyty označit za shodné. Některé konstrukce je možno ve formátu XTM vyjádřit různými ekvivalentními zápisy, ty by měla aplikace vyhodnotit jako shodné. Jedná se o ekvivalentní zápis odkazu na konkrétní téma přes elementy subjectIndicatorRef a topicRef, dále o možnost vyjádření hierarchie instanceOf jako vztahu a ekvivalence více členů se stejnou rolí ve vztahu. Variantní názvy můžeme považovat za shodné, pokud obsahují stejnou množinu parametrů. Výsledná mapa témat by rovněž měla být konzistentní, to znamená bez důvodů ke slučování témat. Příkaz pro explicitní sloučení map témat MergeIn zatím bohužel není v používaném Topic Map Engine k dispozici, proto ho budu při zpracování vynechávat. Do poslední skupiny požadavků na vyhovující zpracování mapy témat patří odstranění duplicitních indikátorů témat, duplicitních názvů témat, duplicitních asociací a duplicitních hráčů stejných rolí v nich. Na každou mapu témat aplikuji rekurzivní funkci. Ta spočívá v opakovaném vnořeném volání stejné funkce na jednotlivé uzly uvnitř mapy témat. Funkce vyhodnocuje názvy a obsah jednotlivých elementů a následně odesílá příkazy do Topic Map Engine. Jednotlivé části mapy témat je potřeba zpracovávat postupně v závislosti na jejich hierarchii a dalších vztazích mezi nimi. To zajistí, že skript nebude zpracovávat elementy obsahující odkazy na elementy dosud nezpracované. Při prvních průchodech dokumentem jsou zpracována jednotlivá témata. Pokud konkrétní téma neobsahuje odkazy na dosud nezpracovaná témata, odešle se příkaz do Topic Map Engine k založení tématu s danou charakteristikou. Po zpracování témat je spuštěno podobné zpracování jednotlivých vztahů. Pokud jednotlivé příkazy pro Topic Map Engine vyhovují podmínkám z předcházejícího odstavce, jsou v pořádku provedeny a jednotlivé elementy z mapy témat uloženy do databáze. V opačném případě skončí provedení příkazu výjimkou, aktuální průběh zpracování se přeruší a spustí se zpracování výjimky. Informace o výjimce je zobrazena na výstupu a zpracovávaný soubor je potřeba před dalším zpracováním opravit. Protože slučování map témat zatím není podporováno používaným Topic Map Engine, jednotlivé direktivy MergeIn a části témat obsahující odkazy na témata v externích mapách budou přeskočeny. Výsledkem zpracování mapy témat je její uložení v databázi ve formátu vyhovujícím ISO 13250. Po dokončení zpracování celého souboru jsou v administračním rozhraní zobrazeny výsledky, případně údaje o přeskočených elementech. Cílem této části aplikace není zpracovávat jakékoliv mapy témat. Samozřejmě je to možné, ale pro korektní fungování dalších součástí aplikace by mapy měly svou strukturou vyhovovat navržené ontologii navigace a obsahovat její klíčové konstrukce včetně zachování jejich názvů a způsobu zápisu. V opačném případě bude uložená mapa v Topic Map Engine nepoužitelná.

37

5. Aplikace Navigace se pravděpodobně nebude generovat, případně nebude obsahovat některé požadované informace. Základním požadavkem je zpracování rozsáhlých souborů pokrývajících obsah celé webové stránky. XTM soubory tedy mohou obsahovat titisíce konstrukcí a přesahovat svou velikostí i několik megabytů. V závislosti na výkonu a vytíženosti webového, případně i databázového serveru, může být potřeba navýšit limit pro zpracování skriptů v nastavení PHP (max_execution_time). Případně tento limit zvýšit pouze skriptu tm-cms\quaaxtm\src\utilities\Mysql.class.php v nastavení webového serveru. Zejména u webhostingových služeb může být nastavení max_execution_time velmi přísné a administrátoři ve snaze o co nejmenší přetěžování serverů nekompromisní. Každý rozumný administrátor je ale ochoten tento limit pro jeden konkrétní skript zvýšit. Z vlastní zkušenosti vím, že tato praxe funguje po slušném požádání na většině českých webhostingů. Pokud dojde k překročení tohoto limitu v průběhu zpracování souboru s mapou témat, je zpracování ukončeno a zobrazeno varování. Při testování jsem dosahoval poměrně dobrých výsledků a mapu témat s konstrukcí základní ontologie a tisíci tématy reprezentujícími jednotlivé dokumenty, jejich obsah a autory zvládala aplikace zpracovat v čase několika málo sekund. Při výchozím nastavení max_execution_time na 30 sekund si aplikace poradila s testovací mapou témat obsahující 10000+ témat. To už ale bylo na hranici třiceti sekund a občas docházelo k vypršení limitu. Doba zpracování je samozřejmě závislá hlavně na výkonu webového serveru. V průběhu zpracování souboru s mapou témat je aplikace uzamčena a zobrazen obrázek načítání, aby uživatel při čekání nenabyl dojmu nečinnosti a nepřerušil neočekávaně aktuální zápis do Topic Map Engine.

5.5. Navigace Kvalitní navigace je jednou z klíčových součástí ovlivňujících použitelnost webových stránek. Měla by čtenáři usnadnit orientaci a pohyb po jednotlivých částech webu a zároveň pro něho být snadno použitelná i pochopitelná. Nikdy sice nemůžeme zaručit její pochopení všemi uživateli, ale dodržením určitých pravidel můžeme rapidně zvýšit její efektivitu. Základním pravidlem je dodržení principů navigace obecně. Primárním cílem kterékoliv navigace je poskytnout uživateli informace o jeho aktuální poloze, stejně tak webová navigace by měla čtenáři sdělovat, v jaké části stránek se právě nachází a o čem daná stránka pojednává. Poté co se čtenář zorientuje, ho pravděpodobně bude zajímat, kam může jít dál. Navigace mu v ideálním případě nabídne odkazy na další související dokumenty, respektive související témata a odhalí mu tak plný potenciál zobrazených webových stránek, zároveň pomůže lépe danou problematiku pochopit poskytnutím doplňujících informací. Aby uživatelé navigaci používali, musí si jí samozřejmě nejprve všimnout. Doporučuje se proto její grafické odlišení od ostatních částí stránky. Toto grafické odlišení by ale nemělo na stránce příliš rušit, zejména pohybující se grafika velmi znepříjemňuje čtení textu. Alternativní technologie jako FLASH nám sice může pomoci vytvořit velmi efektní navigaci, zároveň je ale v rozporu s dalším požadavkem – technickou použitelností. Využitím standardních technologií docílíme fungování navigace i v alternativních prohlížečích a zařízeních. Používáním klasických hypertextových odkazů je posílena přístupnosti jednotlivých stránek vyhledávacím robotům, která je pro většinu webů rovněž velmi důležitá a žádaná. Většina čtenářů je zvyklá na navigaci mnoha jiných internetových stránek, snadněji proto pochopí podobnou navigaci na našem webu. Proto je lepší dát přednost standardnímu typu navigace, než vymýšlet vlastní, kterou se čtenáři budou muset teprve naučit používat a pravděpodobně jí značná část z nich ani nepochopí. Pokud 38

5. Aplikace není navigace jednotná na všech stránkách webu, je to pro čtenáře velmi matoucí a zbytečně zdržující. Neměla by se proto měnit její poloha, design ani funkčnost. Zásadním problémem je otázka, kam navigaci na webových stránkách umístit. Podle různých studií jsou jako nejlepší části pro umístění navigace uváděny levá a horní část stránky, zároveň se jedná o standardní umístění, kde bude většina čtenářů navigaci pravděpodobně hledat. Poslední dobou velmi používaná je takzvaná mapa stránek, jedná se o soustředění odkazů na obsah celého webu na jednom místě. U rozsáhlejších webů je standardem poskytovat i vyhledávání v obsahu. Efektivnost navigace je rovněž doporučeno nadále zlepšovat v průběhu jejího používání. Sofistikovanější skripty na měření návštěvnosti nám prozradí, jak uživatelé navigaci využívají, co pochopili, nebo s čím mají naopak problémy. Pro umístění navigace při prototypové implementaci navigace na příkladu stránek http:// www.kosek.cz/ jsem zvolil levou horní část stránky. Je zde dobře viditelná a jedná se o standardní pozici, ve které jí bude většina uživatelů intuitivně hledat. Pomocí fixního pozicování v CSS nastavím navigačnímu boxu konstantní pozici, aby byl stále po ruce i při rolování stránkou. V horní části navigace se nachází logo, bývá zvykem přes něj odkazovat na titulní stranu webu. Správně navržené logo webových stránek umožní čtenáři jejich zapamatování, navíc se jedná o rychlou možnost návratu na titulní stranu. Pod logem je umístěn odkaz na hlavní stranu prohlíženého dokumentu. Mnoho čtenářů přichází z vyhledávačů prakticky na jakoukoliv vyhledávacími roboty zaindexovanou stránku. Tento odkaz jim pomůže rychle zjistit, o čem dokument pojednává, nebo se dostat na jeho titulní stranu a číst od začátku. Pod odkazem na hlavní dokument jsou v případě vícestránkových dokumentů informace o aktuální straně, možnost pohodlného listování a zobrazení obsahu aktuálního dokumentu. Obsah dokumentu nemusí zobrazovat pouze odkazy na HTML stránky. Mohou v něm být zahrnuty například i odkazy na doplňkové dokumenty ke stažení. Záleží na tom, co vše jsme se rozhodli v mapě témat zachytit. Při odkazování na dokumenty ke stažení ale bývá zvykem do nadpisu odkazu přidat informace o formátu a velikosti souboru, to docílíme přidáním stejných informací do názvu konkrétního tématu.Následují metainformace jako datum poslední změny a autor, případně víc autorů. Problémem většiny zdrojů informací na internetu je jejich aktuálnost. Autor zpravidla vytvoří dokument a dál se o něj nestará, neaktualizuje ho, nekontroluje správnost informací. Čtenář je pak po příchodu na starou stránku často dezinformován již neplatným obsahem. Samotné umístění data vytvoření na viditelné místo nestačí, většina uživatelů není natolik zdatná, aby byly schopni logicky zhodnotit aktuálnost informací. Informace o aktuálnosti dokumentu jsou proto zachyceny jako uložená charakteristika přímo v mapě témat a v případě neaktuálního obsahu se zobrazí viditelné upozornění. Samozřejmě závisí na tvůrci webových stránek, jestli bude ochoten a schopen kontrolovat i starší obsah svého webu a případně ho označovat za neaktuální. Pod informacemi o prohlíženém dokumentu je výpis souvisejících témat. Přímo související témata poskytují i možnost rozbalení seznamu dalšího obsahu, který o nich pojednává. Pokud související téma obsahuje další vnořená témata, je ve výpisu souvisejících dokumentů i odkaz na konkrétní místo s tímto obsahem v mapě stránek. Odkaz na mapu stránek je hned pod výpisem souvisejících témat. Samotná mapa stránek je stránka s odkazy na veškerý obsah webu. V horní části bude naznačená hierarchie témat jako odkazy na jednotlivé fragmenty stránky, kde je souhrn všech relativních odkazů k danému tématu. U rozsáhlejších webů bývá zvykem mapu stránek více logicky uspořádat a mít ji k dispozici předem vygenerovanou jako statickou stránku pro zmenšení zátěže serveru. Pod odkazem na mapu stránek je v navigaci dále k dispozici formulář na vyhledávání, ten slouží k odeslání hledaného výrazu vyhledávacímu skriptu, nebo

39

5. Aplikace aplikaci. Zadání vhodného hledaného výrazu je někdy nejkratší cesta na požadovanou stránku. Standardní zabudování vyhledávacího formuláře do navigace, která je pohodlně přístupná na všech stránkách webu, může tedy být pro čtenáře velké plus. Zbývá ještě ošetřit možnost individuálního nastavení navigačního boxu – při automatickém přidávání na již hotové stránky se může stát, že navigace bude vzhledem k již dříve vytvořené navigaci zbytečná, nebo bude čtenáře jinak obtěžovat. Do spodní části proto umístím dva odkazy na nastavení. První pro vypnutí zobrazování navigace na aktuální stránce, druhý pak pro její zákaz na celém webu. Po kliknutí na nastavovací odkaz dojde k přesměrování na PHP skript tm-cms\tm-cms_setcookie.php, který se pokusí požadovanou předvolbu pomocí cookies a následně přesměruje prohlížeč zpět na původní stránku. Cookies je malý datový soubor, který si skript může uložit v uživatelově počítači. Pokud jeho prohlížeč cookies nepodporuje, skript zobrazí varování. Jestliže si čtenář vypne ze zvědavosti navigaci na celém webu, pravděpodobně jí bude postrádat a rada smažte si cookies asi většině nepomůže. Ještě před vypnutím navigace celkově je tedy informován, že jí může znovu zapnout odkazem z titulní strany webu (ten se zobrazí jen uživatelům s kompletně vypnutou navigací).

Obrázek 5.3. Původní HTML stránka.

40

5. Aplikace

Obrázek 5.4. Část aplikací upravené HTML stránky s přidanou navigací. Navigace sice má být zřetelně graficky odlišena, ale rozhodně by neměla na stránce rušit a kazit tak její design. Navigační box jsem zhotovil celý v neutrálních barvách, aby co nejlépe zapadnul do všech stránek, kam bude nově přidán. Využil jsem pouze standardní technologie: jazyk HTML, kaskádové styly CSS a skriptovací jazyk JavaScript. Prakticky je ale navigace vázána jen na HTML. Bez zbylých dvou technologií se sice nezobrazí ve svém designu (CSS) a s dynamickými efekty (JavaScript), bude však plně použitelná. To zajistí její prostupnost pro vyhledávací roboty a zlepšení pozice stránek ve vyhledávačích, navíc bude použitelná prakticky v jakémkoliv prohlížeči včetně textových. Domnívat se, že toto řešení navigace bude uživatelům mé aplikace postačovat by rozhodně bylo dosti krátkozraké. Každý web má jiné potřeby, jiné nároky na design a technologie. Celá navigace včetně stylů, skriptů a jejího zasazení do existujících HTML souborů, bude proto uložena v takzvané šabloně (template). Použití šablon zajistí oddělení aplikační a zobrazovací logiky, takže i uživatelé s minimálními znalostmi tvorby internetových stránek budou moci šablony podle svých potřeb upravovat, nebo vytvářet vlastní šablony za použití libovolných technologií. Řešení webových stránek pomocí šablon je dnes velmi oblíbené pro svou jednoduchost a vysokou efektivitu. V této aplikaci se bude šablona nechat použít i ke kompletnímu návrhu nového webu, nebo redesignu stávajících stránek, případně k automatickému zprovoznění dalších funkcionalit na všech stránkách webu. Součástí první verze aplikace bude rovněž několik již hotových šablon. Jednotlivé šablony budou uloženy v adresářích tm-cms\templates\nazevsablony. V každém adresáři budou uloženy dva soubory – head.tmpl a body.tmpl. Postup jejich následného zpracování popíši v kapitole o generování navigace.

41

5. Aplikace

Obrázek 5.5. Navigace na alternativním zařízení (PDA).

Obrázek 5.6. Navigace - zobrazení obsahu dokumentu.

5.5.1. Přepsání HTML souborů Klíčovým úkolem této práce je snadné a efektivní začlenění zhotovené navigace do HTML souborů na výstupu z webového serveru. Pokud by se jednalo o méně rozsáhlý web, většinou by asi byla zvolena cesta manuální editace jednotlivých stránek. Při větším počtu statických stránek by se ale jednalo o velmi pracný postup, který by se pravděpodobně navíc musel opakovat při pozdějších požadavcích na další změny webu. Webový server Apache nám naštěstí umožňuje použít nástroj pro přepisování URL – mod_rewrite.

42

5. Aplikace Tento modul je součástí webového serveru Apache již od verze 1.2. Pokud server přijme požadavek ve formě URL, pokusí se najít vhodný soubor a odpovědět. Jestliže chceme tento proces přerušit a přesměrovat požadavek na jiný soubor, nebo na jiné URL, můžeme využít právě mod_rewrite. Oficiální dokumentace tohoto modulu je dostupná v [1]. Asi nejmasověji se mod_rewrite používá při optimalizaci webových stránek pro vyhledávače, vzhledem k možnosti přesměrování i na neexistující soubory, do jejichž názvů se zapíší klíčová slova. V našem případě bude mod_rewrite sloužit pro přesměrování požadavku na PHP skript, který provede přidání navigace, respektive další úpravy a zašle klientovi odpověď v podobě modifikace původního HTML souboru. Pro aktivaci tohoto modulu je nejprve potřeba jeho nahrání při startu webového serveru (zápisem LoadModule rewrite_module modules/mod_rewrite.so do konfiguračního souboru httpd.conf). Samotné direktivy pro přepisování URL se nejčastěji zapisují buď do souboru pro řízení přístupu k jednotlivým adresářům (soubor .htaccess), nebo přímo do konfiguračního souboru serveru (nutný restart Apache při aplikování změn). Struktura souboru .htaccess:

RewriteEngine on RewriteCond %{REQUEST_URI} \.html$ RewriteRule ^(.*)$ /tm-cms/tmcms_modifyoutput.php?url=/$1 Bez tohoto souboru v kořenovém adresáři webu, nebo s vypnutým modulem mod_rewrite nebude aplikace fungovat. Na prvním řádku souboru .htaccess je příkaz k zapnutí přepisování lokátorů URL. Na druhém řádku je podmínka RewriteCond. Ta testuje, zda proměnná serveru %{REQUEST_URI} (požadovaná URI) končí příponou html. Podmínky se při přepisování URL často zapisují pomocí takzvaných regulárních výrazů. Speciálních řetězců znaků, které definují, jak má daný textový řetězec vypadat. Pokud je podmínka splněna, jedná se o požadavek na soubor .html a můžeme začít s vlastním přepisováním. V případě potřeby přepisu dalších typů souborů může direktivě RewriteRule předcházet více podmínek RewriteCond spojených přepínači AND (a) nebo OR (nebo). Poslední direktiva v souboru – RewriteRule definuje samotné přepisovací pravidlo. První část výrazu představuje hledaný vzor, který má být nalezen, aby došlo k přepsání. V našem případě je příkaz k přepsání spouštěn až na základě předchozí podmínky, takže název souboru může být již cokoliv. Eventuelně by touto podmínkou šly ještě vyloučit soubory, které nechceme přepisovat. Místo souboru, uvedeného v původním požadavku, volá server PHP skript /tm-cms/tmcms_modifyoutput.php, cesta k původně požadovanému souboru je připojena za adresu skriptu jako proměnná pro další zpracování.

5.5.2. Generování navigace Po spuštění skript na generování navigace nejprve zkontroluje existenci souboru z proměnné, kterou mu předá systém přepisování URL z předchozí kapitoly. Pokud uvedený soubor neexistuje, vrátí skript jako odpověď stavový kód protokolu HTTP o nenalezené stránce - 404 Not Found a zpracování je ukončeno. Tento případ může nastat zejména po uživatelem špatně zadané adrese, nebo při kliknutí na již neplatný odkaz. Pokud soubor existuje, ověří skript nejprve nastavení navigace v cookies. Jestliže uživatelův prohlížeč poskytne informace z cookies s požadavkem vypnutí navigace na celém webu nebo na příslušné stránce, zpracování rovněž končí a jako odpověď je zaslán původní soubor bez 43

5. Aplikace modifikací. V opačném případě začíná generování navigace. Nejprve je odeslán požadavek do Topic Map Engine s cílem zjistit, zda v databázi existuje mapa témat pro příslušnou doménu. Jmenná adresa serveru, ze kterého je skript volán, je dostupná v takzvané serverové proměnné $_SERVER[SERVER_NAME]. Porovnání nám zajistí, že se navigace nezačne generovat z mapy témat pro jinou doménu. Struktura souborů může totiž být na různých webových stránkách stejná, takže porovnáváním pouze relativních cest k souborům by mohly vznikat chyby na serverech, kde běží více webů. Následuje dotaz do Topic Map Engine na vybrání tématu s lokátorem shodným s adresou souboru z vybrané mapy témat. Pokud některý z předchozích dvou dotazů vrací prázdnou odpověď, jedná se o soubor nezachycený v mapě témat a zpracování končí zasláním původního souboru bez úprav. Po získání tématu s odpovídajícím lokátorem z mapy témat následuje série příkazů, kterými se přes Topic Map Engine zjistí všechny dostupné informace o daném tématu z aktuální mapy témat. Tyto informace se uloží do proměnných a dále poslouží k generování navigace. U zobrazovaných jmen se ještě speciální znaky jazyka HTML převedou na entity funkcí htmlspecialchars. Problém může nastat při použití fragmentů za URL adresou pro rozlišení více kapitol. V tomto případě uvažuje server jako volanou adresu pouze údaj před fragmentem a aplikace nemusí zvolenou kapitolu korektně rozpoznat. Prvním řešením by bylo nepoužívat adresy s fragmenty a v mapě témat zachytit jako téma pouze konkrétní HTML stránku. Za předpokladu souvisejícího obsahu na všech částech stránky bych ale adresy s fragmenty spíše standardně v mapě témat zachycoval, listování i zobrazení obsahu může uživateli pohyb po jedné rozsáhlejší stránce za použití fragmentů velmi zpříjemnit. Jediné stránky, které by se rozhodně neměly do mapy témat zahrnovat, jsou stránky složené z rámců (frames). Možností je zaznamenávat jen stránky tvořící jednotlivý obsahový rámec. Vzhledem k možnosti různého kódování jednotlivých HTML stránek, je před další prací s požadovaným HTML souborem vhodné toto kódování zjistit. Typ kódování bývá zadán v hlavičce HTML dokumentu pomocí atributu charset. Volaná funkce prochází dokumentem, dokud nenarazí na tento atribut. Jestliže není v dokumentu nalezen, jeho tvůrce pravděpodobně kódování nezadal a použije se výchozí kódování, které je nastavitelné v konfiguračním souboru tmcms\tm-cms_config.php. Jelikož velmi často vznikají při zápisu HTML syntaxí různé chyby, nebude na škodu zpracovávaný soubor nejprve opravit. K tomu použiji rozšíření jazyka PHP - TIDY HTML 2.0, které je součástí Zend Engine 2 (PHP verze 5.0 a vyšší). Toto rozšíření nabízí přímo skvělé možnosti pro automatické opravování i další úpravy a převody dokumentů v jazyce HTML. Bez problémů si poradí i s různými WYSIWYG editory a nástroji Microsoft Office, které jsou považovány za editory s nejhorší výslednou syntaxí. Jako vstupní a výstupní kódování pro TIDY HTML nastavím zjištěnou znakovou sadu. Další nastavení pro zpracování a formátování souboru budou dostupná v konfiguračním souboru aplikace. Vítanou funkcí může být zejména automatický převod starších verzí HTML souborů do XHTML. Zejména u starších či velmi nevalidních dokumentů občas dochází při použití TIDY HTML k porušení původního designu, v tomto případě se nechá výsledná chyba lehce opravit zápisem požadované CSS vlastnosti do hlavičkové části šablony. Po automatické opravě syntaxe dokumentu a přepsání zobrazovacích značek na CSS styly přistoupím k aplikaci připravené šablony s navigací na výsledný dokument. Jak jsem již uvedl, šablony jsou vždy uložené ve dvou souborech. Soubor head.tmpl slouží k připojení informací do hlavičky HTML stránky, druhý soubor body.tmpl pak pro aplikaci šablony na obsah těla stránky. Pokud by uživatel smazal obsah šablon, nebo nezapsal jeho název do mapy témat, na dokument nebude aplikována žádná šablona a zůstane na výstupu

44

5. Aplikace beze změn. Zpracovávaný soubor je nejprve rozdělen a prvním souborem jsou do jeho hlavičky zasazeny informace o stylech a skriptech, které jsou potřebné k fungování obsahu šablony z druhého souboru. Tím je umožněn validní zápis výsledného souboru, neboť tyto zápisy patří pouze do jeho hlavičky. Následuje načtení obsahu těla stránky a jeho uložení do proměnné. Jelikož jsou šablony spouštěny PHP funkcí include, jsou v nich přístupné všechny dříve definované proměnné a mohu v nich použít různé konstrukce jazyka PHP. V každé šabloně by měl být na úvodních řádcích popisek s metainformacemi (autor, verze …) a soupisem jednotlivých použitelných PHP proměnných. Názvy témat z Topic Map Engine jsou ještě před zpřístupněním šabloně překódovány do použitého formátování, aby nedocházelo k nesrovnalostem v diakritice. Samotný obsah těla původního souboru je umístěn na zvolené místo v šabloně a stránka je kompletní. Posledním úkolem aplikace je zaslání vyčištěné a novými šablonami zformátované stránky do uživatelova prohlížeče.

Obrázek 5.7. Navigace - dokument bez souvisejícího obsahu, zobrazeno upozornění o zastaralosti dokumentu.

45

5. Aplikace

Obrázek 5.8. Navigace - související dokumenty, ve spodní části jsou odkazy na vnořená témata do mapy stránek.

5.6. Systémové požadavky 5.6.1. Software Programové požadavky na provoz aplikace vyplývají z použitých technologií. PHP je zapotřebí ve verzi minimálně 5.0, vzhledem k využití Tidy HTML 2.0 a objektově orientovanému přístupu v Topic Map Engine i dalších částech aplikace. Databázový server MySQL s podporou tabulek ve formátu InnoDB, ta je v MySQL plně implementována od verze 3.23.44. Webový server Apache postačí od verze 1.3. Uvedené programy fungují prakticky na všech současných operačních systémech, způsob zprovoznění přepisování lokátorů URL www serverem může být na neunixových systémech odlišný.

5.6.2. Hardware Ačkoliv se na oficiálních stránkách jednotlivých součástí LAMP architektury můžeme dočíst o velmi nízkých systémových nárocích, minimální hardwarové požadavky nejsou uvedeny ani v jejich dokumentacích. Je to způsobeno opravdu nízkými požadavky na provoz, závislými především na způsobu jejich využití. [2] Například webový server Apache lze bez problémů rozběhnout na unixovém systému s 12 MB prostoru na pevném disku a 8 MB operační paměti. Pro provoz webového serveru, odpovídajícího na požadavky klientů a generujícího dynamický obsah budeme ale pravděpodobně potřebovat o něco silnější stroj. Pro bezproblémový provoz MySQL je zapotřebí minimálně několik desítek MB operační paměti a místo na disku podle velikosti uložených databází. Podle [13] je postačující konfigurace na provoz linuxového webového serveru Pentium II 400 s 128 MB operační paměti a odpovídajícím diskovým prostorem.

46

5. Aplikace Aplikace by tedy měla fungovat i na většině stolních počítačů současnosti, její výkon a provozuschopnost bude záviset především na velikosti celého webu a vytíženosti webového serveru. Možným postupem před jejím spuštěním na konkrétním serveru by bylo změření využití paměti jednotlivých procesů Apache pomocí speciálních monitorovacích programů (ps, top). Vynásobením výsledku předpokládaným počtem dotazů ve špičce by mělo odpovídat paměťovým požadavkům na provoz webového serveru. Obdobný postup by se musel aplikovat na jednotlivé CGI procesy a výsledek vynásobit počtem CGI požadavků, které chceme být schopni současně obsloužit.

5.7. Instalace aplikace Postup nasazení aplikace do provozu se skládá z několika poměrně jednoduchých úkonů. Nepočítám-li tvorbu samotné mapy témat a vlastní šablony, měl by ho středně zkušený webmaster zvládnout za několik desítek minut. Celý postup je rovněž anglicky popsán v souboru install.txt, který je v kořenovém adresáři distribuce aplikace. Nápomocná může být i vzorová mapa témat a malý web v adresáři example_web. Prvním a u rozsáhlejších webů nejpracnějším krokem je samotné vytvoření mapy témat podle pravidel popsaných ve čtvrté kapitole. Dále si podle potřeb webmaster udělá svou vlastní šablonu, nebo modifikuje nějakou existující. Následujícím krokem je vytvoření databáze přiloženým souborem quaaxtm_db_build.sql. Údaje pro přístup k vytvořené databázi je potřeba zapsat do konfiguračního souboru tm-cms\tmcms_config.php. V něm je dále možnost editace přihlašovacích údajů do administračního rozhraní aplikace, jejího výchozího jazyka, výchozího kódování HTML stránek na webu a případně i požadovanou transformaci pomocí HTML TIDY. Do kořenového adresáře webu následně zkopírovat soubor tm-cms_admin.php, .htaccess a složku tm-cms. Pokud chceme nahrávat soubory do administračního rozhraní přes webový prohlížeč, je nutné nejprve změnit přístupová práva ke složce tm-cms\xtm (chmod 777). Posledním krokem je přihlášení do administračního rozhraní tm-cms_admin.php, zpracování vytvořené mapy témat a zkontrolování výsledku v podobě modifikovaných HTML souborů na výstupu z webového serveru. V případě neúspěšné implementace je možno ihned obnovit původní stav smazáním nahraného souboru .htaccess.

47

Kapitola 6 Závěr Pokud bych měl na základě mého prostudování dostupných dokumentů zhodnotit stav aktuálního vývoje okolo Topic Maps, musím bohužel konstatovat značné zpoždění většiny standardů i technologií oproti optimistickým předpokladům jejich dokončení. Například jazyky pro dotazování TMQL (Topic Map Query Language) a popis omezení TMCL (Topic Map Constraint Language) jsou stále ve fázi rozpracovaných konceptů. Hotové nejsou zatím ani jednotné sady indikátorů PSI pro různá odvětví, které by jistě velmi usnadnily kompatibilitu vznikajících aplikací. Vývoj technologií i standardů pro podporu Topic Maps však nadále pokračuje, sice ne tak rychle jak se v nedávné minulosti předpokládalo, ale vývojáři se v blízké budoucnosti jistě dočkají mnoha již ohlášených novinek. Situace spojení Topic Maps a PHP se po dobu psaní mé práce nijak zásadně nezměnila. Johannes Schmidt dále pracuje na svém prvním Topic Maps Engine pro PHP a v příštích měsících pravděpodobně vydá jeho další vývojovou verzi. Ačkoliv zatím bez viditelných výsledků, zajímavá je i snaha projektu TM4PHP vyvinout Topic Map Engine pro PHP pracující přímo s XTM soubory. Prvním krokem tohoto projektu má být údajně přepracování PHPTMAPI do verze pro PHP 4, což se mi vzhledem k nedávno ukončené podpoře této verze PHP jeví jako ne zcela potřebné. Kromě dvou v této práci použitých projektů od J. Schmidta jsem doposud žádné aplikace pracující na spojení PHP a Topic Maps nezaznamenal. Proto za hlavní přínos své bakalářské práce považuji vytvoření jedné z prvních aplikací, která využívá spojení Topic Maps a architektury LAMP. Věřím, že právě aplikace postavené na tomto dnes nejpopulárnějším řešení webového serveru mohou napomoci širšímu využití map témat na webu. Použití licence GNU GPL navíc zajistí v budoucnu všem tvůrcům podobných aplikací možnost inspirace. Výsledek své práce považuji za úspěšný. Podařilo se mi jako jednomu z prvních implementovat funkční řešení využívající Topic Maps a PHP a to bez větších problémů. Nicméně musím souhlasit s tvrzením mnoha vývojářů v programovacím jazyku Java, i v PHP je používání standardu TMAPI občas přinejmenším velmi nepohodlné. Jelikož se jedná o první prototypovou implementaci, aplikace zcela jistě není v mnoha ohledech ideální. I nadále na ní však budu pracovat a postupně ji vylepšovat. Jakkoliv se zdá princip fungování map témat jednoduchý, je stejně jako v jiných oborech zásadním problémem tvorba vyhovující ontologie. V průběhu tvorby aplikace jsem použitou ontologii několikrát přepracoval, její další potřeby ukážou pravděpodobně již první zkušební implementace na konkrétních webových stránkách. Využití šablon a možností webového serveru Apache dává mé aplikaci daleko širší možnosti než jen generování webové navigace. V úvahu připadá kompletní změna designu starších webových stránek, jejich optimalizace pro vyhledávače či jiné automatické transformace dříve vytvořených statických

48

6. Závěr souborů. Pracnost přetváření staršího rozsáhlého webu je při využití mé aplikace nesrovnatelně menší, než by tomu bylo u manuální editace starého obsahu. Současní redaktoři webových stránek jsou většinou zvyklí na používání redakčních systémů. Jejich práce spočívá převážně v psaní do WYSIWYG editorů, díky tomu většina z nich neví prakticky nic o jazyce HTML a mou aplikaci by pravděpodobně považovali za zbytečnou ztrátu času. Ocenit jí naopak mohou ti, kteří si tvoří své webové stránky stále postaru jako HTML soubory. Současnou internetovou praxí je vydávat články přesahující několik obrazovek. V takovém textu se špatně orientuje a čtenář má často problém s jeho vstřebáním. Nespornou výhodou oproti většině redakčních systémů je proto i možnost přehledného rozčlenění textu do více kapitol. V blízké budoucnosti nepředpokládám masovějšího nasazení mé aplikace ani jiných podobných na weby jednotlivců. Skutečný přínos z postavení svých webových portálů na mapách témat mohou ale již nyní znatelně pociťovat větší firmy. Pokud například zadají své dodavatelské firmě požadavek na zhotovení webových stránek založených na technologii Topic Maps, nebudou v budoucnu vázáni na konkrétní technologii ani firmu. Prakticky kdokoliv bude moci po nastudování tohoto mezinárodního standardu začít na takto zhotovených stránkách pracovat. Status jediného mezinárodního standardu pro sdílení znalostí ISO navíc zaručuje mapám témat velmi stabilní zázemí. Budoucnost spojení Topic Maps a internetu však podle mého názoru nespočívá jen v řešení organizace informací na konkrétních webových stránkách. Vznikají daleko zajímavější projekty v podobě webových portálů založených výlučně na mapách témat. Ty nejenže budou uživateli podávat informace zcela revolučním způsobem, ale rovněž budou schopny mezi sebou komunikovat a informace účelně sdílet. V této práci popisovaná aplikace je dostupná včetně funkčních ukázek na adrese: http://topic-maps-cms.poslouchej.com

49

Literatura [1] Apache HTTP Server Documentation. Dostupný z WWW: http://httpd.apache.org/docs [2] Kabir, M., J.: Apache Server 2 Komplektní příručka administrátora. Brno: Computer Press, 2004. [3] Kal, A. - Lischke, S.: Guide to TMAPI, A. Dostupný z WWW: http://www.tmapi.org/guide/ [4] Kosek, J.: HTML tvorba dokonalých WWW stránek. Praha: Grada Publishing, 1998. [5] JTC1 / SC34: ISO/IEC 13250:2005 Topic Maps. International Standardization Organization (ISO), 2005. [6] Učebnice GNU/Linuxu. 2006. Dostupný z WWW: http://www.abclinuxu.cz/ucebnice [7] Svátek, V.: Ontologie a WWW. 2002. Dostupný z WWW: http://nb.vse.cz/~svatek/ontowww.pdf [8] Šimek, P.: Ontologie a www. Diplomová práce. Praha: VŠE, 1999. [9] Noy, N. F. - McGuinness, D. L. : Ontology Development 101: A Guide to Creating Your First Ontology. Stanford: Stanford University, 2001. Dostupný z WWW: http://protege.stanford.edu/publications/ontology_development/ontology101.pdf [10] Welling, L. - Thomson, L.: PHP and MySQL Web Development. Sams Publishing, 2001. [11] Kosek, J.: PHP - tvorba interaktivních internetových aplikací. Praha: Grada Publishing, 1998. [12] Schlossnagle, G.: Pokročilé programování v PHP 5. Zoner Press, 2004. [13] Požadavky na hardware (Tutoriály na Rootu). Dostupný z WWW: http://tutorialy.root.cz/ vyber-distribuce/pozadavky-na-hardware/ [14] Hemelík, M.: Prodromus philosophiae, aneb, Uvedení do filosofie. Praha: VŠE, 1999. [15] Lhotka, L.: Server v Internetu. České Budějovice: KOPP, 1996. [16] Pepper, S.: The TAO of Topic Maps. Ontopia AS, 2000. Dostupný z WWW: http:// www.ontopia.net/topicmaps/materials/tao.html [17] Rath, H.: The Topic Maps Handbook. empolis GMBH,2003. [18] Kosek, J.: Topic Maps. Praha: VŠE, 2006. Dostupný z WWW: http://www.kosek.cz/xml/ 2006znalosti/ [19] Kosek, J.: XML pro každého podrobný průvodce. Praha: Grada Publishing, 2000. [20] Pepper, S. - Moore, G.: XML Topic Maps (XTM) 1.0. TopicMaps.Org Authoring Group, 2001. Dostupný z WWW: http://www.topicmaps.org/xtm/

50

Využití Topic Maps pro zlepšení navigace na webu

Recommend Documents

Nadpis první úrovně