Automatické zpracování informací webových portálů

Transkript

cs
Automatické zpracování informací
webových portálù
D IPLOMOVÁ
PRÁCE
Rostislav Svoboda
podzim 2005
ProhláŽení
ProhlaŽuji, d̄e tato diplomová práce je mým pùvodním autorským dílem, které jsem
vypracoval˚ samostatnì. VŽechny zdroje, prameny a literaturu, které jsem pøi vypracování poud̄íval˚ nebo z nich èerpal,̊ v práci øádnì cituji s uvedením úplného
odkazu na pøísluŽný zdroj.
Vedoucí práce:
ii
Shrnutí
Cílem práce je analyzovat možností automatického sběru informací na webových
portálech. Dále pak navrhnout metodiky pro automatizované zpracovaní informací
na portálech. Součástí práce je i případová studie, kdy jsou využity získané poznatky a naprogramovány moduly do vyhledávacího systému nad elektronickými
zdroji Masarykovy univerzity. Ty jsou realizovány jako webová služba, jsou také
implementovány pomocné třídy pro tvorbu dalších modulů.
iii
Klíèová slova
extrakce dat, portál, transformace, web, webová služba, XML, XSLT, zpracování informací
iv
Obsah
1
2
3
4
5
6
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Současnost webu . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Problémy s HTML . . . . . . . . . . . . . . . . . . . . . . .
2.2 Webové standardy . . . . . . . . . . . . . . . . . . . . . . .
2.3 Technologie a aktivity W3C . . . . . . . . . . . . . . . . . .
2.4 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Modularizace XHTML . . . . . . . . . . . . . . . . .
2.4.2 Vlivy XML . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Sémantické značkování . . . . . . . . . . . . . . . .
Syndikace obsahu . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Historické a minoritní značkovací jazyky . . . . . . . . . .
3.1.1 CDF . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 OPML . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 OML . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 SyncML . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Majoritní značkovací jazyky . . . . . . . . . . . . . . . . . .
3.2.1 RSS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Srovnání . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Využití syndikace obsahu . . . . . . . . . . . . . . . . . . .
3.3.1 Vyhledávání a spojování zdrojů . . . . . . . . . . . .
3.3.2 Šířené audio a video souborů . . . . . . . . . . . . .
3.3.3 Získávání informací z portálů . . . . . . . . . . . . .
Webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Využití webových služeb . . . . . . . . . . . . . . . . . . . .
Srovnání způsobů vyhledávání informací . . . . . . . . . . . .
5.1 Studie společnosti Ridge Group . . . . . . . . . . . . . . . .
5.2 Srovnání přístupů k informacím . . . . . . . . . . . . . . .
5.3 Elektronické knihovny a portály . . . . . . . . . . . . . . .
Vyhledávač nad elektronickými zdroji Masarykovy univerzity
6.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Datové úložiště . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Moduly pro komunikaci s elektronickými zdroji . . . . . .
6.4 Tenký klient . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Vývojový tým . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
3
4
5
6
7
7
8
9
11
11
11
11
12
12
12
12
15
15
18
18
18
18
19
21
21
22
23
24
24
25
26
27
28
28
29
29
30
v
6.6
6.7
Zadání projektu . . . . . . . . . . . . . . . . . . . . .
Přehled použitých nástrojů . . . . . . . . . . . . . .
6.7.1 Analýza a návrh . . . . . . . . . . . . . . . .
6.7.2 Implementace . . . . . . . . . . . . . . . . . .
6.7.3 Nasazení a správa . . . . . . . . . . . . . . .
6.7.4 Podpora vývoje v týmu . . . . . . . . . . . .
7 Problematika automatizovaného sběru informací . . . .
7.1 Obecné informace . . . . . . . . . . . . . . . . . . . .
7.2 Specifika zdrojů . . . . . . . . . . . . . . . . . . . . .
7.2.1 Způsob zadání dotazu . . . . . . . . . . . . .
7.2.2 Kritéria vyhledávání . . . . . . . . . . . . . .
7.2.3 Struktura odpovědi . . . . . . . . . . . . . . .
7.2.4 Množství a různost poskytnutých informací
7.2.5 Co by měl modul umět . . . . . . . . . . . . .
8 Implementace modulů . . . . . . . . . . . . . . . . . . . .
8.1 Vytvoření požadavku na zdroj . . . . . . . . . . . . .
8.2 Transformace odpovědi do XHTML . . . . . . . . .
8.3 XSLT transformace . . . . . . . . . . . . . . . . . . .
8.3.1 Možnosti zrychlení transformace . . . . . . .
8.3.2 Testování rychlosti transformace . . . . . . .
8.3.3 Hardware použitý pro testy . . . . . . . . . .
8.4 Tvorba odpovědi . . . . . . . . . . . . . . . . . . . .
9 Testy modulů a portálů . . . . . . . . . . . . . . . . . . .
9.1 Testování pomocí rámce JUnit . . . . . . . . . . . . .
9.2 Testování pomocí rámce Cactus . . . . . . . . . . . .
9.3 Vlastní testování . . . . . . . . . . . . . . . . . . . . .
9.4 Testování portálů . . . . . . . . . . . . . . . . . . . .
10 Automatizace tvorby modulů pro sběr dat . . . . . . . .
10.1 Pomocné třídy . . . . . . . . . . . . . . . . . . . . . .
10.2 Třída PluginHelper . . . . . . . . . . . . . . . . . . .
10.3 Třída PluginHelperXML . . . . . . . . . . . . . . . .
10.4 Třída PluginHelperParse . . . . . . . . . . . . . . . .
10.5 Metodika vývoje modulů . . . . . . . . . . . . . . .
10.5.1 Příprava testů . . . . . . . . . . . . . . . . . .
10.5.2 Tvorba dotazu . . . . . . . . . . . . . . . . .
10.5.3 Zpracování odpovědi . . . . . . . . . . . . .
11 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rejstřík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Obsah přiloženého CD . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
31
31
31
32
33
34
34
34
34
35
36
36
36
38
39
39
40
41
42
43
44
46
46
48
51
53
56
56
56
59
60
61
61
61
62
65
67
68
69
vi
B Elektronické zdroje MU . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
vii
Kapitola 1
Úvod
S rostoucím množstvím vystavených článků v síti Internet je stále větší problém vyhledat dokumenty z požadované vědecké oblasti. Existují sice tzv. webové portály,
které se snaží ulehčit přístup k žádaným dokumentům tak, že plní své informační
zdroje výhradně dokumenty, které se zabývají určitou tématickou oblastí. Masarykova univerzita má přístup k více než čtyřiceti takovýmto portálům. Pro studenty
je ovšem časově náročné prohledat všechny tyto zdroje, tudíž vznikl požadavek na
vytvoření centralizovaného vyhledávání. Jsem členem týmu, který má za úkol implementovat takový systém.
Námi navržený vyhledávač se skládá z několika samostatných modulů, které
jsou realizovány jako webové služby. Jádro aplikace jsme se rozhodli postavit na
architektuře Java 2 Enterprise Edition. Uživatel přistupuje k systému přes tenkého
klienta, který je implementován s využitím aplikačního rámce Struts. Mým úkolem
v projektu byla komunikace se zdroji dat.
Zaměřil jsem se na zpracování informací z oborově specializovaných portálů.
Základní úkoly jsou prozkoumání možností automatizovaného sběru dat z těchto
zdrojů, naprogramování několika modulů pro získávání informací, určení postupů
pro správnou tvorbu testů a navržení metodiky pro vývoj dalších zásuvných modulů. To vše s důrazem na webové stránky.
Práce se dá podle svého obsahu rozdělit do dvou částí, teoretické a praktické.
Teoretická začíná druhou a končí pátou kapitolou. Zpočátku se věnuji problematice současného webu, potížím s HTML a zmiňuji se i o webových standardech.
Následuje kapitola o syndikaci obsahu, která přináší především možnost získávání
informací o nově publikovaných článcích a knihách. Poté rozebírám princip, možnosti a výhody webových služeb. Ty jsou v projektu využívány pro komunikaci
mezi moduly pro automatizovaný sběr dat a jádrem. Mohou také sloužit jako zdroj
obsahu na straně portálů. V poslední kapitole teoretické části se zmiňuji o problematice skryté ceny vyhledávání informace.
V praktické části, která začíná šestou kapitolou, nejprve popisuji projekt Vyhledávání nad elektronickými zdroji Masarykovy univerzity (VEZMU). Následuje rozbor problematiky modulů pro automatizovaný sběr dat jako např. způsob zadávání
dotazů, struktura odpovědi. V dalších kapitolách se věnuji implementaci těchto částí
1
1. Ú VOD
systému, jejich testování a ověřování dostupnosti informací na stránkách zdroje dat.
Na závěr popisuji postup vytváření nových modulů a také pomocné třídy, které tuto
činnost usnadňují.
2
Kapitola 2
Současnost webu
Kvalitně vytvořený dokument, bez ohledu na to, zda jde o dokument publikovaný
tradiční cestou nebo o dokument elektronický, je jednoduché zpracovat pro účely
vyhledání. V prostředí webu má respektování zásad a standardů pro vytváření
dokumentů ještě větší význam než v tradičním prostředí tištěných dokumentů, a
to bez ohledu na možnosti a výhody automatizovaného plnotextového sběru dat,
jež pozitivně ovlivňují vyhledávání informací uživateli. Respektování standardů
usnadňuje a zkvalitňuje nejen zpracování a vyhledávání informací, ale také správu
dokumentů, jejich aktualizaci, dlouhodobou dostupnost, použitelnost a nezávislost
na technickém zařízení a cílovém formátu. Hodnotný obsah strukturovaného dokumentu je jednou z cest k dosažení kvalitních výsledků hledání.
Výhodou a současně i nevýhodou elektronického publikování v prostředí webu
je jeho relativní jednoduchost a finanční nenáročnost. Díky tomu se mohou na komunikaci informací podílet i ti, pro něž by bylo šíření informací a poskytování informačních služeb tradičními postupy a cestami prakticky nedostupné.
Psaní textů se řídí určitými pravidly a mělo by to platit i při publikování na
webu. Forma i způsoby šíření informací prošly dlouhým vývojem, během něhož se
vyvíjela pravidla nejen pro psaní textů, ale také pro formální úpravu různých typů
publikací šířených tradiční (tištěnou) formou. Jistě není nutné se dlouze rozepisovat
o tom, jaké problémy se mohou vyskytnout při zpracování dokumentů a při jejich
vyhledávání, když vydavatelé nedodržují určité ustálené zvyklosti pro nakladatelskou úpravu knih a dalších publikací. Dávno již nejde jen o nepsané zásady, ale
o mezinárodně zpracovaná a přijatá doporučení (viz například normy ISO vztahující se k problematice prezentace, identifikace a popisu dokumentů1 ).
Analogie k nedodržování platných webových standardů je zřejmá. Doporučení
týkající se vytváření webových dokumentů v mnohém vycházejí z tradičního způsobu publikování. Nerespektování těchto doporučení přináší obdobné problémy,
jak při zpracování informací, tak při jejich vyhledávání. Elektronické prostředí má
ovšem řadu výhod, které pomáhají ve snadnější orientaci v informacích na webu
zveřejněných. Neznamená to však, že by si díky elektronickému prostředí s těmito
1. Normy jsou dostupné na adrese <http://www.collectionscanada.ca/iso/tc46sc9/
standard/glossry2.htm>
3
2.1. PROBLÉMY S HTML
nedostatky tvůrci vyhledávacích nástrojů jen tak jednoduše poradili. I pro ně to znamená, že je nezbytné s řadou chyb, občas i úmyslných, počítat a nějakým způsobem
je ošetřit. Jestliže k tomu připočteme jinak pozitivní vlivy, které elektronické publikování v prostředí internetu přineslo, například možnosti okamžitých aktualizací a
změn v dokumentech, je zjevné, že také v elektronickém prostředí je výhodné akceptovat postupy a pravidla, která výměnu informací usnadní.
Současný přístup ke tvorbě webových stránek je charakterizován důrazem na
uživatelský prožitek a na přístupnost dokumentů2 . Základem uživatelského prožitku jsou informační architektura, tj. organizace (uspořádání) informací, struktura
a navigace, a použitelnost 3 . Přidanou hodnotou takového přístupu je ekonomický
přínos tvorby webových stránek. Vyjádřením tohoto přístupu jsou doporučení (normy)
konsorcia World Wide Web Consortium <http://www.w3.org/> (W3C), jejichž
dodržování je jednou ze záruk všeobecné dostupnosti informací. Kromě jiného tyto
normy umožňují a usnadňují opětovné používání dat i jejich využívání pro různé
účely, snižují náklady na modernizaci systémů a zajišt’ují nezávislost na konkrétních aplikacích, na určitém softwarovém či hardwarovém řešení. Jsou tak základem
kompatibility, flexibility a dlouhodobé dostupnosti dat.
Každý, kdo vytváří webové dokumenty, víceméně vychází z doporučení, jež připravilo World Wide Web Consortium. Dodržuje tedy na určité úrovni tzv. webové
standardy. Konsorcium W3C samo o sobě není standardizační institucí v běžném
smyslu. Hlavní funkcí W3C je výzkum a vývoj a uveřejňování informací o technologiích a aktivitách týkajících se webu. Webové standardy – specifikace a doporučení
vytvořená konsorciem W3C – nejsou normy, jimiž by se museli autoři bezpodmínečně řídit, zcela jistě však jde o zásady, které se vyplatí respektovat a jež jsou základním souhrnem důsledných, promyšlených a osvědčených postupů.
V současnosti se web zřejmě nachází v přechodném období mezi určitým překotným vývojem poznamenaným zmatky a nedostatky v technologiích 90. let minulého století a budoucností založenou na zvyklostech respektujících postupy vyjádřené ve webových standardech. Jejich cílem je usnadnění práce s webem pro
všechny zúčastněné – počínaje autory, konče čtenáři a uživateli služeb.
2.1
Problémy s HTML
Využívání HTML v průběhu rozvoje služby WWW přineslo řadu inovací, jež změnily původní jednoduchý jazyk pro popis struktury dokumentů (rozvržení obsahu)
a definování vazeb mezi nimi (hypertextových odkazů) na složitý jazyk používaný
2. Pravidla pro přístupnost dokumentů lze najít na stránkách <http://pristupnost.nawebu.
cz/>
3. Web zabývající se použitelností a organizací informací je například <http://www.useit.
com/>.
4
2.2. WEBOVÉ STANDARDY
k budování graficky a typograficky bohatých webových sídel. Jednou z nejproblematičtějších inovací je využívání tabulek pro formátování vzhledu 4 webových dokumentů. Tabulky, zvlášt’ jsou-li složité a vnořené, přinášejí problémy s velikostí
souborů i s rychlostí v zobrazování dokumentů. Je obtížné takto vytvořené dokumenty aktualizovat a udržovat, obzvlášt’ je-li správa webového sídla týmovou
prací. Dokumenty formátované pomocí tabulek jsou navíc často nepřístupné skupinám uživatelů s různými omezeními. Zpracování takových dokumentů přináší
problémy i robotům vyhledávacích služeb.
Nevhodné používání jazyka HTML a jeho úpravy autory webových dokumentů
není pochopitelně jediným problémem doprovázejícím rozvoj webu v uplynulých
letech. Svoji roli sehrály i prohlížeče webu, jejichž podíl na používání nesprávných
postupů je dodnes velmi významný, přestože právě výrobci prohlížečů patří mezi
členy konsorcia W3C. Programové vybavení pro práci s Internetem je součástí výnosného obchodu, a tak je celkem pochopitelná snaha výrobců dosáhnout třeba
i standardům odporujícími lákavými novinkami dominantního postavení. Dosavadní vývoj webu tak poznamenali kladně i záporně všichni: autoři dokumentů,
výrobci prohlížečů i nástrojů pro budování webových stránek a svým způsobem i
jeho uživatelé.
2.2
Webové standardy
Současný vývojový stav v oblasti webových standardů ovšem dosáhl úrovně, kdy se
vyplatí z řady důvodů jejich respektováním využívat obrovského potenciálu, který
je jednoznačně výhodný i z pohledu budoucnosti. A to i přesto, že v současnosti
stále docela dobře „fungují“ webové dokumenty založené na nestandardních postupech.
Existuje totiž řada důvodů, pro něž se vyplatí standardy pochopit a využívat:
•
jejich respektování šetří čas a tím i peníze autorům a poskytovatelům webových informací,
•
využívání postupů založených na standardních technologiích usnadňuje a
urychluje práci uživatelům webu,
•
porozumění standardům vede k chápání širších souvislostí a principů, na
nichž je vznik i rozvoj webu vystavěn a mezi něž patří mj. i myšlenka všeobecné dostupnosti informací 5 .
4. Petr Staníček se na svých stránkách <http://www.pixy.cz/pixylophone/2004_01_
archiv.html#1074594674> tomuto tématu často věnuje.
5. Sedm bodů vysvětlující cíle a principy konsorcia W3C: <http://www.w3.org/Consortium/
Points/>
5
2.3. TECHNOLOGIE A AKTIVITY W3C
Z technologického pohledu je zřejmé, že respektování standardů vede k úspoře
nákladů na budování a údržbu webových dokumentů a umožňuje jejich bezproblémové využívání různými koncovými zařízeními uživatelů. Ze společenského hlediska jsou standardy nástrojem, který odstraňuje bariéry v přístupu uživatelům, at’
jde o překážky či omezení zdravotní, finanční či jazykové.
2.3
Technologie a aktivity W3C
Aktivity konsorcia W3C jsou velmi široké a je možné se o nich více dozvědět na
webových stránkách W3C i z dalších zdrojů, například ze sborníků z konferencí
pořádaných konsorciem (International World Wide Web Conferences). Mezi nejvýznamnější patří:
•
Hypertext Markup Language (HTML) <http://www.w3.org/MarkUp/>.
Značkovací jazyk pro vytváření webových dokumentů, konečnou verzí je
HTML 4.01. Tato verze obsahuje jen menší změny oproti předchozí verzi
HTML 4.0, její význam je však obrovský, protože DTD (Document Type Definition) HTML 4.01 jsou základem XHTML 1.0. Jde dnes o uzavřenou kapitolu
v činnosti W3C.
•
Extensible Markup Language (XML) <http://www.w3.org/XML/>. Značkovací jazyk pro univerzální formát strukturovaných dokumentů a dat.
•
Extensible Hypertext Markup Language (XHTML) <http://www.w3.org/
MarkUp/>. Značkovací jazyk pro vytváření webových dokumentů a dokumentů pro alternativní zařízení. Navazuje na předchozí dvě aktivity. XHTML
je současný standard, který nahradil HTML 4. Obsahu webu navrací přísnou
logickou strukturu dokumentů a současně umožňuje práci s dalšími webovými standardy, jako jsou CSS a DOM. Zajišt’uje rovněž spolupráci s již existujícími i budoucími jazyky, aplikacemi a protokoly založenými na XML.
•
Cascading Style Sheets (CSS) <http://www.w3.org/Style/CSS/>. Stylový jazyk pro prezentaci, formátování vzhledu (X)HTML dokumentů.
•
Synchronized Multimedia Integration Language (SMIL) <http://www.w3.
org/AudioVideo/>. Jazyk založený na XML, jehož cílem je usnadnit synchronizaci multimedií (video, zvuk, text).
•
Scalable Vector Graphics (SVG) <http://www.w3.org/Graphics/SVG/>.
Jazyk založený na XML určený pro popis grafických objektů.
•
Přístupnost (accessibility <http://www.w3.org/WAI/>). Jejím cílem je zajištění přístupnosti dokumentů pro všechny uživatele.
6
2.4. XHTML
•
2.4
Document Object Model (DOM) <http://www.w3.org/DOM/>. Aplikační
programové rozhraní, jež definuje obecný standard pro přístup k jakémukoliv platnému HTML dokumentu nebo ke správně vytvořenému XML dokumentu; cílem je zajistit shodné objektové modely dokumentů v prohlížečích.
XHTML
Konečná verze jazyka HTML, HTML 4.01 <http://www.w3.org/TR/html401/>,
byla zveřejněna v prosinci 1999. Stala se základem pro specifikaci XHTML 1.0 <http:
//www.w3.org/TR/2000/REC-xhtml1-20000126/>, publikovanou brzy poté
v lednu 2000 (revidovaná verze pochází ze srpna 2002), jež je vlastně jen přeformulováním konečné verze HTML v XML. Zatímco první specifikace XHTML zachovává postupy zahrnuté ve standardu HTML 4.01 a jen přepisuje HTML jako aplikaci
XML, v další vývojové verzi XHTML 1.1 <http://www.w3.org/TR/xhtml11/>
z května 2001, se z něj již stává pouze jazyk pro popis struktury dokumentu. Formátování vzhledu je přenecháno samostatnému stylovému předpisu.
Ve stadiu příprav je verze XHTML 2.0 <http://www.w3.org/TR/xhtml2/>,
zveřejněný pracovní návrh doporučení je z května 2005.
2.4.1
Modularizace XHTML
Jednou ze základních myšlenek rozvoje XHTML je jeho modularizace 6 . Jednotlivé
prvky jazyka jsou seskupeny do modulů odpovídajících jejich určení (funkci) společně s vlastnostmi, které se k nim mohou vztahovat, a s minimálním obsahovým
modelem.
Základními moduly XHTML jsou:
•
strukturální modul zahrnující prvky, které tvoří základní strukturu XHTML
dokumentu (body, head, html, title),
•
textový modul, jenž definuje základní prvky sloužící k označení textu a obsahu dokumentů (h1 až h6, address, blockquote, div, p, pre, abbr, acronym,
br, cite, code, dfn, em, kbd, q, samp, span, strong, var),
•
hypertextový modul s prvkem „a“ sloužícím pro hypertextové odkazy na
jiné zdroje,
•
modul seznamů obsahující prvky sloužící k vytváření seznamů (dl, dd, dt,
ol, ul, li),
6. Více
informací
na
stránce
WD-xhtml-modularization-20040218/>
<http://www.w3.org/TR/2004/
7
2.4. XHTML
•
formulářový modul s prvky pro tvorbu formulářů (form, input, label, select,
textarea aj.).
Kromě toho obsahuje XHTML ještě řadu dalších modulů (modul tabulek, objektový modul, modul odkazů, metainformační modul aj.), jež pokrývají celou šíři
povolených prvků dané verze jazyka. Standard XHTML 1.1 postavený na XHTML
1.0 Strict už neobsahuje ty prvky, jež byly v předchozích verzích sice povoleny, ale
byly označeny jako překonané (deprecated). Vezmeme-li v úvahu, co v relativně
krátké historii webu představuje doba, jež uplynula od publikování první specifikace XHTML, a k tomu další fakt, že specifikace CSS2 <http://www.w3.org/
TR/REC-CSS2/> pochází dokonce již z května 1998, je jistě podivné, že se využívání těchto webových standardů autory doposud nestalo běžnou zvyklostí. Zvlášt’,
když jejich respektování přináší tolik výhod, jak autorům, tak samotným uživatelům. Svůj podíl na tom jistě mají výrobci prohlížečů, kteří se značným zpožděním
začali akceptovat normy, na jejichž vývoji se jako členové konsorcia W3C sami určitým způsobem podíleli. Současné verze všech nejrozšířenějších prohlížečů však již
s drobnými odchylkami víceméně podporují platné předpisy, a tak se tou překážkou možná mohou zdát uživatelé webu, kteří kupodivu stále z nějakého důvodu
pracují se staršími verzemi prohlížečů.
2.4.2
Vlivy XML
K nejvýznamnějším vlivům XML na tvorbu webových dokumentů se řadí:
•
důraz na logické značkování struktury dokumentů,
•
rozlišování mezi malými a velkými písmeny (case sensitivity), XHTML používá malá písmena,
•
nezbytnost dodržování syntaktických pravidel jazyka, jehož výsledkem je
správně vytvořený (well-formed) dokument, mj. to znamená, že se prvky
v dokumentu nesmí křížit: pokud nějaký prvek obsahuje počáteční značku
jiného prvku, pak musí obsahovat i příslušnou koncovou značku,
•
dokument musí obsahovat kořenový prvek (root element), v XHTML je to
prvek <html>,
•
nutnost používání koncových značek všech prvků, např. </p>, </li>, a tomu
odpovídající ošetření prázdných značek doplněním lomítka: <br />, <hr />,
•
používání uvozovek při zápisu hodnot vlastností prvků, např. u obrázkových prvků: <img src="fi-logo.png" alt="Fakulta informatiky"/>.
8
2.4. XHTML
Jednou z mnoha výhod respektování webových standardů při vytváření webových dokumentů je možnost ověření jejich platnosti prostřednictvím nástrojů, které
jsou pro tento účel k dispozici (např. W3C Validator <http://validator.w3.
org/>). Validátor dokument zkontroluje, zda je správně strukturován a zda jeho
zdrojový kód souhlasí s deklarovanou definicí typu dokumentu (DTD) v záhlaví.
2.4.3
Sémantické značkování
Sémantické7 značkování založené na významu a smyslu součástí dokumentu znamená, že je obsah dokumentu označen podle toho, o jaký druh informace jde. Pro
tento účel jsou k dispozici logické značky založené na vyjádření obsahu, jež popisují
význam textu, který je jimi označen.
Patří mezi ně např. značky <abbr>, <acronym>, <address>, <blockquote>, <cite>,
<code>, <kbd>, <q>, <samp>, <em> nebo <strong>. Pokud autor nestanoví ve vlastním stylovém předpisu, jakým způsobem se má text uzavřený v takových značkách zobrazit, prohlížeče jej zobrazí podle vlastního stylu víceméně založeného na
obecně používaných zvyklostech. Vytvoří zpravidla určitý vizuální efekt, aniž by
ovšem narušily strukturu dokumentu či pozměnily autorem zamýšlený důvod pro
jejich použití.
Například značky <strong> a <em> se používají pro označení těch pasáží textu,
jimž přikládá autor zvláštní význam, klade na ně důraz, a chce je tedy z nějakého
důvodu zvýraznit. Může jít například o důležité fráze či klíčové pojmy. Z hlediska
obsahového má tedy význam to, že jde o důležitou část textu, výsledný vizuální
efekt je vedlejší, nebot’ je závislý na koncovém zařízení uživatele. Text uzavřený do
značky <strong> běžné prohlížeče zobrazí tučným písmem, text se značkou <em>
kurzívou a text označený <code> neproporcionálním písmem s pevnou šířkou znaků.
Význam takového logického značkování textu je zřetelný, uvědomíme-li si, že třeba
značka <b> pro tučné písmo (bold face) nemá žádný význam pro uživatele používajícího čtecí zařízení pro Braillovo písmo nebo pro toho, kdo používá textový
prohlížeč.
Při vytváření dokumentů je tedy nutné používat značky s vědomím toho, že
nesou určitý význam, že byly zamýšleny pro vyjádření určitého smyslu ve vztahu
k vlastnímu obsahu dokumentu. Je zřejmé, že tento způsob značkování určitých
částí textu je velmi užitečný také pro zpracování dokumentů pro účely vyhledávání
informací.
Je-li řeč o „webových standardech“, je důležité nezapomenout na to, že nejde jen
o technologie, ale především o způsob, jakým tyto nástroje při své práci používají
lidé. To, že někdo vytváří platné XHTML dokumenty a používá CSS pro řízení jejich
7. Vysvětlení pojmu sémantické je možné nalézt na adrese <http://encyclopedia.com/
html/s1/semantic.asp>.
9
2.4. XHTML
vzhledu ani zdaleka neznamená, že se tím tyto dokumenty stávají automaticky přístupnými nebo přenosnými nebo že méně zatěžují přenosové linky. XHTML i CSS
mohou být používány stejně špatně a nesmyslně, tak jako se to stává se staršími
webovými technologiemi.
10
Kapitola 3
Syndikace obsahu
Syndikace obsahu je moderní metodou sdílení velkých objemů rychle se měnících
informací na internetu, zpřístupňuje obsah velkému množství konzumentů současně. Jedná se o terminus technicus vyjadřující možnost přebírat obsah z různorodých zdrojů a dále ho používat pro vlastní stránky či služby – většina webových
syndikací zpracovává pouze titulky, odkazy a anotace konkrétních článků.
Slovo syndikace se používalo původně zejména v USA k označení prodeje autorského díla. Obvykle šlo o periodické příspěvky (fejetony, seriály). Odběrateli těchto
informací byla místní média (deníky, televizní stanice), která je dále zařazovala do
nabídky svého obsahu.
Existuje několik značkovacích jazyků využívaných pro syndikaci obsahu. Budou
probrány v dalších sekcích.
3.1
Historické a minoritní značkovací jazyky
3.1.1
CDF
Channel Definition Format (CDF) <http://www.w3.org/TR/NOTE-CDFsubmit.
html> je XML (eXtended Markup Langugage) standard spojený s technologií firmy
Microsoft Active Channel. Active Channel byl představen v roce 1997 současně se
spuštěním Internet Exploreru 4.0. Umožňoval uživatelům prohlížet webové stránky
z vyrovnávací paměti. Ovšem technologie Active Channel se svým formátem CDF
se příliš neprosadila.
3.1.2
OPML
Outline Processor Markup Language (OPML) <http://www.opml.org/spec>
je XML formát pro schémata. Původně byl vyvinut společností Radio UserLand,
která jej využívala pro publikování seznamu přehrávaných skladeb. OPML specifikace definuje hierarchický setříděný seznam libovolných elementů. Tato volnost
je vhodná pro velké množství typů seznamů. OPML se často používá pro výměnu
RSS vazeb mezi RSS čtečkami.
11
3.2. MAJORITNÍ ZNA ČKOVACÍ JAZYKY
Na popud Davida Winera byl také vytvořen validátor dostupný na adrese <http:
//validator.opml.org>. Existují také možnosti rozšíření, stačí přidat vlastní
element. Není ovšem specifikován žádný element pro tato rozšíření.
3.1.3
OML
OML (Outline Markup Language) <http://oml.sourceforge.net> je specifikace vycházející z OPML s cílem zlepšení některých jejích omezení. Jedná se o stejně
jednoduchý a flexibilní jazyk jako OPML obohacený o mechanismus rozšíření. Je zaveden element <item>, který může obsahovat specifická data a elementy. OML není
oproti svému předchůdci tolik rozšířen, je to dáno také jeho relativní mladostí (dokončen v roce 2003).
3.1.4
SyncML
Synchronization Markup Language (SyncML) <http://www.openmobilealliance.
org/tech/affiliates/syncml/syncmlindex.html> je jazyk pro platformě
nezávislou synchronizaci dat. Dnes je zaštit’ován uskupením Open Mobile Alliance
(OMA, <http://www.openmobilealliance.org>), ve které se o jeho rozvoj
starají dvě pracovní skupiny: Device Management Working Group a Data Synchronization Working Group. Uplatňuje se především na poli mobilních zařízení. Dnes
ho ve svých zařízení podporují firmy jako Nokia a Sony Ericsson.
SyncML se většinou používá v případech jako je synchronizace kontaktů a kalendáře mezi osobním počítačem a zařízením do ruky. Lze ovšem použít i k více
obecné synchronizační účely. Některé produkty pro podporu týmové práce jej využívají k synchronizaci informací o úkolech v jednotlivých projektech. Dalším případem použití jsou zálohovací programy.
3.2
Majoritní značkovací jazyky
3.2.1
RSS
Se zkratkou RSS (popř. RDF nebo XML) se setkáte na mnoha serverech. Najdete ji
v postranním sloupci, nahoře nebo dole na stránce. RSS kanál je velmi vhodný pro
zpravodajské portály, na kterých se také velmi často objevuje. Obecně je to vhodné
pro servery, které často mění nebo přidávají nějaký obsah, jako např. články, zboží,
novinky.
Vyměňují se pouze titulky, odkazy a anotace (perexy) článků. Samotný článek se
většinou nesyndikuje a pokud daný titulek člověka zaujal, přečte si článek na původním místě. Tato technologie je pro obě strany výhodná. Uživatel nemusí ručně
12
navštěvovat své oblíbené webové stránky. A poskytovatel informací má stálé čtenáře.
Zkratka RSS bývá vysvětlována třemi způsoby:
•
Rich Site Summary – stručný přehled obsahu webu (RSS 0.91).
•
RDF Site Summary – RDF znamená Resource Description Framework (RSS
0.9 a 1.0).
•
Really Simple Syndication – opravdu jednoduchá syndikace (RSS 2.0).
RSS z hlediska uživatele
Pokud chcete mít přehled o aktualitách na svých oblíbených stránkách, máte v podstatě 3 možnosti – pravidelně navštěvovat dané stránky, přihlásit se k odběru pravidelných informačních zpráv nebo si do své čtečky přidat RSS kanál webu. RSS
nabízí pravděpodobně nejrychlejší přístup k informacím, odpadá otevírání stránek
v prohlížeči a zobrazení načítání zbytečných dat. Web může mít více než jeden RSS
kanál. RSS kanál má mnoho výhod, protože uživatel – čtenář
•
nezmešká nové příspěvky nebo články,
•
na server s RSS kanálem nezapomene,
•
bude se často vracet.
Díky RSS může uživatel z jednoho místa sledovat, co je nového na mnoha serverech.
Je to pro něj pohodlnější a rychlejší. A nemusí se nikam registrovat a sdělovat osobní
informace (email), jako v případě pravidelných elektronických zpráv.
Kliknutím na zkratu RSS na některém serveru se vám otevře soubor, který sice
je čitelný, ale čtení v něm není příliš pohodlné. Pro lepší čtení slouží RSS čtečky
(agregátory). Do čtečky lze vložit velké množství RSS kanálů a čtečka za vás sleduje, jestli došlo k aktualizaci na daných stránkách. Takovýchto programů je mnoho,
v nových verzích prohlížeče Opera a Firefox je již čtečka integrována, pro Internet
Explorer se musí stáhnout některá z nadstaveb, např. Maxton. Pokud používáte
jiný prohlížeč, budete si muset stáhnout samostatný program. Zmíním program
Feedreader <http://sourceforge.net/projects/feedreader> (Windows
32) šířený pod GPL licencí, pro Linux Straw <http://www.nongnu.org/straw/>
(GTK2, Python) nebo akregator <http://www.kde-apps.org/content/show.
php?content=15621> (QT). Po výběru čtečky ji budete muset „nakrmit“ – dodat
do ní RSS zdroje (RSS feeds). Tvůrci webových stránek ve většině případu odkazují na RSS soubor prostřednictvím oranžového tlačítka. Na stránce <http://www.
syndic8.com> nebo <http://rss.timqui.net/seznam-kanalu.php?p=all>
se nachází velké databáze RSS zdrojů.
13
RSS z hlediska programátora
Princip RSS je velmi jednoduchý. Určité URL je přiřazeno často aktualizovanému
dokumentu v dohodnutém formátu, jehož obsahem je stručný popis obsahu webu,
souhrn novinek a podobně. Pravidelným načítáním tohoto dokumentu pak lze dosáhnout efektu kanálu, který sám „tlačí“ své informace uživatelským agentům. Tímto
způsobem je možné snadno sdružovat a zpracovávat informace z mnoha zdrojů.
Dobrý nápad, jednoduché provedení, proto není divu, že se kanály RSS rychle rozšířily po celém webu a nabízejí pozoruhodné množství i kvalitu informací. Jediným
problémem je naprostý chaos ve verzích formátu, v němž jsou informace poskytovány.
Příčiny současného chaosu se musí, jak jinak, hledat v minulosti. Formát RSS původně navrhla jako aplikaci XML firma Netscape pro potřeby svého portálu my.netscape.com.
První verze RSS označená 0.9 <http://www.purplepages.ie/RSS/netscape/
rss0.90.html> se objevila v březnu 1999. Firma UserLand, jež se sdružováním
obsahu zabývala už od roku 1997 (měla vlastní formát zvaný <scriptingNews>),
začala RSS také podporovat. V červenci 1999 Netscape představil verzi RSS 0.91
<http://my.netscape.com/publish/formats/rss-spec-0.91.html>, která
v sobě integrovala také prvky ze <scriptingNews>. V dalším období Netscape ztrácí
zájem a hlavní postavou na poli RSS se stává David Winer z UserLandu. V červnu
2000 přichází s vlastní specifikací verze 0.91.
Formát RSS se začal významně rozšiřovat a část komunity jeho uživatelů získala dojem, že Dave brzdí další rozvoj. Brzy vznikla mezinárodní skupina vedená
Raelem Dornfestem a Aaronem Swartzem, jež v prosinci 2000 navrhla novou verzi
RSS 1.0 založenou na RDF <http://www.w3.org/RDF/>. Téměř ve stejnou dobu
zveřejnil Winer verzi RSS 0.92 <http://backend.userland.com/rss092> a
dále ignoroval úsilí příznivců RDF, v srpnu 2002 publikoval verzi RSS 2.0. V roce
2003 byla převedena autorská práva na specifikaci RSS 2.0 <http://blogs.law.
harvard.edu/tech/rss> na Harvard University, která ji znovu vydala pod licencí Creative Commons license.
Zmatek ve verzích pochopitelně komplikuje život poskytovatelům informací.
Nezbývá jim, než si pro své kanály vybrat jednu nebo více verzí. Někteří poskytovatelé obsahu pak neváhají oznámit světu, že jejich kanál je to pravé, platné RSS.
Při pohledu na specifikace verzí RSS z Winerovy dílny je poměrně zřetelné, že se
nejedná o nijak podrobné a formální dokumenty. Jejich kvalita má navíc sestupnou
tendenci. Popis verze 2.0 je už spíše než specifikací pouhým esejem. RSS 0.9x a 2.0
je velmi intuitivní, jména elementů a atributů dostatečně vysvětlují jejich význam.
Pokud se podíváte na jeden, dva dokumenty, víte všechno, co byste zjistili čtením
specifikace. Bohužel, „okrajové“ případy, jako je zahrnutí HTML, nikdo neřeší. Důsledkem tohoto přístupu je, že nemalá část kanálů RSS (podle některých odhadů
kolem 20 %) neobsahuje správně zformované XML. Zdá se, že RSS často přitahuje
14
méně technicky orientované autory, pro které je obsah důležitější než jeho forma.
Přímo se nabízí srovnání s HTML, at’ už jde o intuitivní samo popisné elementy a
atributy, nebo ležérní přístup k formálním specifikacím.
RSS 1.0 <http://web.resource.org/rss/1.0/> používá jiný, formálnější
přístup k tvorbě RSS kanálu. Verzi 1.0 můžeme také považovat za jednu z mála již
dnes fungujících součástí sémantického webu. Nevýhodou této varianty RSS je horší
čitelnost zdrojových dokumentů a ne zcela intuitivní datový model RDF. RSS 1.0 se
opravdu podstatně liší od RSS 0.9x a není příliš divu, že je pro zastánce původní
linie těžko přijatelné. Ke zpracování rozšiřitelných dokumentů v RDF/XML lze bez
problémů použít nejen parsery XML, ale také software pro RDF. Velmi známým
rozšířením je Dublin Core Modul. Dublin Core je sada metadat vyvinutá knihovníky
a odborníky na informační technologie. Standardizuje obecná metadata použitelná
pro popis dokumentů. Používá jmenný prostor dc.
3.2.2
Atom
RSS 1.0 a 0.9x, 2.0 jsou neformálními specifikacemi, které nejsou publikovány žádnou známou a uznávanou standardizační autoritou nebo průmyslovým konsorciem, ale místo toho malou skupinou lidí. Někteří lidé jsou tím znepokojeni, protože
taková specifikace může být změněna podle chuti autorů. Standardizační autority
přináší stabilitu díky limitování změn a také tím, že mají zavedenou praxi zavádění
změn. Pro zavedení takovéto stability na poli syndikace obsahu byla ustavena IETF
pracovní skupina.
Atom je funkčně obdobný oběma větvím RSS, je také postaven na XML. Při jeho
koncepci byly využity zkušenosti z několikaleté praxe, stal se technicky kvalitním a
dobře definovaným standardem, jehož dodržování by se dříve nebo později mohlo
stát dobrým zvykem. Obecně není dosud tak široce podporován jako RSS 1.0 nebo
2.0, protože je příliš mladý. V červenci 2005 bylo schváleno doporučení Atom 1.0
<http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html>.
Počítá se ovšem s velkým rozšířením, především na serverech podporující standardizovaná řešení. Příkladem může být společnost Google a její portál Blogger.com a
Gmail.com.
3.2.3
Srovnání
Srovnání verzí RSS
V tabulce [3.1] je podrobněji rozepsáno zastoupení jednotlivých verzí, majoritní jazyk syndikace obsahu je angličtina s 82,8% následovaná němčinou s 7,9% 1 .
1.
Data byla převzata z <http://www.syndic8.com/stats.php>
15
VERZE
0.91
0.92
1.0
2.0
POČET
12,716
1,463
16,918
64,832
PROCENT
13,247%
1,524%
17,625%
67,541%
Tabulka 3.1: Verze RSS a jejich počty
Srovnání RSS 2.0 a Atom
Specifikace Specifikace RSS 2.0 je vlastněna Harvard University a je uzavřená.
Žádné významné změny nemohou být provedeny, je zamýšleno použít jiné jméno
pro další rozšíření.
Specifikace Atom 1.0 reprezentuje shodu skupiny Atompub Working Group s IETF.
Specifikace je koncipovaná tak, aby IETF mohla myslitelně vydat další verze a revize
této specifikace bez nutnosti ovlivňovaní existujících, i když není vyjádřený žádný
závazek nebo spíše žádný požadavek takto postupovat.
Protokoly publikování U RSS jsou široce používány dva protokoly, MetaWeblog
a Blogger. Je ovšem mnoho zpráv o problémech při vzájemné součinnosti a nedostatcích ve funkcích.
Pracovní skupina Atompub vyvíjí Atom Publishing Protocol, který je silně svázán s formátem Atom a je postaven na zkušenostech se stávajícími protokoly.
Požadovaný obsah RSS 2.0 požaduje titulek, odkaz a popis.
Atom 1.0 požaduje titulek, unikátní identifikátor a časovou známku poslední
aktualizace.
Užitná hodnota RSS 2.0 může obsahovat čistý text nebo HTML kód s řídícími znaky <>"& převedenými na odpovídající HTML entity – tedy např. < na <,
ovšem bez možnosti identifikace, který způsob je použit. Takový HTML kód je zdrojem potíží pro programátory. RSS 2.0 nemůže fakticky obsahovat správně strukturované XML značky, což redukuje možnost znovupoužití obsahu.
Atom je v tomto směru daleko lépe navržen. Obsah může být označen jako jeden
z těchto:
•
čistý text, bez značkování,
•
HTML kód s řídícími znaky převedenými na odpovídající HTML entity, jako
v RSS 2.0,
16
•
správně strukturované, zobrazitelné XHTML,
•
jakékoli jiné XML značky,
•
zakódovaný binární obsah (base64),
•
ukazatel na obsah na webu.
Úplný nebo částečný obsah RSS 2.0 má element „description“, který obyčejně
obsahuje celý obsah nebo souhrn, občas ovšem chybí. Není zabudován způsob jak
tuto situaci rozlišit.
Atom má oddělené elementy „summary“ a „content“. Summary je podporován
kvůli přístupnosti pokud je obsah netextový (např. audio) nebo nelokální (např.
ukazatel do webu).
Rozšiřitelnost RSS 2.0 nepoužívá jmenný prostor XML, ale může obsahovat
elementy z jiných jmenných prostorů. Neexistuje žádné centrální místo, kde by se
uživatel mohl dozvědět o možných rozšířeních.
Atom 1.0 používá jmenné prostory XML. Existují i specifická vodítka jak interpretovat elementy rozšíření.
Digitální podpis, šifrování RSS 2.0 může být zašifrováno nebo podepsáno
jako jakýkoli jiný webový obsah.
Atom 1.0 zahrnuje pravidla pro aplikování standardů XML Encryption a XML
Digital Signature. Samozřejmě může být zašifrován stejně jako RSS 2.0, jako „pytel“
bitů.
Kategorie RSS 2.0 kategorie mají dvě části: label a domain.
Atom 1.0 kategorie mají tři části, přidávají nepovinný, lidsky čitelný element
title.
Schéma Specifikace RSS 2.0 neobsahuje žádné schéma.
Atom 1.0 obsahuje RelaxNG schéma, pro podporu těch, kteří chtějí ověřit platnost dat. Ostatní formáty jako XMLSchema mohou být z RelaxNG vygenerovány.
17
3.3. VYUŽITÍ SYNDIKACE OBSAHU
3.3
Využití syndikace obsahu
3.3.1
Vyhledávání a spojování zdrojů
Možnost, která se ihned nabízí je vyhledávání a indexování RSS kanálů. V tomto
směru bylo již podniknuto několik kroků, příkladem mohou být vyhledávače Plazoo <http://www.plazoo.com/>, Feedster <http://www.feedster.com> a
obecně známý Yahoo! <http://www.yahoo.com>. První dva výše zmíněné umožňují zaregistrovat se k odběru všech indexovaných dat splňující uživatelem zadaná
kritéria. Je to další krok pro uživatele k zjednodušení získání informací z určité oblasti. Další významnou výhodou těchto vyhledávačů je fakt, že indexují data velmi
rychle poté, co byla zveřejněna na internetu. To je dáno jejich zaměřením na indexaci
webových blogů a zpravodajských serverů.
3.3.2
Šířené audio a video souborů
Prvním známým způsobem využití syndikace obsahu k šíření souborů byl podcasting (slovo vzniklo spojením názvu populárního přehrávače iPod firmy Apple
a anglickým slovem broadcasting) Je to nová metoda šíření informací, vynalezená
Adamem Curry v roce 2004. Jeho podstatou jsou audio soubory tzv. podcasty, jež si
můžeme představit jako audio blogy.
Podcast lze snadno stáhnout na počítač a poslouchat kdykoli bez připojení k internetu. Na webových stránkách jsou „podcasty“ uložené v uzpůsobeném RSS souboru. Ten pak specializovaný program průběžně monitoruje a nové soubory sám
stahuje a nahrává do uživatelova osobního přehrávače. Podcast tedy funguje velmi
jednoduše a bez omezení hardware. V zásadě jde jen o to, že kdokoliv, kdo chce
takto vysílat, vytvoří libovolný MP3 soubor a odkaz na něj uloží do RSS.
Podcasting je prvním krokem v tomto směru, dále bude následovat šíření video
souborů, integrace do sítí pro sdílení (často nelegálního) obsahu.
3.3.3
Získávání informací z portálů
Z principu syndikace obsahu je patrná možnost využití i u specializovaných portálů. Pro každou oblast mohou definovat kanál, na kterém budou uveřejňovat informace o nových publikacích, článcích. Celý proces se dá zautomatizovat, takže technicky by nebylo složité publikování tímto způsobem. Zatím však žádný z mnou testovaných portálů přístupných pro MU tuto možnost nenabízí. Doufám, že v brzké
době některý z nich tuto funkcionalitu implementuje.
18
Kapitola 4
Webové služby
Webové služby (Web Services – WS) poskytují prostředky pro spolupráci mezi různými aplikacemi, jenž mohou být provozovány na odlišných platformách v sít’ovém
prostředí. WS představují v podstatě distribuovanou technologii, jakými jsou například RPC <http://www.xmlrpc.com/spec> a CORBA <http://www.omg.
org/technology/documents/corba_spec_catalog.htm>. Architektura webových služeb nespecifikuje, jakým způsobem jsou implementovány, ani neurčuje způsob jejich provázání. Účel WS je vykonání určité služby poskytovatelem (provider),
jenž poskytuje příslušného agenta implementujícího danou službu a umožňuje tak
žadateli (requester) tuto službu využívat.
Technologie webových služeb není ve světě počítačové vědy revolucí, ale evolucí starých koncepcí vývoje software na bázi komponent. Úsilí o zvýšení efektivnosti programování vedlo v 80. letech minulého století ke vzniku objektově orientovaného programování. Definování a opakované využívání objektů a využívání
tříd postupně pronikalo do všech programovacích jazyků, vývojových prostředí a
technologií, někde ve větší, jinde v menší míře. Nejdříve se využívaly knihovny
tříd, později dynamicky připojené knihovny. V první polovině 90. let tento vývoj
vyvrcholil tvorbou a využíváním komponentů – objektů COM (Component Object
Model). Ve druhé polovině 90. let se v podobě DCOM (distributed COM) podařilo
překročit hranici jednoho počítače, čímž byla vytvořena možnost, aby program běžící na jednom počítači v sít’ovém prostředí využíval třídy umístěné na jiném počítači. Webové služby jsou pokračováním této expanze za hranice počítače, umožňují
překročení hranice jedné platformy, programovacího jazyka a dokonce i sít’ového
protokolu.
Webové služby představují posun od velkých monolitních struktur aplikací k modelu založenému na komponentech. Aplikace jsou v rámci tohoto modelu sestavené
z malých stavebních prvků – jednotlivých funkcí. Pokud jsou tyto funkce umístěné
na různých internetových serverech, označují se jako webové služby. Takto sestavené aplikace je možné snadno vytvořit, dynamicky modifikovat a měnit. Obrázek
4.1 ilustruje implementační nezávislost jednotlivých komponent. Byl převzat z dokumentu [16]
Webový model programování byl přijat mnohem rychleji a v podstatně širším
19
4. W EBOVÉ SLUŽBY
Obrázek 4.1: Nezávislost platforem
rozsahu, než jakýkoli jiný přístup k tvorbě distribuovaných aplikací. Fenomenální
úspěch webového modelu je možné přisoudit jedné z jeho klíčových charakteristik, je totiž mnohem volněji vázaný než tradiční modely distribuovaného programování. Interakce mezi webovým klientem a serverem je jednoduchá: navzájem si
vyměňují zprávy, které obsahují údaje typu MIME <http://www.mhonarc.org/
~ehood/MIME/> (Multipurpose Internet Mail Extensions). Sémantika zprávy může
být modifikovaná pomocí hlavičky nebo hlaviček (headers). Destinace (cíl) zprávy
je specifikovaná nepřímo pomocí URL (Uniform Resource Locator). Tato úroveň indirekce může být využita k implementaci vyvážení zatížení (load balancing) a sledování spojení (session tracking).
Způsob výměny zpráv mezi agenty žadatele a poskytovatele je dokumentován
v popisu webové služby (Web Service Description - WSD). WSD formálně popisuje
rozhraní WS pomocí jazyka WSDL (Web Service Description Language). WSDL tedy
slouží k popisu formátu zpráv, datových typů, přenosového protokolu, specifikaci
URL poskytovatelova agenta a jména služby. WSDL popisuje i chování služby, a
to především odpověd’ na zprávu zaslanou této službě. V podstatě jde o dohodu
mezi žadatelem a poskytovatelem určující záměr a výsledek interakce. Agenti žadatele a poskytovatele mezi sebou komunikují prostřednictvím zpráv. Nejčastěji je
použit protokol SOAP (Simple Object Access Protocol), který je založen na XML. Požadavek také může být specifikován jako požadavek HTTP GET. V tomto případě,
ale není možné využít rozšířených funkcí webových služeb. Samotné zprávy protokolu SOAP mohou být přenášeny pomocí protokolu HTTP, nebo i jiných protokolů,
jako například SMTP a FTP. Třetí významnou součástí webových služeb je seznam
webových služeb UDDI (Universal Description, Discovery and Integration).
20
4.1. WSDL
4.1
WSDL
WSDL (Web Services Description Language) <http://www.w3.org/TR/wsdl>
je XML struktura popisující sít’ové služby jako soustavu koncových bodů pracujících se zprávami obsahujícími bud’ dokumentově orientované, nebo procedurálně
orientované informace. Operace a zprávy jsou popsané abstraktně, potom se váží
na konkrétní sít’ový protokol a formát zprávy, aby vytvořily koncový bod. Související koncové body jsou spojené do abstraktních koncových bodů (služeb). WSDL je
schopný umožnit popis koncových bodů a jejich zpráv bez ohledu na formáty zpráv
nebo sít’ové protokoly, pomocí kterých se komunikace uskutečňuje. V současnosti
je reálné použití WSDL ve spojení se SOAP 1.1, HTTP (HyperText Transfer Protocol)
GET/POST a MIME (Multipurpose Internet Mail Extensions).
WSDL vzniklo jako společná iniciativa firem Microsoft a IBM, které si uvědomily potřebu sjednocení jazyka používaného pro popis rozhraní webových služeb.
Navazuje tak na předchozí aktivity, zejména na jazyky NASSL (Network Accessable
Service Specification Language), SCL (SOAP Contract Language) a SDL (Service Description Language). WSDL je v současné době vydán jako informativní poznámka
W3C a v rámci pracovní skupiny pro popis webových služeb se pracuje na vytvoření skutečného standardu.
4.2
SOAP
SOAP (Simple Object Access Protocol) <http://www.w3.org/TR/soap/> je protokol určený k výměně informací v decentralizovaném distribuovaném prostředí. Je
to protokol založený na standardu XML a skládá se ze tří částí: z obálky, která definuje strukturu popisující, co je ve zprávě a jak se má zpráva zpracovat, ze souboru
pravidel kódování vyjadřujících instance (výskyt) údajových typů charakteristických pro určitou aplikaci a z konvence pro reprezentaci vzdáleného volání procedur
a odpovědí. SOAP může být používaný teoreticky v kombinaci s libovolnými protokoly. V současnosti je reálné použití SOAP ve spojení s protokolem HTTP a se
systémem rozšíření HTTP.
První verze (1.0) protokolu SOAP vznikla na konci roku 1999 jako výsledek společné práce firem DevelopMentor, Microsoft a UserLand, které chtěly vytvořit protokol pro vzdálené volání procedur (RPC) založený na XML. Protokol navazoval na
o rok mladší, jednodušší a méně flexibilní protokol XML-RPC. V průběhu roku 2000
se k podpoře přihlásila i firma IBM a nová verze protokolu SOAP 1.1 byla zaslána
W3C konsorciu. Verze 1.1 protokolu SOAP je dnes nejpoužívanější, na půdě W3C
konsorcia bylo v červnu 2003 schváleno SOAP verze 1.2 jako doporučení.
Princip volání metod vzdálených objektů s využitím protokolu HTTP:
1. Klient SOAP (nemusí to být tradiční klient, může se jednat o web server,
21
4.3. UDDI
webovou aplikaci, ale také součást desktopu) vytváří dokument XML s údaji
pro vzdálené volání metody objektu na externím systému. Vytvoří požadavek na server SOAP, zabalí XML dokument do obálky SOAP a vysílá ho jako
požadavek HTTP POST.
2. Celá obálka je odeslaná klasickým připojením protokolu HTTP.
3. Příjmová aplikace, server SOAP, dostane zprávu. Touto aplikací je obyčejně
web server, který analyzuje došlou obálku, zavolá příslušný objekt a odevzdá
mu přitom potřebné parametry, které přišly v dokumentu SOAP.
4. Objekt vykoná požadovanou operaci a vrátí získanou informaci serveru SOAP.
Server SOAP zabalí odpověd’ do obálky SOAP.
5. Obálka je odeslaná zpět do počítače, odkud přišel požadavek. SOAP dokument je uschovaný pod hlavičkou HTTP.
6. Klient SOAP čeká na odpověd’ objektu. Když přijde, klient odstraní obálku a
odešle dokument té aplikaci, která ho potřebuje.
4.3
UDDI
UDDI (Universal Description, Discovery and Integration) <http://xml.coverpages.
org/uddi.html> je veřejný registr určený na strukturované uchování informace
o firmách a jejich službách. Prostřednictvím UDDI je možné publikovat a zjišt’ovat informace o technickém rozhraní služeb firmy. Prostřednictvím série XML API
(Application Programming Interface) volání na bázi SOAP je možné být v interakci
s UDDI jak v čase návrhu, tak i během uskutečňování aplikace za účelem získání
technických údajů, aby tyto webové služby mohly být vyvolané a využité. UDDI
takto slouží jako infrastruktura softwarového prostředí založeného na webových
službách.
UDDI je konstruovaný jako registr, ne jako sklad. Registr odesílá (přesměruje)
uživatele ke zdroji, zatímco sklad představuje aktuální zdroj informací. Samotný
registr pracuje rovněž jako webová služba a komunikace s ní tedy opět probíhá pomocí protokolu SOAP.
UDDI je provozováno na uzlech, přičemž pro koncového uživatele je lhostejné,
který uzel pro vyhledávání použije. Uzly totiž replikují data, takže přidáním informace o nějaké službě na jeden uzel, se tato informace zanedlouho objeví i na ostatních uzlech. Např. uzel od firmy Microsoft je na adrese <http://uddi.microsoft.
com> a od IBM na <https://uddi.ibm.com/ubr>.
22
4.4. VYUŽITÍ WEBOVÝCH SLUŽEB
UDDI má tři části: jedna uvádí kontaktní informace o firmě, která vytvořila danou webovou službu, druhá je tvořená jednotlivými webovými službami rozdělenými do kategorií, například podle geografického umístění nebo odvětví průmyslu,
a třetí část obsahuje popis WSDL, business pravidla a instrukce, jak tuto službu používat.
4.4
Využití webových služeb
Aplikacemi využívajícími webové služby mohou být jiné webové služby, ale i klientské aplikace. Na straně klientů to mohou být standardní osobní počítače, ale také
zařízení typu PDA (personal digital assistants) nebo mobilní telefony. Pro programátora je způsob jejich využívání velmi blízký využívání tříd.
Webové služby je možné spolu s dalšími komponenty vyhledávat v registrech a
vytvořit z nich aplikace. Spojování webových služeb však vyžaduje něco více, než
pouze konektivitu – účelné je propojit je inteligentně, to znamená tak, aby výsledná
sít’ webových služeb fungovala v rámci procesních a obchodních pravidel. Ten, kdo
tuto sít’ tvoří, je IT manažer nebo obchodní analytik zaměřený spíše na obchodní
procesy než na (složité) programování. Využívá k tomu nástroje ke znázornění obchodního procesu a formulaci nezbytné procesní logiky bez toho, že by musel psát
nějaký kód.
Webové služby přinášejí nové možnosti pro vytváření rozsáhlých podnikových
systémů. Díky použití XML umožňují jednotnou komunikaci mezi různými platformami a lze tak vytvářet distribuované systémy, které využívají služeb poskytovaných jinými aplikacemi. Možnosti této technologie jsou obrovské a závisí pouze
na tom, jak se bude tato technologie využívat při implementaci systémů. Důležitým
faktorem při používání webových služeb je jejich dostupnost a bezpečnost.
Webové služby lze také využít pro získávání informací z portálů, které by tímto
způsobem mohly poskytovat metadata o článcích a publikacích, případně jejich
elektronické verze. Vše by šlo zabezpečit oproti IP adresám, případně autentizací
pomocí jména a hesla nebo s využitím nějakého vygenerovaného klíče. Zatím však
žádný z mnou prověřovaných portálů přístupných pro MU tuto možnost nenabízí.
Doufám, že v brzké době některý z nich tuto funkcionalitu implementuje a přispěje
tak k lepší dostupnosti shromážděných informací.
23
Kapitola 5
Srovnání způsobů vyhledávání informací
V této části bych chtěl představit studii společnosti Ridge Group, rozebrat výhody
specializovaných portálů a zmínit ty, ke kterým má Masarykova univerzita přístup.
5.1
Studie společnosti Ridge Group
Ridge Group byla založena v roce 1998 s cílem poskytovat konzultace k technologiím, vývoji softwaru, instalaci softwarových produktů a podporu produktů. Zaměřuje se na kombinování technologií a obchodních procesů, technologie na internetu
a na CRM (Customer Relationship Management) software. Ridge Group dále provádí hodnocení investic do rizikových firem. Specializuje se především na americký
trh, domovské stránky jsou <http://ridge-group.com/>
Podle výzkumu společnosti Ridge Group (Information gathering in the electronic age: the hidden cost of the hunt [17] ) z roku 2003 pracovník v oblasti IT stráví
kolem 7 hodin týdně, tj. 28 hodin měsíčně vyhledáváním informací, odpovědí a řešení technických problémů. Častější jsou kratší úkoly, jejichž frekvence je ovšem také
vyšší, takže zabírají celkově více času než problémy složitějšího rázu, kterých není
v průměru mnoho. Studie dochází k závěru, že čas strávený vyhledáváním informací znamená pro podnik s 500 profesionálními pracovníky výdaje v řádu sto tisíc
až několika miliónů dolarů ročně.
Vyhledávání informací je nedílnou součástí činností každého, kdo působí v oblasti technologií, přesto hodně záleží na efektivitě vyhledávání. Internetu dnes obsahuje příliš mnoho informací a ne všechny jsou správné, přesné nebo relevantní,
takže používání klasických vyhledávačů může být zdlouhavé. Volba správného zdroje
a ještě více volba vhodného dotazu či klíčového slova nebo pojmu pro vyhledávání
je dnes podobné umění jako rychlá orientace v mnoha zdrojích nabízejících odpovědi na dotaz. Vytřídění zdrojů podle spolehlivosti si vyžaduje od internetového
uživatele určitou zkušenost.
Vyhledávání v knihách také nepatří mezi rychlé a vždy účinné metody, knihovna
něco stojí a informace v nich rychle zastarávají a i v době vydání jsou minimálně 6–
10 měsíců staré (podle toho, jak dlouho trvá jejich výroba od odevzdání rukopisu).
Stále populárnější jsou knihy dostupné on-line, které stojí jen zlomek ceny tištěných
24
5.2. SROVNÁNÍ P ŘÍSTUP Ů K INFORMACÍM
publikací, je k nim neomezený přístup s dobrými vyhledávacími možnostmi, ale
stále platí, že získané informace nemusí být zcela aktuální a bude nutné je ověřit
jinde. Dotazování se kolegů patří také mezi častý způsob, jak získat odpovědi na
otázky, ale může být zdlouhavý a nemusí ani vést ke spolehlivým odpovědím.
Proto roste požadavek na prostředky managementu informací, z čehož plynou
zisky poskytovatelům databází. Ti dnes musí provádět pečlivou filtraci informací
pro jednotlivé klienty a vyvíjet stále více sofistikovanější interaktivní nápovědu a
znalostní báze.
5.2
Srovnání přístupů k informacím
Rychlost vyhledávání a kvalita získaných informací nejsou v žádné pevné korelaci.
Obrázek 5.1 naznačuje relaci mezi přesností obdržených informací a rychlostí jejich
získání pro různé typy zdrojů. ERL je zkratka pro Electronic Reference Library, tedy
elektronickou knihovnu, portál. Data pro obrázek byla převzata z dokumentu [17].
Obrázek 5.1: Vztah přesnosti obdržených informací a rychlosti jejich získání u jednotlivých zdrojů
Rychlejší přístup k lepším informacím přináší rychlejší implementaci. Podle výše
25
5.3. ELEKTRONICKÉ KNIHOVNY A PORTÁLY
zmíněné studie více jak 95% techniků a programátorů hledá řešení problému na
internetu, okolo 20% ještě dále použije knihu nebo se poradí s kolegou.
5.3
Elektronické knihovny a portály
Z obrázku 5.1 jasně vyplývá, že pro co nejrychlejší získání kvalitní informace je
vhodné si objednat odběr dat z nějaké elektronické knihovny. Obzvláště vhodné
to může být pro větší organizace s technickým zaměřením, kterým poplatek za využívání zdroje výrazně nezvýší výdaje. Zefektivní to především její činnost, protože
zaměstnanci se budou věnovat svým úkolům a nebudou ztrácet čas vyhledáváním
informací.
Jedním z příkladů elektronické knihovny je Safari Tech Books Online <http:
//www.safaribooksonline.com>. Jedná se o knihovnu, kde mohou IT profesionálové a programátoři vyhledávat ve více jak tisícovce elektronických verzích knih
od osmnácti nakladatelství zahrnující O’Reilly, Addison-Wesley, Cisco Press, Peachpit Press, Prentice Hall, New Riders a Microsoft Press.
Podle uživatelů této služby jim Safari přináší úsporu 3,3 hodiny týdně, tedy
zhruba 13 hodin měsíčně. Tato čísla jsou publikovaná přímo společností, takže se
musí brát s určitou rezervou. Firma Sun Microsystems Inc. <http://www.sun.
com/> provedla vlastní test Safari Tech Books Online v rámci hodnocení zvýšení
produktivity jejich technických týmů při používání elektronických knihoven. Podle
jejich výsledků bylo ušetřeno průměrně 9 hodin měsíčně na jednoho zaměstnance.
Je to sice méně než u studie společnosti Ridge Group[17], ale i tak je to důležitých
108 hodin ročně na zaměstnance.
Další společností, která se podílela na testování Safari Tech Books byla America
Online <http://www.aol.com/>. Ta ovšem nezveřejnila své výsledky, ale pouze
potvrdila zlepšení vyhledávání informací u jejich zaměstnanců při použití Safari a
celkové zrychlení procesů závislých na daných informací.
Důvodem zkrácení doby hledání informací v elektronických knihovnách a portálech je fakt, že vracejí výsledky, které jsou více spjaty s informací, po které uživatel
pátrá. Google a ostatní podobné vyhledávače přináší příliš mnoho nedůležitých výsledků a v důsledku stěžují nalezení požadované informace.
Každá větší firma, organizace by měla mít přístup k nějakému elektronickému
zdroji, který vyhovuje jejímu zaměření. Masarykova univerzita není v tomto směru
výjimkou, v dodatku B jsou rozebrány jednotlivé zdroje a jejich zaměření na určitou
oblast lidského bádání.
26
Kapitola 6
Vyhledávač nad elektronickými zdroji Masarykovy univerzity
Vyhledávač má za úkol sjednotit přístup k více než čtyřiceti elektronickým zdrojům
Masarykovy univerzity a umožnit prohledávání těchto zdrojů podle tématických
oblastí z jednoho místa. Uživatel tak může vyhledávat v odborných článcích publikovaných na předplacených portálech, v bakalářských, diplomových a disertačních
pracích i v dalších elektronických publikacích. Samozřejmostí je možnost rozšířeného vyhledávání podle názvu, autora, data publikování či vydavatele. Dotazy lze
rovněž upřesnit podle oboru či zdroje.
Obrázek 6.1: Uživatelské rozhraní
Samotný vyhledávací systém se skládá z několika samostatných modulů, které
jsou realizovány jako webové služby. Jádro systému je postaveno na vícevrstvé architektuře Java 2 Enterprise Edition (J2EE). Uživatel přistupuje k systému přes tenkého klienta, který je implementován s využitím aplikačního rámce Struts. Každému elektronickému zdroji odpovídá jeden modul umožňující automatizované
získávání dat. Jednotlivé moduly pak s jádrem systému komunikují nad protokolem SOAP. Pro nasazení systému byl vybrán open source aplikační server JBoss.
Databázovou vrstvu zabezpečuje PostgreSQL.
27
6.1. SERVER
Obrázek 6.2: schéma celého systému
6.1
Server
Modul server je jádrem celého systému. Přijímá dotazy od klienta, které analyzuje
a dále přeposílá odpovídajícím modulům komunikujícím s elektronickými zdroji.
Přijaté odpovědi spolu s dotazem ukládá do databáze a postupně nabízí uživateli.
Součástí serveru je i modul pro stahování vybraných dokumentů. Server automaticky uloží první nalezený dokument do vyrovnávací paměti, čímž může uživateli
poskytnout požadovaný dokument lokálně a tedy rychleji.
6.2
Datové úložiště
Vzhledem k tomu, že odezva většiny elektronických zdrojů není zanedbatelná, vznikla
potřeba implementace určité vyrovnávací paměti vyhledávače (Cache). Ta je realizována pomocí datového úložiště, do kterého si server ukládá dopředu stažené
dokumenty. Dále pak samotné dotazy uživatelů, výsledky vyhledávání, stažené dokumenty a jejich metadat.
28
6.3. MODULY PRO KOMUNIKACI S ELEKTRONICKÝMI ZDROJI
Obrázek 6.3: Implementační diagram
6.3
Moduly pro komunikaci s elektronickými zdroji
Každý elektronický zdroj vyžaduje vlastní modul (Plugin) pro přeposílání dotazu
a následné zpracování odpovědi. Moduly jsou realizovány jako webové služby. Pro
zpracování odpovědí a jejich převedení do unifikovaných metadat využívají řadu
pomocných nástrojů, mezi které například patří – XSLT procesor Xalan, korektor
správnosti kódu HTML JTidy, analyzátor HTMLParser nebo aplikační rámec pro
zpracování XML Dom4j. Metadata jsou v rámci systému používána v souladu s doporučeními Dublin Core [9].
6.4
Tenký klient
Webové rozhraní vyhledávače je realizováno pomocí aplikačního rámce Struts. Je
dostupné ve dvou jazykových mutacích – česky a anglicky. V jednoduchém režimu
uživatel zadává pouze klíčová slova, v režimu rozšířeném má možnost vyhledávat
ve vybraných tématických oblastech nebo zdrojích. Samozřejmostí je i vyhledávání
například podle autora, názvu, data publikace či vydavatele. Dostupné elektronické
zdroje klient načítá z externího RDF souboru. V současné chvíli je toto rozhraní opti29
6.5. VÝVOJOVÝ TÝM
malizováno pro nejběžnější webové prohlížeče – Internet Explorer, Firefox, Mozilla
a Opera. V testovacím režimu i pro mobilní zařízení typu PDA.
Obrázek 6.4: Uživatelské rozhraní pro PDA
6.5
Vývojový tým
Na projektu pracují tito řešitelé:
•
Mgr. Jan Pavlovič – vedoucí projektu,
•
Bc. Jakub Ďurovec – modul server,
•
Bc. Jiří Běl – modul datové úložiště,
•
Bc. Rostislav Svoboda – moduly pro komunikaci s elektronickými zdroji,
•
Bc. Petr Klemšinský – modul PDA.
6.6
Zadání projektu
•
Analyzovat strukturu elektronických zdrojů MU.
•
Naprogramovat vyhledávací a stahovací systém, který uživateli nabídne ke
stažení relevantní publikace.
•
Systém bude realizován jako webová služba (webservice).
30
6.7. P ŘEHLED POUŽITÝCH NÁSTROJ Ů
6.7
Přehled použitých nástrojů
V této části uvádím přehled softwarových nástrojů použitých při vývoji projektu.
Nástroje jsou rozděleny podle fáze vývoje projektu, nechybí u nich krátký popis
a poznámky z praxe. U každého najdete rovněž odkaz na WWW stránky a další
zdroje informací.
6.7.1
Analýza a návrh
Magic Draw
Verzi Community edition považuji v současnosti za nejlepší volně dostupný CASE
nástroj. Napsán v jazyce Java, je velmi rychlý, přehledný, dobře se s ním pracuje.
Nabízí i funkci reengeneering, modely ukládá ve formátu XMI. Ve verzi Community
nejsou žádná omezení pro Class diagramy, ale pro ostatní typy diagramů je omezen
počet elementů použitých v jednom diagramu na 25.
Nástroj je v současnosti dostupný ve verzi 10 na stránkách MagicDraw <http:
//www.magicdraw.com/>.
6.7.2
Implementace
Netbeans
Vývojové prostředí pro Java aplikace z dílny české pobočky firmy SUN. Nabízí podporu Enterprise JavaBeans 2.1, webových služeb, refactoring, automatizované testy,
integrovaný aplikační server, připravuje se i podpora pro JBoss. Verze 4.1 a 5.0 jsou
dostupné na stránkách Netbeans <http://www.netbeans.org/>.
JDeveloper
Vývojové prostředí pro Java aplikace od firmy Oracle, v současnosti ve verzi 10
g. Nabízí podporu pro JDK 5.0, J2EE 1.4, JSF, EJB 3.0, UML, spolupráci s databází,
základní Javu a XML. Může obsahovat také ADF (Application Development Framework), tato možnost je volitelná. Aktuální verze je dostupná na stránkách Oracle
JDeveloper <http://www.oracle.com/technology/products/jdev/>.
Ant
Nástroj na sestavování aplikací z dílny The Apache Software Foundation. Velmi podobný známému Make, pouze vhodně přizpůsobený pro použití v Javě. Ekvivalentem Makefile pro Make je zde build.xml. Netbeans jej interně používají pro sesta31
vování projektů. Verze 1.6.5 je dostupná na těchto stránkách Ant <http://ant.
apache.org/>
JUnit
JUnit je programový rámec (framework) pro automatizované testování, odpovídající filosofii agilního programování. Umožňuje vývojáři otestovat funkčnost systému
ihned po jakémkoliv zásahu do zdrojového kódu. Dříve, než se začne psát zdrojový
kód nějaké metody, je vhodné pro ni napsat test. Po vytvoření zdrojového kódu metody, je pak okamžitě možné tuto funkčnost ověřit. Aktuální verze je dostupná na
stránkách JUnit <http://www.junit.org/>.
JMeter
JMeter je grafický nástroj na tvorbu zátěžových testů pro www aplikace, webové
služby, JDBC spojení, java aplikace apod. Skládá se ze tří hlavních částí:
•
Konzoly pro tvorbu testů, řízení testů a pro sběr statistických informací.
•
Dělníka, který generuje požadavky na testovaný subjekt.
•
HTTP Proxy na generování testů. Používá se pro vytvoření složitějšího testu,
simulujícího chování uživatele.
Výsledky testů se dají zobrazit v grafu i uložit ve formátu XML nebo CSV. Aktuální verze JMeter je dostupná na stránkách <http://jakarta.apache.org/
jmeter/>. Velmi dobrým zdrojem informací je kniha Martina Hynara, Java – nástroje [12].
6.7.3
Nasazení a správa
Tomcat
Open source kontejner pro servlety a JSP s prvky webového serveru. Vyvíjen jako
součást projektu Jakarta pod záštitou The Apache Software Foundation. Aktuální
verze je dostupná na stránkách projektu Jakarta <http://jakarta.apache.org/
tomcat/>.
JBoss
Výkonný, robustní a velmi rozšířený open source aplikační server. Jeho popis by vystačil na samostatnou práci. Aktuální verze je dostupná na stránkách JBoss <http:
//www.jboss.org/>.
32
6.7.4
Podpora vývoje v týmu
Maven
Maven pomáhá při řízení týmového projektu. Z jednoho místa je uživatel schopen
sestavit projekt, vytvořit zprávy, či dokumentaci, webovou stránku o stavu projektu
a další. Patří zatím bohužel k nástrojům, po kterých se v týmovém projektu sahá
teprve tehdy, když se stává téměř neudržitelným. Maven oplývá i řadou přídavných modulů, pomocí kterých jste například schopni testovat kvalitu zdrojových
kódů, spouštět testy nebo generovat pomocné třídy. Více informací je k dispozici na
stránkách Maven <http://maven.apache.org/>. Velmi dobrým zdrojem rad a
postupů je rovněž kniha Martina Hynara, Java – nástroje [12].
Subversion
Systém pro správu verzí by neměl chybět při žádném projektu vyvíjeném v týmu.
Zdrojové kódy se ukládají do společné úschovny. Z té si vývojář před započetím
práce zkopíruje aktuální stav na lokální stroj a pokračuje v programování. Po dokončení práce odešle své změny zpět do úschovny, aby byly dostupné i pro kolegy.
Případně vyřeší konflikty souborů, které mezitím změnil někdo z ostatních členů
týmu. Systém poskytuje funkce jako rozdíl mezi verzemi, vývoj více větví, popis
změn v dané verzi.
Aktuální verzi systému lze volně stáhnout na domácích stránkách <http://
subversion.tigris.org/>.
Subversion má velmi dobře zpracovanou dokumentaci, nicméně rád bych doporučil i článek na ABC Linuxu od Ondřeje Zloského <http://www.abclinuxu.
cz/clanky/show/54058>.
Wiki
Encyklopedických systémů není nikdy dost. Dají se velmi dobře využít na sdílení
poznatků mezi kolegy v týmu, rovněž tak na vystavení směrnic a pracovních postupů. Jedna z nejlepších je MediaWiki <http://www.mediawiki.org/>. Pro
projekt VEZMU existují stránky <http://kore.fi.muni.cz:5080/wiki/index.
php/Projekty:VEZMU>, na kterých je velké množství informací o dílčích řešeních
jednotlivých úkolů.
33
Kapitola 7
Problematika automatizovaného sběru informací
7.1
Obecné informace
Modul pro automatizovaný sběr dat slouží jako prostředník mezi jádrem systému a
zdrojem elektronických dat, poskytuje jednotné rozhraní pro vyhledávání nad konkrétními zdroji. Je mu zaslán unifikovaný dotaz, který zpracuje a vyhodnotí. Výsledek hledání odešle zpět serveru. Komunikace probíhá pomocí webových služeb –
protokol SOAP. Z toho plyne, že není nutné modul naprogramovat v jazyce Java,
může se použít jakýkoli, v kterém jsou implementované webové služby. Další nespornou výhodou je jejich distribuovatelnost, moduly mohou být spuštěny na více
strojích, což přináší lepší možnost rozložení zátěže aplikace. Seznam všech elektronických zdrojů Masarykovy university je na adrese <http://library.muni.
cz/e_zdroje.html>.
7.2
Specifika zdrojů
Při přípravě implementace modulu pro určitý zdroj dat se musí brát v potaz několik
faktorů, které silně ovlivňují složitost samotné implementace. Základní specifika
zdrojů jsou tyto:
•
Způsob zadání dotazu.
•
Kritéria vyhledávání.
•
Struktura odpovědi.
•
Množství a různost poskytnutých informací.
7.2.1
Způsob zadání dotazu
Nejprve se musí prozkoumat jakou metodou a v jaké formě je dotaz zasílán serveru
s elektronickými daty. Pokud se jedná o metodu GET, je tento úkol jednodušší, protože je možno získat většinu informací z URL. Při používání metody POST se musí
34
7.2. SPECIFIKA ZDROJ Ů
prozkoumat samotný zdrojový kód vyhledávací stránky. Další důležitou informací
je, jakou URL má odpověd’ na dotaz. Existují dvě možnosti: bud’to je dotaz uveden v lidsky čitelné podobě v adrese odpovědi, nebo je zaslána pouze identifikace
dotazu (většinou session, případně id vytvořené serverem) a doplňkové informace
o stránkování. Lepší varianta je samozřejmě ta první.
7.2.2
Kritéria vyhledávání
Každý zdroj umožňuje vyhledávat podle několika kritérií, která se ovšem většinou
navzájem liší. Proto se u každého zvlášt’ musí zvažovat, která podmínky jsou relevantní pro zahrnutí do implementace modulu.
Snažil jsem se prozkoumat zdroje elektronických dat a jejich rozhraní pro rozšířené vyhledávaní. Výstupem by měla být množina kritérií rozšířeného vyhledávání,
podle které je možno specifikovat své požadavky u většiny zdrojů. Při implementaci
vyhledávacích modulů je nutné vzít v úvahu tuto množinu kritérií.
Při řešení úkolu jsem se zaměřil především na stránky IEEE (<www.computer.
org>), Nature (<www.nature.com>), ACM (<http://www.acm.org/dl/>) a
Springer (<http://link.springer.de/>). V tabulce [7.1] jsou podrobněji rozepsané možnosti jednotlivých zdrojů.
Plnotextové
Název publikace
Autor
Datum publikování
ISBN/ISSN
Datum Od/Do
Abstrakt
Editor
Výsledků / strana
IEEE
X
X
X
X
X
X
–
–
X
Nature
X
X
X
–
–
X
X
–
–
ACM
X
X
X
–
X
X
X
X
X
Springer
X
X
X
–
–
X
X
–
X
Tabulka 7.1: Kritéria rozšířeného vyhledávání
Jako výslednou množinu implementovatelných kritérií vyhledávání pro moduly
jsem vybral tyto:
•
Plnotextové vyhledávání.
•
Název publikace.
•
Autor.
35
•
Datum Od/Do.
•
Abstrakt
•
Výsledků na stranu.
Pokud nějaký zdroj dat neumožňuje vyhledávání podle některého z uvedených kritérií, záleží čistě na programátorovi, jak s touto situací naloží. Je doporučeno serveru
VEZMU vrátit prázdnou odpověd’.
7.2.3
Struktura odpovědi
Strukturou odpovědi je myšlena kvalita zdrojového kódu a množství klíčových prvků
ve stránce pro snazší vyhledání potřebných informací. Pokud je odpověd’ v XHTML,
případně splňuje nějaké schéma, lze pro získání potřebných informací použít XSLT
transformaci. V opačném případě je nutno procházet zdrojový dokument a vyhledávat klíčové řetězce, což je velice pracné a také méně elegantní než XSLT transformace.
7.2.4
Množství a různost poskytnutých informací
Informace poskytnuté v odpovědi na dotaz se liší zdroj od zdroje. Některé zašlou
potřebná data hned v odpovědi, jiné poskytnou na ně odkazy, stává se však také, že
potřebné informace nelze dohledat. Zdroje by měly být schopny poskytnout informace jako název článku, jméno autora, abstrakt, datum publikování, číslo strany a
odkaz na článek.
7.2.5
Co by měl modul umět
V následujícím obrázku 7.1 jsou zachyceny základní případy užití modulu pro automatizovaný sběr dat.
36
Obrázek 7.1: Diagram případů užití
37
Kapitola 8
Implementace modulů
Doposud byly implementovány moduly pro portály IEEE (<http://www.computer.
org>), Nature (<http://www.nature.com>), ACM (<http://www.acm.org/
dl/>) a Springer LINK (<http://www.springerlink.com/>). Jako hlavní programovací jazyk je zvolena Java. Autorům dalších modulů velice doporučuji knihy
Java efektivně, 57 zásad softwarového experta [3] od J. Blocha a Java: programujeme
profesionálně [?], jejím autorem je Brett Spell.
Obrázek 8.1: Diagram aktivit
Obrázek 8.2: Diagram aktivit – pokračování
38
8.1. VYTVO ŘENÍ POŽADAVKU NA ZDROJ
Obrázek 8.3: Sekvenční diagram
8.1
Vytvoření požadavku na zdroj
Modul, běžící jako webová služba, dostane od serveru VEZMU požadavek. V Javě
se předá objekt Query. Z toho se získají všechny potřebné informace nutné pro sestavení dotazu, jako např. dotaz na vyhledávání v celém textu, jméno autora, název
díla. Samotné sestavení požadavku je specifické pro každý zdroj, protože se musí
zohlednit způsob zadávání dotazu. Nejjednodušší varianta je, pokud jsou data serveru zasílána metodou GET v lidsky dobře čitelné formě.
8.2
Transformace odpovědi do XHTML
Z odpovědi zdroje na dotaz od modulu je potřeba získat relevantní informace, které
se dále přepošlou serveru VEZMU. Jednou z možných cest je data postupně procházet a vyhledávat v nich klíčové řetězce. Tento postup je velice pracný a časově náročný. Nese s sebou další nevýhodu, a tou je nárůst velikosti zdrojového kódu modulu. S tím souvisí větší pravděpodobnost výskytu chyby, horší orientace v kódu,
problémy s jeho udržitelností a vyšší nároky na programátora.
Existuje však elegantnější cesta a tou je transformace odpovědi do XML a její
další zpracování pomocí XSLT stylu. Tuto transformaci lze aplikovat pouze u některých zdrojů dat, jejichž odpověd’ je bud’ ve formátu XHTML nebo ji lze do něj
lehce převést. V opačném případě se musí postupovat výše zmíněným návodem.
39
8.3. XSLT TRANSFORMACE
Pro samotnou transformaci jsem vyzkoušel několik javových balíků, využíval jsem
i části projektů, které byly vystaveny na webu. Výsledek byl často nevyhovující, někdy se vůbec nedostavil. Po dlouhém hledání a testování jsem našel dva projekty,
které vyhovovaly mým potřebám.
První z dvojice je HTMLParser, adresa projektu je <http://www.htmlparser.
org>. Jak název napovídá, jedná se analyzátor HTML kódu. Tento balík je spíše
vhodný pro případ nekvalitního kódu odpovědi. Umožňuje extrakci textu, odkazů,
obrázků, kontrolu odkazů, přepis URL, ukládání stránek a mnoho dalších věcí.
Druhým projektem je JTidy, adresa domácí stránky je <http://jtidy.sourceforge.
net>. Jedná se o port programu HTML Tidy <http://www.w3.org/People/
Raggett/tidy/> konsorcia W3C. Primárním úkolem je kontrola syntaxe a formátování zdrojového kódu. Stejně jako jeho vzor, JTidy může být použit pro opravování poškozených a chybných HTML. Tento balík se používá pro transformaci
výsledku vyhledávání do XHTML. Nejprve se musí vytvořit nová instance objektu
Tidy, poté je nutné nastavit transformaci do XHTML pomocí metody setXHTML(true).
Dále je vhodné potlačit vypisování různých varování a doporučení, protože JTidy
podává velké množství informací a zbytečně by zaplňovalo soubor se záznamy
o činnosti. Nakonec se zavolá metoda parse(), která má dva parametry: InputStream
a OutputStream. Tímto je převod do XHTML hotov.
U transformace odpovědi do XHTML je možno přemýšlet o potencionálním
zrychlení této fáze. Bylo by ovšem nutné nalézt balík s možností převodu HTML
do XHTML, ale žádný další dosahující kvalit JTidy jsem bohužel nenašel. V úvahu
přichází pouze analyzátory kódu, u kterých by se musela struktura dokumentu procházet ručně, což není v žádném případě rychlé a ani efektivní.
8.3
XSLT transformace
V předchozí části bylo ukázáno jak převést odpověd’ do XHTML. Dalším krokem
je získat potřebné informace. K tomu poslouží XSLT transformace. Nejprve se musí
vytvořit XSLT styl. Jeho složitost je silně ovlivněná členitostí zdrojového kódu odpovědi. Nejlepší cesta je nalézt význačné, případně unikátní elementy a pomocí nich
adresovat hledané informace. Tvorba stylu je časově náročná, musí se provádět pro
každý zdroj. Velmi bych doporučil knihy XSLT – Příručka internetového vývojáře
[11] a XML Bible [13].
Dále je nutné vybrat některý z nástrojů pro zpracování XML. Nejpoužívanějšími
jsou Saxon a Xalan. Více informací o nich lze nalézt na domovských stránkách projektů <http://saxon.sourceforge.net/> a <http://xml.apache.org/xalan-j/>.
Jejich volání z programů napsaných v jazyce Java je dobře popsané v dokumentaci,
proto se tu o něm nebudu zmiňovat. Výstup transformace by měl být obdobný jako
v příkladu 8.3.1. Specifická data pro určitý zdroj mají ve svém názvu jako prefix
40
název zdroje, např. IEEE_More_abstract_link.
<?xml version="1.0" encoding="ISO-8859-2"?>
<document><clanek>
<Title>
Automating Experiments Using Semantic Data on a Bioinformatics Grid
</Title>
<Creators>
Chris Wroe, Carole Goble, Mark Greenwood, Phillip Lord,
Simon Miles, Juri Papay, Terry Payne, Luc Moreau
</Creators>
<Date>January 2004</Date>
<Page>48-55</Page>
<Abstract>
myGrid assists bioinformaticians in designing and executing
in silico experiments using the Grid’s resources. In myGrid,
much of this experimental design has been encoded as workflows...
</Abstract>
<IEEE_Whole_document>
IEEE Intelligent Systems
</IEEE_Whole_document>
<IEEE_Whole_document_link>
http://www.computer.org/intelligent/
</IEEE_Whole_document_link>
<IEEE_Pdf>
http://csdl.computer.org/dl/mags/ex/2004/01/x1048.pdf
</IEEE_Pdf>
<IEEE_Html>
http://csdl.computer.org/dl/mags/ex/2004/01/x1048.htm
</IEEE_Html>
</clanek></document>
Pøíklad 8.3.1: XML data po transformaci
8.3.1
Možnosti zrychlení transformace
Velmi zajímavým problémem je možnost zrychlení této fáze. Předně musí být efektivně napsán XSLT styl, což klade na autora netriviální požadavky. Měly by se používat osy předek, následník a sourozenec pro adresování blízkých elementů. Nevhodné je absolutní adresování každého elementu od kořene, protože se vždy musí
procházet celý strom elementů. Obecně je tedy vhodnější globálně adresovat jeden
41
základní element a od něj nalézt lokální vazby k dalším elementům, většinou následníkům nebo sourozencům.
Dalšího zrychlení je možno dosáhnout na straně samotného transformačního
procesoru. Každý procesor se liší v implementaci, z toho plyne i různá rychlost prováděných transformací. Vliv má také způsob tvorby transformačního objektu, zda
je XSLT styl předkompilován do objektu Template nebo použit jednorázově. Není
možné ihned říci, který transformační balík a jaký způsob konstrukce transformačního objektu je nejrychlejší. Bylo tedy nutné provést testování rychlosti transformace.
8.3.2
Testování rychlosti transformace
Cílem testování bylo transformovat data ve formátu XHTML do zjednodušeného
XML formátu. Data byla uložena na lokálním souborovém systému pro eliminaci
možných zpoždění při načítání ze sítě. Jednalo se o výsledek hledání ze stránek
<http://www.computer.org> společnosti IEEE s omezením 50 nalezených odkazů na stránku. XSLT šablona byla taktéž uložena na lokálním souborovém systému. Více informací o hardwarové stránce testu je v sekci 8.3.3.
Prověrkou prošly dva nejrozšířenější balíky nástrojů pro zpracování a transformování XML v Javě, Saxon (ve verzi 8.2) a Xalan (ve verzi 2.6.0). Xalan implementuje také technologii XSLTC1 , k transformaci se nepoužívají přímo XSLT styly, ale
zkompilované třídy těchto stylů. Důsledkem by mělo být zrychlení transformací.
Vytvořit archiv IEEEstyl.jar, ve kterém bude třída cz.muni.fi.vezmu.styles.IEEEstyl
obsahující prědkompilovaný styl se dá například tímto příkazem:
java org.apache.xalan.xsltc.cmdline.Compile -j IEEEstyl.jar
-p cz.muni.fi.vezmu.styles IEEEstyl.xsl
K otestování byly vybrány čtyři různé druhy transformací:
•
Saxon s přímým voláním XSLT stylu.
•
Xalan s přímým voláním XSLT stylu (v obrázcích označováno jako XalanNoTranslet).
•
Xalan s použitím technologie XSLTC, kompilování stylu za běhu (XalanTransletOnlineCompilation).
•
Xalan s použitím technologie XSLTC, styl již předkompilován (XalanTransletCompiled).
1. Více informací je možné získat na adrese <http://xml.apache.org/xalan-j/xsltc_
usage.html>.
42
Každá transformace se prováděla 100krát. V těle testovací metody se zaznamenal
čas začátku a konce transformace, na standardní výstup se poté vypsal jejich rozdíl
v milisekundách. Nakonec se vypočítal průměrný čas. Vítězem se podle očekávání
stal Xalan s předkompilovaným XSLT style, následován Saxonem. Výsledky jsou
vidět na obrázcích 8.4. a 8.5, časy jsou uvedeny v milisekundách.
Obrázek 8.4: Tabulka rychlosti transformace
Obrázek 8.5: Graf tabulky rychlosti transformace
8.3.3
Hardware použitý pro testy
Využity byly 3 stroje:
1. Prvním strojem je můj postarší stolní počítač (steve_old).
CPU: Intel Pentium IITM 266MHz (sběrnice jen na 66MHz)
Pamět’: 64 MB
43
8.4. TVORBA ODPOV ĚDI
HDD: 3,2 GB UDMA
2. Druhým strojem je můj nový stolní počítač (steve_new).
CPU: Intel Pentium CeleronTM 2GHz
Pamět’: 512 MB
HDD: 160 GB UDMA 100
3. Třetím strojem je nymfe33 (nymfe33.fi.muni.cz).
CPU: AMD AthlonTM XP 2500+
Pamět’: 768 MB
HDD: 80 GB 7200 ot./min UDMA 100
Na všech počítačích byly nainstalované linuxové distribuce, jmenovitě Mandrake
Linux 9.1, Mandrake Linux 10.0 a Fedora Linux Core 3. Java byla použita ve verzi
1.5.0-rc-b63, respektivě 1.5.0-01-b08.
8.4
Tvorba odpovědi
Poslední krokem při implementaci modulu pro automatický sběr dat je tvorba odpovědi a její zaslání serveru VEZMU, který data dále zpracovává. Vracen je vektor objektů Metadata, jeden objekt Metadata obsahuje vždy informace o jednom
díle nebo článku. Skládá se z vektoru objektů Element a doplňujících informací
jako identifikátor v databázi, identifikátor dat v rámci zdroje (nejčastěji adresa dokumentu), název zdroje, z kterého dokument pochází. Objekt Element uchovává
jméno proměnné, její hodnotu a zkratku jazyka, v kterém jsou informace uchovány.
new Element("Publisher","IEEE Inc.","en");
Názvy metadat jsou převzaty z Dublin Core (<http://www.dublincore.org/>).
Jedná se o tyto termíny: Language, Publisher, Type, Format, Title, Creator, Date,
44
8.4. TVORBA ODPOV ĚDI
Page, Abstract. Specifická metadata pro určitý zdroj mají ve svém názvu jako prefix
název zdroje.
Pro tuto fázi jsem si vybral na pomoc balík Dom4j, jehož domovské stránky jsou
na adrese <http://www.dom4j.org/>. Pomocí tohoto nástroje lze lehce procházet strukturu XML dat, podporuje XPath výrazy. V XML datech by měly být korektní
názvy elementů již připraveny, pouze element Creators se musí rozdělit na jednotlivé elementy Creator. K tomuto účelu využívám objekt StringTokenizer. Postupně
se vytváří objekty Element, ty se přidávají do vektoru těchto objektů. Vektor Elementů se přidá do objektu Metadata, ve kterém jsou zachyceny informace o zdroji,
datu poslední změny metadat a datu poslední změny v mezipaměti. Nakonec se
vytvoří vektor objektů Metadata, který se odešle serveru. Příklad zasílaných metadatdat (název metadat: hodnota) je v příkladu 8.4.1.
Metadata ID: http://csdl.computer.org/dl/mags/ex/2004/01/x1048.pdf
Metadata source: IEEE
Language : en
Publisher : IEEE Inc.
Type : Text
Format : application/pdf
Title : Automating Experiments Using Semantic Data on
a Bioinformatics Grid
Creator : Chris Wroe
Creator : Carole Goble
Creator : Mark Greenwood
Creator : Phillip Lord
Creator : Simon Miles
Creator : Juri Papay
Creator : Terry Payne
Creator : Luc Moreau
Date : January 2004
Page : 48-55
Abstract : myGrid assists bioinformaticians in designing and
executing in silico experiments using the Grid’s resources...
IEEE_Whole_document : IEEE Intelligent Systems
IEEE_Whole_document_link : http://www.computer.org/intelligent/
IEEE_Pdf : http://csdl.computer.org/dl/mags/ex/2004/01/x1048.pdf
IEEE_Html : http://csdl.computer.org/dl/mags/ex/2004/01/x1048.htm
IEEE_More_abstract_link :
http://csdl.computer.org/comp/mags/ex/2004/01/x1048abs.htm
Pøíklad 8.4.1: Data zasílaná serveru
45
Kapitola 9
Testy modulů a portálů
Při vývoji jakékoli aplikace je nezbytné provádět testy její funkčnosti. Rozlišují se
dva základní typy testování: automatické a ruční. První z nich je méně náročný,
provádí se testy zvenku, někdy nazývané testy černé skříňky. Při ručním testování
se většinou kontrolují postupy uvnitř metod, bývá složitější. Nejvhodnější bývá oba
postupy kombinovat.
U jednotlivých modulů se uchovávají záznamy o prováděných operacích, takže
v případě chyby lze dohledat příčinu takového stavu. Dále jsou implementovány
metody pro ověření správné funkčnosti modulu a dostupnosti získávaných informací.
Před psaním samotných testů je vhodné nastudovat nějakou literaturu o tomto
tématu, například knihu Programování řízené testy [4].
9.1
Testování pomocí rámce JUnit
Testovací rámec JUnit <http://www.junit.org/> je open source produkt, který
urychluje vývoj opakovatelných testů a poskytuje mechanismus pro jejich spouštění. Předmětem testování jsou javovské třídy. JUnit framework zahrnuje:
•
Srovnávání očekávaných hodnot se skutečnými.
•
Příslušenství pro sdílení společných testovacích dat.
•
Sady testů pro snadnou organizaci a snadné spouštění testů.
•
Grafický a textový spouštěč testů.
Testy, tedy testovací třídy, je vhodné psát před implementací samotné třídy testované. Při psaní testů se mnohdy odhalí chyby, na které se nemyslelo při analýze a
návrhu. Další výhodou je, že usnadňují ladění implementované testované třídy. Tato
pozitiva jsou často zdůrazňovaná v metodice extrémního programování. V praxi to
bohužel bývá tak, že na testování vzhledem k časovému skluzu projektu nezbývá
dostatečné množství času a unit testy se pak nepíší bud’ vůbec, nebo až úplně na
závěr.
46
9.1. TESTOVÁNÍ POMOCÍ RÁMCE JUNIT
Pro každou třídu vzniká jedna testovací třída. Název bývá zvykem vytvořit
spojením názvu třídy testované a slova „Test“. Tedy pro třídu „NATUREPlugin“
vzniká typicky testovací třídy s názvem „NATUREPluginTest“. Na stránkách projektu JUnit je dostatečně kvalitně zpracovaná dokumentace, viz [14].
package cz.muni.fi.vezmu.searchPluginImpl;
import junit.framework.TestCase;
public class NATUREPluginTest extends TestCase {
public NATUREPluginTest(String testName) {
super(testName);
}
K inicializaci a vyčistění prostředí JUnit poskytuje metody setUp() a tearDown(),
které jsou volány před každým a po každém vykonání testu. Testy ve třídě jsou tak
od sebe izolovány.
protected void setUp() throws java.lang.Exception {
plugin = new NATUREPlugin();
dotaz = new AxisQuery();
}
protected void tearDown() throws java.lang.Exception {
}
Je vhodné testovat minimálně všechny public metody třídy. Většinou se netestují
primitivní get a set metody. Název testovací metody, pokud má být spuštěn automaticky v sadě, musí začínat řetězcem „test“. Pro jednu metodu testované třídy
může existovat více testovacích tříd. To závisí na tom, co všechno se rozhodneme
testovat.
public void testNumberOfResults(){
int limit = 7;
try {
dotaz.setFulltext("garbage");
dotaz.setLimit(limit);
Vector result = plugin.processQuery(dotaz);
assertEquals( limit, result.size());
} catch (AxisSearchException e) {
fail();
}
}
Nakonec se vytvoří sada testů, která slouží ke spouštění všech testovacích metod
testovací třídy. Nejsnadněji se sada vytvoří pomocí metody suite() s využitím Java
47
9.2. TESTOVÁNÍ POMOCÍ RÁMCE CACTUS
reflection pro dynamické vytvoření testovací sady zahrnující všechny testXXX() metody. Jednotlivé testy jsou do sady přidávány ve stejném pořadí, v jakém jsou implementovány. Je tedy nutné brát v úvahu toto pořadí v případě, kdy jsou jednotlivé
testy navzájem závislé. Tím se myslí používání společných dat. Klasicky se může
jednat o vytvoření, aktualizaci a zrušení objektu nebo jiné entity, například databázové.
public static junit.framework.Test suite() {
return new junit.framework.TestSuite(NATUREPluginTest.class);
}
Pro start testů nabízí JUnit dva spouštěče, textový a grafický. Pro využití textového
se musí implementovat následující metoda main().
public static void main(String args[]) {
junit.textui.TestRunner.run(suite());
}
}
Samotné spuštění se pak realizuje přímým zavoláním třídy. Start testů pomocí grafického spouštěče se provede takto:
java junit.swingui.TestRunner cz.muni.fi.vezmu.NATUREPluginTest
Vývojová prostředí mnohdy nabízejí ještě pohodlnější spouštění JUnit testů pomocí
integrovaných či doinstalovaných přídavných částí. Netbeans integrují JUnit testy
přímo do sebe, stačí si vybrat projekt a z kontextového menu zvolit položku Run
tests. Pro spuštění testu v Eclipse je nutné použít menu Run | Run As | JUnit Test.
JUnit testy jsem využil především během implementace modulů pro jednotlivé
zdroje. Velmi mi pomohly při hledání chyb a nekorektních zpracování dat. Testoval
jsem hlavní i pomocné metody, korektnost vracených informací, počet odpovědí i
správnost návratového typu při nevhodně položeném dotazu. Zpočátku jsem neměl
zahrnuté testy dostupnosti portálů, ty jsem ovšem velmi brzy dodělal. Po nasazení
modulů do provozu již tento způsob ověřování funkčnosti úplně nevyhovoval. Neměl jsem vždy ihned přístup ke zdrojovým kódům a proto jsem pátral po způsobu,
jak nasazené moduly okamžitě otestovat, nejlépe přes webové rozhraní.
9.2
Testování pomocí rámce Cactus
Testovací rámec Cactus <http://jakarta.apache.org/cactus/> je určen pro
testování kódu na straně serveru. Využívá JUnit a dále jej rozšiřuje.
Při tvoření testu je na výběr ze dvou možnosti: rozšířit třídu TestCase z balíku
Cactus
48
public class TestSampleServlet extends ServletTestCase
{ }
public class TestSampleTag extends JspTestCase
{ }
public class TestSampleFilter extends FilterTestCase
{ }
nebo použít JUnit test
package cz.muni.fi.vezmu.searchPluginImpl;
import junit.framework.Test;
import junit.framework.TestCase;
import org.apache.cactus.ServletTestSuite;
public class NATUREPluginTest extends TestCase {
public static Test suite() {
ServletTestSuite suite = new ServletTestSuite();
suite.addTestSuite(NaturePluginTest.class);
return suite;
}
public void testNatureAddressAvailable(){
...
}
K inicializaci a vyčistění prostředí jsou poskytnuty metody setUp() a tearDown(),
které mají stejné vlastnosti jako u JUnitu. Více informací lze nalézt na stránkách
projektu, v sekci Writing Tests [8].
Pro spouštění testů nabízí Cactus několik způsobů:
•
Manuální spouštění z příkazové řádky, vývojového prostředí nebo webového
prohlížeče.
•
Integrace s programem Ant a automatizované spouštění.
•
Integrace s programem Maven a automatizované spouštění.
•
Integrace s Jetty – prostředí pro běh Servletů.
Více informací o spouštění testů lze nalézt na stránkách projektu, sekce Running
Tests <http://jakarta.apache.org/cactus/integration/index.html>.
Pro moduly jsem využil spouštění testů přes webové rozhraní. Musí se upravit
soubor web.xml jako je tomu v příkladě 9.2.1.
49
</servle<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector
</servlet-class>
</servlet>
<servlet>
<servlet-name>ServletTestRunner</servlet-name>
<servlet-class>org.apache.cactus.server.runner.ServletTestRunner
</servlet-class>
<init-param>
<param-name>xsl-stylesheet</param-name>
<param-value>cactus-report.xsl</param-value>
</init-param>
</servlet>
...
<servlet-mapping>
<servlet-name>ServletRedirector</servlet-name>
<url-pattern>/ServletRedirector</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ServletTestRunner</servlet-name>
<url-pattern>/ServletTestRunner</url-pattern>
</servlet-mapping>
Pøíklad 9.2.1: Nastavení souboru web.xml pro spouštění testů pomocí rámce Cactus
Dále je nutné zabezpečit nakopírování potřebných knihoven pro Cactus a XSLT
procesor Xalan. Soubor cactus-report.xsl musí být umístěn do kořene adresářové
struktury aplikace. Test na běžící webové aplikaci se spouští zadáním specifické adresy do prohlížeče, například:
http://localhost:18080/vezmu-plugin-Nature/ServletTestRunner?suite=
cz.muni.fi.vezmu.searchPluginImpl.NaturePluginTest&transform=yes
Využil jsem již implementované JUnit testy a dále je rozšířil. Cactus standardně
vrací výsledek testování jako XML soubor. Pro zobrazení výsledku je na straně serveru použita XSLT transformace do HTML s využitím balíku Xalan, protože např.
prohlížeč Opera nepodporuje transformaci na straně klienta. Při spouštění testů pro
více modulů souběžně běžících modulů se vyskytl velmi závažný problém. Vždy
se volal pouze ServletRedirector modulu u kterého byl spuštěn první test. Při dotazu na vývojáře rámce Cactus mi bylo sděleno, že ServletRedirector se inicializuje
globálně v rámci běžící Java Virtual Machine a můj problém není v současné době
50
9.3. VLASTNÍ TESTOVÁNÍ
řešitelný. Také mi sdělili, že pravděpodobně neexistuje žádné jiné řešení, než si napsat vlastní testy.
9.3
Vlastní testování
Protože testování za pomoci Cactusu nevyhovovalo přesně mým požadavkům, byl
jsem nucen napsat testy úplně sám. Při implementaci jsem použil rámec Struts <http:
//jakarta.apache.org/struts>, který je vyvíjen v rámci projektu Jakarta pod
záštitou Apache. Velmi doporučuji knihu Programujeme Jakarta Struts [6], jejímž
autorem je Chuck Cavaness. Aplikace psaná v Struts musí splňovat především MVC
(Model-View-Controller) paradigma, což je soubor obecných pravidel týkajících se
vývoje aplikace. MVC je minimálně o deset let starší, nežli web v podobě jak ho
známe (na bázi hypertextových dokumentů), jeho vznik se datuje na přelom roku
1978–79. MVC určuje striktní rozdělení aplikace na tři oddělené části:
•
Model – vlastní aplikační logika aplikace.
•
View – stará se o zobrazování dat.
•
Controller – určuje řízení toku.
Pokud se programátor při vývoji aplikace řídí tímto doporučením, získá především
nepředstavitelnou výhodu v znovupoužitelnosti aplikace. Není pak problém převést stávající webovou aplikaci na rozhraní swing (grafické rozhraní pro Javu) jenom tím, že se nahradí stávající vrstva View. Rámec Struts implementuje vrstvu
Controller, v části Model dokáže spolupracovat se stávajícími technologiemi pro
přístup k datům jako je třeba JDBC a EJB, stejně dobře jako k produktům Hibernate nebo Object Relational Bridge. V části View standartně podporuje JavaServer
Pages včetně JSTL a JSF, ale problémy nemá ani s Velocity Templates a kombinací
XML + XSLT.
Pro každý modul jsem vytvořil třídu, která rozšiřuje třídu org.apache.struts.action.Action,
např. NaturePluginTestAction. V ní jsem překryl metodu execute(ActionMapping
mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) vlastním kódem. Volám testovací metody, které postupně naplňují datový
objekt TestReportVO. Na obrázku 9.1 jsou vidět vtahy mezi jednotlivými třídami.
Na konci metody uložím datový objekt do požadavku a přesměruji výstup na
stránku, která se stará o prezentaci dat.
request.setAttribute("testReport", testReport);
return mapping.getInputForward();
JSP stránka, na kterou se přesměruje výstup je definována v souboru struts-config.xml
51
9.3. VLASTNÍ TESTOVÁNÍ
Obrázek 9.1: Diagram tříd pro datové objekty využité při testování
<action-mappings>
<action path="/pluginTest" forward="/pluginTest.jsp"/>
<action
path="/test"
type="cz.muni.fi.vezmu.searchPluginImpl.NaturePluginTestAction"
scope="request"
validate="false"
input="/pluginTest.jsp">
</action>
</action-mappings>
<message-resources parameter="ApplicationResource"/>
Pomocí elementu message-resources v souboru struts-config.xml se definuje zdroj
pro zprávy. Poté stačí v JSP stránce zavolat <bean:message key="test.report"/> a
vloží se text odpovídající klíči test.report.successRate. Tím je aplikace připravená
52
9.4. TESTOVÁNÍ PORTÁL Ů
na lokalizaci a ulehčí se případné změny. Na obrázcích 9.2 a 9.3 jsou vidět příklady
výsledků testů.
Obrázek 9.2: Test bez chyb
Test na běžící webové aplikaci se spouští zadáním specifické adresy do prohlížeče, např.:
http://kore.fi.muni.cz:18080/vezmu-plugin-Nature/test.do
Vlastní testy jsou zaměřeny spíše na zkoumání dostupnosti portálu a vyhledávací stránky. Prověřuji, zda získaná stránka obsahuje identifikační prvky, podle kterých je možné jednoznačně určit, že se jedná o stránku s výsledky hledání. Dále
zkoumám identifikátory metadat a názvy publikací. To jsou položky, které by měly
být vždy naplněny nějakými daty. Tyto testy používám v současné době nejvíce,
kombinuji je také s JUnit testy.
9.4
Testování portálů
U modulů pro automatizovaný sběr informací se musí testovat nejen metody, ale i
samotné portály poskytující informace. Jednak je tu možnost dlouhodobějšího vý53
Obrázek 9.3: Test s chybovými hláškami
padku, reorganizace celého serveru spojená se změnou adresy pro vyhledávání a
nakonec asi ta nejhorší možnost, kterou je změna kódu generovaných HTML stránek s odpovědí.
Během posledních několika měsíců se vyskytly problémy u všech čtyřech implementovaných modulech. Byl jsem vděčen za testy, protože mi jednak umožnily
rychle objevit nefunkčnost a také pomohly při přepisování stávajícího kódu.
Stránky digitální knihovny ACM <http://www.acm.org/dl/> částečně změnily kód HTML. Stále bohužel používají tabulky pro formátování obsahu, oproti
předchozí verzi bylo přidáno několik řádků kódu na začátek, čímž se posunula celá
struktura stránky. Pro tento zdroj stále není možné použít XSLT transformaci, protože stránky jsou nevalidní a nejde je upravit pomocí JTidy na XHTML. Naštěstí
se nezměnila struktura části s výsledky hledání. Stačilo pouze změnit část, která se
stará o vybrání hlavní tabulky, ve které jsou obsaženy veškeré odpovědi. Ostatní
54
části jsem měl naprogramované pro hledání dat relativně oproti hlavní tabulce,
takže už nebylo potřeba nic měnit.
Portál IEEE <http://www.computer.org> změnil kód stránek o poznání více
než ACM. Stále sice využívá tabulky pro formátování obsahu, ovšem jejich použití
velmi redukoval. Stránky lze bez problémů převést do XHTML a dále zpracovat pomocí transformací. Pro opětovnou funkčnost modulu jsem musel přepsat a znovu
zkompilován XSLT styl, bylo nutné změnit více jak polovinu jeho obsahu. Způsob
vytváření dotazů zůstal zachován.
U serveru Nature <http://www.nature.com> došlo k největším změnám.
Změnila se úplně adresa a způsob zadávání dotazů u vyhledávání, ušetřen nezůstal
ani obsah. Stránky mají sice v záhlaví dokumentu napsáno, že používají XHTML
Strict, ale při prozkoumání kódu jsem zjistil, že text není korektně označkován a nesplňuje ani podmínku označovanou jako well-formed. Největším problém na stránkách jsou definice funkcí v jazyku JavaScript, kvůli kterým nejde výsledek hledání
převést na XHTML. Před změnou vzhledu tato transformace fungovala bez problému, takže současný stav hodnotím spíše negativně. Pro Nature jsem byl nucen
napsat modul úplně od začátku, při získávání informací jsem musel použít HTMLParser.
Portál Springer <http://www.springerlink.com> změnil adresu vyhledávání a pravděpodobně úplně přešel na platformu .NET. Nezůstala zachována ani
struktura odpovědi. Server si vnitřně uchovává pro každé sezení aktuální stav a na
stránkách s výsledky hledání jsou odkázány pouze relativně k aktuálně hledanému
dokumentu a uloženému stavu. Navíc pro zobrazení dokumentu se nejprve musí
kliknout na odkaz na stránku s informacemi o publikaci a až poté lze stáhnout dokument. Odkaz na elektronickou verzi publikace je na všech stránkách stejný, server
si totiž pamatuje, o jaké publikaci si uživatel naposledy zobrazil informace a podle
toho odešle dokument. Takže pokud si uživatel v prohlížeči otevře výsledky vyhledávání ve více záložkách a v každé z nich si klikne na odkaz pro elektronickou
verzi dokumentu, ve všech se otevře stejný, odpovídající obsahu poslední otevřené
záložky. Toto chování značně komplikuje implementaci modulu. Musí se nasimulovat postupné proklikání všech výsledků hledání a následné zobrazení dokumentů.
Protože si server pamatuje nalezené výsledky a aktuální stav, není možné tuto činnost provádět paralelně. Na začátku je ještě nutné kontaktovat server pro získání
dočasné identifikace (platná maximálně 2 hodiny), která umožní provést dotazy.
Výsledky hledání většinou splňují podmínku správně utvořené stránky, ale občas
obsahují nestandardní elementy, především v části abstrakt a autor. Opět tedy není
možné použít XSLT transformaci a je nutné kód stránek procházet pomocí balíku
HTMLParser. Z dosud implementovaných modulů je tento nejkomplikovanější.
55
Kapitola 10
Automatizace tvorby modulů pro sběr dat
10.1 Pomocné třídy
Jak již bylo dříve zmíněno, naskýtá se možnost alespoň částečné automatizace tvorby
modulů. Jejich vývoj se do značné míry urychlí, musí být ovšem splněna podmínka
převoditelnosti odpovědi zdroje do formátu XHTML. Jinak nepůjde aplikovat XSLT
transformace. Pokud zdroj, pro který je modul vyvíjen splní tuto podmínku, stačí
udělat dvě věci a implementace bude téměř hotová. První z nich je napsat metodu
pro generování dotazu, druhým úkolem je napsat XSLT styl pro daný zdroj. Zbývá
již jen změnit drobnosti jako je identifikátor dat, zdroj dat a vydavatele. V následujícím textu jsou představeny javové třídy, které přispívají k zrychlené tvorbě modulů pro získávání dat. Jsou umístěny v balíku cz.muni.fi.vezmu.searchPluginImpl
a jedná se o PluginHelper, PluginHelperParse a PluginHelperXML. Již z názvu je
patrné pro jakou skupinu stránek obsahují funkce. Třída PluginHelper obsahuje metody, které se využijí při zpracování jak validních, tak i nevalidních HTML stránek.
Další dvě třídy z ní dědí, takže jsou i v nich tyto metody dostupné.
10.2 Třída PluginHelper
Tato třída je implementovaná s využitím návrhového vzoru Singleton, tudíž se inicializuje pouze jednou a šetří systémové prostředky Java Virtual Machine. Více o návrhových vzorech je možné se dočíst v knížce J2EE Best Practices [2]. Tato třída
obsahuje tyto metody:
•
getAgentName()
Metoda vrací String, který obsahuje jednu z definovaných identifikací prohlížeče. Ta se dále využije při stahování dat.
•
getData(String URL)
Metoda stáhne obsah zadané adresy do objektu Stringu, vhodné při ručním
procházení HTML stránek.
56
10.2. T ŘÍDA PLUGINHELPER
Obrázek 10.1: Diagram tříd modulu
•
getCharsetName()
Metoda pro získání znakové sady, ve které se provádí operace jako čtení dat
ze serveru. Implicitně vrací UTF-8.
•
getInputStream(String URL)
Metoda ze zadané adresy vytvoří objekt InputStream určený pro další zpracování.
•
getInstance()
Vrací instanci objektu PluginHelper.
•
printErrors(Exception e)
Metoda vypíše do objektu String chybovou hlášku z předaného objektu Exception.
57
10.2. T ŘÍDA PLUGINHELPER
Obrázek 10.2: Diagram pomocných tříd
•
printVector(Vector<cz.muni.fi.vezmu.Metadata> input)
Vypíše na standardní výstup informace o předaném vektoru Metadat, vhodné
při ladění zdrojových kódů.
•
setCharsetName(String charsetName)
Metoda pro nastavení znakové sady, ve které se provádí operace jako čtení
dat ze serveru.
•
showHeaders(URLConnection conn)
Na standardní výstup vypíše hlavičky spojení.
•
tokenizeCreators(String creators)
58
10.3. T ŘÍDA PLUGINHELPERXML
Rozdělí String, který obsahuje více autorů oddělených čárkou do vektoru položek Element, které mají nastavené jméno uchovávané proměnné na „Creator“.
•
writeStreamToFile(InputStream input, String path)
Metoda zapisuje InputStream do zadaného souboru.
10.3 Třída PluginHelperXML
Tato třída je taktéž implementovaná s použitím návrhového vzoru Singleton. V následující části jsou popsány jednotlivé metody.
•
getInstance()
Metoda vrací instanci objektu PluginHelper.
•
transformDataToXHTML(InputStream input)
Metoda transformuje java.io.InputStream HTML dat na java.io.OutputStream
XHTML dat.
•
transformDataToXML(InputStream input, String transletName, String packageName)
Metoda transformuje java.io.InputStream HTML dat na java.io.OutputStream
XML dat, potřebuje také znát jméno zkompilovaného stylu (transletName) a
balík (packageName), v kterém je tento styl umístěn. Jde o spojení volání metod transformDataToXHTML a transformXHTMLToXML.
•
transformXHTMLToXML(InputStream input, String transletName, String packageName)
Metoda transformuje java.io.InputStream XHTML dat na java.io.OutputStream
XML dat, potřebuje také znát jméno zkompilovaného stylu (transletName)
a balík (packageName), v kterém je tento styl umístěn. Využívá se XSLTC
transformace, více informací na stránce <http://xml.apache.org/xalan-j/
xsltc_usage.html>. XSLT styl, který je zkompilován by měl být schopen
z XHTML dat produkovat obdobné XML jako v tomto příkladu:
<Document>
...
<Article>
<Title>
59
10.4. T ŘÍDA PLUGINHELPERPARSE
Assessment and Treatment of Compulsive Sex/Love Behavior
</Title>
<Id>W620L2U217732210.pdf</Id>
<Article_link>
http://www.springerlink.com/app/home/contribution.asp?
wasp=aa7b14939614456082e56bf64f3ab9ae&referrer=parent&
backto=searcharticlesresults,6,1000;
</Article_link>
<Article_pdf>
http://www.springerlink.com/media/N97PTGXUQNY9737JTE27/
Contributions/W/6/2/0/W620L2U217732210.pdf
</Article_pdf>
<Publication>
Journal of Rational-Emotive & Cognitive-Behavior Therapy
</Publication>
<Creators>Janet L. Wolfe</Creators>
<Publisher>
Springer Science+Business Media B.V.
</Publisher>
<Recency>Volume 18, Number 4</Recency>
<Page>235 - 246</Page>
<Abstract>
Sex-love compulsivity or "addiction" involves most of the
same issues as other addictive or compulsive behavior ...
</Abstract>
</Article>
...
</Document>
•
transformXML2Metadata(InputStream input, String source, String publisher,
String idElement)
Metoda, jejímž úkolem je převést XML data na Vector<Metadata>. Potřebuje
znát InputStream s XML daty, název zdroje (source), oficiální název nakladatelství a název elementu, který slouží jako identifikace dokumentu v rámci
zdroje (idElement).
10.4 Třída PluginHelperParse
•
getInstance()
Metoda vrací instanci objektu PluginHelper.
60
10.5. METODIKA VÝVOJE MODUL Ů
•
removeBlankSpace(String inputString)
Metoda vhodná při ručním procházení stránek, vrací inputString bez přebytečných mezer.
10.5 Metodika vývoje modulů
V této části chci zmínit postup tvorby nových modulů pro elektronické zdroje MU.
Následující text obsahuje popis jednotlivých fází implementace. Výsledný modul
napsaný v jazyce Java by měl implementovat připravená rozhraní CorePlugin a
WebservicesPlugin z balíku cz.muni.fi.vezmu.searchPluginImpl, respektive cz.muni.fi.vezmu.ws.
10.5.1 Příprava testů
Prvním krokem je tvorba testovacích tříd. Doporučuji se nechat inspirovat existujícími kódy z již vytvořených modulů. Testování jsem se věnoval v kapitole 9, proto
se zde nebudu dále o tomto tématu rozepisovat.
10.5.2 Tvorba dotazu
Samotné sestavení požadavku je specifické pro každý zdroj, protože se musí zohlednit způsob zadávání dotazu. Nejjednodušší varianta nastává, pokud jsou data
z vyhledávacího formuláře na stránkách elektronického zdroje zasílána serveru metodou GET v lidsky dobře čitelné formě. Stačí pouze zadat několik dotazů pro každé
vyhledávací kritérium, uložit si a analyzovat strukturu adresy s odpovědí. Důležité
je zjistit, zda vyhledávací rozhraní umožňuje kombinovat různá kritéria současně
a jak se tato možnost promítne do výsledné adresy s odpovědí. Neměla by také
chybět možnost třídění výsledků podle aktuálnosti a důležitosti. Po analytické části
je nutné implementovat metodu, která z předaného objektu Query dokáže sestavit
adresu s požadovanou odpovědí. Je vhodné mít připravený test, který ověří správnou funkčnost. Pokud je v objektu Query obsaženo více vyhledávacích kritérií než
umožňuje server s obsahem současně zpracovat, je nutné zvážit důležitost jednotlivých kritérií a stanovit prioritu při sestavování dotazu. Další možností je vytvořit
více dotazů a jejich výsledky následně kombinovat.
Problém nastává, když jsou data z vyhledávacího formuláře na stránkách elektronického zdroje zasílána serveru metodou POST, případně pokud jsou dále modifikovaná pomocí jazyka JavaScript. Nezbývá než odposlechnout komunikaci na
sít’ové kartě. K tomu může sloužit program tcpdump <http://www.tcpdump.
org/>. Podle mého názoru je daleko vhodnější open source produkt Ethereal <http:
61
//www.ethereal.com/>. Je dostupný pro systémy Windows, Linux, UNIX, Solaris, Mac OS X i Irix, jeho ovládání je velice intuitivní. Umožňuje nastavit různé
filtry, které z výpisu odstraní záznamy o nedůležité komunikaci na sít’ovém zařízení. Oba zmíněné programy vyžadují pro svůj běh administrátorská oprávnění.
Pokud tvůrce modulů nemá na fakultě taková práva k žádnému počítači, bude
pravděpodobně nucen využít svůj osobní počítač. Doporučil bych připojení do virtuální privátní sítě Masarykovy univerzity, protože některé zdroje mají omezení
přístupu jen na IP adresy začínající 147.251. Více informací lze nalézt na adrese
<http://pptp.ics.muni.cz/>.
Implementace se dále komplikuje, pokud všechny potřebné informace nejsou
dostupné z jedné stránky výsledků hledání. V takovém případě musí modul simulovat kliknutí na jednotlivé odkazy. Většinou je nutné takto získávat abstrakt a odkaz na plný text publikace. Příkladem může být portál Springer <http://www.
springerlink.com/>. U něj je situace ještě ztížena nutností nejprve získat unikátní identifikaci a nemožností paralelního simulování proklikání odkazů. Server si
totiž uchovává pro každé sezení aktuální stav, detailněji se tímto problémem zabývám v sekci 9.4.
10.5.3 Zpracování odpovědi
Nejprve se musí zjistit, zda stránka obsahující odpovědi splňuje specifikaci XHTML,
případně, zda je možné ji do takového tvaru transformovat. Korektnost stránek se
může zjistit validátorem konsorcia W3C umístěným na stránce <http://validator.
w3.org/>. Pro ověření možnosti transformovat data do formátu XHTML slouží
metoda transformDataToXHTML(InputStream input) z třídy PluginHelperXML. Pokud proběhne bez chybových hlášení, je tu vysoká pravděpodobnost využití XSLT
transformací pro další zpracování. Tyto prověrky je nutné provést na minimálně
deseti různých dotazech.
Pokud lze data transformovat do formátu XHTML, může se využít předpřipravených metod z třídy PluginHelperXML. Nejprve se musí vytvořit XSLT styl. Jeho
složitost je silně ovlivněná členitostí zdrojového kódu odpovědi. Nejlepší cesta je
nalézt význačné, případně unikátní elementy a pomocí nich adresovat hledané informace. Měly by se používat osy předek, následník a sourozenec pro určování blízkých elementů. Nevhodné je absolutní adresování každého elementu od kořene,
protože se vždy musí procházet celý strom elementů. Obecně je tedy vhodnější určit
jeden základní element a od něj nalézt lokální vazby k dalším elementům, většinou
následníkům nebo sourozencům.
Při tvorbě stylů se mi osvědčilo nejprve si uložit několik stránek s výsledky hledání na lokální disk, převést je do XHTML a poté pro ně vytvořit styl. Pro ukládání
stránek na disk nedoporučuji internetové prohlížeče, protože výsledný soubor mo62
difikují. K tomuto účelu jsem používal wget <http://www.gnu.org/software/
wget/> a Free Download Manager <http://www.freedownloadmanager.org/>.
Následně lze již využít zmiňovanou metodu transformDataToXHTML(InputStream
input) a writeStreamToFile(InputStream input, String path) pro transformaci souborů do XHTML formátu. Při psaní stylu jsem používal editor jEdit <http://www.
jedit.org/>, ke kterému se dá stáhnout zásuvný modul pro XSLT transformaci.
Po napsání a odzkoušení stylu se musí předkompilovat pro další použití, například
tímto příkazem:
java org.apache.xalan.xsltc.cmdline.Compile -j IEEEstyl.jar
-p cz.muni.fi.vezmu.styles IEEEstyl.xsl
Při implementaci modulu pro stahování dat z elektronických zdrojů je vhodné použít metody transformDataToXML(InputStream input, String transletName, String
packageName), transformXHTMLToXML(InputStream input, String transletName,
String packageName) a transformXML2Metadata(InputStream input, String source,
String publisher, String idElement). Jejich popis je uveden v předcházející části.
Pokud není možné stránku s výsledky hledání transformovat do XHTML, musí
se použít analyzátor HTML kódu. Jako nejlepší jsem vyhodnotil HTMLParser <http:
//www.htmlparser.org>. Umožňuje extrakci textu, odkazů, obrázků, kontrolu
odkazů, přepis URL, ukládání stránek a mnoho dalších věcí. Dokumentace k projektu je výtečná, což velmi usnadňuje jeho použití. Opět se mi osvědčilo nejprve si
uložit několik stránek s výsledky hledání na lokální disk a až poté je procházet pomocí metod z balíku HTMLParser. I zde platí doporučení nepoužívat internetové
prohlížeče k ukládání těchto stránek. Při ručním procházení dat je nejlepší cesta nalézt význačné elementy a od nich relativně adresovat hledané informace, obdobně
jako u XSLT transformace. Při prohledávání kódu stránek se mi velmi osvědčil objekt NodeFilter, díky kterému jsem specifikoval podmínky, které mají uzly splňovat,
jako například v této ukázce:
NodeFilter tableFilter = new NodeFilter() {
public boolean accept(Node node) {
if (node instanceof TableTag) {
Tag tag = (Tag) node;
String attribute = tag.getAttribute("id");
return ((attribute != null) && (attribute.equals("Table2")));
} else {
return false;
}
}};
Parser parser = new Parser();
parser.setURL(URL);
parser.setEncoding("ISO-8859-2");
63
parser.reset();
NodeList tablesList = parser.extractAllNodesThatMatch(tableFilter);
Z pomocných metod je možné využít pouze removeBlankSpace(String inputString)
a tokenizeCreators(String creators). Po získání všech potřebných dat se musí vytvořit odpověd’ pro server VEZMU, tu ovšem není možné automatizovat. Pro tuto fázi
bych spíše doporučil prostudování zdrojových kódů na přiloženém CD, případně
z úschovny zdrojových kódů projektu <https://kore.fi.muni.cz:5443/repos/
fi/elsw/vezmu/trunk/>.
64
Kapitola 11
Závěr
V práci jsem se zabýval problematikou automatizovaného sběru dat, důraz jsem
kladl především na webové stránky a na možnosti získání informací v nich obsažených. Zmínil jsem také možnosti webových služeb a syndikace obsahu. U portálů
nejsou bohužel tyto varianty poskytování informací prozatím příliš rozšířené. Praktickým výsledkem mé práce je implementace čtyř modulů pro sběr dat z elektronických zdrojů Masarykovy univerzity, které jsou dále využity v projektu VEZMU. Pro
tvorbu nových modulů jsem navrhl metodiku zohledňující jak validní, tak i nevalidní HTML stránky. Vytvořil jsme tři pomocné třídy usnadňující tuto činnost a také
doporučil vhodné nástroje zjednodušující a urychlující implementaci. Pro každý
modul jsem naprogramoval sadu metod sloužící k prověření jejich funkčnosti a dostupnosti zdrojů dat. V práci jsem popsal postup správné tvorby testů, upozornil na
části kódu vhodné k prověření a zmínil implementační problémy stávajících testů.
Další vývoj vyhledávače vidím především v oblasti implementace nových přídavných modulů pro komunikaci s elektronickými zdroji a sofistikované aplikační
logiky pro stahování dokumentů do mobilních zařízení typu PDA. Po dokončení
specifikace EJB 3.0 pak postupný přechod jádra systému na tuto technologii.
Tato práce je jedním z prvních kroků ve vývoji tohoto projektu. Do textu jsem se
snažil vložit mnohé mé poznatky, související s návrhem, implementací, optimalizací
a testováním modulů. Může se tak stát dobrým výchozím bodem pro další vývojáře,
kteří budou na tomto projektu pracovat v příštích letech.
65
Literatura
[1] Arlow, J. a Neustadt, I.: , UML a unifikovaný proces vývoje aplikací, Computer Press, 2003, 80-7226-947-X.
[2] Broemmer, D.: , J2EE Best Practices: Java Design Patterns, Automation and
Performance, John Wiley & Sons Inc, 2002, 0-471-22885-0. 10.2
[3] Bloch, J.: , Java efektivně, 57 zásad softwarového experta, Grada, 2002, 80-2470416-1. 8
[4] Beck, K.: , Programování řízené testy, Grada, 2004, 80-247-0901-5. 9
[5] Bartošek, M.: , Novinky v oblasti elektronických informačních zdrojů pro výzkum, výuku a vzdělávání na MU, 2001, Zpravodaj ÚVT MU. B
[6] Cavaness, C.: , Programujeme Jakarta Struts: Tvorba webových aplikací se servlety a stránkami JSP, Grada Publishing, 2003, 80-247-0667-9. 9.3
[7] Henzinger, M. a Motwani, R. a Silverstein, C.: , Challenges in web search engines, 2002, ACM SIGIR Forum.
[8] Cactus: , Writing Tests, 2005. 9.2
[9] The Dublin Core Metadata Initiative: , Dublin Core Metadata Element Set,
2004. 6.3
[10] Ústav výpočetní techniky Masarykovy univerzity v Brně: , Dublin Core: referenční popis, 2000.
[11] Holzner, S.: , XSLT – Příručka internetového vývojáře, 2002, Computer Press.
8.3
[12] Hynar, M.: , Java – nástroje, Neocortex, 2004, 80-86330-16-8. 6.7.2, 6.7.4
[13] Harold, E.: , XML Bible, 1999. 8.3
[14] JUnit: , Documentation, 2005. 9.1
[15] Masarykova univerzita: , Elektronické informační zdroje Masarykovy univerzity. B
[16] Patočka, M.: , Webové služby, 2004. 4
[17] Ridge Group: , Information Gathering in the Electronic Age: The Hidden Cost
of the Hunt, 2003. 5.1, 5.2, 5.3
66
[18] Spell, B.: , Java: programujeme profesionálně, 2002, Computer Press, 80-7226667-5.
[19] JCP: , Specifikace J2EE 1.4 Final Release, 2003.
[20] Tkačíková, D.: , Kvalitní dokument jako základ účinného vyhledávání informací, 2004.
67
Index
Ant, 31
Atom, 15
1.0, 15
Cactus, 48, 50
CDF, 11
diagram
Activity, 38
Class, 52, 57, 58
Implementation, 29
Sequence, 39
Use Case, 37
Dom4j, 29, 45
Dublin Core, 15, 29, 44
Subversion, 33
SyncML, 12
Tomcat, 32
UDDI, 22
web.xml, 49
Wiki, 33
WSDL, 21
Xalan, 29, 40, 42, 50
XHTML, 7, 39
XML, 8
XSLTC, 59
HTMLParser, 29, 40, 63
JBoss, 32
JDeveloper, 31
JMeter, 32
JTidy, 29, 40
JUnit, 32, 46, 49, 53
Magic Draw, 31
Maven, 33
Netbeans, 31
OML, 12
OPML, 11
Ridge Group, 24
RSS, 12
0.91, 14
0.92, 14
1.0, 14, 15
2.0, 14
Saxon, 40, 42
SOAP, 21
Struts, 27, 51
struts-config.xml, 51, 52
68
Dodatek A
Obsah přiloženého CD
/doc
Dokumentace a specifikace
/install Instalační balíky programů potřebných pro nasazení
/projekt Aktuální stav systému
/text
Elektronická podoba diplomové práce
69
Dodatek B
Elektronické zdroje MU
Web of Science <http://wos.cesnet.cz/> Multioborová citační databáze od
společnosti ISI (Institute for Scientific Information). Jedná se o webovou podobu
známých databází Science Citation Index, Social Science Citation Index a Arts &
Humanities Citation Index. Databáze obsahuje týdně aktualizované údaje o článcích
z více než 8500 vědeckých časopisů ze všech oborů. Kromě bibliografických údajů
a abstraktu jsou u každého článku uvedeny všechny jeho reference a také všechny
jeho citace (odkazy na daný článek z novějších prací). Týdně v databázi přibývá na
25000 nových záznamů a přes 400000 citačních odkazů. Uživatelům je k dispozici
retrospektiva za posledních dvacet let.
ProQuest 5000 <http://www.proquest.com/pqdauto> Rozsáhlá databáze
aktuálních informací společnosti Bell+Howell zahrnující plné texty cca 5000 periodik a dále bibliografické záznamy z dalších cca 3000 časopisů, pokrývajících zejména:
humanitní a společenské obory, obchod, medicínu, aplikované přírodní vědy, výpočetní a telekomunikační techniku. Retrospektivní pokrytí je od roku 1993 do současnosti. Záznamy o nových publikacích jsou v databázi zveřejňovány nejpozději do
48 hodin od jejich vydání.
EIFL Direct <http://search.epnet.com/> Databáze plných textů článků
z celkem 3300 časopisů, novin a zpravodajství od r. 1990, především z oblasti sociálních a humanitních věd, od EBSCO Publishing – jednoho z předních světových dodavatelů elektronických a tištěných časopisů. Informace jsou rozděleny do několika
dílčích databází: Academic Search Elite (společenské a humanitní vědy), Business
Source Premier (ekonomie, finance, management, účetnictví, mezinárodní obchod),
Newspaper Source Plus (přes půl miliónů článků z více jak 100 novin v anglickém jazyce) a MasterFILE Premier (obecně zájmové tituly, obchod, zdraví, kultura).
K tomu navíc medicínské databáze Medline (kompletní soubor od roku 1966, plus
plné texty z 80 lékařských časopisů), Health Source Plus (oblast výživy, pohybové
aktivity, péče o vlastní zdraví, problematiku drogové závislosti) a další.
JSTOR – Journal Storage <http://www.jstor.org/> Retrospektivní on-line
databáze digitalizovaných plných textů z více jak 117 amerických vědeckých časopisů z humanitní oblasti (antropologie, ekologie, ekonomika, filosofie, finance,
historie, literatura, matematika, politické vědy, sociologie, statistika, vzdělávání).
70
B. E LEKTRONICKÉ ZDROJE MU
Každý časopis je plně digitalizován od prvního vydaného čísla (sahajícího mnohdy
hluboko do minulého století) až po pohyblivou hranici tří až pěti let od současnosti,
podle dohody s vydavatelem tištěné verze.
Biological Abstracts <http://web5s.silverplatter.com/webspirs/start.
ws?customer=mazaryk> Bibliografická databáze od společnosti BIOSIS: databáze
Biological Abstracts (se záznamy od roku 1997) obsahuje reference na články z téměř
6000 časopisů z oblasti life sciencies, včetně biochemie, biotechnologií, botaniky,
ekologie, životního prostředí, mikrobiologie, neurologie, farmakologie, zdravotnictví, a zemědělství.
Zoological Records <http://web5s.silverplatter.com/webspirs/start.
ws?customer=mazaryk> Bibliografická databáze od společnosti BIOSIS: databáze
Zoological Records (kompletní přístup k elektronickým záznamům od roku 1978)
pokrývá informace pro výzkum živočichů z oblastí od biochemie až po veterinární
medicínu. Pokrývá 4500 periodik ze 100 zemí světa.
Springer-LINK <http://www.springerlink.com/> Databáze Springer-LINK
nabízí abstrakty i plné texty vědeckých a odborných časopisů nakladatelství Springer Verlag. V současnosti poskytuje přístup k 481 časopisům a 17 edicím.
Springer-LNCS (Lecture Notes in Computer Science) <http://link.springer.
de/series/lncs/> Databáze elektronických verzí sborníků vědeckých konferencí
a monografií z oblasti computer science, umělé inteligence a jejich aplikací, publikovaných nakladatelstvím Springer-Verlag v rámci řady "Lecture Notes in Computer
Science". Ročně je v rámci této řady vydáno přes 200 publikací.
Digitální knihovna ACM <http://www.acm.org/dl/> Digitální knihovna
americké počítačové společnosti ACM obsahující elektronické verze cca 30 časopisů
z oblasti počítačů od roku 1985 a plné texty sborníků vědeckých konferencí pořádaných společností ACM od roku 1985 (stovky sborníků z více než 130 sérií konferencí). Povolen je přístup pro maximálně tři souběžně přistupující uživatele z MU
SportDiscuss <http://erl.aip.cz/> Bibliografická databáze z oblasti sportu
a fitness od SIRC (Sport Information Resource Centre), obsahující citace více než půl
miliónu prací (časopiseckých článků, knih, sborníků, výzkumných zpráv, disertací)
od roku 1975 po současnost. Pokrývá kompletní řadu sportovních disciplín, sportovní medicínu, aplikovanou fyziologii, trénink, dopink, tělesnou výchovu, biomechaniku, sportovní management, ekonomii, historii a další.
LION <http://lion.chadwyck.com/> LIterature ONline představuje unikátní soubor více jak 300000 úplných literárních textů z britské a americké literatury,
ale také kritických článků a bibliografických odkazů. To vše rozděleno tématicky
do 19 databází – anglická poezie, americká poezie, afroamerická poezie, anglické
drama, americké drama, beletrie, plné texty z literárních časopisů, Websterův slovník aj. Databáze je ve vlastnictví nakladatelství Chadwyck-Healey.
ScienceDirect (Elsevier) <http://www.sciencedirect.com/> Služba umož71
ňující on-line přístup k elektronickým verzím vědeckých časopisů z nakladatelství
Elsevier Science. Časopisy z tohoto nakladatelství pokrývají zejména oblasti medicíny, přírodních věd, matematiky, výpočetní techniky, ale též ekonomie, obchodu
a řízení, psychologie a sociálních věd a dalších. Jako součást českého konsorcia
ScienceDirect má MU přístup k časopisům, které v tištěné podobě odebírá některý
z členů českého konsorcia ScienceDirect. V současnosti jde o 400 titulů časopisů.
Journal Citation Reports <http://isiknowledge.com/> Jde o specializovanou databázi obsahující statistické údaje a nástroje pro systematické a objektivní
bibliometrické vyhodnocování a srovnávání vědeckých časopisů zpracovávaných
bibliograficky společností ISI (viz Web of Science a Current Contents). Jedním z nástrojů pro toto porovnávání je tzv. impact factor, který udává míru frekvence citací
průměrného článku daného časopisu za dané období, a lze jej využít jako základ pro
odhad prestiže akademických časopisů. Tento zdroj slouží především informačním
specialistům, nakladatelům a editorům; je však využitelný i autory, zejména pro
výběr časopisů k publikování a identifikaci časopisů relevantních pro oblast jejich
odborného zájmu.
Časopisy Elsevier-Kluwer-Wiley <http://www.suweco.cz/online/cz3/
client/pristup_srch0.asp> Portál zpřístupňující přes 1100 titulů vědeckých
časopisů z nakladatelství Elsevier, Kluwer a Wiley s plnými texty publikovaných
článků. Jde o časopisy zejména z oblasti přírodních věd, medicíny, výpočetní techniky, práva, ekonomie, ale částečně i z oblasti humanitních věd.
Česká elektronická knihovna <http://www.ceska-poezie.cz> Česká elektronická knihovna – Poezie 19. století (Ústav pro českou literaturu AV ČR) nabízí
přístup k plným textům digitalizovaných sbírek české poezie. Díky počítačovému
zpracování je možné provádět nad texty řadu pokročilých literárněvědných zkoumání, stejně jako nabídnout široké veřejnosti přístup k plným textům básnických
sbírek. Zdroj je volně dostupný, je vyžadována registrace uživatele.
Česká národní bibliografie <http://aip.nkp.cz/> ČNB (producentem dat
je Národní knihovna ČR v Praze) nabízí nejucelenější zdroj bibliografických informací nejen o českém písemnictví, ale je i primárním referenčním zdrojem informací
o produkci vydané na území ČR. Zdroj je rozdělen do několika databází: články
v českých novinách, časopisech a sbornících, české knihy, zahraniční bohemika, speciální dokumenty, národní autority, disertace a autoreferáty, periodika vydaná na
území ČR. Zdroj je volně dostupný.
ELIS - Encyclopedia of Library and Information Science <http://www.dekker.
com/servlet/product/productid/E-ELIS> Čtyřdílná encyklopedie zaměřená
na knihovnictví a informační vědu.
EMBASE <http://gateway.ovid.com/autologin.html> Databáze EMBASE patří mezi stěžejní medicínské informační zdroje, je nezastupitelná pro obory
farmacie a farmakologie. Obsahuje více než 6 miliónů záznamů o článcích v cca 3 800
72
mezinárodních lékařských časopisech z více než 110 zemí, ve srovnání s MEDLINE
ve větším zastoupení také české a slovenské tituly. Více než 65% záznamů obsahuje
abstrakty, které vytváří specializovaný tým odborníků. Navíc je zde specializovaný
tezaurus EMTREE s více než 36 000 deskriptorů a 150 000 synonym. Roční přírůstek
je cca 380 000 záznamu. 53% záznamu pokrývá Evropu, 3% USA. Přes 44% záznamů
EMBASE je zcela unikátních (nejsou pokryty v MEDLINE).
MEDLINE <http://gateway.ovid.com/autologin.html> MEDLINE je
jedním ze dvou nejdůležitějších zdrojů informací v lékařství. Kompletní databáze
Národní lékařské knihovny USA obsahuje přes 8,4 miliónu záznamů od roku 1966
do současnosti, roční přírůstek MEDLINE je cca 380000 záznamů. Zahrnuje citace a
abstrakty (ke zhruba 60% citací po roce 1975 je k dispozici abstrakt) celosvětové lékařské literatury včetně výzkumu, klinické praxe, administrativy, služeb pro ochranu
zdraví. MEDLINE obsahuje reference o článcích z cca 3400 odborných časopisů ze
70 zemí. Záznamy jsou klasifikovány pomocí tezauru Medical Subject Headings.
ETRDL – ERCIM Technical Report Digital Library <http://dienst.muni.
cz/> MU Brno se zapojila do distribuované sítě technických zpráv z oblasti computer science a matematiky evropského konsorcia ERCIM (European Research Consortium for Informatics and Mathematics). Na MU byl zprovozněn server, který
jednak vystavuje světu technické a výzkumné zprávy z Fakulty informatiky, jednak slouží jako brána pro vyhledávání obdobných zpráv v rámci celého evropského
konsorcia ERCIM i celosvětové digitální knihovny NCSTRL (Networked Computer
Science Technical Reference Library). Postupně tento server zpřístupní i dokumenty
ostatních členů konsorcia CRCIM (Czech Research Consortium for Informatics and
Mathematics).
Gale <http://infotrac.galegroup.com/itweb/masaryk?db=GVRL> Virtuální knihovna elektronických encyklopedických knih z nakladatelství GALE, na
jejímž konstituování se podílely knihovny FSS a ESF MU.
GeoBase <http://web5s.silverplatter.com/webspirs/start.ws?customer=
mazaryk> Multidisciplinární databáze od Elsevier Science poskytující bibliografické informace a abstrakta z humánní a fyzické geografie, ekologie, geologie, oceánografie, geomechaniky apod. Databáze pokrývá 1700 současných časopisů z dané
oblasti a archivně dalších několik tisíc titulů. Obsahuje víc než milion záznamů od
r. 1980, ročně přibývá 72000 záznamů. Každý záznam obsahuje úplnou bibliografickou citaci, indexující termíny a kódy, přes 99% všech záznamů obsahuje abstrakta.
ChemNetBase <http://www.chemnetbase.com/> Kolekce chemických referenčních příruček nakladatelství CRC/Chapman and Hall, zahrnující tři elektronické zdroje: Combined Chemical Dictionary, The Handbook of Chemistry and Physics, Polymers – a Property Database. Pro prohlížení strukturních vzorců je potřeba
stáhnout si a nainstalovat příslušný zásuvný modul ze stránek ChemNetBase.
IEEE Computer Society Digital Library <http://www.computer.org/> Plné
73
texty více než 20 počítačově orientovaných odborných časopisů a 900 sborníků konferencí z oblasti Computer Science vydávaných resp. pořádaných americkou odbornou společností IEEE.
Inspec <https://dialog.cvut.cz/> INSPEC (The Database for Physics, Electronics and Computing) je abstraktová online databáze obsahově odpovídající třem tištěným publikacím: Physics Abstracts, Electrical and Electronics Abstracts, a Computer and Control Abstracts z řady The Science Abstracts (již od roku 1898). Sledováno
je přes 4100 časopisů a seriálů z uvedených oblastí.
Institute of Physics E-Journals <http://www.iop.org/EJ/> Plné texty 30
titulů časopisů z nakladatelství Institute of Physics Publishing – periodika z oblasti
fyziky, okrajově z matematiky, lékařství, biologie a informatiky.
Journal Citation Report <http://isiknowledge.com/> Tato databáze nakladatelství ISI je základním a jedinečným zdrojem pro vyhodnocování časopisů a
zpracovává citační údaje z více než 8400 vědeckých a technických časopisů z celého
světa. Pokrytí je multidisciplinární a mezinárodní a zahrnuje přes 3000 nakladatelství v 60 zemích. Journal Citation Reports je databáze obsahující statistické údaje
a kvantitativní nástroje pro systematické a objektivní vyhodnocování, kategorizaci
a vzájemné porovnávání vědeckých a odborných časopisů sledovaných společností
Institute for Scientific Information (ISI), např. v databázích Web of Science a Current
Contents.
Kluwer eBOOKS <http://ebooks.springerlink.com/> Plné texty elektronických verzí 31 biomedicinských knižních titulů nakladatelstvi Kluwer (Kluwer
eBOOKS), nyní pod Springer LINK.
Library and Information Science Abstracts <http://www.csa.com/htbin/
dbrng.cgi?username=masa&access=masa12&cat=lisa> LISA je jedna z nejrozsáhlejších databází se zaměřením na knihovnictví, informační vědu, informační
technologie, informační management, knihovědu a hraničních odvětví. Je to bibliografická databáze od anglické firmy Cambridge Scientific Abstracts obsahující záznamy a abstrakty článků více než 470 titulů oborových časopisů z 68 zemí světa.
V rámci projektu LI je pro MU zpřístupněna databáze aktuálních dat plus retrospektiva od r. 1969 do současnosti.
Library Literature and Information Science Fulltext <http://vnweb.hwwilsonweb.
com/hww/jumpstart.jhtml> Databáze zahrnuje celkem 200 klíčových knihovnických periodik a přes 600 monografií včetně diplomových prací a sborníků (od
roku 1936). Ve verzi FULLTEXT jsou navíc plné texty 78 časopisů počínaje rokem
1998. Tématicky databáze pokrývá automatizaci, katalogizaci, cenzuru, autorské
právo, pracovní příležitosti, národní a mezinárodní knihovny, ochranu fondů, vydavatelství, standardizaci apod.
Medieval <http://www.phil.muni.cz/klas/databaze.html> Soubor databází řeckých a latinských textů starověku a středověku.
74
Micromedex <http://micromedex.cuni.cz/> Micromedex (v konfiguraci
Drugdex, Martindale, PDR, P&T Quick) je špičková americká bibliografická a faktografická databáze specializovaná na oblast farmakologie, farmakologické informace
a příbuzné vědní obory (např. chemie, toxikologie, teratologie, cestovní medicína,
apod.). Základem je modul Drugdex s monografiemi jednotlivých léčiv zpracovanými podle jednotné osnovy, modul PDR (Physician Desk Reference) je základní
informační zdroj o léčivech tradičně používaný lékaři v USA, modul Martindale obsahuje údaje světoznámé lékové encyklopedie britské královské farmaceutické společnosti s desítkami tisíc hesel (zahrnuje informace i o léčivech používaných v Evropě), modul P&T Quick obsahuje detailní a kritické informace o nových léčivech.
Informace databáze jsou nezávislé na farmaceutických firmách a jsou aktualizovány
čtvrtletně.
NATURE <http://www.nature.com/nature/> Elektronická verze týdně vydávaného časopisu Nature z oblasti přírodních věd a medicíny. Články pokrývají
všechny oblasti přírodních věd (včetně fyziky, věd o Zemi, biologie, chemie, biomatematiky, aj.) Archiv plných textů je rozdělen na dvě části:
•
1997 – do současnosti: plné texty jsou dostupné jako součást standardního
předplatné.
•
1987 – 1996: dostupné jsou jen abstrakty článků, plné texty je nutné zaplatit.
OXFORD Reference Online <http://www.oxfordreference.com/> Kolekce více jak 100 slovníků a encyklopedií budovaná Oxford University Press a uvedená na trh v březnu 2002. Jde o velmi rozsáhlý a širokospektrální zdroj pokrývající
široké spektrum oborů – od obecných příruček a jazykových slovníků, přes přírodní
vědy a medicínu, humanitní a sociální vědy, až po právo, ekonomiku a obchod.
Portál STM <http://www.portalstm.cz/> Průvodce informačními zdroji
v oblasti věda-technika-medicína spravovaný Státní technickou knihovnou v Praze.
Soustřed’uje odkazy na licencované i volně dostupné profesionální elektronické informační zdroje doma i v zahraničí. Kromě toho obsahuje odkazy z oblastí věda a
výzkum v ČR, knihovny, patenty, normy a další.
SCOPUS <http://www.scopus.com/> V současnosti je největší světovou abstraktovou a citační databází, která poskytuje (s denní aktualizací) informace o článcích ze 14000 vybraných vědeckých časopisů z oblasti přírodních věd, technických
věd, medicíny, společenských věd. SCOPUS je přímým konkurentem databáze Web
of Science (WoS) od ISI. V srovnání s WoS má SCOPUS nejen větší absolutní pokrytí
časopisů, ale má i větší pokrytí evropských titulů. MU získala bezplatný přístup do
30.9.2006.
The Times Digital Archive <http://infotrac.galegroup.com/itweb/
brno?db=TTDA> Úplný archiv londýnských The Times za 200 let od jejich vzniku
75
(1785 – 1985), celkem přes 7,5 miliónů článků. Stránky se zobrazují jako náhledy tištěné podoby (články lze vytisknout, ne však stahovat v textové podobě). Součástí
zdroje je i úplný archiv významného literárně kritického týdeníku The Times Literary Supplement za období 1902 až 1990. Přístup z MU je omezen na 4 současně
pracující uživatele.
ULRICH’s International Periodicals Directory <http://www.ulrichsweb.
com/> Databáze ULRICH’S poskytuje podrobné bibliografické informace o více než
250000 periodikách, ročenkách a dalších titulech z celého světa. Obsahuje také podrobné kontakty na jednotlivé vydavatele, přímé odkazy na abstrakty či plné texty
vlastněné danou knihovnou. Slouží především knihovníkům, ale může poskytnout
cenné informace pro kteréhokoliv uživatele hledající informace o světových periodikách.
Wiley Medical Reference Works <http://www3.interscience.wiley.com/>
Elektronické verze „Reference Work“ nakladatelství Wiley a jejich dalších publikací.
Tato část byla vytvořena s využitím informací z [5] a [15]
76

Automatické zpracování informací webových portálů

Transkript

Podobné dokumenty

Rozklikněte si též článek o našem projektu v časopise Chatař

RE/MAX Italy - RE/MAX Kenya

fronte VR 38 EUROPE - Viroplastic CZ, as

Nastavitelné součásti a sestavy