Univerzita Karlova v Praze

Matematicko-fyzikální fakulta

DIPLOMOVÁ PRÁCE

Bc. Filip Pekárek

Extrakce fakt· z Webu

Katedra softwarového inºenýrství

Vedoucí diplomové práce: RNDr. Leo Galambo², Ph.D.

Studijní program: Informatika, Softwarové systémy, Systémové architektury

2010
Na tomto míst¥ bych cht¥l pod¥kovat svému vedoucímu diplomové práce panu RNDr. Leo

Galambo²ovi, Ph.D. za podn¥tné p°ipomínky a vedení.

Prohla²uji, ºe jsem svou diplomovou práci napsal samostatn¥ a výhradn¥ s pouºitím

citovaných pramen·. Souhlasím se zap·j£ováním práce.

V Praze dne 1.8.2010 Filip Pekárek

2
Obsah

1 Úvod 6
1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Související práce 7

3 Pouºité technologie 8
3.1 Parser stránek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Roz²í°ení do Mozilla Firefox . . . . . . . . . . . . . . . . . . . . . . 8

3.1.2 ƒisté Java °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.3 SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 DOM struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Gecko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.2 XULRunner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.3 XPCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.4 JavaXPCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Vizuální atributy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1 Výb¥r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.2 CSS a implementace . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 Neuronové sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4.1 SOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.2 LVQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.3 Weka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5 Ostatní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Návrh °e²ení 18
4.1 Vizuální blok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 Denice dle VIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Úprava blok· dle lokálního kontextu . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Pozorování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Návrhy algoritm· . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.3 Implementovaný algoritmus . . . . . . . . . . . . . . . . . . . . . . 25

4.2.4 Kontrola kontextu . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Klasikace získaných dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 Testované kategorie . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.2 Denice atribut· . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.3 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Problémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3
5 VIPS 34
5.1 Extrakce vizuálního bloku . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Vizuální separátory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.1 Detekce separátor· . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.2 Nastavení vah separátor· . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Konstrukce vizuálního stromu . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Výsledky 43
6.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Klasikace stránek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Záv¥r 47
7.1 Spln¥ní cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2 Dal²í práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 P°ílohy 49
8.1 Ukázky kongurací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.2 Tabulky výsledk· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.3 P°iloºený digitální materiál . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9 Literatura 55

4
Název práce: Extrakce fakt· z Webu
Autor: Filip Pekárek
Katedra (ústav): Katedra softwarového inºenýrství
Vedoucí diplomové práce: RNDr. Leo Galambo², Ph.D.
e-mail vedoucího: Leo.Galambos@m.cuni.cz

Abstrakt: V p°edloºené práci navrhujeme a testujeme nový postup extrakce fakt· z webu.
P°edloºená metoda bere v úvahu, v£etn¥ DOM stromu webové stránky, také její vizuální

podobu. Základem a první £ástí je extrakce sémantických £ástí stránky pomocí algoritmu

VIPS. Dal²ím krokem je ov¥°ení a p°ípadná úprava získaných dat na základ¥ lokálního

kontextu. Finální £ástí je pomocí získaných a p°ípadn¥ upravených fakt· klasikovat ana-

lyzované webové stránky do p°edem denovaných kategorií. Ur£ování t°íd probíhá pro-

st°ednictvím mnoºiny posuzovatel· implementovaných v konguraci denovatelnými in-

stancemi neuronových sítí.

Klí£ová slova: web, extrakce, fakta, vizuální, DOM, VIPS

Title: Web Information Extraction

Author: Filip Pekárek
Department: Department of Software Engineering
Supervisor: RNDr. Leo Galambo², Ph.D.
Supervisor's e-mail address: Leo.Galambos@m.cuni.cz

Abstract: In the present work we suggest and test new process of web information ex-

traction. Proposed method consider DOM tree of the web page including it's visual cues.

Basic and the rst part is semantic parts extraction of a page using VIPS algorithm.

Next step is validation and eventual modication of gained information based on the lo-

cal context. Final part is classication of analyzing page into predened classes using got

facts. Set of critics implemented by congurable instances of neural networks determine

the classes.

Keywords: web, extraction, facts, visual, DOM, VIPS

5
1 Úvod

1.1 Motivace
Sou£asný Internet obsahuje nep°eberné, denn¥ rostoucí mnoºství stránek. Podle svých

obsah· se dají °adit do mnoha r·zných kategorií, které se navzájem více £i mén¥ p°e-

krývají. Pat°í sem nap°íklad informativní weby, internetové obchody, servery s r·znými

druhy inzerce, diskuzní fóra, portály poskytující r·zné sluºby a mnoho dal²ích. Jednou

z hojn¥ pouºívaných sluºeb Internetu je vyhledávání. Kaºdému se jiº ur£it¥ stalo, ºe

po zadání klí£ových slov do vyhledáva£e musel proklikat n¥kolik nalezených odkaz· nebo

zm¥nit zadaná slova a hledání opakovat, neº na²el skute£n¥ to, co hledal. Je to zp·sobeno

práv¥ zmi¬ovaným obrovským mnoºstvím stránek, které internetoví roboti prohledávají,

analyzují a indexují ve svých databázích.

Vezm¥me si nap°íklad klí£ová slova ko²atý strom. Pokud tato slova zadá programá-

tor nebo zahrádká°, budou s velkou pravd¥podobností kaºdý z nich hledat zcela odli²né

informace. Oba v²ak dostanou stejné výsledky a pokud nebudou mít zrovna ²t¥stí, nebo

nezp°esní své dotazy, stráví n¥kolik chvil hledáním toho pro n¥ správného odkazu. Moºnost

ur£it si své role, nebo lépe °e£eno oblast svého zájmu p°ed vlastním hledáním by zp·so-

bilo zp°esn¥ní výsledk·. Tím pádem se uºivateli zkrátí vlastní doba hledání správného

výsledku. Aby takový mechanismus mohl fungovat, pot°eboval by ke své práci existenci

ur£itého indexu p°es kategorie stránek, ve kterých se vyhledává.

1.2 Cíle
Cílem této práce je pokusit se navrhnout, naimplementovat a otestovat zp·sob, který by

co moºná nejvíce automaticky, bez pot°eby zásahu uºivatele, za°adil konkrétní webovou

stránku do kategorie. Hledaný algoritmus by m¥l krom¥ prosté DOM struktury vyuºívat

také prezenta£ní podobu dokumentu a m¥l by pracovat v n¥kolika krocích. T¥mi jsou

získání a zpracování DOM struktury analyzované stránky, validace získaných dat v rámci

místního kontextu, p°edloºení získaných informací sad¥ tématicky r·zných extraktor· a

následné za°azení stránky do jedné z rozpoznávaných kategorií.

Implementace by m¥la být v jazyce Java zaji²´ující nezávislost na platform¥ a snadné

p°ípadné následné vyuºití programu jinými aplikacemi.

6
2 Související práce

V¥t²ina systém· na získávání informací z Webu povaºuje internetové stránky za nejmen²í

a dále ned¥litelnou jednotku, která ale ne vºdy, reprezentuje jeden sémantický celek.

V¥t²inou obsahuje r·zné £ásti, které se nevztahují k hlavnímu tématu stránky. Nap°íklad

nabídka, dekorativní prvky nebo reklamní panely. Webové stránky £asto obsahují více

témat, které spolu nesouvisí.

Struktury zaloºené na sémantickém obsahu stránek vyuºívá mnoho aplikací. Nap°íklad

p°ístupy pouºívající databázové techniky, které vyuºívají rozd¥lení webových dokument·

na r·zné informa£ní £ásti. [1] B¥hem posledních let se mnoho pozornosti soust°edilo také

na analýzu odkaz·. Jejím základním p°edpokladem je, ºe pokud je odkaz mezi dv¥ma

stránkami, existuje mezi celými stránkami n¥jaký vztah. Ve v¥t²in¥ p°ípad· v²ak odkaz

ze stránky A do stránky B indikuje, ºe pouze m·ºe existovat n¥jaká závislost mezi ur£itou

£ástí stránky A a ur£itou £ástí stránky B.

Nicmén¥ samotný DOM strom stránky není posta£ující k sémantickému d¥lení stránky.

Díky své exibilit¥ mnoho stránek nespl¬uje W3C specikace, coº m·ºe zp·sobit chyby

v DOM strom¥. Nap°íklad to, ºe dva prvky DOM stromu mají spole£ného p°edch·dce

nemusí znamenat, ºe k sob¥ mají sémanticky blíº, neº k jiným prvk·m stromu. [4]

Existuje n¥kolik p°ístup·, jak získat obsahovou strukturu stránky. Mnoho prací bere

v úvahu parametry HTML tag·. Mezi ty d·leºité pat°í nap°íklad <P> (odstavec), <UL>

(list) nebo <TABLE> (tabulka). [23] Jiné algoritmy zaloºené na odkazech uvnit° stánek

pouºívají heuristiku pro rozpoznání jednotlivých záznam· uvnit° stránek. [17] Dal²ím

p°ístupem je FOM (Function-based Object Model), kde kaºdý dál ned¥litelný element

v DOM stromu je nazýván objektem a m·ºe být sou£ástí sloºených objekt·. Funk£ní typ

lze denovat ke kaºdému objektu a slouºí ke generování hierarchické struktury dokumentu.

[10]

Lidské vnímání internetových stránek je £asto jako sloºení n¥kolika r·zných séman-

tických objekt· a ne jako jednoho celku. N¥které výzkumy ukázaly, ºe uºivatelé £asto

o£ekávají ur£ité £ásti stránek dle své funk£nosti (nap°íklad nabídka, reklamní plocha)

na specických místech. [13] Prostorové a vizuální podn¥ty pomáhají uºivateli podv¥-

dom¥ rozd¥lit stránky do n¥kolika sémantických £ástí.

V²echny vý²e zmín¥né metody neberou v úvahu vizuální strukturu. Proto je v této

práci pouºit a naimplementován algoritmus VIPS (Vision-based Page Segmentation),

který práv¥ prostorové a vizuální aspekty dokumentu vyuºívá. Podrobn¥ji je algoritmus

popsán v samostatné kapitole 5 na stran¥ 34. Dále je v této práci pouºita my²lenka lokál-

ního kontextu jednotlivých £ástí stránek. Kone£nou fází je klasikace webových stránek

pomocí neuronových sítí. V²echny £ásti výsledného programu jsou popsány odd¥len¥. Po-

slední dv¥ kapitoly práce se zabývají dosaºenými výsledky a celkovým zhodnocením.

7
3 Pouºité technologie

V této kapitole jsou uvedeny existující nástroje, metody a struktury vyuºívané programem

DataExtraxtor.

3.1 Parser stránek

St¥ºejním úkolem první £ásti celého procesu analyzování a klasikace konkrétní webové

stránky je poºadovanou stránku zobrazit a získat její d·leºité vlastnosti. Bylo tedy pot°eba

najít a vybrat technologii, nástroj, který by tento úkol plnil v dostate£né mí°e a poskytoval

pot°ebné rozhraní. V úvahu bylo také pot°eba brát poºadavek, ºe implementace celého

výsledného programu m¥la být v jazyce Java.

3.1.1 Roz²í°ení do Mozilla Firefox

Prvním pokusem bylo vydat se sm¥rem napsání celé aplikace ve form¥ pluginu do Fire-

foxu. Po prozkoumání moºností se ukázalo, ºe Firefox poskytuje dobré a ²iroké rozhraní,

které odpovídá na²im poºadavk·m a pot°ebám. Men²í p°ekáºkou byla p·vodní neznalost

technologií XUL [21], která se pro programování dopl¬k· do Firefoxu pouºívá.

XUL (XML User Interface Language) je XML jazyk od Mozilly pro vývoj funk£n¥

bohatých na platform¥ nezávislých aplikací. Technologie mimo jiné poskytuje snadnou

jazykovou lokalizaci program· a celkov¥ je velmi podobná dynamickému HTML.

<? xml version=" 1 . 0 " ?>

<? xml− s t y l e s h e e t h r e f =" c h r o m e : / / b r o w s e r / c o n t e n t / b r o w s e r . c s s "

t y p e=" t e x t / c s s " ?>

<! DOCTYPE w i n d o w [
<!ENTITY % d t d 1 SYSTEM

" c h r o m e : / / d a t a E x t r a c t o r / l o c a l e / d a t a E x t r a c t o r . d t d ">

%d t d 1 ;

]>

<? x u l − o v e r l a y

h r e f =" c h r o m e : / / d a t a E x t r a c t o r / c o n t e n t /

d a t a E x t r a c t o r O v e r l a y . x u l " ?>

<w i n d o w

x m l n s=" h t t p : / /www . m o z i l l a . o r g / k e y m a s t e r /

gatekeeper / there . i s . only . xul "

x m l n s : h t m l=" h t t p : / /www . w3 . o r g / 1 9 9 9 / x h t m l "

i d=" d a t a E x t r a c t o r W i n d o w "

w i d t h=" 6 4 0 "

h e i g h t=" 4 8 0 "

p e r s i s t =" s c r e e n X screenY width height sizemode "

t i t l e ="& d a t a E x t r a c t o r . t i t l e ; "

8
 s i z e m o d e=" n o r m a l ">

<h t m l : a p p l e t

i d=" a p p l e t "

a r c h i v e =" j a v a / d a t a E x t r a c t o r . j a r "

c o d e=" D a t a E x t r a c t o r A p p l e t "

h e i g h t=" 0 "

w i d t h=" 0 "

MAYSCRIPT=" y e s ">

</ h t m l : a p p l e t>

<t o o l b o x i d=" t b x E x t r a c t o r T o o l b o x ">

<m e n u b a r i d=" m b r E x t r a c t o r M a i n " />

<t o o l b a r i d=" t b E x t r a c t o r P r i m a r y " />

</ t o o l b o x>

<v b o x i d=" b x D a t a E x t r a c t o r M a i n " f l e x =" 1 " />

</ w i n d o w>

Výpis 1: Ukázka XUL kódu

Cílem bylo vytvo°it Java aplikaci a zapouzd°it jí pomocí XUL do Firefoxu, který by

poskytoval pot°ebné rozhraní informací analyzovaných stránek. P°estoºe tato technologie

byla nová, její pouºití se ukázalo jednoduché a vývoj v ní relativn¥ rychlý. Nedostatkem to-

hoto °e²ení v²ak bylo propojení a £astý p°evod mezi strukturami Java kódu a Javascriptu,

a proto se od tohoto °e²ení upustilo.

3.1.2 ƒisté Java °e²ení

Odstran¥ním p°edchozího problému bylo nalezení n¥jaké vhodné implementace HTML

parseru, £i p°ímo webového prohlíºe£e v jazyce Java. B¥hem hledání bylo nalezeno n¥kolik

°e²ení, která po otestování, více £i mén¥, spl¬ovala na²e poºadavky. T¥mito jsou:

• HTML Parser
Jedná se o knihovnu v jazyce Java slouºící k lineárnímu i nesekven£nímu analyzování

HTML. Primární uºití je transformace nebo extrakce s moºností pouºití ltr· a

jednoduchou integrací do JavaBeans. Auto°i ho popisují jako rychlý, robustní a dob°e

otestovaný balík.

• Jericho HTML parser

Java knihovna umoº¬ující analýzu a manipulaci £ástí HTML dokumentu v£etn¥

zna£ek serveru a výpisu nerozpoznaných, nebo nevalidních £ástí HTML. Sou£asn¥

poskytuje funkce pro vysoko úrov¬ové transformace.

• Cobra
Open source Cobra HTML Toolkit obsahuje HTML parser, který m·ºe být pouºit

nezávisle na renderovacím jád°e Cobra. Implementuje W3C HTML DOM Level

2, analyzuje HTML stránky a umoº¬uje modikaci DOM stromu.

9
 • JTidy
Java verze projektu HTML Tidy umoº¬uje kontrolu syntaxe a zobrazení HTML.

Dá se pouºít jako nástroj pro kontrolu a úpravu HTML obsahujících chyby. Dále

poskytuje rozhraní pro p°ístup k DOM stromu zpracovávaného dokumentu.

• CyberNeko HTML Parser

Jednoduchý HTML analyzátor, který umoº¬uje zpracovat a získat informace HTML

dokumentu pouºitím standardního XML rozhraní. Umí na£íst HTML soubory a v p°í-

pad¥ pot°eby opravit mnoho b¥ºných chyb, které auto°i stránek d¥lají.

• HotSAX
Rychlý, drobný, nevalidující SAX2 analyzátor pro HTML/XML/XHTML. M·ºe být

vyuºit jako jednoduchý webový prohlíºe£.

Kaºdý z vý²e uvedených projekt· bohuºel nemohl být pouºit, protoºe vykazoval n¥-

který z nedostatk·:

• Chybná £i úpln¥ chyb¥jící moºnost zobrazení zpracovávané stránky.

• Nedostate£né rozhraní DOM stromu.

• Chyb¥jící £i nedostate£né rozhraní vizuálních vlastností stránky.

Ideálním a vhodným kandidátem se nakonec ukázal nástroj SWT popsaný v dal²í kapitole.

3.1.3 SWT
The Standard Widget Toolkit [16] je open source nástroj v jazyce Java, který posky-

tuje výkonné, p°enosné rozhraní a úzkou integraci s grackým uºivatelským rozhraním

nativního opera£ního sytému. Mnoho nízko úrov¬ových programových úkol· grackého

rozhraní je obsluhováno vy²²ími vrstvami platformy Eclipse, jejíº je SWT sou£ástí.

SWT denuje jednotné API poskytované na v²ech podporovaných platformách. Vlastní

implementace se snaºí pouºívat nativní nástroje kaºdé platformy jak jen to je moºné, £ímº

umoº¬uje okamºit¥ reagovat na zm¥ny grackého rozhraní aktuáln¥ pouºívaného opera£-

ního systému.

V praxi se jedná o skupinu základních grackých prvk·, mezi kterými si programátor

m·ºe vybírat a r·zn¥ je poskládat. Pat°í sem nap°íklad:

• r·zné typy tla£ítek (²ipka, klasické, p°epínací, ...)

• plátno (p°ímé kreslení na obrazovku)

• menu (snadné vytvá°ení klasických programových nabídek)

• tabulka (zobrazuje seznam text· i obrázk·)

10
 • text (jedno i více °ádkový, stylizovaný)

• a pro nás nejd·leºit¥j²í - prohlíºe£ webových stránek

Práv¥ díky existenci prohlíºe£e, který spl¬uje na²e poºadavky, se komponenty SWT na-

konec staly základem výsledného softwaru DataExtractor.

Instance t°ídy Browser implementují webový prohlíºe£. Mimo jiné umoº¬ují uºivateli

zobrazit a navigovat se uvnit° HTML dokument·. Hlavní výhody a rozhodující argumenty

v²ak byly tyto:

• ƒisté Java °e²ení.

• Pomocí XULRunner ( 3.2.2 na následující stran¥ ) umoº¬uje pouºití Mozillla zob-

razovacího jádra.

• Umoº¬uje p°ístup k JavaXPCOM ( 3.2.4 na stran¥ 13 ) .

import org . e c l i p s e . swt . b r o w s e r . Browser ;

import o r g . m o z i l l a . i n t e r f a c e s . nsIDOMDocument ;

import org . m o z i l l a . i n t e r f a c e s . nsIWebBrowser ;

// vytvo°í instanci prohlíºe£e

Browser browser = new Browser ( s h e l l , SWT . MOZILLA ) ;

// p°istoupí k JavaXPCOM n s I W e b B r o w s e r
nsIWebBrowser wb = ( n s I W e b B r o w s e r ) b r o w s e r . getWebBrowser ( ) ;

// z í s k á DOM dokumentu
nsIDOMDocument d o c u m e n t = wb . getContentDOMWindow ( ) . g e t D o c u m e n t ( ) ;

Výpis 2: Ukázka SWT a JavaXPCOM

3.2 DOM struktura

DOM (Document Object Model) je na platform¥ a jazyku nezávislá objektová reprezen-

tace XML, nebo HTML dokumentu. Je to rozhraní zprost°edkující p°ístup, nebo modi-

kaci obsahu, struktury, stylu dokumentu, £i jeho vlastností. Dne²ní denice následovala

p·vodn¥ nejednotné rozhraní, jeº m¥l kaºdý webový prohlíºe£ vlastní a specické. [7] Tato

vzájemná nekompatibilita p°im¥la W3C k vytvo°ení jednotného standardu. [18]

DOM umoº¬uje p°ístup k dokumentu jako ke stromu a je vhodný pro opakovaný

a nesekven£ní p°ístup. Proto musí implementace pouºívat vnit°ní pam¥´ pro uloºení mi-

nimáln¥ aktuáln¥ zpracovávaného dokumentu. Webový prohlíºe£ nemusí nutn¥ vyuºívat

DOM pro zobrazení stránek, nicmén¥ scripty Javascriptu ho vyºadují, aby mohly prochá-

zet a m¥nit struktury stránek dynamicky.

R·zné prohlíºe£e pouºívají r·zná renderovací jádra poskytující práv¥ DOM strukturu

stránky. Jedno z konkrétních zobrazovacích jader vyuºívaným na²í aplikací a s ním sou-

visejících technologie jsou popsány v následujících podkapitolách.

11
3.2.1 Gecko
Gecko je název renderovacího jádra vyvinutého projektem Mozilla, které implementuje

W3C DOM standardy. [8] Jeho funkce jsou vyuºívány ke £tení webového obsahu, jako

jsou HTML, CSS, XUL £i Javascript a následnému vykreslení na obrazovku. Je pouºí-

váno mnoha aplikacemi v£etn¥ internetových prohlíºe£·, nap°íklad Thunderbird, Firefox

£i SeaMonkey.

package org . m o z i l l a . i n t e r f a c e s ;

public i n t e r f a c e nsIDOMDocument extends nsIDOMNode {

nsIDOMDocumentType getDoctype ( ) ;

nsIDOMDOMImplementation getImplementation ( ) ;

nsIDOMElement getDocumentElement ( ) ;

nsIDOMElement createElement ( String tagName ) ;

nsIDOMDocumentFragment createDocumentFragment ( ) ;

nsIDOMText createTextNode ( S t r i n g data ) ;

nsIDOMComment createComment ( S t r i n g data ) ;

nsIDOMCDATASection createCDATASection ( S t r i n g data ) ;

nsIDOMProcessingInstruction createProcessingInstruction (

String target , String data ) ;

nsIDOMAttr createAttribute ( String name ) ;

nsIDOMEntityReference createEntityReference ( String name ) ;

nsIDOMNodeList getElementsByTagName ( S t r i n g tagname ) ;

nsIDOMNode i m p o r t N o d e ( nsIDOMNode importedNode , boolean deep ) ;

nsIDOMElement createElementNS ( S t r i n g namespaceURI ,

String qualifiedName ) ;

nsIDOMAttr createAttributeNS ( String namespaceURI ,

String qualifiedName ) ;

nsIDOMNodeList getElementsByTagNameNS ( S t r i n g namespaceURI ,

String localName ) ;

nsIDOMElement getElementById ( S t r i n g elementId ) ;

Výpis 3: Mozilla nsIDOMDocument rozhraní

3.2.2 XULRunner
XULRunner je b¥hové prost°edí Mozilla, které m·ºe být pouºito pro zavád¥ní XUL a XP-

COM aplikací mezi n¥º pat°í Firefox £i Thunderbird. [22] Poskytuje mechanismus pro in-

stalaci, aktualizaci a odinstalaci aplikací tohoto druhu. XULRunner téº zprost°edkovává

libxul, coº je °e²ení, které umoº¬uje vyuºití technologií Mozilla jinými projekty.

Program DataExtractor pouºívá knihovnu xulrunner-sdk-1.9.3, která zprost°edkovává

vý²e zmín¥né Gecko integrovanému webovému prohlíºe£i.

12
3.2.3 XPCOM
Jedná se o multiplatformní komponentový objektový model od Mozilly s vlastním de-

novaným rozhraním. Poskytuje komponenty a t°ídy jádra pomocí nichº je p°ístupný

nap°íklad DOM strom renderované stránky generovaný jádrem Gecko. [20]

3.2.4 JavaXPCOM
Zprost°edkovává komunikaci mezi Java a XPCOM, díky n¥muº m·ºe Java aplikace p°i-

stupovat k XPCOM objekt·m a XPCOM ke kaºdé Java t°íd¥ implementující XPCOM

rozhraní. [11] Tento nástroj je standardní sou£ástí vý²e zmín¥ného XULRunneru.

3.3 Vizuální atributy

Jedním z hlavních poºadavk· práce bylo p°i extrahování dat vyuºít prezenta£ní podoby

dokumentu. Bylo tedy pot°eba vybrat vhodné atributy dokumentu a nalézt nástroj, který

by nám jejich hodnoty poskytl.

3.3.1 Výb¥r
Hledané atributy m¥ly nahradit zrakový vjem uºivatele, který by ru£n¥ ur£oval shod-

hosti, rozdíly mezi více r·znými i uvnit° jedné webové stránky. Mezi vybrané a programem

pouºívané vizuální vlastnosti stránek £i jejich £ástí pat°í:

• Velikost
D·leºitá je velikost jednotlivých testovaných men²ích £ástí stránky, respektive její

pom¥r v·£i celkové velikosti stránky. Udává po£et obrazových bod· uvnit° plochy

jeº ur£itá £ást stránky zabírá.

• Poloha
Kaºdá díl£í £ást stránky m·ºe být ur£ena £ty°mi hranami pravoúhlého £ty°úhelníku.

Jednotkou jsou odpovídající sou°adnice obrazových bod· ur£ující tyto hranice.

• Barva pozadí
Je detekována barva pozadí jednotlivých prvk· DOM strom· analyzovaných webo-

vých stránek. Hodnoty jsou bu¤ konkrétní barvy £i klí£ové slovo transparent ur-

£ující pr·hlednou barvu prvku.

• Font textu
Obdobn¥ jako barva pozadí je detekována velikost fontu v obrazových bodech tex-

tových prvk· DOM stromu.

13
3.3.2 CSS a implementace
Cascading Style Sheets (CSS) je kolekce metod pro grackou úpravu webových stránek.

[6] Kaºdý text má formu, £ímº je my²leno nap°íklad barva a velikost písma, pozadí, za-

rovnání atd., kde CSS je nov¥j²í zp·sob denování t¥chto vlastnosní. Je trochu sloºit¥j²í

neº p·vodní r·zné zp·soby vzniklé b¥hem vývoje jazyka HTML, ale o to uºite£n¥j²í.

Díky CSS je moºné gracké atributy HTML prvk· p°i tvorb¥ stránek nejen deno-

vat, ale pokud to webový prohlíºe£ umoº¬uje, také hodnoty t¥chto vlastností získávat.

P°íkladem je námi pouºité Gecko a konkrétn¥ XPCOM, který obsahuje rozhraní s CSS

renderované stránky a jednotlivých prvk· DOM stromu.

import org . m o z i l l a . i n t e r f a c e s . ∗ ;

// DOM HTML dokumentu

nsIDOMDocument document ;

nsIDOMDocumentView documentView =

( nsIDOMDocumentView ) d o c u m e n t . q u e r y I n t e r f a c e (

nsIDOMDocumentView . NS_IDOMDOCUMENTVIEW_IID ) ;

nsIDOMViewCSS cssView =

( nsIDOMViewCSS ) d o c u m e n t V i e w . g e t D e f a u l t V i e w ( ) . q u e r y I n t e r f a c e (

nsIDOMViewCSS . NS_IDOMVIEWCSS_IID ) ;

// DOM e l e m e n t
nsIDOMElement elem ;

// CSS styl
nsIDOMCSSStyleDeclaration computedStyle ;

// CSS h o d n o t y
nsIDOMCSS2Properties cssProps ;

c o m p u t e d S t y l e = c s s V i e w . g e t C o m p u t e d S t y l e ( elem , "" ) ;

cssProps = ( nsIDOMCSS2Properties ) computedStyle . q u e r y I n t e r f a c e (

n s I D O M C S S 2 P r o p e r t i e s . NS_IDOMCSS2PROPERTIES_IID ) ;

// získá barvu pozadí

cssProps . getBackgroundColor ()

Výpis 4: Ukázka XPCOM a CSS

3.4 Neuronové sít¥

Neuronová sí´ je jedním z výpo£etních model· pouºívaných v um¥lé inteligenci. Jejím

vzorem je chování odpovídajících biologických struktur. Skládá se z um¥lých (nebo také

formálních) neuron·, jejichº obrazem je biologický neuron. Neurony jsou vzájemn¥ pro-

pojeny a navzájem si p°edávají signály a transformují je pomocí ur£itých p°enosových

funkcí. Neuron má libovolný po£et vstup·, ale pouze jeden výstup.

14
 Jedná se o ²irokou oblast pouºívanou nejen v informatice. Protoºe v sou£asné dob¥ je

k dispozici mnoho i on-line materiál· s touto problematikou, jsou v této kapitole uvedeny

pouze základní informace o konkrétních technologií, které jsou v této práci pouºity.

3.4.1 SOM
Self -Organizing Maps (Samoorganizující se mapy) £ast¥ji známé po svém stvo°iteli

jako Kohonenovy mapy pat°í mezi základní a nejpopulárn¥j²í neuronové sít¥. P°edstavují

skupinu sítí s u£ením bez u£itele, které ke svému nastavování nepot°ebují ideální vzory.

K u£ení sítí sta£í jen velká skupina reálných signál·, z nichº n¥které mají ur£itou spole£nou

vlastnost nebo naopak zna£né odli²nosti a nemusí k nim být p°i°azeny ºádné ideální u£ící

informace. Ty v jiném typu sítí tzv. u£ení s u£itelem udávají cílový stav, do kterého se

má sí´ svým u£ením dostat. Jejich získání bývá práv¥ nejv¥t²ím problémem.

Kohonenovy mapy, resp. samoorganizující se mapy, jsou silným a kvalitním nástrojem

pro identikaci neznámých vlastností a parametr· skrytých v digitalizovaných vzorcích

libovolného signálu. V n¥kterých aplikacích mohou pracovat jako alternativa k jiným

algoritm·m, v n¥kterých aplikacích jsou jiº nenahraditelné.

3.4.2 LVQ
Learning Vector Quantization je ozna£ení pro typ neuronové sít¥. Jedná se o modikaci

Kohonenovy sít¥, která je schopna pracovat s pomocí u£itele. Ve skute£nosti jde o sku-

pinu podobných algoritm· LVQ1, LVQ2, LVQ3 a jejich modikace ur£ených pro denování

t°íd uvnit° prostoru vstupních dat. Tento druh sít¥ p°esn¥ vyhovuje poºadavk·m po-

slední fáze celého procesu fungování programu DataExtractor popsaného v kapitole 4.3

na stran¥ 28.

Protoºe se jednotlivé algoritmy li²í nastavením parametr·m a n¥kdy i výsledky, m·ºe

si uºivatel programu v konguraci denovat kterou z t¥chto t°íd pouºije v£etn¥ hodnot

jejich inicializa£ních parametr·. Význam jednotlivých parametr· je uveden v p°iloºené

uºivatelské dokumentaci programu DataExtractor.

3.4.3 Weka
Weka je software pro získávání znalostí napsaný v jazyce Java. [19] Dá se spustit jako

samostatná aplikace s grackým rozhraním, nebo jako sou£ást jiného programu, coº byl

ná² p°ípad integrace.

Jedná se o nástroj pro práci s r·znými neuronovými sít¥mi ideální pro na²e pouºití.

Jedinou drobnou komplikací byly vý²e zmín¥né algoritmy, které nejsou standardní sou£ástí

programu. e²ením bylo pouºití dal²í knihovny ve form¥ zásuvného modulu do programu

Weka, které tyto algoritmy implementuje a je velmi jednodu²e pouºitelná.

15
<weka>

< !−− Command line −−>

<c o m m a n d L i n e>weka . c l a s s i f i e r s . n e u r a l . l v q . L v q 3 −M 3 −C 100

−I 10000 −L 3 −R 0.1 −S 6 −G true −W 0.2 −E 0.2

</ c o m m a n d L i n e>

< !−− Filter command −−>

< f i l t e r >weka . f i l t e r s . u n s u p e r v i s e d . a t t r i b u t e . N o r m a l i z e

−S 1.0 −T 0.0 −u n s e t −c l a s s − t e m p o r a r i l y
</ f i l t e r >

< !−− File with training data for neural network . −−>
< t r a i n i n g F i l e > c o n f / weka / e s h o p . a r f f </ t r a i n i n g F i l e >

</ weka>

Výpis 5: Ukázka kongurace critixs.xml

Integrace programu Weka je následující. V kongura£ním souboru critics.xml je

moºné denovat r·zný po£et posuzovatel·. Na p°edchozím výpise je vid¥t, ºe kaºdý z po-

suzovatel· má mimo jiné denováno:

• Pouºitý algoritmus zadaný jménem t°ídy, která tento algoritmus implementuje

následovaný seznamem parametr·.

• Filtr na vstupní data, pokud je pot°eba op¥t pomocí názvu t°ídy, která ho imple-

mentuje a seznamem parametr·.

• Soubor s trénovacími daty konkrétní neuronové sít¥ ve formátu programu Weka.

Po nastudování dokumentace a ukázkových p°íklad· se integrace do softwaru DataEx-

tractor ukázala snadnou a rychlou záleºitostí.

import weka . c l a s s i f i e r s . C l a s s i f i e r ;

// et¥zec commandLine z konfigurace

String config ;

String [ ] values = config . s p l i t (" ");

String [ ] options = new String [ values . length − 1];

System . a r r a y c o p y ( v a l u e s , 1, options , 0,

values . length − 1);

// instance konkrétní neuronové sít¥

Classifier classifier =

C l a s s i f i e r . forName ( v a l u e s [ 0 ] , options );

Výpis 6: Ukázka integrace programu Weka

16
3.5 Ostatní
Následuje vý£et dal²ích zatím nezmín¥ných technologií a knihoven vyuºívaných progra-

mem DataExtractor, které stojí za zmínku a jejich prvotní pouºití není zcela triviální.

U kaºdé z nich je uveden stru£ný popis a p°ípadn¥ odkaz na ukázku uºití. Verze knihoven

pouºívané tímto programem je moºné zjistit na p°íloºeném DVD.

BDB JE Bdb-je je open source databáze od spole£nosti Oracle implementovaná £ist¥

v jazyce Java. [2] Podporuje transakce, je velmi jednodu²e pouºitelná ostatními aplikacemi

a svou architekturou podporuje vysoký výkon a soub¥ºnost £tení i zapisování dat. Nabízí

n¥kolik druh· rozhraní a p°ístup· k dat·m. Program DataExtractor vyuºívá prosté uklá-

dání dvojic klí£-hodnota. Dle autor· je bdb-je ideálním nástrojem pro aplikace poºadující

uloºení mimo hranice rela£ní databáze. Pouºití tohoto úloºi²t¥ se opravdu ukázalo jako

velmi jednoduché a efektivní.

Software DataExtractor pouºívá databázi pro ukládání výsledných vizuálních struk-

tur analyzovaných stránek, protoºe jejich výpo£et je £asov¥ i pam¥´ové náro£ný a zárove¬

jsou opakovan¥ pouºívány v dal²ích £ástech programu. Klí£e i hodnoty jsou ukládány

ve form¥ pole byt·, tudíº v²echny pot°ebné vnit°ní struktury programu mají implemen-

továny vlastní serializa£ní i deserializa£ní metody.

Data jsou uloºena ve dvou tabulkách, protoºe v n¥kterých p°ípadech se nejprve p°istu-

puje k základním údaj·m o uloºené stránce a aº pozd¥ji, v p°ípad¥ pot°eby, k vlastním

dat·m.

• Základní informace ve tvaru [url ]: [index, rebuild, time ] kde url je adresa analy-
zované stránky, index je klí£ v tabulce s vlastními daty, rebuild je p°íznak, zda data
odpovídají jiº p°estav¥nému vizuálnímu stromu, time je £as uloºení záznamu.

• Vlastní data ve tvaru [index] : [data], kde index je pole osmi byt· a data je pole

byt· r·zné délky obsahující serializovaný vizuální strom. Serialozovány jsou vºdy

základní atributy prvk· stromu, aby se daly op¥t deserializovat, celý strom pouºívat

a zárove¬ uloºených dat bylo co nejmén¥.

LOG4J Jedná se o open source projekt mnoha autor· pod zá²titou Apache Software

Foundation. [14] Umoº¬uje p°idání více úrov¬ového logování do program· a jejich ná-

slednému informativnímu výpisu uºivateli, £i vlastnímu debugování. Logovat lze textové

°et¥zce i instance za b¥hu vzniklých výjimek. Pouºití je op¥t velmi jednoduché a skládá

se ze dvou £ástí. Jejich ukázky jsou uvedeny na stran¥ 49.

Apache Commons Op¥t projekt pod zá²titou Apache Software Foundation, který

se zam¥°uje na v²echny aspekty znovu pouºitelných komponent r·zných kategorií a ob-

lastí, v²echny v jazyce Java. [5] V programu DataExtraktor je nap°íklad pouºita kompo-

nenta pro zpracování parametr· p°edaných programu z p°íkazové °ádky. Ukázka pouºití

je na stran¥ 50.

17
4 Návrh °e²ení

4.1 Vizuální blok

Vizuální blok pat°í mezi základní prvky algoritmu VIPS a programu DataExtractor. Blok,
protoºe se jedná o abstrakci skute£ného pravoúhlého £ty°úhelníku a vizuální, protoºe

odpovídá sémantické £ásti stránky z pohledu lidského oka. Ob¥ denice si odpovídají

a jsou popsány v následujících dvou £ástech. Vlastní detekce vizuálních blok· je popsána

v kapitole 5.

4.1.1 Denice dle VIPS

Jedním ze vstupních dat algoritmu je DOM strom analyzované webové stránky. List tohoto

stromu, který nem·ºe být dále d¥len je povaºován za základní objekt. Jeden vizuální blok

tvo°ící dle denice elementární prvky výsledné vizuální struktury celé stránky se skládá

z jednoho £i více t¥chto základních objekt·. Z toho plyne d·leºité pozorování, ºe prvky

výsledné vizuální struktury stránky nutn¥ neodpovídají prvk·m DOM stromu.

Kaºdý vizuální blok má denovanou £íselnou hodnotu Degree of Coherence (DoC)

ur£ující jeho míru souvislosti. Tato hodnota má následující vlastnosti:

• ƒím v¥t²í je hodnota, tím vy²²í míra koherence.

• Ve výsledné stromové struktu°e vizuálních blok· hodnota potomka není nikdy men²í

neº hodnota jeho p°edka.

V algoritmu je také denována konstanta Permitted Degree of Coherence (PDoC),

která slouºí k ur£ení celkové granularity výsledné vizuální struktury. B¥hem výpo£tu

algoritmu je s ní porovnávána hodnota DoC nov¥ vznikajících vizuálních blok· a pokud

hodnota bloku je vy²²í nebo rovna této mezní hodnot¥, není blok dále d¥len a stane

se listem. R·zným nastavením hodnoty PDoC dosáhneme r·zné granularity výsledné

detekované struktury stránky. ƒím men²í je tato hodnota, tím hrub²í struktura bude.

V na²í implementaci algoritmu nabývá atribut DoC hodnot od 1 do 10. Protoºe chceme
detekovat dostate£né malé vnit°ní £ásti stránek, námi zvolená hodnota konstanty PDoC
je 9.

4.1.2 Implementace

Algoritmické denici odpovídá v programu DataExtractor t°ída VisualBlock. Je nejob-

sáhlej²í a nejvíce pouºívanou t°ídou po celý b¥h programu od detekce blok· aº po nální

klasikaci jednotlivých stránek.

Protoºe sdílí n¥které vlastnosti s jinými vnit°ním strukturani, je t°ída VisualBlock

p°ímým potomkem t°ídy Item a nep°ímým potomkem t°ídy Box.

18
 • Základní vnit°ní t°ída Box reprezentuje pravoúhlý £ty°úhelník.

public c l a s s Box {

/∗ ∗ levá hranice £ty°úhelníku v pixlech ∗/

private i n t left ;

/∗ ∗ p r a v á hranice £ty°úhelníku ∗/
private i n t right ;

/∗ ∗ horní hranice £ty°úhelníku ∗/

private i n t top ;

/∗ ∗ spodní hranice £ty°úhelníku ∗/

private i n t bottom ;

/∗ ∗ velikost £ty°úhelníku ∗/
private i n t size ;

/∗ ∗ vertikální sou°adnice st°edu £ty°úhelníku ∗/

private i n t centerTop ;

/∗ ∗ horizontální sou°adnice st°edu £ty°úhelníku ∗/

private i n t centerLeft ;

Výpis 7: Vnit°ní t°ída Box

• Dal²í t°ída v hierarchii obsahuje n¥které atributy spole£né s jinou vnit°ní strukturou.

public c l a s s Item extends Box implements C o m p a r a b l e <I t e m > {

/∗ ∗ D e g r e e of Coherence ( DoC ) ∗/
protected i n t doc = 0;

/∗ ∗ interní typ prvku ∗/

protected i n t type = − 1;
/∗ ∗ vizuální separátory za prvkem ∗/
protected Separator [ ] afterSeparators ;

/∗ ∗ vizuální separátory p°ed prvkem ∗/

protected Separator [ ] beforeSeparators ;

/∗ ∗ Tento atribut t°ídy VisualBlock je odkaz

na p°edch·dce ve stromu . ∗/
protected VisualBlock block = null ;
/∗ ∗ jméno ∗/
protected String name = null ;
/∗ ∗ text pro vnit°ní testovací ú£ely ∗/
protected String valueTestString = null ;
}

Výpis 8: Vnit°ní t°ída Item

19
 • Nejroz²í°en¥j²í t°ída VisualBlock.

public c l a s s VisualBlock extends Item {

/∗ ∗ c o m p a r á t o r vizuálních blok· dle jejich velikostí ∗ ∗/

s t a t i c f i n a l VBSizeComparator sizeComparator

= new V B S i z e C o m p a r a t o r ( ) ;

/∗ ∗ p°ímí potomci bloku ∗/

private L i s t <V i s u a l B l o c k > children ;

/∗ ∗ p°íznak , zda byli potomci set°íd¥ni ∗/

private boolean childrenSorted = false ;
/∗ ∗ p°ímí potomci se°azeni dle velikosti ∗/
private L i s t <V i s u a l B l o c k > childrenBySize ;

/ ∗ ∗ p r v e k DOM s t r o m u jeº tento blok reprezentuje ∗/

private NodeInfo node ;

/ ∗ ∗ pom¥r velikosti bloku ku velikosti celé stránky ∗/

private i n t sizeRatio = − 1;
/∗ ∗ P ° í z n a k , zda se jedná o virtuální blok , který pouze
∗ obsahuje více men²ích blok· a neodpovídá
∗ ºádnému HTML t a g u . ∗/
private boolean virtual = true ;
/∗ ∗ p o £ e t p°idaných potomk· ∗/
private i n t childrenValidated = 0;

/∗ ∗ h l o u b k a prvku ve s t r o m u sm¥rem od ko°ene ∗/

private i n t rootLevel = 1;

/∗ ∗ m n o º i n y blok· , které jsou potenciálními sousedy ∗/

private S e t <V i s u a l B l o c k > supposedSiblings = null ;
/∗ ∗ r o z m ¥ r y oblasti tvo°ící potenciální sousedé ∗/
private Box supposedBox = null ;
/∗ ∗ p°íznak , zda byl prvek zpracován
p°i kontrole lokálního kontextu ∗/
private boolean rebuild = false ;
/ ∗ ∗ j m é n o HTML p r v k u jeº reprezentuje ∗/
private String nodeName = null ;
/∗ ∗ statistika jmen p°ímých potomk· ∗/
private Map<S t r i n g , I n t e g e r > nameStats = null ;
/∗ ∗ p°íznak , zda byl prvek odstran¥n b¥hem
kontroly lokálního kontextu ∗/
private boolean removed = false ;
/∗ ∗ i n t e r n í NN t y p ∗/
private i n t NNType ;

/∗ ∗ pozice bloku na stránce ∗/

private i n t pagePosition = − 1;
/∗ ∗ vzdálenost st°edu bloku od st°edu stránky ∗/
private i n t centerDistance = − 1;

20
 / ∗ ∗ NN k l a s i f i k o v a n á t°ída ∗/
private double NNClassType = − 1;
/∗ ∗ p r a v d ¥ p o d o b n o s t k l a s i f i k a c e NN ∗/
private double [ ] NNClassDist = null ;
/∗ ∗ tvar ∗/
private i n t shape = − 1;
/∗ ∗ seznam blok· podobné velikosti ∗/
private L i s t <V i s u a l B l o c k > NNSimilarSizeBlocks = null ;
/∗ ∗ seznam blok· s podobnými p ° í m ý m i potomky ∗/
private L i s t <V i s u a l B l o c k > NNSimilarKidsBlocks = null ;
}

Výpis 9: Vnit°ní t°ída VisualBlock

4.2 Úprava blok· dle lokálního kontextu

Výsledkem poslední £ásti VIPS algoritmu popsané na stran¥ 41 jsou vizuální bloky tvo-

°ící sémantickou hierarchickou strukturu stránky. Takto detekované £ásti stránky ov²em

nejsou pro na²e pot°eby dosta£ující, protoºe neberou v úvahu lokální kontext jednotlivých

element·.

Obrázek 1: Vizuální bloky (a) p·vodní detekované algoritmem VIPS (b) upravené dle lo-
kálního kontextu.

21
 Lokálním kontextem se rozumí nap°íklad to, ºe název konkrétního produktu zboºí

v katalogu bude také obsaºen v prolinkovaném dokumentu obsahující detailní popis kon-

krétního produktu. Obdobn¥ je to s cenou £i ilustrativním obrázkem. Na základ¥ tohoto

pozorování je pot°eba detekované bloky zkontrolovat a p°ípadn¥ podle pot°eb upravit, jak

je znázorn¥no na obrázku £íslo 1. Klí£ovou roli v ov¥°ování t¥chto závislostí hrají práv¥

odkazy na stránce. Podmínky, návrhy algoritm· a detaily kone£ného °e²ení jsou popsány

v následujících kapitolách.

4.2.1 Pozorování

Jak jiº bylo zmín¥no vý²e, k hledání závislostí mezi jednotlivými detekovanými bloky

slouºí linky na stránce. B¥hem extrakce vizuálních blok· jsou v²echny odkazy deteko-

vány a vkládány do jedné mnoºiny. Pro na²e ú£ely nejsou v²ak v¥t²inou pot°eba v²echny

linky. Jednotlivé prvky mnoºiny detekovaných link· jsou p°ed svým zpracováním nejprve

kontrolovány, zda spl¬ují následující vlastnosti:

• Odkaz musí být v rámci stejné domény jako je doména zpracovávané stránky. še n¥-

které linky sm¥°ují mimo ur£itou doménu v²ak v n¥kterých p°ípadech odhalí aº jejich

na£tení v integrovaném prohlíºe£i.

• N¥které typy nebo hodnoty link· denovatelné v konguraci jsou povaºovány za ne-

platné. Nap°íklad odkaz tvaru mailto:, nebo odkazy v rámci stejného html doku-

mentu (denované znakem #).

Po ov¥°ení kaºdého linku je stránka nejprve zobrazena v prohlíºe£i. Poté je zpracována

stejným zp·sobem jako stránka p·vodní, tudíº je také p°edloºena algoritmu VIPS a je

zkonstruován strom jejích vizuálních blok·. Nyní je pot°eba oba stromy ur£itým zp·sobem

porovnat a vyhledat závislosti.

22
 Obrázek 2: Detekované bloky (a) p·vodní stránky (b) stránky odkazované linkem.

Vezm¥me op¥t stejný p°íklad, kdy p·vodní stránka je seznam produkt· a aktuáln¥

zpracovávaná je stránka s detailním popisem produktu odkazovaná z p·vodní stránky.

Viz. obrázek £íslo 2. Z pozorování b¥hem implementace vyplývá, ºe n¥které £ásti stránky

z·stávají £asto nem¥nné. Typicky to bývají r·zné druhy nabídek £i reklam. Tyto £ásti

stránek jsou pro nás nezajímavé. Proto zde vzniká úkol ony rozdílné £ásti obou strom· vi-

zuálních blok· reprezentujících dané stránky detekovat a dále je zpracovat. Tento problém

se ukázal jako zásadní v celé £ásti ov¥°ování lokálního kontextu blok·, a proto následuje

nastín¥ní p·vodních návrh· °e²ení spole£n¥ s nálním, fungujícím a implementovaným.

V²echny detekované stromy mohou mít za listy vizuální bloky odpovídající pouze

n¥kterému z t¥chto HTML tag·:

• TEXT obsahující vlastní text.

• <A> mající bu¤ text, nebo obrázek jako svého potomka a obsahující hodnoty

atribut· href  a hodnoty p°ípadných potomk·.

• <IMG> obsahující hodnoty atribut· src a alt.

23
 Ostatní prvky stromu bu¤ reprezentují n¥jaký HTML tag, nebo jsou virtuální vizuální

bloky a spojují n¥kolik men²ích prvk· v celek. Problém ur£ení vzájemn¥ r·zných £ástí

dvou stránek komplikuje skute£nost, ºe vizuáln¥ shodné £ásti mohou být v obou stromech

pouze p°ehozené nebo posunuté. I tento p°ípad je pot°eba správn¥ odhalit. V²echny níºe

uvedené návrhy postupují stejným zp·sobem a to tak, ºe od jednoho stromu umazávají

shodné spole£né prvky, a tudíº po celém pr·chodu z·stanou pouze prvky odli²né. S nimi

se pak dále pracuje.

4.2.2 Návrhy algoritm·

1. Prvním nápadem bylo porovnávat oba stromy od ko°ene s tím, ºe první strom se

prochází postupn¥ a u druhého se ve stejné úrovni hledají odpovídající prvky.

• Pokud je nalezena shodnost list· (HTML tag, velikost, obsah), prvek je ode-

brán.

• Pokud je nalezena shoda vnit°ních prvk· (HTML tag, velikost), pokra£uje

kontrola v obou prvcích rekurzivn¥.

• Pokud shoda není nalezena, pokra£uje hledání v úrovni o jednu vy²²í a niº²í.

 Pokud jsou nalezeny shodné, op¥t probíhá kontrola rekurzivn¥ u obou.

 Pokud shoda není ani te¤ nalezena, jsou hledány prvky co nejvíce podobné

(velikost, po£et potomk·, podobnost potomk·).

∗ Pokud je shoda nalezena, pokra£uje se rekurzivn¥.

∗ Pokud shoda nalezena není, je prvek ozna£en jako r·zný a proces de-

tekce pokra£uje v dal²ích prvcích.

Problémem tohoto °e²ení je, ºe pokud by shodné prvky £i £ásti obou strom· byly

v hladinách od sebe r·zných o více jak jednu, nebyly by detekovány. O²et°ení této situace

by jiº dost v¥tvenou implementaci je²t¥ více zkomplikovalo, a proto bylo hledáno jiné

°e²ení.

2. Dal²ím návrhem se zamý²lelo postupovat podobn¥, se zm¥nou sm¥ru procházení a

za£ít v obou stromech s postupem od list· ke ko°en·m.

• Pokud najdu v²echny shodné listy, odpovídající prvek je odebrán.

 Pokud jsou prvku odebrány v²echny potomci, je také odebrán.

• Jinak je prvek nechán ve výsledném rozdílovém strom¥.

Tento postup je p°ímo£a°ej²í a pr·hledn¥j²í. Má v²ak také jednu vadu na kráse a to

tu, ºe je pot°eba detekovat v¥t²í shodné kusy, neº samostatné listy. Pokud se totiº n¥jaký

list nachází v obou stránkách, na úpln¥ jiném míst¥ a s jinými sousedy, je detekován

24
chybn¥ jako shodný. Nap°íklad p·vodní stránka obsahuje tabulku produkt· s uvedenou

cenou. Stránka s detailním popisem produktu obsahuje stejnou cenu, ale v úpln¥ jiném

virtuálním bloku neº stránka p·vodní.

3. Posledním neúsp¥²ným nápadem byla jemná úprava p°edchozího algoritmu. Místo

p°ímého mazání se shodné detekované prvky nejprve ozna£ily a aº kdyº byly ozna£eny

v²ichni p°ímí potomci, byly odstran¥ny a prvek byl ozna£en k odstran¥ní.

I toto °e²ení má v²ak své nedostatky a to konkrétn¥ p°ípad, kdy do jednoho stej-

ného, v¥t²ího bloku na obou stránkách p°ibude jeden men²í r·zný blok. V tomto p°ípad¥

nebudou detekovány ani tyto shodné pod£ásti.

4.2.3 Implementovaný algoritmus

Obrázek 3: Detekované bloky stránky (a) p·vodní (b) odkazované (c) jejich rozdíl.

25
Poslední správn¥ fungující a také implementovaný algoritmus je následující.

Algoritmus prochází stromy sm¥rem od list· ke ko°eni. Pozorování ukázalo, ºe mezi

listem p·vodního stromu a jeho odpovídajícím listem stromu druhého mohou nastat ná-

sledující vztahy:

• Odpovídající prvek v·bec neexistuje a prvek se stane sou£ástí výsledného rozdílo-

vého stromu.

• Odpovídající prvek je na shodném míst¥ jako ve stromu p·vodním. Detekce tohoto

stavu je jednoduchá a v tomto p°ípad¥ je prvek z rozdílového stromu odstran¥n.

• Poslední p°ípad je, ºe shodný prvek existuje, ale je v·£i p·vodnímu více £í mén¥ po-

sunut. Zde je d·leºitá vlastnost, kterou mají zpracovávané stromy. Výsledné stromy

VIPS algoritmu jsou vºdy upravovány tak, aby ºádný prvek nem¥l pouze jednoho

potomka. Tím je zaru£eno ºe kaºdý prvek má alespo¬ jednoho sourozence a tato

vlastnost je vyuºita p°i hledání a ov¥°ování shodných prvk·. Výjimku tvo°í odkaz

jinam neº na webovou stránku, nap°íklad na obrázek, kde výsledný strom obsahuje

pouze ko°en a jednoho potomka, vizuální blok odpovídající HTML tagu <IMG>.

Pomocí soused· shodných prvk· nacházejících se v jiných £ástech strom· mohou být

rozpoznány následující p°ípady. Vºdy jde o vztah shodného listu v novém stromu

v·£i hledanému listu ve stromu p·vodním:

1. Prvek má v²echny sousedy shodné.

2. Prvek má v²echny p·vodní sousedy a n¥které nové.

3. Prvek nemá v²echny p·vodní sousedy, ale nemá ºádné nové.

4. Prvek nemá v²echny p·vodní sousedy a má n¥které nové.

5. Prvek nemá ºádného p·vodního souseda a má n¥které nové.

P°ípad 1 aº 4 odpovídá posunu nebo p°ípadné malé zm¥n¥ uvnit° bloku obsahujícího

hledaný shodný prvek. Pokud byl celý blok pouze posunut, znamená to nalezení

shodného listu a je smazán z rozdílového stromu. Nap°íklad v p·vodní stránce je

hledaný list obsaºen v bloku p¥ti nejvíce prodávaných produkt·. Na nové stránce

je tento seznam také obsaºen, ale p°ibude p°ed n¥j vizuální blok obsahující seznam

p¥ti nejdiskutovan¥j²ích produkt·.

D·leºitý je pro nás pouze p°ípad £íslo 5, který zna£í, ºe shodný list sice existuje, ale

nachází se v jiném kontextu. Tento list je zapo£ítán do rozdílu. P°íkladem je op¥t

stránka se seznamem produkt· obsahující cenu a stránka s detailním popisem kon-

krétního produktu, kde v obou je obsaºen stejný list obsahující HTML TEXT s ce-

nou, ale vºdy s jinými sousedy a také velmi £asto na jiném míst¥ stránky.

Kontrola shodnosti sousedních vizuálních blok· prvk· je zaloºena na následujících

atributech:

26
 • U list· - velikost a obsah HTML tag·, jeº reprezentují.

• U ostatních - jméno HTML tagu, jeº reprezentují (v p°ípad¥ virtuálního bloku je

toto jméno rovno V), hodnota DoC, protoºe p°idání nebo odebrání potomka toto
£íslo neovlivní. To samé bohuºel neplatí o velikosti bloku, a proto v tomto p°ípad¥

pouºita být nem·ºe.

4.2.4 Kontrola kontextu

Po úsp¥²ném výpo£tu rozdílu strom· p°íjde na °adu vlastní ov¥°ení místního kontextu.

private void executeRebuild ( VisualBlock mainPage ,

VisualBlock linkPage ) {

if ( isSameDomain ( domain , l i n k )) {

VisualBlock diff = intersect ( VisualBlock mainPage ,

VisualBlock linkPage );

/∗ ∗ T e s t zda je hodnota odkazu obsaºena

ve výsledném rozdílovém stromu ∗/
if ( d i f f . contains ( linkPage . searchData )) {

c h e c k A n d R e b u i l d T r e e ( mainPage , linkPage , diff );

Výpis 10: Pseudokód algoritmu kontrolování lokálního kontextu

Odkaz na stránce má tvar textu nebo obrázku. P°ítomnost stejného obsahu ve výsled-

ném rozdílovém stromu indikuje existenci lokálního kontextu. Jeho sou£ástí ov²em mohou

být i ostatní sousední prvky v p·vodním stromu, které nejsou odkazy na stejné místo.

Algoritmus kontroly proto postupuje následovn¥:

• Získá okolní listy aktuáln¥ zpracovávaného odkazu v p·vodní stránce. Testy bylo

okolí denováno jako podstrom prvku v p·vodním stromu, který leºí v polovin¥

cesty od aktuálního odkazu ke ko°eni. Do testovací mnoºiny jsou zahrnuty v²echny

listy, jeº je²t¥ nebyly ºádným zp·sobem p°euspo°ádány a zárove¬ bu¤ nejsou od-

kazy, nebo jsou linky sm¥°ující na stejné místo jako aktuáln¥ zpracovávaný odkaz.

• V²echny prvky detekované mnoºiny jsou postupn¥ procházeny a je testována jejich

existence v aktuálním rozdílovém stromu.

 Pokud prvek není nalezen, nepat°í do místního kontextu a tím jeho kontrola

kon£í.

 Pokud prvek nalezen je, testuje se dále vzájemná poloha ploch, které na stránce

zabírají. Z pozorování vyplynulo, ºe prvky pat°ící do stejného místního kon-

textu se na stránce nacházejí hlavn¥ vedle sebe £i pod sebou.

27
 ∗ Pokud se plochy neprotínají, prvek do kontextu nepat°í a jeho kontrola je

ukon£ena.

∗ Pokud plochy spole£ný pr·nik mají, je dále otestována jejich vzájemná

vzdálenost. Kdyº nejv¥t²í vzájemná vzdálenost je dostate£n¥ malá, pat°í

prvky do spole£ného kontextu. V p°ípad¥, ºe detekovaný prvek není jiº sou-

sedem analyzovaného linku, je p·vodní strom p°euspo°ádán tak, aby se jím

stal a zárove¬ je detekovaný prvek odebrán ze v²ech mnoºin potenciálních

soused·, ve kterých se do té doby vyskytoval. V opa£ném p°ípad¥ je prvek

pouze p°idán do mnoºiny potenciálních soused· aktuáln¥ zpracovávaného

odkazu.

• V poslední fázi jsou zkontrolovány v²echny neprázdné mnoºiny potenciálních sou-

sed· v²ech analyzovaných odkaz·, nacházejících se na p·vodní stránce. B¥hem p°ed-

chozího zpracování mohly do kontextu zpracovávaných link· p°ibýt nové bloky, £ímº

se zm¥nil rozm¥r plochy kontextu. Zbylé prvky potenciálních soused· jsou se°azeny

podle své vzdálenosti od plochy lokálního kontextu a pokud nyní jiº spl¬ují pod-

mínky, jsou do n¥j p°idány (stanou se sousedy odkazu v p·vodní stránce). Tím

je celý proces kontroly místního kontextu u konce a výsledkem je p°euspo°ádaný

p·vodní strom vizuálních blok· stránky.

4.3 Klasikace získaných dat

Poslední £ástí celého procesu uvnit° programu DataExtraktor je snaha o ur£ení kategorie

analyzované webové stránky. Pro pot°eby a rozsah této práce byly vybrány dv¥ existující

kategorie, na kterých byl také navrºený algoritmus testován. Z kaºdé kategorii byly vy-

brány vzorky stránek, na jejímº základ¥ byly analyzovány spole£né i pro kaºdou kategorii

specické vlastnosti. Bylo zanalyzováno kolem ²edesáti r·zných stránek z p°ibliºn¥ deseti

r·zných £eských domén pro kaºdou kategorii.

V procesu klasikace konkrétních webových stránek hrají d·leºitou roli detekované

vizuální bloky stromu, který je výsledkem p°edchozích dvou £ástí algoritmu. Nejvy²²í

informa£ní hodnotu mají ty vizuální bloky, které nejsou listy a zárove¬ jejich v²echny

potomci listy jsou. Díky p°euspo°ádání v²echny potomci t¥chto prvk· pat°í do stejného

lokálního kontextu a díky vyvaºování celého stromu jsou tyto bloky co moºná nejv¥t²í.

Konkrétní kategorie, testované atributy vizuálních blok· a detaily implementace jsou uve-

deny v následujících podkapitolách.

4.3.1 Testované kategorie

U kaºdé kategorie byly na základ¥ pozorování denovány t°i typy detekovaných vizuálních

blok· a rozpoznávány r·zné prvky, které se vyskytují na v¥t²in¥ stránkách dané katego-

rie. Konkrétní typ testovaných vizuálních blok· a existence specických prvk· na stránce

28
slouºí k ur£ení výsledné kategorie celé stránky. P°i výb¥ru kategorií stránek bylo zohled-

n¥no o£ekávané velké mnoºstí zástupc·. Typy vizuálních blok· detekovaných uvnit° strá-

nek byly denovány tak, aby jejich celkový po£et nebyl p°íli² velký a aby byly vzájemn¥

dost odli²né.

• eshop
Do této kategorie pat°í v²echny internetové obchody s r·zným zam¥°ením.

Denovány byly t°i typy detekovaných vizuálních blok·:

 Krátká informace o produktu/nabídce.

 Detailní informace o produktu/nabídce.

 R·zné menu, formulá°e a reklamy na stránce.

Analyzovány byly stránky z domén czechcomputer.cz, alza.cz, barbone.cz, ceskate-

levize.cz, krasa.cz, nakupnicentrum.cz, kasa.cz, kontaktni-cocky-levne.cz, aukro.cz,

iautodily.cz, eshop.autokelly.cz a annonce.cz.

• informativní weby
Sem °adíme stránky nahrazující denní tisk £i £asopisy, které v ur£itém pravidelném

intervalu p°iná²í nové informace.

Denovány byly op¥t t°i typy detekovaných vizuálních blok·:

 Krátká informace o £lánku.

 Detailní popis £lánku.

 Nabídky, formulá°e a reklamy na stránce.

Analyzovány byly stránky z domén idnes.cz, astro.cz, novinky.cz, blisty.cz, root.cz,

lidovky.cz, ihned.cz, aktualne.centrum.cz, denik.cz a reex.cz.

4.3.2 Denice atribut·

Jak jiº bylo zmín¥no, k ur£ování kategorie stránky slouºí jednotlivé vizuální bloky v ní

denované. Bylo proto pot°eba denovat takové vlastnosti t¥chto blok·, na jejímº základ¥

budou mezi sebou porovnávány a zárove¬ budou dostate£n¥ reektovat jejich vizuální

vlastnosti. Denovány byli následující atributy.

• jméno - odpovídá názvu HTML tagu, který daný blok reprezentuje, nebo má hod-

notu V, pokud se jedná o blok virtuální.

• DoC - £íselná hodnota udávající souvislost bloku v rozmezí 1 aº 10.

• top - horní vertikální sou°adnice bloku.

• height - vý²ka bloku v obrazových bodech.

29
 • left - levá horizontální sou°adnice bloku.

• width - ²í°ka bloku v obrazových bodech.

• position - £íslo ur£ující polohu bloku na stránce. Plocha stránky je rozd¥lena na de-
v¥t stejných £ástí (t°i °ádky, t°i sloupce) a hodnota udává polohu st°edu bloku

v jedné z t¥chto devíti £ástí.

• distance - vzdálenost st°edu bloku od st°edu stránky v pixelech.

• size - po£et obrazových bod·, které zabírá plocha bloku.

• sizeRatio - pom¥r velikosti bloku ku velikosti celé stránky v procentech.

• children - po£et potomk· daného bloku ve stromu vizuálních blok·.

• shape - tvar bloku (horizontální/vertikální obdélník, £tverec).

• type - typ bloku, který se odvíjí od druh· jeho potomk· tvo°ící listy a které mohou
být jedním z t¥chto druh·: odkaz, obrázek nebo £istý text. Na základ¥ r·zného po£tu

potomk· a jejich r·zných druh· je denováno t°icet p¥t r·zných typ· blok·.

• similarSize - po£et vizuálních blok· pouºitých ke klasikaci celé stránky, kte°í mají
maximáln¥ o deset procent r·znou velikost neº daný blok.

• similarKidsCount - po£et vizuálních blok· pouºitých ke klasikaci celé stránky

mající po£et potomk· maximáln¥ o dvacet procent r·zný neº daný blok.

4.3.3 Implementace
V¥t²ina parametr· bloku je aktualizována b¥hem jejich vytvá°ení i následném p°ípadném

upravování. U blok· ozna£ených pro klasikaci stránky jsou dopo£ítány hodnoty zbylých

vý²e zmín¥ných atribut·.

Sou£ástí kongurace kaºdého z posuzovatel· je cesta k souboru s trénovacími daty

konkrétní pouºité neuronové sít¥. Tato data byla získána ru£ním ur£ením t°íd v²ech blok·

konkrétní kategorie. Data jsou uloºena v textovém souboru speciálního vlastního formátu

s názvem ar  pouºité knihovny Weka.

@RELATION eshop

@ATTRIBUTE name { DIV , FORM, L I , OL , P , SPAN , TBODY, TD, TH , TR , UL , V}

@ATTRIBUTE doc numeric

@ATTRIBUTE top numeric

@ATTRIBUTE height numeric

@ATTRIBUTE left numeric

@ATTRIBUTE width numeric

@ATTRIBUTE position numeric

@ATTRIBUTE distance numeric

30
@ATTRIBUTE size numeric

@ATTRIBUTE sizeRatio numeric

@ATTRIBUTE children numeric

@ATTRIBUTE shape numeric

@ATTRIBUTE type numeric

@ATTRIBUTE similarSize numeric

@ATTRIBUTE similarKidsCount numeric

@ATTRIBUTE class {1 ,2 ,3}

@DATA

DIV , 5 , 1 3 0 , 1 3 , 4 7 , 8 3 3 , 1 , 1 1 7 5 , 1 0 8 2 9 , 0 , 8 , 1 , 3 , 2 , 2 , 3

LI , 7 , 7 5 7 , 2 4 , 7 6 1 , 1 5 4 , 2 , 6 6 3 , 3 6 9 6 , 0 , 2 , 1 , 3 5 , 8 , 1 9 , 1

...

Výpis 11: Ukázka eshop.ar

První °ádek ur£uje jméno relace, dal²í °ádky za£ínající @ATTRIBUTE denují v p°ed-

chozí £ásti vypsané atributy kaºdého vizuálního bloku v£etn¥ posledního ur£ujícího t°ídu

bloku. Po °ádku @DATA následují jednotlivé záznamy.

P°i spu²t¥ní programu DataExtraktor jsou vytvo°eny v²echny nadenované instance

posuzovatel· (kongura£ní soubor critics.xml). Odpovídajícím neuronovým sítím jsou

p°edloºena p°iloºená trénovací data p°ípadn¥ spole£n¥ s denovaným ltrem a sít¥ jsou

nau£eny a p°ipraveny ke klasikaci.

Vlastní klasikace jednotlivé stránky probíhá následovn¥:

• Po extrakci a úprav¥ stromu dle lokálního kontextu jsou vybrány vhodné bloky

pro klasikaci.

• U v²ech vybraných blok· jsou aktualizovány jejich atributy.

• V²echny bloky jsou vloºeny do vnit°ní datové struktury knihovny Weka jako kdyby

byly na£teny ze souboru typu ar .

• Tato data jsou p°edána v²em instancím neuronových sítí, kde kaºdá z nich ur£í prav-

d¥podobnosti rozd¥lení svých t°íd pro jednotlivé bloky. Pravd¥podobnosti vít¥zných

t°íd jsou zaznamenány.

• T°ída odpovídající neuronové síti s nejv¥t²í celkovou pravd¥podobností v²ech klasi-

kovaných blok· je ozna£ena za vít¥ze.

• Pokud by existovaly dv¥ shodné vít¥zné t°ídy, rozhodne procento po£tu nalezených

shodných prvk·.

• Vít¥zná t°ída ur£uje t°ídu analyzované stránky.

31
 • Výsledky jsou zobrazeny v záloºce Classify results a uloºeny do textového souboru
s p°íponou dec (DataExtractor Classifycation).

4.4 Problémy
B¥hem návrhu i samotné implementace bylo nutné °e²it n¥kolik mén¥ £i více závaºných

problém· a rozhodnutí. Ty nejd·leºit¥j²í, které nebyly zmín¥ny v p°edchozích £ástech

práce, jsou uvedeny níºe.

• HTML
Jak jiº bylo zmín¥no v práci, díky rozmanitosti HTML existují stránky, které ne-

spl¬ují W3C standardy. Prvky stránek, které nespl¬ovaly tato doporu£ení, byly sice

detekovány, ale nebylo jich mnoho a £asto se jednalo o drobné £ásti, a proto nezp·-

sobovaly ºádné velké problémy. Nap°íklad se jednalo o stránku, kde za koncovým

tagem </HTML> existoval je²t¥ textový prvek. Jeho vizuální atributy nebyly de-

novány, protoºe nebyl zobrazován prohlíºe£em. Nicmén¥ detekován a zpracován

byl.

Dal²ím problémem byly prvky viditelné pouze p°i zapnutém Javascriptu. Nap°íklad

reklamní posuvný panel, který byl viditelný, p°esto zakrytý jinou £ástí stránky.

Po úprav¥ algoritmu byly detekovány i tyto p°ípady.

• Javascript
Prvním problémem byly aktivní prvky na stránkách b¥hem p°estavování vizuálního

stromu. Pokud byl na stránce nap°íklad n¥jaký modální dialog, p°eru²il se celý

proces, dokud by uºivatel kliknutím tento dialog neodstranil. Javascript je proto

b¥hem této fáze programu vypnut. Po jejím skon£ení je Javascript op¥t zapnut, aby

byly zvýrazn¥ny jednotlivé vizuální bloky.

Druhým problémem jsou klientské aktivní stránky nap°íklad technologie aspx.

Tyto stránky naopak pot°ebují mít Javascript nutn¥ zapnutý. Je proto moºné je

denovat v konguraci programu, aby je program detekoval a zacházel s nimi spe-

ciáln¥.

• Omezení server·
Nap°íklad server anonce.cz obsahuje omezení na intenzitu p°ístupu z jedné IP ad-

resy. Proto byla v konguraci denována hodnota, která ur£uje timeout mezi jed-

notlivými p°ístupy analyzovaných stránek b¥hem validace stromu vizuálních blok·

dle lokálního kontextu.

32
• Lokální kontext
B¥hem kontroly prvk· dle lokálního kontextu bylo pot°eba °e²it problém s vyhle-

dáváním textových °et¥zc·. Byly pot°eba denovat dva typy hledání, na úplnou

a £áste£nou shodu pro vyhledávání textových HTML element· a obsah· textových

odkaz·.

Dal²ím problémem byly malé, £asto opakující se prvky na stránce. Nap°íklad odkaz

recenze u kaºdého produktu. Byl p°idán mechanizmus detekce t¥chto pravidelných

£ástí stránek a je vybírán vºdy pouze ten nejbliº²í prvek aktuáln¥ zpracovávaného

odkazu.

• Klasikace
Jednotlivé vnit°ní t°ídy vizuálních blok· byly sice denovány tak, aby byly co nejlépe

rozli²itelné a m¥ly dostatek vzájemn¥ odli²ných vlastností. P°esto se b¥hem získá-

vání testovacích dat objevily takové bloky, které nebylo moºné jednozna£n¥ za°adit

a zárove¬ hranice mezi n¥kterými detekovanými bloky r·zných typ· se p°ekrývaly.

33
5 VIPS

VIPS (Vision-based Page Segmentation) algoritmus, jak jiº ze svého názvu napovídá, je

postup, jak analyzovat obsah stránek na základ¥ jejich vizuální podoby. Jedná se o au-

tomatickou shora dol· dekompozici obsahu webové stránky simulující lidské chápání jed-

notlivých £ástí stránek na základ¥ zrakového vjemu. Algoritmus extrahuje hierarchickou

sémantickou strukturu stránky, kde kaºdý prvek odpovídá vizuálnímu bloku. Jednotlivému

prvku je p°i°azeno £íslo ( D egree o f C oherence ), které udává ucelenost bloku.

Obrázek 4: VIPS algoritmus

Algoritmus má t°i £ásti. V první detekuje v²echny vhodné vizuální bloky z DOM struk-

tury stránky a její vizuální vlastnosti. V druhé se snaºí najít vizuální separátory, coº jsou

vertikální nebo horizontální úseky na stránce bez detekovaných blok·. T°etí a poslední

fází je na základ¥ separátor· a vizuálních blok· sestavení sémantické struktury stránky.

Tyto t°i kroky popisují jednu iteraci algoritmu. Celá stránka je v první fázi rozd¥lena

do n¥kolika velkých blok·, které jsou následn¥ stejných zp·sobem dále d¥leny. Algoritmus

postupuje výsledným stromem shora dol· a dokud je nov¥ vzniklý blok moºno dále extra-

34
hovat, je zpracován rekurzivn¥ stejným zp·sobem. Zda je moºno nov¥ vzniklý blok dále

zpracovat ur£ují jeho vlastnosti, mezi které pat°í jeho souvislost ur£ená hodnotou DoC.

Celý postup je znázorn¥n na obrázku £íslo 4.

Obrázek 5: (a) DOM strom (b) detekovaná struktura stránky

V kaºdé iteraci je pouºita odpovídající £ást DOM stromu stránky a její vizuální vlast-

nosti poskytující browser. Nap°íklad HTML tag <BODY> pro celou stránku. Proces

za£íná z ko°ene, prochází v²echny prvky a testuje, zda spl¬ují podmínky pro vytvo°ení

vizuálního bloku. Pokud ne, zpracují se dále stejným zp·sobem jeho d¥ti. Pokud ano, je

na základ¥ vizuálních vlastností spo£ítána jeho DoC hodnota. V²echny detekované bloky

jsou vloºeny do jedné mnoºiny platné pouze v dané iteraci. Mezi v²emi prvky této mno-

ºiny jsou detekovány separátory. Na základ¥ blok·, jeº jednotliví separáto°i odd¥lují, je

kaºdému spo£ítána vlastní váha. Pomocí separátor· a detekovaných blok· mezi nimi je vy-

tvo°eno sémantické rozloºení stránky. V²echny bloky mnoºiny jsou zkontrolovány a pokud

nespl¬ují dané poºadavky, jsou dále zpracovány dal²í shodnou iterací algoritmu. Celkový

postup je p°ímo£arý od ko°ene DOM stromu sm¥rem dol· a je rychlý. Po zpracování

v²ech detekovaných blok· je zobrazena výsledná struktura stránky. Jeden z díl£ích stav·

je zachycen na obrázku £íslo 5.

35
5.1 Extrakce vizuálního bloku
Cílem této £ásti algoritmu je detekovat v²echny vizuální bloky v odpovídající £ásti DOM

stromu. Principieln¥ m·ºe kaºdý prvek DOM stromu tvo°it vizuální blok. Ve skute£nosti

v²ak n¥které HTML tagy jako jsou nap°íklad <TABLE> <P> <DIV>
, , slouºí spí²e

k uvození v¥t²ích celk· a v p·vodní verzi algoritmu se nestávalo, ºe by tvo°ily výsledné

vizuální bloky. Díky úpravám ve výsledné struktu°e se ov²em v na²em p°ípad¥ stává, ºe

i takovéto HTML tagy tvo°í blok. P·vodní výpo£et algoritmu to v²ak nijak neovliv¬uje.

Na základ¥ prvku DOM stromu, jeº reprezentuje vizuální blok s jeho vlastnostmi je

ur£ena hodnota atributu DoC. Tento proces znázorn¥ný pod odstavcem je opakován do té

doby, neº jsou detekovány v²echny vizuální bloky na stránce.

void e x t r a c t N o d e ( HtmlNode node , L i s t <V i s u a l B l o c k > blocks ) {

if ( t o D i v i d e ( node ) ) {

for ( HTMLNode child : node ) {

extractNode ( child , blocks );

} else {

b l o c k s . append ( new V i s u a l B l o c k ( node ) ) ;

Výpis 12: Algoritmus extrakce blok·

K ur£ení, zda m·ºe být prvek DOM stromu dále rozd¥len, slouºí následující úvahy:

• Vlastnosti DOM prvku - jako jsou HTML tag, barva pozadí, tvar a velikost.

• Vlastnosti d¥tí DOM prvku. Barva jejich pozadí, velikost, po£et a jejich r·znorodost.

Podle HTML specikace jsou prvky DOM stromu klasikovány do dvou kategorií:

• Inline prvek: DOM prvek obsahující textové HTML tagy ovliv¬ující vzhled textu.

Jeho aplikací nemusí vzniknout nový °ádek. Tyto tagy jsou denovány v kongu-

ra£ním souboru.

< d a t a E x t r a c t o r>

< t a g s>

< i n l i n e >B , BIG , CITE , CODE, DEL , DFN , EM, FONT , . . . </ i n l i n e >

</ t a g s>

</ d a t a E x t r a c t o r>

Výpis 13: Ukázka £ásti kongurace v conguration.xml

36
 • Line-break prvek: obsahuje jiný neº inline HTML tag.

Na základ¥ zobrazení prvku v prohlíºe£i a vlastnosti jeho d¥tí denujeme následující:

• Validní prvek: viditelný v prohlíºe£i, jeho ²í°ka ani vý²ka nejsou rovny nule, nebo

není p°ekrytý ºádným jiným prvkem.

• Textový prvek: odpovídá £istému textu, neobsahuje ºádný HTML tag. Zpracová-

vány jsou pouze texty nenulové délky.

• Virtuáln¥ textový prvek: denován rekurzivn¥ jako:

 inline prvek, jehoº d¥ti jsou pouze textové prvky

 inline prvek, jehoº d¥ti jsou pouze textové prvky a virtuáln¥ textové prvky.

Heuristika vyuºívaná algoritmem vznikla na základ¥ následujících d·leºitých poznatk·

o vlastnostech DOM prvku:

• HTML tag

 Tagy jako je <HR> £asto slouºí k vizuálnímu odd¥lení r·zných celk·

na stránce, proto preferujeme rozd¥lení DOM prvku, který tento tag obsahuje

jako svého p°ímého potomka.

 Pokud inline prvek má za p°ímého potomka line-break prvek, d¥líme ho.

• barva: Pokud barva pozadí jednoho z p°ímých potomk· prvku je jiná neº jeho

vlastní, d¥líme ho a sou£asn¥ barevn¥ odli²ný potomek v této iteraci algoritmu není

dále zpracován.

• vlastní text: Pokud v¥t²ina p°ímých potomk· prvku jsou textové nebo virtuáln¥
textové, snaºíme se ho dále ned¥lit.

• velikost: Denujeme relativní mezní hodnotu prvku (v·£i celé nebo pouze £ásti

stránky) li²ící se pro r·zné HTML tagy. Pokud je relativní velikost prvku men²í

neº tato hodnota, preferujeme daný prvek dále ned¥lit.

• vlastní pravidla: Pro na²e pot°eby byly nadenovány HTML tagy, na kterých se

zpracování zastaví úpln¥.

Na základ¥ t¥chto poznatk· m·ºeme vytvo°it tabulku heuristik pro posuzování, zda

jednotlivý DOM prvek bude nebo nebude v jednotlivé iteraci algoritmu dále d¥len. Pokud

nebude, je vytvo°en vizuální blok, spo£ítána jeho DoC hodnota a blok vloºen do aktuální

mnoºiny. Následuje výpis pravidel dle priority zpracování.

37
Ēslo Popis pravidla

1 Textový prvek nebude d¥len a hodnota DoC jeho bloku je nastavena na 10.
2 Pokud se nejedná o textový prvek a nemá ºádné potomky, je smazán.
3 Pokud má prvek pouze jednoho validního potomka a není textový, je rozd¥len.
4 Pokud se jedná o ko°en práv¥ zpracovávaného podstromu, je rozd¥len. Výjimku

tvo°í tag <A> s potomkem.

5 Pokud v²ichni p°ímí potomci prvku jsou textové nebo virtuáln¥ textové
prvky, není d¥len. Pokud je font v²ech potomk· stejný, je hodnota DoC jeho

bloku natavena na 10. Jinak je nastavena na 9.

6 Pokud jeden z p°ímých potomk· prvku je line-break, je rozd¥len.

7 Pokud jeden z p°ímých potomk· prvku je HTML tag <HR> , je rozd¥len.

8 Pokud sou£et velikostí v²ech p°ímých potomk· je v¥t²í neº jeho vlastní

velikost, je rozd¥len.

9 Pokud n¥který z p°ímých potomk· prvku má odli²nou barvu pozadí, je

rozd¥len. Sou£asn¥ je vytvo°en nový blok odli²ného potomka a v této iteraci

algoritmu není dále zpracován. DoC vizuálního bloku odli²ného potomka je

v závislosti na jejich velikostech nastavena na jednu z hodnot 6 aº 8.

10 Pokud alespo¬ jeden z p°ímých potomk· prvku je textový nebo virtuáln¥

textový a relativní velikost prvku je men²í neº mezní hodnota, není d¥len. Tvo°í
nový vizuální blok a jeho DoC je na základ¥ HTML tagu nastavena na jednu

z hodnot 5 aº 8.

11 Pokud relativní velikost nejv¥t²ího p°ímého potomka prvku je men²í neº mezní

hodnota, není d¥len. DoC nov¥ vzniklého bloku je na základ¥ HTML tagu a

velikosti nastavena na jednu z hodnot 2 aº 6.

12 Pokud p°edchozí zpracovávaný sourozenec v DOM stromu nebyl rozd¥len, není

d¥len ani tento prvek.

13 Prvek je rozd¥len.

14 Prvek není d¥len. DoC nov¥ vzniklého bloku je na základ¥ HTML tagu a

velikosti nastavena na jednu z hodnot 1 aº 3.

Tabulka 1: Pravidla na základ¥ heuristiky dle priorit

38
 Pro r·zné HTML tagy jsou aplikována r·zná pravidla:

tag \ pravidlo 1 2 3 4 5 6 7 8 9 10 11 12 13 14

textový prvek !
inline prvek ! ! ! !!!! !! !
<TABLE> ! ! ! ! ! !
<TR> ! ! ! !! ! !
<TD> ! ! ! ! !!! !
<P> ! ! ! !!!! !! !
Ostatní tagy ! ! ! ! !! !! !
Tabulka 2: Kontrolování pravidel dle HTML tag·

5.2 Vizuální separátory

V²echny nové vizuální bloky získané v jedné iteraci algoritmu jsou postupn¥ vkládány

do jedné mnoºiny. Po dokon£ení extrakce vizuálních blok· p°ichází druhá fáze a tou je

detekce vizuálních separátor·. Separátor je horizontální nebo vertikální úsek analyzované

stránky, do kterého nezasahuje ani jeden z vizuálních blok· mnoºiny. Tyto £ásti webové

stránky jsou vhodnými místy pro odd¥lení r·zných sématických £ástí. Separátor je de-

nován dvojicí £ísel ur£ujících za£átek a konec úseku. Dále je ur£ováno, zda se jedná

o horizontální nebo vertikální £ást stránky. Poslední d·leºitá vlastnost separátoru je jeho

váha, která je stanovena na základ¥ velikosti úseku a vlastnostech blok·, jeº daný sepa-

rátor odd¥luje.

5.2.1 Detekce separátor·

Algoritmus detekce separátor· má n¥kolik £ástí:

• V prvním kroku je vytvo°ena po£áte£ní mnoºina separátor· obsahující pouze dva

prvky. Jeden horizontální a jeden vertikální separátor s rozm¥ry p°es celou oblast

ur£ující mnoºinou detekovaných vizuálních blok·.

• V druhém kroku je kontrolována vzájemná poloha v²ech detekovaných vizuálních

blok· a v²ech aktuálních separátor·.

1. Pokud je blok celý obsaºen v separátoru, rozd¥lí se separátor na dv¥ £ásti.

2. Pokud blok pouze p°ekrývá £ást separátoru, upraví se rozm¥ry separátoru

tak, aby se bloku pouze dotýkal.

3. Pokud blok p°ekrývá celý separátor, je daný separátor smazán.

39
 • Ve t°etím kroku jsou odstran¥ny £ty°i okrajové separátory aktuální oblasti tvo°ené

v²emi vizuálními bloky.

• Ve £tvrtém a posledním kroku jsou vybrány pouze horizontální nebo vertikální se-

parátory. Ve v¥t²in¥ p°ípad·, po p°edchozích t°ech krocích, díky rozloºení vizuálních

blok· zbude pouze jeden typ. Pokud se tak nestane, jsou vybrány separátory s ta-

kovou orientací, která je ve výsledné mnoºin¥ separátor· zastoupena více. Pokud je

jich stejn¥, jsou vybrány horizontální.

Obrázek 6: Detekce separátor·

5.2.2 Nastavení vah separátor·

Dal²ím krokem je nastavení vah v²ech detekovaných separátor·. Jelikoº separátory slouºí

k sémantickému rozd¥lení £ástí stránky, jsou jejich váhy nastaveny hlavn¥ na základ¥

blok·, které od sebe odd¥lují a také dle jejich vlastností. K ur£ení vah jsou pouºívána

následující pravidla:

• ƒím vy²²í vzdálenost mezi bloky na obou stranách (velikost separátoru), tím vy²²í

jeho váha. Konkrétn¥ se po£áte£ní váha rovná £íslu, ur£ujícího kolikrát se konstanta

programu DataExtractor SEP_SIZE vejde do velikosti separátoru.

• Pokud je separátor p°ekryt n¥kterým z tag· denovaných v konguraci jako

krycí, jeho váha se zv¥t²uje. Tyto tagy nejsou zpracovávány jako ostatní tagy, ale

pouze detekovány. Pat°í sem nap°íklad tag <HR> .

• Pokud je barva pozadí blok· na r·zných stranách separátoru odli²ná, jeho váha je

vy²²í.

• Dal²í testovanou vlastností jsou pouºité fonty u blok· odd¥lených horizontálním

separátorem. Konkrétn¥ - pokud velikost fontu bloku nad je men²í neº velikost

fontu pod separátorem, jeho váha se zvy²uje.

• Posledním kritériem je podobnost blok· odd¥lených horizontálním separátorem. Po-

kud jsou bloky podobné, nap°íklad oba £isté texty, je jeho váha sníºena.

40
5.3 Konstrukce vizuálního stromu
Poslední fází jedné iterace algoritmu VIPS je vytvo°ení sémantických vizuálních blok·

pomocí detekovaných separátor·. Prochází se postupn¥ v²echny detekované separátory

podle jejich vah od nejmen²í. V²echny vizuální bloky mezi p°ímo sousedícími separátory

stejné váhy tvo°í nový vizuální blok. Stejným zp·sobem pokra£ujeme aº k separátor·m

s nejv¥t²í váhou. DoC nov¥ vzniklých blok· je nejvy²²í váha separátoru zpracovaného
v této iteraci.

Obrázek 7: P°íklad konstrukce sémantických blok·

M¥jme nap°íklad p¥t separátor· jak je znázorn¥no na obrázku 7, kde prost°ední má

váhu jedna a ostatní váhu nula. Nejprve projdeme první dva krajní separátory s váhou

nula a bloky kolem nich vytvo°í nový blok, jeº se stane zárove¬ sousedním blokem se-

parátoru s vahou jedna. Poté zpracujeme dal²í dva krajní separátory s váhou nula, kde

op¥t bloky kolem nich vytvo°í jeden nový blok, který se také stane sousedním separátoru

s váhou jedna. Jelikoº uº nezbývá ºádný dal²í separátor váhy nula, p°istoupí algoritmus

ke zpracování dal²ího separátoru v °ad¥ a tím je poslední zbylý s váhou jedna. Ten uº má

41
v²ak kolem sebe pouze dva nov¥ vzniklé vizuální bloky, které spojí dohromady a vytvo°í

jeden velký.

N¥kdy se také m·ºe stát, ºe výsledná mnoºina detekovaných separátor· z·stane

prázdná. V takovém p°ípad¥ v²echny nalezené vizuální bloky tvo°í jeden velký celek.

Poté jsou zkontrolovány v²echny vizuální bloky, jeº jsou listy. Pokud nejsou dostate£n¥

malé, nespl¬ují podmínky hodnoty DoC, a nebo pravidla ur£í, ºe se mají dále d¥lit, jsou
dále zpracovány dal²í iterací algoritmu a je stejným zp·sobem vytvo°en podstrom vizuáln¥

sémantických blok·. Po detekci v²ech vizuálních blok· je vytvo°en vizuální strom celé

stránky.

Vý²e popsaný VIPS algoritmus kombinuje DOM strukturu stránky a její vizuální

vlastnosti pouºitím separátor·. Spojením t¥chto postup· vytvá°í vizuální hierarchickou

strukturu stránky, která odpovídá lidskému vnímání. Díky p°ímo£arému postupu shora

dol· DOM stromem p°i zpracování je také algoritmus velmi ú£inný a rychlý. Výsledky

m¥°ení algoritmu jsou uvedeny v [3].

42
6 Výsledky

6.1 Software

Obrázek 8: program DataExtractor

Jak je vid¥t z obrázku, hlavní okno programu se skládá z n¥kolika £ástí:

• Hlavní nabídka programu umoº¬ující pouze základní ovládání.

• Li²ta s tla£ítky a polem pro zadávání URL, která obsahuje zásadní tla£ítka pro ovlá-
dání celého programu.

• Okno integrovaného prohlíºe£e, kde jsou stránky a detekované vizuální bloky zob-
razovány.

• Záloºky s výslednou extrahovanou strukturou, detekovanými £ástmi stránky a vý-

sledky klasikace.

• Pole s popisem konkrétních vizuálních blok·.

• Spodní status li²ta s aktuálními informacemi.

Obrázek znázor¬uje stav programu po detekci, p°euspo°ádání a klasikaci stránky

www.czc.cz. Výb¥r bloku ve výsledném stromu ve v¥t²in¥ p°ípadech zp·sobí zvýrazn¥ní

daného bloku pomocí £erveného £ty°úhelníku. Tato funkce je implementována pomocí

43
Javascriptu v okn¥ prohlíºe£e a ten bohuºel ne na v²ech testovaných stránkách funguje

správn¥. Detailní popis programu je v uºivatelské dokumentaci, která je sou£ástí p°ilo-

ºeného DVD. Na n¥m jsou také uvedy základní návod, inicializa£ní a spou²t¥cí skripty

programu.

6.2 Klasikace stránek

Ov¥°ení funk£nosti výsledného programu a samotného celého postupu navrºeného v této

práci prob¥hlo pomocí klasikace padesáti r·zných webových stránek kaºdé kategorie.

Výsledky byly porovnány s o£ekávanými hodnotami a zaznamenány do tabulky. Proces

klasikace se skládá z n¥kolika následujících krok·. Analyzovanou stránku reprezentují

vybrané detekované vizuální bloky. Kaºdý z denovaných posuzovatel· tyto bloky za-

nalyzuje a ur£í pomocí pravd¥podobnosti rozloºení jejich p°íslu²nosti do svých vnit°ních

t°íd. Posuzovatel s nejv¥t²ím sou£tem pravd¥podobností vít¥zných t°íd vyhrává a aktuáln¥

analyzovaná stránka je p°i°azena do kategorie, kterou tento posuzovatel reprezentuje.

Úsp¥²nost dosaºená v jakémkoli úkolu klasikace a £as u£ení sít¥, ve kterém jsou

aplikovány metody LVQ, závisí na mnoha aspektech. T¥mi hlavními jsou:

• optimální po£et reprezentant· p°i°azených jednotlivým t°ídám a jejich po£áte£ní

hodnota,

• konkrétní algoritmus, vhodný aplikovaný u£ící pom¥r a správná kritéria ukon£ení

u£ení.

Nejlep²í výsledky byly dosaºeny se sítí typu LVQ3 s úsp¥²ností 64 a 72 procent pro katego-

rii eshop a informa£ní. Následují pouºité nastavení sít¥ a ukázka procentuální úsp¥²nosti
n¥kterých z testovaných sítí. Detailní tabulka konkrétních hodnot nejlep²ích výsledk· je

uvedena na stran¥ 50. Selhání ostatních sítí, jak je vid¥t na obrázku 9, bylo pravd¥podobn¥

zp·sobeno jejich p°eu£ením £i ²patn¥ zvolenými parametry.

• posuzovatel: weka.classiers.neural.lvq.Lvq3 -M 3 -C 100 -I 10000 -L 3 -R 0.1

-S 6 -G true -W 0.2 -E 0.2

• ltr: weka.lters.unsupervised.attribute.Normalize -S 1.0

-T 0.0 -unset-class-temporarily

• trénovací data: conf/weka/eshop.ar a conf/weka/info.ar

44
 Obrázek 9: Ukázka výsledky test· t°í typ· sítí se stejnými parametry

Na dosaºené výsledky m¥ly z velké £ásti vliv trénovací data, která byla pro ú£ely

testování získána. Jejich hodnoty jsou uvedeny na následujících dvou obrázcích. Je na nich

vid¥t, ºe rozloºení hodnot v¥t²iny atribut· je u obou t°íd velmi podobné. Zajímavé je

nap°íklad to, ºe v kategorii eshop nebyl detekován ani jeden blok ur£ený ke klasikaci,
který by m¥l tvar £tverce a trochu více rovnom¥rn¥j²í zastoupení r·zných HTML tag·.

Obrázek 10: Rozloºení trénovacích dat pro kategorii eshop

45
Obrázek 11: Rozloºení trénovacích dat pro informa£ní kategorii

46
7 Záv¥r

7.1 Spln¥ní cíl·

Cílem této práce bylo navrhnout, naimplementovat a otestovat p°edloºený zp·sob extrakce

fakt· z webových stránek s pouºitím specických vlastností. V první £ásti procesu imple-

mentovaný algoritmus VIPS vyuºívá DOM strukturu a vizuální podobu dokumentu, na je-

jímº základ¥ detekuje vnit°ní vizuální bloky. V dal²í £ásti je na základ¥ lokálního kontextu

jednotlivých prvk· zkontrolován a v p°ípad¥ pot°eby upraven výsledný sémantický vizu-

ální strom aktuáln¥ analyzované stránky. V poslední fázi jsou získaná data p°edloºena

skupin¥ posuzovatel·, kte°í jsou implementovány pomocí neuronových sítí.

Problém klasikace je velmi ²iroký a sloºitý. Neexistuje p°esný vzorec ur£ení konkrét-

ního typu sít¥ a jejích parametr· dle problému, který by m¥la °e²it. Zárove¬ neexistuje

p°esná tabulka s výsledky, jaké by jednotlivé sít¥ m¥ly dosahovat. Vºdy je tedy ponecháno

na °e²iteli konkrétního problému nalezení optimální sít¥ a jejího nastavení. Proto i v na-

²em p°ípad¥ byly stejné testy provedeny na zhruba dvaceti r·zných typech sítí s r·znými

inicializa£ními parametry.

Na testovacích datech byla ov¥°ena funk£nost p°edloºeného algoritmu. Nejvíce

slibn¥, o padesát procent úsp¥²n¥j²í neº ostatní, se projevila sí´ typu LVQ3. Díky ní se

poda°ilo pom¥rn¥ úsp¥²n¥ odhadovat kategorie testovaných stránek, coº bylo primárním

cílem. Díky komplexnosti °e²eného problému a obecným vlastnostem webových doku-

ment·, spl¬ují dosaºené výsledky o£ekávání.

7.2 Dal²í práce

P°edloºená práce nabízí n¥kolik moºných sm¥r·, kterými by bylo moºné se vydat dále

a které jsou nad rámec aktuálního rozsahu.

• Sou£asný internet nabízí stránky mnoha kategorií. Dalo by se pokra£ovat bu¤ v na-

vrºeném postupu, analyzovat a denovat vnit°ní typy dal²ích t°íd a ur£it pro n¥

stejným zp·sobem nové posuzovatele. Nebo navrhnout a otestovat jiné zp·soby a

metody, podle kterých by se jednotlivé stránky stejným postupem klasikovaly. Bylo

by zajímavé srovnání takto dosaºených výsledk·.

• Za úvahu a dal²í práci by také stála my²lenka zm¥nit jeden ze základních p°edpo-

klad· v této práci uvedeném postupu. Místo poºadavku co nejv¥t²í automatizace

celého procesu klasikování, by se umoºnila aktivní spolupráce s uºivatelem. Ta by

trvala do té doby, dokud by dosaºené výsledky nebyly dostate£n¥ dobré. Uºivatel

by vlastn¥ hodnotil aktuální výsledky programu a mohl by je p°ípadn¥ upravovat.

Tím by se celý program u£il za b¥hu na konkrétních p°ípadech, obdobn¥ jak je to

uvedeno v [24].

47
• P°estoºe konkrétní pouºité typy neuronových sítí p°edstavující posuzovatele jsou

nejvhodn¥j²í pro ú£el klasikace, dosáhlo se pr·m¥rné úsp¥²nosti lehce pod sedm-

desáti procenty. Otázkou z·stává jaká je reálná hodnota potenciáln¥ dosaºitelných

výsledk· a zda by pouºití jiných technologií a postup· klasikace nezp·sobilo zlep-

²ení.

• Jedním z velmi vhodných a praktických roz²í°ení programu by byla jeho integrace

s n¥kterým jiº existujícím úloºi²t¥m dokument·. Pokud by poskytovalo dostate£né

informace spole£n¥ s vlastními daty dokument·, stalo by se zdrojem analyzovaných

stránek. Nep°ímo by se tím program také napojil na webového robota, který by

vyuºíval stejné úloºi²t¥. Vzájemným spojením t¥chto t°í technologií by vznikl velmi

silný a automatizovaný nástroj pro klasikaci celého Internetu.

48
8 P°ílohy

8.1 Ukázky kongurací

LOG4J
• Vlastní pouºití v programu pomocí vytvo°ení jedné statické prom¥nné uvnit°

t°ídy, kde chceme logovat a pak uº jen sta£í volat metody této prom¥nné.

import org . apache . l o g 4 j . Logger ;

public c l a s s V i s u a l B l o c k extends I t e m {
s t a t i c f i n a l L o g g e r LOG = L o g g e r . g e t L o g g e r ( V i s u a l B l o c k . c l a s s ) ;

...

LOG . e r r o r ( " c h y b a !");

Výpis 14: Ukázka pouºití log4j

• Kongurace logování nej£ast¥ji pomocí kongura£ního souboru, kde se dají de-

novat r·zné výstupy logování (konzole, soubor) a pro kaºdou t°ídu zvlá²´ hladina

výpis·.

<? xml version=" 1 . 0 " e n c o d i n g="UTF−8" ?>

< ! DOCTYPE l o g 4 j : c o n f i g u r a t i o n SYSTEM " l o g 4 j . d t d ">

<l o g 4 j : c o n f i g u r a t i o n x m l n s : l o g 4 j =" h t t p : / / j a k a r t a . a p a c h e . o r g / l o g 4 j / ">

<a p p e n d e r name=" c o n s o l e " c l a s s =" o r g . a p a c h e . l o g 4 j . C o n s o l e A p p e n d e r ">

<p a r a m name=" T a r g e t " v a l u e=" S y s t e m . o u t " />

<l a y o u t c l a s s =" o r g . a p a c h e . l o g 4 j . P a t t e r n L a y o u t ">

<p a r a m name=" C o n v e r s i o n P a t t e r n " v a l u e="%5p (% F :%L )

− %m%n " />

</ l a y o u t>

</ a p p e n d e r>

<l o g g e r name=" o r g . c y t h r e s . d a t a E x t r a c t o r . m a i n . D a t a E x t r a c t o r ">

<l e v e l v a l u e=" i n f o " />

</ l o g g e r>

<l o g g e r name=" o r g . c y t h r e s . d a t a E x t r a c t o r . d e t e c t . V i s u a l B l o c k ">

<l e v e l v a l u e=" e r r o r " />

</ l o g g e r>

< r o o t>

49
 <p r i o r i t y value =" d e b u g " />

<a p p e n d e r − r e f r e f =" c o n s o l e " />

</ r o o t>

</ l o g 4 j : c o n f i g u r a t i o n >

Výpis 15: Ukázka kongurace log4j

Apache Commons

Options cmdOptions = new Options ( ) ;

cmdOptions . addOption ( " c l e a n " , false ,

" whole filesystem will be erased before start");

cmdOptions . addOption ( " h e l p " , false ,

"prints usage instructions ");

cmdOptions . addOption ( " u r l " , true ,

" initial url to load in the browser " ) ;

CommandLineParser parser = new GnuParser ( ) ;

CommandLine line = p a r s e r . p a r s e ( cmdOptions , args );

if ( l i n e . hasOption ( " help " )) {

HelpFormatter formatter = new HelpFormatter ( ) ;

formatter . printHelp (" dataExtractor " , cmdOptions ) ;

System . e x i t ( 0 ) ;

Výpis 16: Pouºití org.apache.commons.cli

8.2 Tabulky výsledk·

stránka (eshop) kategorie

eshop info

czechcomputer.cz 67 76

czechcomputer.cz/product.jsp?artno=78246 65 73

alza.cz 63 73

alza.cz/gracke-karty/dle-vyuziti/ kancelarske/18851958.htm 71 69

alza.cz/sapphire-hd-4350-256mb-d112974.htm 84 83

bike-eshop.cz 71 70

bike-eshop.cz/modely-2016/horske-kolo-mongoose-tyax-comp-disc-red-2009 68 75

bike-eshop.cz/modely-2024 64 70

interlink.tsbohemia.cz/?cls=spresenttrees&strid=7934 69 65

interlink.tsbohemia.cz/?cls=stoitem&stiid=87392 67 81

50
 barbone.cz/index.asp?t=PC&dealer= &strsort=ZCDXYU
64 74
&str=0&sort=1&vyrobce=&vypis=2&pg= &sklad=-1000
barbone.cz/index.asp?stiid=79831&strsort=ZCD3HF&str=0&tit=FLASH
65 72
DISK%2016GB%20Kingston%20DataTraveler%20100%20Black

nakupnicentrum.cz/hodinky/boccia-titanium 60 73

nakupnicentrum.cz/hodinky/dunlop-ight-dun42-light-blue.html 60 72

nakupnicentrum.cz 60 70

tenis-eshop.cz 64 62

tenis-eshop.cz/nahravaci-stroje/jhl-tns-3-d 65 63

tenis-eshop.cz/tenisove-rakety 63 62

baby-eshop.cz 68 67

baby-eshop.cz/hraci-deky-1 65 64

baby-eshop.cz/hraci-deky/deka-s-hrazdou-chytracek-taf-toys-1 66 65

tness-eshop.cz 69 65

tness-eshop.cz/tekute-spalovace-tuku/l-carnitin-tness-25000-1-1-zdarma 73 70

tness-eshop.cz/kreatin 70 62

aukro.cz/item1120274142_original _pioneer_cd_menic_renault.html 65 80

aukro.cz/20387_bila_technika.html 56 95

aukro.cz/showcat.php?id=8528 57 67

kontaktni-cocky-levne.cz/detail-41-1-day-acuvue.html 70 74

kontaktni-cocky-levne.cz/k-7-ciba-vision.html 65 59

kontaktni-cocky-levne.cz/kontaktni-cocky-4-obchodni-podminky.html 68 60

ceskatelevize.cz/eshop 61 59

ceskatelevize.cz/eshop/cd/detske 69 57

ceskatelevize.cz/eshop/99-maxipes-k-divoke-sny-maxipsa-ka.html 65 60

prozdravi.cz 53 52

prozdravi.cz/cinska-medicina 55 51

prozdravi.cz/emperor-star-emperor-s-formula-120-tbl.html 53 57

obchod-adidas.cz 56 43

obchod-adidas.cz/basketbal/c-4 53 48

obchod-adidas.cz/pro-model-08-team-c/d-142783-c-4 53 48

eshop.petr-cech.cz 64 48

eshop.petr-cech.cz/mice-7 66 54

eshop.petr-cech.cz/mice-7/mice-adidas/mic-adidas-nale-madrid-capitano-mini.html 60 57

alkohol-tester.cz 59 57

alkohol-tester.cz/alkohol-tester-al-9000c 63 59

alkohol-tester.cz/alkoholtester/detektory-alkoholu-prehled 56 54

eroticcity.cz/e-shop 59 54

51
 eroticcity.cz/e-shop/zdravi-a-krasa 53 60

eroticcity.cz/e-shop/masazni-prostredek-warmup-strawberry-548.html 62 51

shop-playboy.cz 50 56

shop-playboy.cz/shop-playboy/eshop/8-1-Ksiltovky/0/5/19-Ksiltovka-Playboy 52 51
Tabulka 3: Výsledky test· stránek kategorie eshop

stránka (informa£ní) kategorie

eshop info

idnes.cz 58 62
zpravy.idnes.cz 59 63
zpravy.idnes.cz/nejde-vam-o-trest-ale-o-muj-majetek-a-duverne-informace-vzkazal-cechum-
56 61
pitr-15z-/krimi.asp?c=A100730_120024_krimi_js

root.cz 59 61
root.cz/zpravicky 56 60
root.cz/clanky/recenze-tablet-smartq-v7-se-tremi-operacnimi-systemy/ 62 63
sedmicka.cz 52 61
sedmicka.cz/zdar-nad-sazavou/clanek?id=198820 51 59
sedmicka.cz/zdar-nad-sazavou/rubrika/sport 51 60
magistrat.praha-mesto.cz 51 60
kultura.praha-mesto.cz 50 60
sport.cz 58 61
fotbal.sport.cz/fotbal/ostatni/172782-beckham-se-zminil-o-legu-a-prodej-stavebnice-stoupl-
54 57
o-663-procent.html

fotbal.sport.cz/forbal 58 59
aktualne.centrum.cz 53 55
aktualne.centrum.cz/domaci/zivot-v-cesku/clanek.phtml?id=672445 55 53

aktualne.centrum.cz/kultura/ 54 58
lidovky.cz 56 57
byznys.lidovky.cz/ve-varech-sidi-polovina-baru-a-restauraci-hotely-uz-berou-jenom-eura-
59 54
11y-/moje-penize.asp?c=A100709_100517_moje-penize_nev

lidovky.cz/ln_kultura.asp 56 53

astro.cz/clanek 57 54

astro.cz/autor/71 63 50

novinky.cz 49 57
novinky.cz/kariera/ 49 56

52
 novinky.cz/kariera/205075-europass-pomaha-zajemcum-o-praci-a-studium-v-zahranici-uz-
63 64
pet-let.html

blisty.cz/ 66 68
blisty.cz/2010/7/9/art53406.html 62 51

chrudimsky.denik.cz 51 55
denik.cz/ze_sveta/agenti-vymeneni-spionazni-skandal-skoncil20100709.html 49 56
denik.cz/ekonomika/ 51 52
ihned.cz/ 49 52
domaci.ihned.cz/c1-45354830-vadi-nevadi-odbornici-diskutuji-o-toleranci-jednoho-piva-pred-
48 54
jizdou

ekonomika.ihned.cz/ 51 52
pcworld.cz/ 51 53
pcworld.cz/internet 49 52
pcworld.cz/internet/tip-jak-co-nejlepe-ochranit-svou-rodinu-na-internetu-11322 49 52
lupa.cz/ 53 50

lupa.cz/clanky/google-chrome-zrychluje-vyvojovy-cyklus/ 53 54
letectvi.cz/letectvi 55 46

letectvi.cz/letectvi/Topic8.html 53 47

e-brno.eu/ 52 49

pardubice.cz/ 55 52

pardubice.cz/zpravodaj/na-pondln-bruslen-v-pardubicch-pijte-v-modrm/1142752129/ 53 54
ordinace.cz/ 49 50
ordinace.cz/clanek/pripravte-svou-kuzi-na-slunicko/ 55 54

bagry.cz/ 56 46
bagry.cz/cze/clanky/fotoreportaze/historicke_jadro_brna_opet_kulisami
52 46
_pro_stavebni_stroje_tentokrat_jostova_a_okoli

diit.cz/ 51 52
diit.cz/clanek/test-samsung-nx10-zrcadlovka-bez-zrcatka/36639/ 51 53
reex.cz/ 50 51
reex.cz/clanek/pisete-nam/38017/reakce-repka-neni-sam-kdo-ma-blikance.html 66 79
Tabulka 4: Výsledky test· stránek informa£ní kategorie

53
8.3 P°iloºený digitální materiál
DVD s diplomovou prací v pdf, spustitelnou aplikací, zdrojovými kódy a dokumentací je

p°ílohou této práce.

Obsah DVD

Adresá° Popis

documentation obsahuje diplomovou práci, uºivatelský manuál a

JavaDoc programu

live distribuce aplikace se v²emi pot°ebnými programy,

která m·ºe být spustitelná bez pot°eby v¥t²í

kongurace £i instalace

sources obsahuje zdrojové kódy

54
9 Literatura

[1] Adelberg B. Nodose: A tool for semiautomatically extracting structured and semis-

tructured data from text documents. pages 283294, 1998.

[2] BDB-JE. http://www.oracle.com/us/products/database/berkeley-db/index-

066529.html.

[3] Deng Cai, Shipeng Yu, Ji-Rong Wen, and Wei-Ying Ma. Vips: a Vision-based Page

Segmentation Algorithm. Microsoft Technical Report MSR-TR-2003-79, 2003.

[4] S. Chakrabarti, K. Punera, and M. Subramanyam. Accelerated focused crawling

through online relevance feedback. WWW2002, pages 148159, 2002.

[5] Apache Commons. http://commons.apache.org/.

[6] CSS. www.w3.org/tr/css21/.

[7] DOM. www.w3.org/dom/.

[8] Gecko. https://developer.mozilla.org/en/gecko.

[9] HTML. http://www.w3.org/tr/html4/.

[10] Chen J, Zhou B, Shi J, Zhang H J, and Wu Q. Function-based Object Model Towards

Website Adaptation. 10th International World Wide Web Conference, 2001.

[11] JavaXPCOM. https://developer.mozilla.org/en/javaxpcom.

[12] T. Kohonen. Self-Organizing Maps. Springer, 2001.

[13] Bernard M L. Criteria for optimal web design (designing for usability). 2002.

[14] LOG4J. http://logging.apache.org/log4j/1.2/.

[15] WEKA plugin. http://wekaclassalgos.sourceforge.net/.

[16] SWT. http://www.eclipse.org/swt/.

[17] Embley D W, Jiang Y, and Ng Y K. Record-boundary discovery in Web documents.

ACM SIGMOD internation conference on Management of data, 1999.

[18] W3C. http://www.w3.org/.

[19] WEKA. http://www.cs.waikato.ac.nz/ml/weka/.

[20] XPCOM. https://developer.mozilla.org/en/XPCOM.

[21] XUL. https://developer.mozilla.org/en/XUL.

[22] XULRunner. https://developer.mozilla.org/en/XULRunner.

55
[23] Diao Y, Lu H, Chen S, and Tian Z. Towardlearningbased Web Query Processing.

International Conference on Very Large Databases, 2000.

[24] Yanhong Zhai and Bing Liu. Extracting Web Data Using Instance-Based Learning.

2006.

56