}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Personalizace a profilovaní vyhledávání vˇedeckých publikací D IPLOMOVÁ PRÁCE
Bc. Jan Kubˇeja
Brno, podzim 2006
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: Mgr. Jan Pavloviˇc ii
Podˇekování Rád bych podˇekoval vedoucímu projektu Mgr. Janu Pavloviˇcovi za odborné vedení a konˇ zultace pˇri tvorbˇe této diplomové práce. Dále bych chtˇel podˇekovat Mgr. Jakubu Durovcovi za seznámení s aktuálním stavem a nedostatky vyhledávacího systému pˇred mými úpravami.
iii
Shrnutí Obsahem práce je analýza a implementace personalizace a profilování do vyhledávacího systému nad elektronickými zdroji Masarykovy Univerzity. V úvodních kapitolách je popsán vyhledávací systém, jeho stav a funkce pˇred implementací personalizace. V dalších kapitolách bude cˇ tenáˇr seznámen s úpravami, které byly v rámci návrhu implementace na vyhledávacím systému provedeny. Jedná se pˇredevším o personalizaci, dále potom také o vizualizaci nalezených výsledku, ˚ zobrazení postupu pˇri vyhledávání a zaˇclenˇení nové webové služby, která vrací nalezené výsledky formou XML dokumentu.
iv
Klíˇcová slova Java, vyhledávání, elektronické zdroje MU, webová služba, Internet, vˇedecké publikace, personalizace, profilování, CCS tˇrídy
v
Obsah 1 2
3
4
5
6
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vyhledávací systém vˇedeckých publikací VEZMU . . . 2.1 Architektura systému . . . . . . . . . . . . . . . . . . 2.1.1 Uživatelský klient . . . . . . . . . . . . . . . 2.1.2 Klient . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Server . . . . . . . . . . . . . . . . . . . . . . 2.1.3.1 Downloader . . . . . . . . . . . . . 2.1.3.2 Cache . . . . . . . . . . . . . . . . . 2.1.4 Plugin . . . . . . . . . . . . . . . . . . . . . . Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Webové služby - Web services . . . . . . . . . . . . . 3.1.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 WSDL . . . . . . . . . . . . . . . . . . . . . . 3.1.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Implementace XFire . . . . . . . . . . . . . . 3.1.4.1 Praktický pˇríklad použití z projektu 3.2 Apache Struts . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Konfigurace . . . . . . . . . . . . . . . . . . . Personalizace . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Personalizace v digitálních knihovnách . . . . . . . 4.1.1 Klasifikace metod personalizace . . . . . . . 4.2 Personalizace vyhledávacího systému . . . . . . . . 4.2.1 Preprocessing dotazu . . . . . . . . . . . . . 4.2.2 Elektronický zdroj ACM . . . . . . . . . . . . 4.2.3 CCS klasifikace . . . . . . . . . . . . . . . . . 4.2.4 Autentizace uživatele vuˇ ˚ ci INET MUNI . . . 4.2.5 Uživatelský profil . . . . . . . . . . . . . . . . 4.2.5.1 Úložištˇe profilu˚ . . . . . . . . . . . . Vizualizace nalezených výsledku˚ . . . . . . . . . . . . . 5.1 Postprocessing . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Pomocná CCS mapa výsledku˚ . . . . . . . . 5.1.2 CCS strom . . . . . . . . . . . . . . . . . . . . 5.2 Informace o nalezených publikacích . . . . . . . . . 5.3 Vizualizace . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Textový výpis . . . . . . . . . . . . . . . . . . 5.3.2 Grafický výpis . . . . . . . . . . . . . . . . . Zobrazení postupu pˇri vyhledávání . . . . . . . . . . . . 6.1 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Implementace u serveru . . . . . . . . . . . . . . . . 6.3 Implementace u klienta . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 2 2 3 3 4 4 4 7 7 8 9 9 9 9 11 11 13 13 14 15 16 16 17 17 18 19 22 22 23 24 24 24 25 25 30 30 31 32 vi
7
Výsledky formou XML . . . . . . . . . . 7.1 Rozhraní služby . . . . . . . . . . . . 7.2 Implementace služby . . . . . . . . . 7.3 Pˇridání webové služby do seznamu 8 Závˇer . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . Rejstˇrík . . . . . . . . . . . . . . . . . . . . . . A Obsah pˇriloženého CD . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
37 38 38 39 41 43 44 45
vii
Kapitola 1
Úvod Tato diplomová práce je primárnˇe zamˇerˇ ena na to, jak vylepšit stávající vyhledávací systém vˇedeckých publikací MU z hlediska personalizace a profilování. Tento vyhledávací systém byl puvodnˇ ˚ e vyvinut v rámci pˇredmˇetu PA165 - Vývoj programových systému˚ v jazyce JAVA jedním z projektových týmu. ˚ Systém je funkˇcní a je nasazen v provozu v prostˇredí univerzity a svou vyhledávací funkci provádí správnˇe. Ovšem cˇ asem se zjistilo, že by bylo vhodné jej po nˇekolika stránkách vylepšit. Jedná se zejména o nˇejakou uživatelsky pˇrívˇetivou prezentaci nalezených výsledku˚ a o personalizaci ve vyhledávání. Stávající systém totiž funguje tak, že na zadaný dotaz odpoví velkým poˇctem nalezených výsledku, ˚ které nejsou žádným zpusobem ˚ seˇrazeny a hlavnˇe nejsou žádným standardním zpusobem ˚ klasifikovány. Tyto problémy by mˇela tato práce vyˇrešit. Kromˇe personalizace a vizualizace výsledku˚ je tato práce ještˇe o dalších úpravách systému, pˇresnˇeji jde o zobrazování postupu vyhledávání a o vytvoˇrení webové služby, která poskytuje výsledky formou XML dokumentu.
1
Kapitola 2
Vyhledávací systém vˇedeckých publikací VEZMU Vyhledávací systém vˇedeckých publikací VEZMU (Vyhledávaˇc nad Elektronickými Zdroji MU) je projekt který vznikl v rámci pˇredmˇetu PA165 - vývoj programových systému˚ v jazyce Java. Jeho hlavní úˇcel byl zapouzdˇrit ruzné ˚ zpusoby ˚ vyhledávání nad ruznými ˚ dostupnými elektronickými zdroji do z uživatelského hlediska jediné aplikace, která se uživateli má jevit jako samostatný vyhledávaˇc vˇedeckých publikací nad nˇekolika více dostupnými elektronickými zdroji. Dˇríve bylo totiž možné vyhledávat pouze nad každým el. zdrojem zvlášt’, každý zdroj má své vlastní obecnˇe ruzné ˚ rozhraní k vyhledávání. Dá se tedy rˇ íct, že když uživatel chtˇel vyhledat maximum publikací, které vyhovují danému dotazu, musel vyhledávat nad každým zdrojem zvlášt’, což je pochopitelnˇe zdlouhavé a nepˇríjemné.
2.1
Architektura systému
Celý systém je navržen jako nˇekolik webových aplikací, které mezi sebou komunikují prostˇrednictvím webových služeb. Jedná se tedy o servisnˇe orientovanou architekturu (SOA). Systém je tedy navržen pomˇernˇe hodnˇe modulárnˇe, což má za následek nˇekolik výhod, zejména to, že každý z modulu˚ muže ˚ fungovat samostatnˇe na jiném servlet containeru cˇ i aplikaˇcním serveru. Každý modul v sobˇe zapouzdˇruje svou funkcionalitu, kterou ostatním komponentám poskytuje prostˇrednictvím definovaného rozhraní. Komponenty mezi sebou komunikují pomocí SOAP protokolu, ovšem systém s uživatelem resp. uživatelskou aplikací cˇ i klientem komunikuje prostˇrednictvím protokolu HTTP. Na obrázku je zakreslena architektura systému. Jednotlivé souˇcásti budou dále podrobnˇeji rozebrány. 2.1.1
Uživatelský klient
Pod pojmem uživatelský klient mˇejme na mysli klientskou aplikaci cˇ i obecnˇe pˇrístroj, který pˇristupuje k vyhledávání jakožto k celému systému. Tato komponenta tedy není souˇcástí vyhledávacího systému, ale je potˇreba ji zde také uvést. Typicky se tedy jedná o nˇejaký webový prohlížeˇc na stranˇe uživatele, který vidí celý systém pouze jako jednu velkou serverovou aplikaci. Tímto uživatelským klientem ovšem muže ˚ být cokoliv dalšího, co je schopné komunikovat s vyhledávacím systémem prostˇrednictvím HTTP protokolu. Muže ˚ to tedy být i nˇejaká jiná aplikace nebo také nˇejaký jiný webový prohlížeˇc v PDA pˇrístrojích. 2
2.1. ARCHITEKTURA SYSTÉMU
ˇ Obrázek 2.1: Architektura systému, zdroj: Jakub Durovec - Komponentová zapouzdˇrenost webových aplikací 2.1.2
Klient
Klient je webová aplikace, která slouží jako rozhraní systému s uživatelem nebo chceme-li s uživ. klientem. Uživatel vidí pouze tuto aplikaci, zde zadává vyhledávací dotaz a poté je zde seznámen s výsledky vyhledávání. Tato aplikace je navržena s využitím možností aplikaˇcního rámce Apache Struts, který slouží k vývoji web. aplikací tak, že plnˇe podporuje model architektury MVC (Model View Controller). K provozu této aplikace staˇcí jednoduchý servlet container jako je napˇr. Apache Tomcat. 2.1.3
Server
Server je jádrem systému. Pˇreposílá vyhledávací dotaz zadaným elektronickým zdrojum ˚ (pˇresnˇeji jejich pluginum) ˚ a dále shromažd’uje výsledky vyhledávání a potom je odesílá WS klientovi. Server nerozlišuje typy dotazu, ˚ neví jak se nad kterým elektronickým zdrojem vyhledává. Pˇri pˇrijetí dotazu od klienta s si z nˇej zjistí, ve kterých el. zdrojích se má dále vyhledávat a na ty tento dotaz odešle a cˇ eká na výsledky. K provozu této aplikace staˇcí též 3
2.1. ARCHITEKTURA SYSTÉMU
Obrázek 2.2: Aplikace Klient jednoduchý servlet container jako je napˇr. Apache Tomcat. Když se podíváme na informaˇcní JSP stránku serveru, vypíše se nˇekolik informací, zejména zde vidíme seznam vyhledávacích pluginu, ˚ které server v aktuální konfiguraci muže ˚ využívat na vyhledávání. 2.1.3.1 Downloader Aplikace server dále funguje jako Downloader - pˇresnˇeji ze všech nalezených publikací vybere nˇekolik prvních (dle nastavení) z nich a dané publikace se pokusí stáhnout ze vzdálené elektronické knihovny k sobˇe do své databáze. 2.1.3.2 Cache Server má k dispozici svoji cache. Uchovává si historii dotazu˚ kladených na systém a jejich nalezené výsledky, aby pro následující stejný dotaz nemusel systém vyhledávat stejné publikace znovu. Takže prakticky to funguje tak, že pˇrijde-li na server vyhledávací dotaz, tak se nejdˇríve prohledá cache, zda-li nebyl náhodou tento dotaz už v poslední dobˇe zpracován. Když ano, výsledky se naˇctou z cache, když ne, tak se pokraˇcuje ve standardním vyhledávacím postupu. Tato cache je realizována pomocí databáze PostgreSQL a aplikace s ní komunikuje pomocí JDBC. 2.1.4
Plugin
Systém má k dispozici nˇekolik elektronických zdroju˚ nad kterými vyhledává. Ovšem tyto zdroje jsou obecnˇe ruzné, ˚ pˇresnˇeji komunikace s nimi je obecnˇe ruzná. ˚ Proto je systém dále navržen tak, že s tˇemito zdroji nekomunikuje hlavní komponenta server, nýbrž speciální pluginy. Plugin má za úkol pˇrevzít od serveru dotaz ve standardní jednotné formˇe (pˇresnˇeji objekt tˇrídy, která implementuje rozhraní standardního vyhl. dotazu), a podle tohoto dotazu 4
2.1. ARCHITEKTURA SYSTÉMU
Obrázek 2.3: Aplikace Server se patˇriˇcnˇe dotazuje na jeden svuj ˚ konkrétní elektronický zdroj. Tedy každý plugin umí vyhledávat ve svém el. zdroji a také z nˇej cˇ íst výsledky vyhledávání. Tyto výsledky se opˇet pˇrevedou do jisté standardní formy srozumetelné pro server a vrátí se serveru, který je takto zaˇcnˇe sbírat od všech požadovaných vyhledávacích pluginu, ˚ které se této jedné vyhledávací akce zúˇcastnily. Na poˇcátku implementace systému byly k dispozici cˇ tyˇri elektronické zdroje. V prubˇ ˚ ehu dalšího vylepšování systému jich pˇribývalo. V souˇcasné dobˇe je jich šest a mám informace, že se plánuje zaˇclenˇení dalších dvou el. zdroju. ˚ Souˇcasné elektronické zdroje jsou uvedeny v seznamu níže. •
Nature - Nature DLhttp://www.nature.com 5
2.1. ARCHITEKTURA SYSTÉMU •
ACM - Association for Computing Machinery DL, http://www.nature.com
•
IEEE - IEEE computer society DL, http://www.computer.org/portal/site/csdl/
•
DocBook - DocBook DL, http://www.docbook.org/search/
•
Link - Springer Link DL, http://www.springerlink.com/
•
Oxford-Ref - Oxford Reference Online, http://www.oxfordreference.com/
Pluginu˚ je tedy v systému nˇekolik, každý z nich je jedna webová aplikace. K provozu každé této aplikace staˇcí též jednoduchý servlet container jako je napˇr. Apache Tomcat.
6
Kapitola 3
Technologie Dˇríve než se budeme podrobnˇeji zabývat úpravami celého vyhledávacího systému, seznámíme se s nˇekolika zásadními technologiemi, na kterých je projekt postaven. Jedná se tedy pˇredevším o: •
Web Services - webové služby, slouží ke komunikaci mezi komponentami systému
•
Apache Struts - open-source framework pro tvorbu webových aplikací dle modelu MVC
3.1
Webové služby - Web services
Webové služby pˇredstavují standardizované rozhraní pro komunikaci a pˇrenos dat mezi ruznorodými ˚ aplikacemi, které mohou bˇežet na obecnˇe ruzných ˚ operaˇcních systémech. Jsou založeny na mnoha dalších technologiích a standardech. Nahrazují dˇrívˇejší zpusob ˚ komunikace pˇres HTTP protokol pomocí metod GET a POST. Puvodnˇ ˚ e fungovala komunikace mezi dvˇema aplikacemi cˇ asto tak, že klient zaslal HTTP požadavek na server a to použitím metody GET cˇ i POST, které umožnují ˇ v rámci tohoto požadavku zaslat i požadovaná data. Server požadavek pˇrijal, data zpracoval a výsledek zaslal klientovi jako HTTP odpovˇed’. Tento zpusob ˚ komunikace ovšem skrývá nˇekolik nevýhod, zejména fakt, že pˇrenášená binární data jsou závislá na architektuˇre cˇ i operaˇcním systému. A jak se data budou posílat nebylo nikde rˇ eˇceno. Webové služby mají standardizovaný zpusob ˚ pˇrenosu dat, díky kterému se vyhneme tomuto problému. Využívá jazyka XML, který je vhodný pro pˇrenos ruzných ˚ textových dat, ale také i složitˇejších datových struktur. Webové služby využívají tˇechto standardu: ˚ •
SOAP
•
WSDL
•
UDDI
7
3.1. WEBOVÉ SLUŽBY - WEB SERVICES
Obrázek 3.1: Schéma komunikace a standardu˚ webových služeb, zdroj: Wikipedia http://en.wikipedia.org/wiki/Web_service 3.1.1
SOAP
SOAP (Simple Object Access Protocol) je protokol pro zasílání zpráv obvykle pˇres HTTP protokol. Definuje rozšiˇritelný formát zpráv mezi klientem a serverem založený na XML. Tedy cokoliv se odesílá, musí se pˇrevést do tohoto formátu. Textová data nejsou problémem, ale v pˇrípadˇe dat binárních je ještˇe nutné je zakódovat pomocí kódování BASE64. Toto kódování a následné dekódování s sebou ovšem nese nˇejakou cˇ asovou nároˇcnost. Zde je uveden pˇríklad SOAP zprávy, kterou vygeneroval klient a zasílá ji serveru: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>
<productID>827635
A tady je SOAP odpovˇed na požadavek od klieta: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>
<productName>Toptimate 3-Piece Set <productID>827635
8
3.1. WEBOVÉ SLUŽBY - WEB SERVICES <description>3-Piece luggage set. Black Polyester. <price>96.50 true
3.1.2
WSDL
WSDL (Web Services Description Language) je XML formát pro popis webových služeb. Definuje zpusob, ˚ jak lze volat danou vebovou službu a jakým zpusobem ˚ se pak vrací výsledek. Díky tomuto popisu si muže ˚ klient nejprve zjistit, jaké služby nabízí server. V tomto popisu jsou také zaˇclenˇeny formáty ruzných ˚ složitˇejších datových struktur formou XML schématu. Na základˇe WSDL popisu muže ˚ klient sestavit SOAP požadavek. 3.1.3
UDDI
UDDI (Universal Description, Discovery, and Integration) je další ze základních standardu˚ pro webové služby. Je to veˇrejný registr, uchovává informace o webových službách a jejich poskytovatelích ve formátu XML. Registr je pˇrístupný prostˇrednictvím své webové služby, tedy pomocí protokolu SOAP. 3.1.4
Implementace XFire
V tomto projektu byla zpoˇcátku používána pro webové služby implementace Apache Axis. Nicménˇe vývojáˇri cˇ asem zjistili, že to s sebou nese nˇekolik problému˚ napˇr. cˇ asová nároˇcnost, absence podpory Javy 5 . Potom bylo rozhodnuto pˇrepracovat projekt tak, aby se používala implementace webových služeb XFire, která rˇ eší všechny výše uvedené problémy a navíc programování komunikace je jednodušší. 3.1.4.1 Praktický pˇríklad použití z projektu Nyní si popíšeme, jak vypadá komunikace mezi klientem a serverem pomocí webové služby, konkrétnˇe implementace XFire. Je potˇreba provést následující kroky: •
Na stranˇe serveru vytvoˇrit rozhraní služby a tˇrídu, která jej implementuje
•
Nakonfigurovat server
•
–
XFire
–
aplikaci
Implementovat klienta 9
3.1. WEBOVÉ SLUŽBY - WEB SERVICES Na stranˇe serveru tedy máme rozhraní SearchService, které specifikuje dvˇe metody s názvem processQuery: package cz.muni.fi.vezmu; import java.util.Vector; public interface SearchService{ public Vector<Metadata> processQuery (Query query) throws SearchException; public Vector<Metadata> processQuery (String query) throws SearchException; }
Dále na stranˇe serveru máme tˇrídu Server, která toto rozhraní implementuje. Nyní je potˇreba ještˇe nˇejak dát rámci XFire na vˇedomí, že je zde tato služba k dispozici. V adresáˇri webové aplikace se vytvoˇrí soubor META-INF/xfire/services.xml, který slouží k popisu jednotlivých webových služeb. Popis naší konkrétní služby je následující:
<service> VezmuService cz.muni.fi.vezmu <serviceClass>cz.muni.fi.vezmu.SearchService cz.muni.fi.vezmu.server.Server
Ještˇe je potˇreba v aplikaˇcní konfiguraˇcním souboru web.xml nadefinovat XFireServlet a jeho URL: <servlet> <servlet-name>XFireServlet
XFire Servlet <servlet-class> org.codehaus.xfire.transport.http.XFireConfigurableServlet <servlet-mapping> <servlet-name>XFireServlet
/servlet/XFireServlet/* <servlet-mapping> <servlet-name>XFireServlet
/services/*
V tuto chvíli je webová služba na stranˇe serveru prakticky pˇripravena k použití. Její WSDL popis mužeme ˚ získat pomocí XFireServletu pˇri HTTP GET dotazu na URL 10
3.2. APACHE STRUTS http://localhost:8084/vezmu-server/services/VezmuService?wsdl
kde http://localhost:8084/vezmu-server/ je URL, kde je aplikace v tuto chvíli nasazena. Na stranˇe klienta je potˇreba provést požadavek na tuto službu, což je v pˇrípadˇe použití rámce XFire docela jednoduché: ... //Define service URL String serviceUrl = "http://localhost:8084/vezmu-server/"
;
//Create a metadata of the service Service serviceModel=new ObjectServiceFactory().create(SearchService.class); //Create a proxy for the deployed service XFire xfire = XFireFactory.newInstance().getXFire(); XFireProxyFactory factory = new XFireProxyFactory(xfire); SearchService client = null; try{ client = (SearchService) factory.create(serviceModel, serviceUrl); }catch (MalformedURLException ex) { throw new SearchException("Malformed web-service URL", ex); } //Invoke the service Vector<Metadata> serviceResponse = null; serviceResponse = client.processQuery(query); ...
3.2
Apache Struts
Struts je jedním z frameworku˚ pro tvorbu webových aplikací, který dodržuje architekturu MVC (Model View Controller). Tento model vznikl z toho duvodu, ˚ že se cˇ asto programují webové aplikace pomˇernˇe chaoticky, tedy napˇr. do JSP stránek se vkládají kusy databázových kódu˚ cˇ i kód, který zpracovává data odeslaná z pˇredchozí stránky a podobnˇe. MVC model rozdˇeluje celý kód aplikace na tˇri cˇ ásti. Model reprezentuje datovou vrstvu, View reprezentuje design web. stránek, Controller reprezentuje navigaˇcní záležitosti aplikace, stará se o data zadaná uživatelem a volá datovou vrstvu. 3.2.1
Konfigurace
Konfigurace rámce Struts se provádí v souboru struts-config.xml. Nastavuje se zde vše co tento rámec nabízí: •
Form Beans - formuláˇrové beany
•
Global Exceptions - globální vyjímky 11
3.2. APACHE STRUTS •
Global Forwards - globální pˇresmˇerování
•
Action Mappings - mapování akcí na URL
•
Message Resources - zdroje pro texty a zprávy v aplikaci
•
a další
Nejvýznamˇejším nastavením jsou definice akcí a jejich mapování na URL. Z tˇechto definic lze pak krásnˇe vidˇet, jak aplikace pracuje a jak probíhá interakce s uživatelem. Zde je uvedena jedna z akcí aplikace klient vyhledávacího systému:
type="cz.muni.fi.vezmu.client.QueryAction"
Tato akce ja definována tak, že ji rámec Struts spustí, když pˇrijde požadavek na URL /Search.setSource. Tato akce má k sobˇe asociován form-bean queryForm, který je umístˇen v oblasti session. Formuláˇrová data se mají validovat, a když se pˇri validaci vyskytne chyba, rˇ ízení se vrátí na stránku /pages/Source.jsp. Je-li validace bez chyb, rˇ ízení se pˇredá tˇrídˇe cz.muni.fi.vezmu.client.QueryAction resp. její metodˇe execute, která vrací výsledek jako objekt tˇrídy ActionForward. Zde se nabízí k použití forward default, který pˇredá rˇ ízení JSP stránce /pages/AdvancedQuery.jsp.
12
Kapitola 4
Personalizace Personalizace elektronických knihoven snižuje rozdíl mezi tím, co všechno muže ˚ knihovna uživateli nabídnout a tím, co je skuteˇcnˇe potˇreba v této knihovnˇe najít. Vzhledem k tomu, že každá skupina uživatelu˚ vyžaduje jiné typy informací, hraje personalizace významnou roli v jejich vyhledávání. Hlavním pˇrínosem personalizace je pˇredvýbˇer obsahu, strukturování obsahu v závislosti na dané specifické doménˇe a obohacení obsahu o metadata.
4.1
Personalizace v digitálních knihovnách
Digitální knihovna je prostˇredníkem mezi uživatelem resp. jeho informaˇcními potˇrebami a mezi globálnˇe dostupným obsahem informací. Její funkcionalita se dá rozdˇelit do cˇ tyˇr následujících funkcí. •
Pˇredvýbˇer obsahu (content pre-selection) - knihovna vybere kvalitní obsah potenciálnˇe relevantní pro danou zájmovou skupinu uživatelu˚
•
Strukturování obsahu (content structuring) - knihovna vytváˇrí strukturu obsahu dle významných domén zájmových skupin uživatelu. ˚
•
Obohacení obsahu (content enrichment) - knihovna obohacuje objekty obsahu popisujícímy metadaty
•
Knihovní služby (library services) - služby pro získání obsahu, pro pˇrístup a pro podporu identifikace relevantních materiálu. ˚
Pˇrestože tyto cˇ tyˇri techniky umožnují ˇ digitálním knihovnám výraznˇe zmenšit rozdíl mezi hojným a ruznorodým ˚ obsahem a specifickými informaˇcními potˇrebami konkrétních uživatelských komunit , stále je zde jistý nedostatek v tom, že obsah a služby jsou nabízeny komunitˇe jakožto celku. Informaˇcní potˇreby jednotlivcu˚ cˇ i menších skupin uživatelu˚ jsou urˇceny ruznými ˚ faktory, které jsou celkovˇe nazývány jako kontext použití (context-of-use). Mimoto individuální konceptualizace informaˇcního spektra, které se obecnˇe u každého uživatele liší ovlivnuje ˇ individuální pˇrístup. Tedy personalizace u digitálních knihoven pˇredstavuje i to, že knihovny v závislosti na kontextu použití nabízí jednotlivcum ˚ specifický pohled na obsah, místo jednotného pohledu pro celou komunitu. 13
4.1. PERSONALIZACE V DIGITÁLNÍCH KNIHOVNÁCH
Obrázek 4.1: Digitální knihovna jako prostˇredník mezi obsahem a komunitou uživatelu, ˚ zdroj: Erich Neuhold - Personalization in Digital Libraries An extended view 4.1.1
Klasifikace metod personalizace
Na základˇe výše uvedeného netriviálního pohledu na personalizaci v digitálních knihovnách mohou být metody personalizace klasifikovány dle obrázku 4.2. Na nejvyšší úrovni máme personalizaci v digitálních knihovnách, u které dále rozlišujeme metody, které se odkazují na služby knihovny a metody, které se odkazují na obsah knihovny. U personalizace služeb knihovny dále rozlišujeme služby pro podporu personalizace jako napˇr. individuální notifikace a personalizaci vlastností služeb jako napˇr. personalizovaná vizualizace, individuální nastavení služeb a podobnˇe. Personalizace obsahu je rozdˇelena na tˇri cˇ ásti. Personalizace pomocí obohacování informací (content enrichment), personalizace pomocí výbˇeru obsahu (content selection) a personalizace pomocí individuálního strukturování obsahu (content structuring). V pˇrípadˇe obohacování informací jsou k usnadnˇení individuálních rozhodnutí poskytována dodateˇcná metadata. To mohou být komentáˇre expertu˚ dané domény, ruzná ˚ doporuˇcení získaná na základˇe podobností uživatelských preferencí a jiných typu˚ anotací. Personalizace pomocí výbˇeru obsahu obsahuje metody, které používají filtrování informací na základˇe uživatelských preferencí. Vˇetšina tˇechto 14
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU
Obrázek 4.2: Klasifikace metod personalizace, zdroj: Erich Neuhold - Personalization in Digital Libraries An extended view metod je založena na modelování charakteru uživatele napˇr. oblast zájmu uživatele. Metody získávají tato data sledováním chování uživatele. Jednoduchá forma personalizace pomocí strukturování obsahu je poskytnutí dodateˇcných vstupních bodu˚ (entry points) k nabídce dané informace v digitální knihovnˇe. Další formou mohou výt navigaˇcní zkratky - dodateˇcné navigaˇcní struktury, které jsou vytváˇreny na základˇe frekvence navigací použitých uživatelem.
4.2
Personalizace vyhledávacího systému
Nˇekteré zájmové skupiny uživatelu˚ cˇ i pˇrímo nˇekteˇrí uživatelé by rádi oˇcekávali od systému takovou vlastnost, že bude pˇri vyhledávání brát na zˇretel i jejich implicitní pˇredem definované parametry napˇr. vˇední oblast, minimální a maximální rok vydání publikace a podobnˇe. Vyhledávací systém je totiž navržen tak, že vrací pomˇernˇe velké množství dokumentu˚ bez ohledu na to, v jaké míˇre jsou k dotazu relevantní. Vznikl tedy požadavek, aby byl vyhledávací systém patˇriˇcnˇe pˇrepracován a aby do nˇej byla implementována v jisté míˇre personalizace. Puvodnˇ ˚ e systém totiž umˇel vyhledávat maximálnˇe podle nˇekolika málo vstupních údaju: ˚ •
Vlastní dotaz
•
Autor
•
Název publikace 15
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU •
Minimální datum vydání
•
Maximální datum vydání
•
Klíˇcová slova
•
Velikost seznamu výsledku˚
•
Preferovaný jazyk
Tˇechto parametru˚ není mnoho, ale hlavnˇe mezi nimi není žádný takový, který by nˇejakým zpusobem ˚ reprezentoval pˇríslušnost k nˇejaké konkrétní vˇední oblasti. Dále systém nerozlišuje uživatele. Uživatel se prostˇe dostane na vyhledávací formuláˇr, zadá nˇekterá z tˇechto mála kritérií a spustí vyhledávání. Chce-li poté vyhledávat znovu, vrátí se na zmínˇený formuláˇr a nezbývá mu nic jiného než zadat dotaz znovu, i když má uživatel na mysli dotaz docela podobný tomu pˇredchozímu. Struˇcnˇe rˇ eˇceno, neprobíhá zde žádná personalizace, žádná autentizace, systém se ke všem uživatelum ˚ chová stejnˇe. 4.2.1
Preprocessing dotazu
Chceme systém vylepšit. Jedno z vylepšení spoˇcívá v preprocessingu nebo-li pˇredzpracování dotazu v závislosti na daném uživateli, který dotaz zadal. Stávající vyhledávací systém totiž nic takového neumožnuje, ˇ pracuje dle activity diagramu, který je znázornˇen na obrázku 4.3. My potˇrebujeme totiž ještˇe pˇred zahájením vyhledávání provést nˇejaké vhodné zpracování dotazu, obohacení dotazu v závislosti na konkrétním uživateli. Je tedy potˇreba si nˇekde pamatovat seznam výchozích vyhledávacích parametru˚ uživatele a pˇred vlastním vyhledáváním tyto parametry spolu se zadaným dotazem nˇejakým zpusobem ˚ spojit v jeden nový dotaz, který bude dále vyslán serveru k vyhledávání. Systém by mohl vypadat následujícím zpusobem, ˚ který je znázornˇen activity diagramem na obrázku 4.4. Postprocessing a výpisy výsledku˚ dle CCS klasifikace jsou pˇredmˇetem další kapitoly, tyto cˇ ásti procesu vyhledávání jsou zde uvedeny jen pro úplnost. 4.2.2
Elektronický zdroj ACM
Vyhledávací systém má k dispozici nˇekolik elektronických zdroju. ˚ Jedním z nich je digitální knihovna ACM. Právˇe s ohledem na vlastnosti této knihovny bude do systému zapracována personalizace. Nabízí totiž velké množství vstupních parametru˚ k vyhledávání, ale hlavnˇe umí vyhledávat dle CCS klasifikace, což je velmi duležitý ˚ poznatek. Tato digitální knihovna poskytuje jednoduché a rozšíˇrené vyhledávání. Vyhledávací systém využívá rozšíˇrené vyhledávání. 16
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU
Obrázek 4.3: Activity diagram procesu vyhledávání stávajícího systému z hlediska zpracování dotazu 4.2.3
CCS klasifikace
CCS (Computing Classification System) je obecná klasifikace vˇedních oblastí a jejich podoblastí v rámci oboru IT. Je to hierarchie tˇríd, každá tˇrída reprezentuje jistou oblast zájmu. Každá tˇrída má svuj ˚ kód, tyto kódy dodržují jistou teˇckovou notaci. Tedy napˇr. tˇrída B.4.2 - Input/Output Devices reprezentuje oblast, která patˇrí do oblasti B.4 - INPUT/OUTPUT ˇ AND DATA COMMUNICATIONS a též do oblasti B.- Hardware. Cást výpisu hierarchie je zobrazena na obrázku 4.5.
4.2.4
Autentizace uživatele vuˇ ˚ ci INET MUNI
Aby systém mohl vubec ˚ personalizaci provádˇet, musí umˇet nˇejakým zpusobem ˚ rozlišovat a identifikovat uživatele, kteˇrí s ním pracují. Na snadˇe je tedy uživatele autentizovat. Autentizaci provádí INET MUNI pomocí Basic autentizace. Chce-li uživatel pracovat s cˇ ástí vyhledávacího systému, kde se uplatnuje ˇ personalizace, je nejdˇríve vyzván, aby zadal své pˇrihlašovací jméno a heslo platné v rámci INET MUNI. Probˇehne-li autentizace úspˇešnˇe, rˇ ízení je opˇet pˇredáno vyhledávacímu systému. Ten si ještˇe uloží identifikaci pˇrihlášeného uživatele a dále muže ˚ s uživatelem pracovat. 17
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU
Obrázek 4.4: Požadovaný activity diagram procesu vyhledávání
4.2.5
Uživatelský profil
Každý uživatel má v autentizované cˇ ásti systému svuj ˚ profil. Tento profil v praxi znamená pˇrednastavené hodnoty parametru˚ pro vyhledávání. Navíc tˇechto parametru˚ je zde podstatnˇe více než v bˇežném formuláˇri pro pokroˇcilé vyhledávání a zejména je tu parametr CCS klasifikace, který je jedním z nejvýznamˇejších podnˇetu, ˚ a na kterém vubec ˚ myšlenka profilování a personalizace vyhledávacího systému vznikla. Tento profil se chová tak, že po pˇrihlášení uživatele si naˇcte jeho formuláˇrové parametry z databáze a pˇredvyplní je do formuláˇre. Uživatel tak muže ˚ mít trvale nastavena jistá vyhledávací kritéria. Do formuláˇre muže ˚ zadat další explicitní parametry. Formuláˇr má dole vedle odesílacího tlaˇcítka Search ještˇe zaškrtávací pole Save, které bývá implicitnˇe zaškrtnuto. To znamená, že formuláˇr, tak jak byl odeslán k vyhledávání publikací, se uloží uživateli do profilu. 18
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU
ˇ Obrázek 4.5: Cást výpisu hierarchie http://www.acm.org/class/1998/ccs98.html
CCS
tˇríd,
zdroj:
ACM
DL
-
4.2.5.1 Úložištˇe profilu˚ Informace z uživatelských profilu˚ je potˇreba nˇekam trvale uložit. Nejlepší volbou v této situaci je pochopitelnˇe databáze. Dokonce nám nic nebrání použít stejný databázový stroj, jaký používá komponenta server pˇri cachování, tedy databázi PostgreSQL. V této databázi již máme nˇekolik tabulek pro provoz cachování pro server, ale vubec ˚ nevadí, když bude naše úložištˇe právˇe zde. Na obrázku 4.7 je uveden ERD diagram databáze, kde entita profile tvoˇrí úložištˇe informací o profilu uživatele.
19
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU
Obrázek 4.6: ACM uživatelský profil
20
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU
Obrázek 4.7: ERD diagram vyhledávacího systému
21
Kapitola 5
Vizualizace nalezených výsledku˚ Vyhledávací systém po zadání dotazu vrací uživateli seznam výsledku. ˚ Jedná se o popisy nalezených publikace. Samotné publikace lze stáhnout až kliknutím na odkaz na pˇríslušnou publikaci. Výsledek se tedy skládá z nˇekolika informací popisujících vlastní dokument, pˇriˇcemž nˇekteré z tˇechto informací jsou základní a jsou k dispozici u každého výsledku a ostatní informace o výsledku jsou dodateˇcné, nepovinné. Povinné informace jsou v následujícím seznamu: •
Název publikace
•
Autor cˇ i autoˇri
•
Vydavatel
•
Datum vydání
•
URL odkaz na vlastní publikaci
Dodateˇcné informace do výsledku zapisuje komponenta plugin v závislosti na tom, o jaký elektronický zdroj se jedná, protože každý el. zdroj poskytuje ruzné ˚ informace o svých výsledcích. Ovšem informace, které jsou poskytovány všemi el. zdroji jsou brány jakožto základní. Problém je ovšem v tom, že výsledek vyhledávání je pro uživatele jen holý seznam výsledku, ˚ nic víc. Tento seznam není podle žádného kritéria seˇrazen, není nijak kategorizován, výsledky nejsou žádným zpusobem ˚ klasifikovány. Ovšem my bychom potˇrebovali provést po vyhledání výsledku˚ nˇejaký postprocessing, na základˇe kterého bychom potom mohli výsledky nˇejakým zpusobem ˚ setˇrídit nebo kategorizovat. Chtˇeli bychom, aby systém vypadal asi tak, jak je uvedeno na obrázku 4.4 pˇredchozí kapitoly.
5.1
Postprocessing
Postprocessing nebo-li zpracování výsledku˚ po vyhledávání se provádí na stranˇe klienta. Jeho prubˇ ˚ eh je znázornˇen na activity diagramu na obrázku 5.1. 22
5.1. POSTPROCESSING
Obrázek 5.1: Activity diagram postprocessingu 5.1.1
Pomocná CCS mapa výsledku˚
Postprocessing je navržen tak, že pˇri finálním výpisu výsledku˚ dle CCS stromu se musí v daný okamžik nˇejak zjistit, které všechny výsledky patˇrí do dané CCS tˇrídy. Šlo by to sice provádˇet nˇejakým iteraˇcním cyklem pˇres všechny výsledky, ale toto rˇ ešení by bylo pomˇernˇe neefektivní. Je lepší, když si systém hned na poˇcátku zpracování výsledku˚ vytvoˇrí tzv. CCS mapu výsledku, ˚ pomocí které si bude mapovat CCS tˇrídu na seznam výsledku, ˚ které do ní patˇrí. Toto rˇ ešení bude efektivnˇejší a tedy i rychlejší a navíc se dá pozdˇeji vytvoˇrená CCS mapa využít i k dalším pˇrípadným vylepšováním systému. Využijeme toho, že po získání výsledku˚ od serveru si klient všechny výsledky postupnˇe projde, pˇresnˇeji prochází se seznam výsledku˚ od serveru a tvoˇrí se nový seznam výsledku˚ v podobˇe jiných objektu, ˚ se kterými umí klient lépe pracovat. V rámci tohoto procházení se cˇ íslo výsledku patˇriˇcným zpusobem ˚ zapíše do CCS mapy. Tato mapa má v sobˇe tˇri základní privátní objekty: •
private HashMap<String, List
> primaryMap ;
•
private HashMap<String, List > additionalMap ;
•
private List unclassifiedList ;
Mapa primaryMap mapuje kód CCS tˇrídy na seznam cˇ ísel výsledku, ˚ které mají tuto CCS tˇrídu jakožto primární klasifikaci. Mapa additionalMap mapuje kód CCS tˇrídy na seznam cˇ ísel výsledku, ˚ které mají tuto CCS tˇrídu jakožto dodateˇcnou klasifikaci. Každý výsledek je bud’ klasifikován nebo neklasifikován. Je-li neklasifikován, pak nepatˇrí do žádné z map, patˇrí do seznamu neklasifikovaných výsledku, ˚ tedy do seznamu unclassifiedList. Je-li výsledek klasifikován, je zaˇrazen do mapy primárních klasifikací dle své klasifikace, má-li dále ještˇe nˇejaké dodateˇcné klasifikace, je také patˇriˇcnˇe zaˇrazen do mapy dodateˇcných klasifikací. 23
5.2. INFORMACE O NALEZENÝCH PUBLIKACÍCH 5.1.2
CCS strom
Je potˇreba, aby systém znal strukturu CCS stromu, protože právˇe podle tohoto stromu se provádí výpis seznamu výsledku. ˚ Tato struktura je dána XML souborem. My ovšem potˇrebujeme na procházení tohoto stromu nˇejaký lepší mechanismus objekt org.w3.dom.Document, který bychom jednoduše vytvoˇrili na základˇe tohoto souboru. Pro procházení CCS stromu pˇri výpisu výsledku˚ bude vhodnˇejší struktura jiná, protože XML soubor obsahuje daleko více informací než je k tomuto úkolu potˇreba a tudíž je pomˇernˇe velký. Na práci se strukturou CCS stromu byla navržena tˇrída CCSTree, která reprezentuje strom a každý jeho list je objekt tˇrídy CCSNode. Tˇrída CCSTree je singleton tj. budeme používat pouze jedinou její instanci. To proto, protože v konstruktoru se provádí naˇcítání dat z XML souboru a konstrukce vlastního podstromu a navíc není duvod, ˚ aby se to provádˇelo opakovanˇe.
5.2
Informace o nalezených publikacích
Když se podíváme na obrázek 5.1 a zamˇerˇ íme na proces Vyhledávání výsledku˚ tak zjistíme, že pod tímto procesem se skrývá nˇekolik dalších akcí, které musí server zajistit: •
Zjistit z dotazu seznam elektronických zdroju, ˚ které se mají použít
•
Poslat dotaz všem pˇríslušným pluginum ˚
•
Zadat dotaz a získat výsledky - provádí každý z pluginu˚
•
Shromáždit výsledky od všech pluginu˚ do jednoho seznamu
Informace o nalezených publikacích tedy získávají až pˇríslušné pluginy. Žádná jiná komponenta systému žádné další informace nepˇridává. My ovšem chceme, aby se seznam výsledku˚ dal podle nˇecˇ eho klasifikovat, ale žádná ze stávajících informací o výsledku nám to neumožnuje. ˇ Cílem tedy je alesponˇ u zdroje ACM získat ještˇe informaci o CCS klasifikaci výsledku, aby se dal potom výpis výsledku˚ nˇejakým zpusobem ˚ zakreslit do hierarchie CCS tˇríd. Ovšem aby se získala CCS informace o výsledku, bylo tˇreba trochu pˇrepracovat ACM Plugin, protože ten tuto informaci neposkytoval. Tato úprava prakticky znamená to, že ACM Plugin vyšle na svuj ˚ elektronický zdroj více HTTP požadavku, ˚ což v jisté míˇre zpomaluje celý vyhledávací proces, ale výhodou je, že pomocí CCS informace o výsledcích mužeme ˚ následnˇe v klientovi provést nˇejaký speciální výpis výsledku˚ dle CCS klasifikace a dále tato informace muže ˚ sloužit k dalším úˇcelum ˚ cˇ i úpravám systému.
5.3
Vizualizace
Jsme již ve fázi, kdy máme k dispozici informace o CCS tˇrídách jednotliových výsledku. ˚ Díky výše uvedeným pˇripraveným strukturám - CCS mapa a CCS strom mužeme ˚ nyní zaˇcít s vlastní vizualizací výsledku. ˚ Máme nˇekolik možností jak vizualizaci implementovat: 24
5.3. VIZUALIZACE •
Textovˇe
•
Graficky
•
Pomocí jiných technologií s tím, že by se musel znaˇcnˇe pˇrepracovat klient
Nejprve byl zvolen textový zpusob. ˚ Provedla se implementace a vypadalo to zpoˇcátku jako postaˇcující rˇ ešení. Ale pozdˇeji vznikl požadavek výpis výsledku˚ pokud možno nˇejakým zpusobem ˚ lépe zvizualizovat. Byl tedy navržen a vytvoˇren nový zpusob ˚ zobrazení, který lze považovat za grafický. Klient má tedy implementovány dva režimy zobrazení. Oba tyto režimy si dále podrobnˇeji rozebereme. 5.3.1
Textový výpis
Textový výpis je proveden následujícím zpusobem. ˚ Seznam výsledku˚ je vypsán stejným zpusobem ˚ jako dˇríve, viz. obrázek 5.2. U každého výsledku jsou vypsány tˇri nejduležitˇ ˚ ejsí informace - název publikace, vydavatel a rok vydání. Další informace se vypíší, když klikneme na malé plus, jak bývá zvykem. Pod tímto seznamem je dále vypsána relevantní cˇ ást CCS hierarchie s ohledem na nalezené výsledky - obrázek 5.3. Vypisovat celou CCS hierarchii je zbyteˇcné, je velmi rozsáhlá. Vypisuje se tedy relevantní cˇ ást, tím rozumˇejme ty tˇrídy, jejichž klasifikaci má alesponˇ jeden z výsledku˚ a jejich všechny nadtˇrídy, aby byla cesta ke každé tˇrídˇe jasná. Dále každá tˇrída, která obsahuje alesponˇ jeden výsledek je vypsána formou HTML odkazu a vedle jejího názvu máme v závorkách uveden ještˇe poˇcet nalezených publikací, které odpovídají této klasifikaci, tedy patˇrí do této CCS tˇrídy. Kliknutím na tento odkaz se dostaneme do podrobného výpisu výsledku, ˚ vypíší se pouze výsledky požadované CCS tˇrídy a pod nimi se zobrazí opˇet CCS strom tˇríd obsažených ve všech výsledcích vyhledávání. Velká vˇetšina nalezených výsledku˚ obsahuje informaci o CCS klasifikaci . Pro ty ostatní, které jsou neklasifikovány, slouží odkaz unclassified, který funguje podobnˇe jako odkazy z výše uvedené hierarchie CCS tˇríd, tj. po kliknutí se nám vypíše seznam neklasifikovaných výsledku. ˚ 5.3.2
Grafický výpis
Grafický výpis výsledku˚ je o nˇeco pestˇrejší než textový a uživatel má tak mnohem lepší pˇrehled o výsledcích vyhledávání. Textový výpis se opíral pouze o primární CCS klasifikaci publikace. Ovšem každá publikace muže ˚ mít mimo jedné primární CCS klasifikace ještˇe nˇekolik dodateˇcných. Pˇrípad, že by mˇela publikace pouze dodateˇcné klasifikace nemuže ˚ nastat. Dodateˇcných klasifikací bývá obvykle nˇekolik, zhruba jedna až pˇet. V tomto režimu jsou barevnˇe vykreslovány CCS tˇrídy ve formˇe oken, název a kód CCS tˇrídy je uveden ve hlaviˇcce okna. Každá ze tˇríd první úrovnˇe má svoji vlastní barvu, tyto barvy byly zvoleny tak, aby byly co nejvíce odlišné. Dále každá CCS tˇrída druhé a nižší úrovnˇe dˇedí barvu ze své nadˇrazené tˇrídy. Výpis probíhá podobnˇe tako v textovém režimu. 25
5.3. VIZUALIZACE Prochází se strom všech CCS tˇríd a ty které jsou pro nás zajímavé, pˇresnˇeji rˇ eˇceno ty, které jsou primární nebo dodateˇcnou klasifikací nˇekterého z výsledku, ˚ budou mít ve svém oknˇe zaznamenán daný výsledek cˇ i výsledky. Zakreslují se i všechny nadˇrazené tˇrídy od tˇrídy každého z výsledku, aby byla lépe znázornˇena daná vˇední oblast.
26
5.3. VIZUALIZACE
Obrázek 5.2: Activity diagram vyhledávání
27
5.3. VIZUALIZACE
Obrázek 5.3: Textový výpis výsledku˚ vyhledávání
28
5.3. VIZUALIZACE
Obrázek 5.4: Výpis CCS hierarchie relevantních tˇríd
29
Kapitola 6
Zobrazení postupu pˇri vyhledávání Vyhledávání je proces, který muže ˚ nˇekdy trvat pomˇernˇe dlouho, záleží na tom, jaký se zadá limit dokumentu˚ k nalezení. Když je tento limit velký, rˇ eknˇeme tˇreba 20 cˇ i 30 dokumentu, ˚ vyhledávání muže ˚ trvat i nˇekolik desítek vteˇrin. Klient je ovšem navržen tak, že od zadání dotazu až po získání odpovˇedi od serveru nedˇelá nic, jen cˇ eká. Takže uživatel nemuže ˚ oˇcekávat žádné informace co se týˇce nˇejakého postupu pˇri vyhledávání. Vyˇrešit tento problém bylo mým dalším úkolem. Jelikož se jedná o nˇejaké zobrazování postupu u klienta a jedná se o stav, kdy uživatel na nic nekliká, jen vidí stránku s nápisem „probíhá vyhledávání, cˇ ekejte prosím“, nabízí se využít technologie AJAX.
6.1
AJAX
AJAX (Asynchronous JavaScript and XML) technika vývoje interaktivních webových aplikací. Základní myšlenkou je vytvoˇrit webové stránky tak, že budou reagovat rychleji, protože pˇri komunikaci se serverem se bude pˇrenášet jen minimum potˇrebných dat. Je totiž mnoho webu, ˚ kde uživatel vyplnuje ˇ vícestránkový formuláˇr a mimo tohoto formuláˇre se na stránce vyskytuje mnoho dalších elementu, ˚ ruzné ˚ obrázky, animace a podobnˇe. Pˇri každém odeslání jednoho formuláˇre se posílá klientovi formuláˇr další s tím, že se opˇet posílá znova kompletní HTML stránka, tedy i ty obrázky a vše ostatní co stránka obsahuje. Stává se, že tento zpusob ˚ práce bývá cˇ asto pomalý právˇe z duvodu ˚ opakovaného naˇcítání stejných elementu˚ na ruzných ˚ webových stránkách. Takové vícestránkové vyplnování ˇ formuláˇre muže ˚ v klasickém pˇrípadˇe tedy pˇri použití synchronního HTTP request-response zpusobu ˚ komunikace vypadat tak, jak je uvedeno na obrázku 6.1 a nˇekdy bývá tento pˇrístup nežádoucí. Naproti tomu pˇrístup technologie AJAX je takový, že AJAX vytvoˇrí další komunikaˇcní vrstvu mezi jednou webovou stránkou a serverem, viz. obrázek 6.2. Tato vrstva pˇrebírá požadavky od uživatele a dále jej vyˇrizuje asynchronnˇe se serverem. Uživatel tedy vidí jednu webovou stránku a pomocí AJAXu se jen mˇení její obsah, mˇení se jen konkrétní elementy. Dále lze v tomto pˇrípadˇe pomocí Javascriptu provádˇet ruzné ˚ funkce, které budou volány po nˇejakých cˇ asových intervalech a budou pomocí AJAXu komunikovat se serverem, což je myšlenka, jak implementovat tento požadavek do vyhledávacího systému. A právˇe tento asynchronní pˇrístup je v pˇrípadˇe zobrazování postupu pˇri vyhledávání potˇreba. Naše situace je tedy ještˇe trochu specifiˇctˇejší tím, že uživatel bˇehem vyhledávání 30
6.2. IMPLEMENTACE U SERVERU
Obrázek 6.1: Klasická interakce klient-server, zdroj: Phill Ballard - Teach Yourself Ajax in 10 Minutes
Obrázek 6.2: AJAX interakce klient-server, zdroj: Phill Ballard - Teach Yourself Ajax in 10 Minutes nezadává žádné požadavky, tudíž je potˇreba, aby se informace o aktuálním stavu vyhledávání mˇenily automaticky po nˇejakém cˇ ase.
6.2
Implementace u serveru
Abychom mohli asynchronnˇe získávat nˇejaké informace o aktuálním stavu vyhledávání musíme provést jistou úpravu serveru, aby byl schopen tyto informace poskytovat. Implementace je taková, že server si pro každý aktuální dotaz pamatuje seznam pluginu, ˚ na kterých již vyhledávání skonˇcilo. K tomu slouží tˇrída QueryStatus. Má jeden atribut, tím je statická mapa, která si ke každému klíˇci - identifikátor dotazu pamatuje seznam prohledaných el. zdroju. ˚ Tˇrída má tˇri metody, které jsou uvedeny v seznamu níže. Dále je potˇreba zajistit komunikaci mezi webovým prohlížeˇcem a serverem. K tomu slouží zmínˇený servlet QueryStatusServlet, protože tato komunikace bude probíhat stejným 31
6.3. IMPLEMENTACE U KLIENTA zpusobem ˚ jako synchronní komunikace webového prohlížeˇce a webového serveru, tedy nad protokolem HTTP. Tento servlet umí jediné - když dostane HTTP GET požadavek, zjistí si z nˇej parametr urˇcující identifikaci vyhledávacího dotazu a zavolá výše uvedenou statickou metodu getFinishedPlugins(queryId) tˇrídy QueryStatus. Její výstup, kterým je textový rˇ etˇezec pˇredává pˇrímo do odpovˇedi na svuj ˚ požadavek. •
public static void setFinishedPlugin(String queryId, String pluginId)
Tato metoda je volána v okamžiku, kdy server zjistil, že vyhledávání nˇekterého z dotazu˚ na nˇekterém z pluginu˚ je ukonˇceno. •
public static String getFinishedPlugins(String queryId)
Tato metoda je volána ze servletu QueryStatusServlet, který slouží ke komunikaci s webovým klientem. Webový klient tak získává díky této metodˇe pˇredhled o tom, které elektornické zdroje jsou již prohledány. •
public static void queryFinished(String queryId)
Tato metoda je volána serverem pˇri ukonˇcení zpracování dotazu. Zpusobí ˚ odstranˇení klíˇce a hodnoty z uvedené mapy.
6.3
Implementace u klienta
U klienta je to tak, že pˇri odeslání dotazu se volá ve frameworku Struts akce Search.1.do. Ta zajistí zpracování dotazu z formuláˇre a pˇredá rˇ ízení JSP stránce WaitPlease.jsp. A právˇe v této stránce je potˇreba zobrazování postupu pomocí AJAXu implementovat. Souˇcasný stav systému byl takový, že klient zaslal požadavek serveru a po dobu vyhledávání se uživateli zobrazuje pouze hláška, že má cˇ ekat a jediný aktivní prvek na této JSP stránce bylo nˇekolik velkých teˇcek na rˇ ádku. Jejich poˇcet se v prubˇ ˚ ehu cˇ asu zvˇetšoval a až jich bylo moc, zredukoval se na jednu teˇcku a zase zaˇcaly teˇcky pˇribývat. Tímto aktivním prvkem chtˇel nejspíš autor uživateli naznaˇcit to, že když se dívá na tuto JSP stránku, tak mezitím vyhledávání opravdu probíhá. Ovšem poˇcet teˇcek se zvˇetšuje o jednu v pravidelném cˇ asovém intervalu a pomocí Javascriptu. Tedy tento aktivní prvek bˇeží zcela automaticky a nezávisle na stavu vyhledávání ostatních komponent systému. Zde se tedy tyto blikající teˇcky nahradily následujícím výpisem stavu vyhledávání, který již zobrazuje aktuální stav vyhledávání, který je pravidelnˇe získáván pomocí AJAXu od aplikace server, která tyto informace o stavu shromažd’uje a udržuje. Zobrazení výpisu stavu vyhledávání je znázornˇeno na obrázku cˇ . 6.3. Na zaˇcátku si klient ještˇe z dotazu zjistí, ve kterých elektronických zdrojích se bude vyhledávat. Pro každý ze zdroju˚ zapíše jeho název a stav searching.... Další funkcionalitu zajišt’ují Javascriptové funkce uvedené níže. 32
6.3. IMPLEMENTACE U KLIENTA
Obrázek 6.3: Zobrazení výpisu stavu vyhledávání
var xmlHttp; function loadStatus() { xmlHttp=GetXmlHttpObject() if (xmlHttp==null){ alert ("Browser does not support HTTP Request") ; return; } var url= vezmuServerURL + "/QueryStatus?queryId=" + queryId; xmlHttp.onreadystatechange=stateChanged ; xmlHttp.open("GET",url,true) xmlHttp.send(null) ; setTimeout("loadStatus()", 500) } function GetXmlHttpObject(){ var objXMLHttp=null ; if (window.XMLHttpRequest){ objXMLHttp=new XMLHttpRequest() ; } else if (window.ActiveXObject){ objXMLHttp=new ActiveXObject("Microsoft.XMLHTTP") ; } return objXMLHttp } function stateChanged() { if(xmlHttp.readyState==4 || xmlHttp.readyState=="complete"){ updateStatus( xmlHttp.responseText ); } } function updateStatus(str){ var array = str.split(’,’); var i ; var s; for(i in array ){ s=array[i]; var element;
33
6.3. IMPLEMENTACE U KLIENTA if(element = document.getElementById(’span-’+s)){ var html = element.innerHTML ; if(html.charAt(html.length - 1 ) == ’.’){ element.innerHTML = ’finished’; element.className=’finished’ ; } } } }
Promˇenná xmlHttp je globální, je tedy zadefinována mimo uvedené funkce, jedná se o klíˇcovou promˇennou, je to objekt tˇrídy XMLHTTPRequest. Pomocí tohoto objektu mu˚ žeme realizovat komunikaci se serverem - viz. obrázek 6.4. Nejprve je ovšem potˇreba jej patˇriˇcnˇe inicializovat. To bohužel není jednoznaˇcná záležitost, nebot’ ne všechny prohlížeˇce považují tento objekt za nativní javascriptový objekt, pˇresnˇeji rˇ eˇceno nelze vždy tento objekt inicializovat pomocí klasické konstrukce xmlHttp = new XMLHTTPRequest() ;
Tuto konstrukci sice podporuje vˇetšina prohlížeˇcu˚ napˇr. Mozilla, Opera, ale nepodporuje ji MS Internet Exporer, což je v souˇcasné dobˇe jeden z pˇredních prohlížeˇcu. ˚ Ten implementuje tento objekt jakožto ActiveX objekt. ActiveX je proprietární technologie Microsoftu, která umožnuje ˇ práci s aktivními objekty na webových stránkách. Takže v pˇrípadˇe, že je kód volán v prohlížeˇci MS I.E. je potˇreba XMLHTTPRequest inicializovat kontrukcí xmlHttp = new ActiveXObject("Microsoft.XMLHTTP") ;
Ale protože obecnˇe nevíme v jakém prohlížeˇci se bude tento kód interpretovat, musíme zajistit korektní inicializaci pro obecný prohlížeˇc. To má na starosti funkce GetXmlHttpObject(). Ta zjistí, zda prohlížeˇc podporuje XMLHTTPRequest jakožto nativní nebo jakožto ActiveX objekt a podle toho jej patˇriˇcnˇe inicializuje. Funkce loadStatus() je první podprogram, který se volá a volá se pˇrímo hned po naˇctˇení webové stránky. V této funkci se hned na zaˇcátku inicializuje výše uvedený XMLHTTPRequest objekt. Muže ˚ stát, že se jedná o nˇejaký zastaralý prohlížeˇc a inicializace se nepovedla, pˇresnˇeji funkce GetXmlHttpObject() vrátila null. Pak se pouze zobrazí uživateli zpráva, že tento prohlížeˇc nepodporuje tuto technologii. To by se ovšem pˇri použití dnešních prohlížeˇcu˚ nemˇelo stát. Dále sestavíme URL, které se pozdˇeji aplikuje pˇri HTTP GET požadavku. URL se skládá ze tˇrí cˇ ástí - URL serveru, název servletu, který poskytuje informace o stavu vyhledávání a identifikace dotazu. URL serveru a identifikaci dotazu získáme z globálních promˇenných vezmuServerURL a queryId, které byly definovány již dˇríve. Dále zadefinujeme do XMLHTTPRequestu vlastnost onreadystatechange. Tato vlastnost urˇcuje funkci, která se má zavolat, když se zmˇení stav komunikace se serverem. Poté následuje pˇríprava k vyslání požadavku serveru. Toto se provede pomocí funkce xmlHttp.open("GET",url,true) ;
34
6.3. IMPLEMENTACE U KLIENTA
Obrázek 6.4: Použití objektu XMLHTTPRequest, zdroj: Phill Ballard - Teach Yourself Ajax in 10 Minutes Tímto se pˇripraví HTTP požadavek, který bude proveden metodou GET na zadané URL. Tˇretí argument, v našem pˇrípadˇe true znamená, že požadavek bude zaslán asynchronnˇe. V opaˇcném pˇrípadˇe (false) by to znamenalo, že požadavek bude zaslán synchronnˇe, a stránka by se až do dokonˇcení požadavku zamkla proti dalším operacím, což v našem pˇrípadˇe není vubec ˚ potˇreba. A koneˇcnˇe provedeme vlastní realizaci HTTP poˇradavku pomocí funkce xmlHttp.send(null) ;
Argument null je zde z duvodu ˚ toho, že posíláme požadavek pomocí metody GET. Tento argument slouží k pˇredání obsahu požadavku v pˇrípadˇe použití metody POST. Když dojde ke zmˇenˇe stavu komunikace, XMLHTTPRequest objekt zavolá funkci stateChanged() ;
V této funkci se ovˇerˇ í, zda-li se stav zmˇenil na stav complete, tedy na stav, kdy je požadavek vyˇrízen a XMLHTTPRequest již obdržel odpovˇed’. Když ano, volá se dále funkce updateStatus(xmlHttp.responseText) ;
35
6.3. IMPLEMENTACE U KLIENTA která slouží ke zpracování odpovˇedi od serveru, která je získána pomocí vlastnosti responseText objektu XMLHTTPRequest. Text odpovˇedi je seznam elektronických zdroju˚ oddˇelený cˇ árkami. Server tímto odpovídá, že pro daný dotaz je již na tˇechto el. zdrojích vyhledávání ukonˇceno.
36
Kapitola 7
Výsledky formou XML Vyhledávací systém je navržen a implementován tak, že klient na základˇe vyhledávacího formuláˇre vytvoˇrí vyhledávací dotaz, ten zašle serveru, server zprostˇredkuje pomocí pluginu˚ vlastní vyhledávaní a nakonec vrátí klientovi výsledky a ten je zobrazí uživateli. Ovšem z tohoto pohledu tu není žádná možnost exportu seznamu výsledku˚ napˇr. do formátu XML. Urˇcitˇe by bylo vhodné, aby systém umožnoval ˇ i toto, protože seznam výsledku˚ ve formˇe XML dokumentu by mohla být cesta k dalšímu pˇrípadnému zpracování. V pˇrípadˇe, že by si chtˇel nˇekdo nalezené výsledky uložit, což za souˇcasného stavu systému žádným rozumným zpusobem ˚ nelze, by to též nebyl problém. Uživatel by nˇekde klikl na odkaz uložit výsledky do XML a nabídlo by se mu okénko pro stažení tohoto XML dokumentu. Takže první, co nás jakožto vývojáˇre systému napadne je implementovat do klienta pˇrevod seznamu výsledku˚ na XML dokument. Ovšem uvažujme ještˇe dále. Co kdyby tuto funkcionalitu poskytoval server? To by bylo samozˇrejmˇe z mnoha pohledu˚ lepší. Hlavnˇe z toho duvodu, ˚ že systém je navržen pomˇernˇe hodnˇe modulárnˇe a klientu˚ muže ˚ být více ruzných ˚ typu˚ - webový prohlížeˇc, PDA, dále jakákoliv další aplikace, která zvládá komunikaci po síti a protokol HTTP. Ale v každém pˇrípadˇe dotaz prochází vždy jádrem celého systému - tedy serverem. Zadáním mého dalšího úkolu tedy bylo implementovat do serveru funkcionalitu, která umožní pˇrevod seznamu výsledku˚ do XML dokumentu a ten následnˇe nˇejakým zpusobem ˚ poskytne klientovi. Hned zpoˇcátku se nabízí rˇ ešit tento úkol pomocí nové webové služby na stranˇe serveru. Sice by to šlo udˇelat takovým zpusobem, ˚ že by se pˇridala další funkce resp. metoda do stávající webové služby serveru, ovšem to se nejeví jako dobré rˇ ešení. Systém totiž pro webové služby využívá implementaci XFire, jak bylo uvedeno na zaˇcátku této práce. A každá webová služba má své rozhraní, které ji popisuje a svou tˇrídu, která toto rozhraní implementuje. Dále server s vyhledávacímy pluginy komunikuje také prostˇrednictvím webové služby. Problém je v tom, že všechny webové služby v systému mají ve svém popisu to, že jejich funkce jsou specifikovány rozhraním SearchService. Tedy všechny webové služby systému mají stejné rozhraní. Z prvního pohledu na tom není nic špatného, dokonce lze i rˇ íci, že se na stranˇe serveru webové služby vždy vykonává podobná funkcionalita. Ale z duvodu ˚ modifikace nˇekteré z web. služeb si myslím, že by bylo vhodnˇejší mít služby definovány tak, aby nebyly všechny specifikovány stejným rozhraním. Chceme-li v souˇcasné situaci zmˇenit rozhraní webové služby, kterou poskytuje server, tak touto modifikací vlastnˇe zmˇeníme jednotné rozhraní všech web. služeb systému, což není vždy žádoucí. Pro tuto funkcionalitu tedy bude vhodné vytvoˇrit novou webovou službu na stranˇe ser37
7.1. ROZHRANÍ SLUŽBY veru. Tento proces se dá rozdˇelit na tˇri elementární úkony. •
Vytvoˇrit rozhraní služby
•
Implementovat funkce služby
•
Pˇridat službu do seznamu poskytovaných služeb aplikace
7.1
Rozhraní služby
Rozhraní nové služby vypadá jednoduše, je zde jen metoda, protože požadujeme jedinou funkci. package cz.muni.fi.vezmu; public interface SearchXmlService{ public String processQuery (Query query) throws SearchException; }
Toto rozhraní je stejnˇe jako rozhraní SearchService definováno tak, aby jej bylo vidˇet ze všech aplikací systému, tedy je definováno v rámci knihovny vezmu-core. Jediný parametr metody je dotaz Query a metoda vrací rˇ etˇezec, což je XML dokument v textové podobˇe.
7.2
Implementace služby
Implementace služby je ovšem daleko zajímavˇejší. Služba má vykonávat témˇerˇ to samé, ovšem výsledkem nemá být seznam výsledku˚ v podobˇe nˇejaké kolekce objektu, ˚ výsledkem má být XML dokument. Tedy je rozumné provést implementaci tak, že se nejprve provede vyhledávání, což je hotová vˇec, a pak se na výsledky aplikuje pˇrevod do XML Dokumentu. Tento dokument má másledující XML schéma. <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" > <xsd:element name="searchResults" > <xsd:complexType > <xsd:sequence minOccurs="1" maxOccurs="1" > <xsd:element name="result" type="result" minOccurs="0" maxOccurs="unbounded" />
38
ˇ 7.3. P RIDÁNÍ WEBOVÉ SLUŽBY DO SEZNAMU <xsd:complexType name="result" > <xsd:sequence > <xsd:element name="title" minOccurs="1" maxOccurs="1" type="xsd:string" /> <xsd:element name="creators" minOccurs="1" maxOccurs="1" type="xsd:string" /> <xsd:element name="publisher" minOccurs="1" maxOccurs="1" type="xsd:string" /> <xsd:element name="date" minOccurs="1" maxOccurs="1" type="xsd:string" /> <xsd:element name="ccsPrimary" minOccurs="0" maxOccurs="1" type="xsd:string" /> <xsd:element name="ccsAdditional" minOccurs="0" maxOccurs="unbounded" type="xsd:string" /> <xsd:element name="link" minOccurs="1" maxOccurs="1" type="xsd:string" /> <xsd:element name="metadata" minOccurs="0" maxOccurs="unbounded" > <xsd:complexType > <xsd:simpleContent> <xsd:extension base="xsd:string" > <xsd:attribute name="name" type="xsd:string" use="required"/>
Schéma je navrženo docela pˇrirozenˇe, dle oˇcekávání. Po pˇrevodu výsledku˚ do XML dokumentu vrací webová služba tento dokument klientovi v textové podobˇe.
7.3
Pˇridání webové služby do seznamu
V implementaci XFire se seznam webových služeb aplikace udržuje v konfiguraˇcním souboru services.xml. Jsme-li s implementací hotovi, zapíšeme do tohoto souboru tuto novou webovou službu s názvem VezmuXmlService. Konfiguraˇcní soubor webových služeb serveru bude poté vypadat takto: <service> VezmuService
39
ˇ 7.3. P RIDÁNÍ WEBOVÉ SLUŽBY DO SEZNAMU cz.muni.fi.vezmu <serviceClass>cz.muni.fi.vezmu.SearchService cz.muni.fi.vezmu.server.Server <service> VezmuXmlService cz.muni.fi.vezmu <serviceClass>cz.muni.fi.vezmu.SearchXmlService cz.muni.fi.vezmu.server.ServerXml
40
Kapitola 8
Závˇer Výsledkem práce je návrh a imlementace uvedených vylepšení do vyhledávacího systému. Díky personalizaci se nyní s tímto systémem pracuje o poznání lépe. Vizualizace vyhledaných výsledku˚ je další významnou úpravou, díky které je nyní možné vidˇet seznam výsledku˚ ne jako jednoduchý neˇrazený seznam, ale výsledky jsou patˇriˇcnˇe graficky vykreslovány do relevantní cˇ ásti hierarchie CCS tˇríd dle jejich primárních a dodateˇcných CCS klasifikací. Výpis výsledku˚ je možný pˇrepnout do textového režimu, kde se zobrazí seznam výsledku˚ a vypíše se relevantní cˇ ást hierarchie CCS stromu s odkazy na seznamy výsledku, ˚ které jsou primárnˇe klasifikovány pˇríslušnou CCS tˇrídou. Další možnosti vývoje vyhledávacího systému vidím v ještˇe vˇetším vylepšení výpisu výsledku˚ uživateli. Výpis je nyní sice grafický, ale stále se jedná o vykreslování jistých elementu˚ pomocí XHTML, CSS a Javascriptu. Bylo by šikovné, aby se nˇekdo formou další diplomové práce zaˇcal zabývat tím, jak by se mohl seznam výsledku˚ plnˇe graficky zvizualizovat a jak zakreslit do výstupu nˇejakou formou vztahy mezi jednotlivými výsledky. K tomuto by mohly posloužit ontologie jednotlivých výsledku˚ a jazyk OWL. Tímto zpusobem ˚ by se mohly výsledky zakreslit do nˇejakého grafického schématu nebo grafu, který by lépe charakterizoval jejich význam, CCS klasifikaci a vztahy mezi nimi. Tento obrázek by se pak vykreslil uživateli do prohlížeˇce klasickým zpusobem, ˚ tedy pomocí XHTML. Takový postup je znázornˇen na obrázku 8.1. Další možnost zlepšení systému vidím v podrobnˇejším zobrazování stavu procesu vyhledávání uživateli. Zobrazování stavu vyhledávání je ted’ totiž provedeno tak, že uživatel vidí zpoˇcátku seznam elektronických zdroju, ˚ na kterých se zaˇcíná vyhledávat. U každého z nich je zobrazen stav searching, což znamená, že na daném elektronickém zdroji vyhledávání zaˇcalo a ještˇe probíhá. Až aplikace server zjistí, že vyhledávání na nˇejakém el. zdroji bylo ukonˇceno, patˇriˇcnˇe si to zaznamená a pˇri dalším dotazu od uživatelského klienta od prohlížeˇce (pomocí AJAXu) odpoví tuto skuteˇcnost a prohlížeˇc u daného zdroje zobrazí stav finished . To je sice šikovné, ovšem ideální by bylo informovat uživatele o každém elementárním kroku ve vyhledávání, tj. pˇri každém získání podrobných informací od daného elektronického zdroje. Ale obávám se, že toto v souˇcasné situaci nebude jednoduché navrhnout, protože systém je navržen pomˇernˇe hodnˇe modulárnˇe a pˇri každém nalezeném výsledku by musel každý plugin nˇejakou další cestou - napˇr. formou další webové služby informovat server a toto rˇ ešení se mi zdá ponˇekud nešikovné. Systém je totiž primárnˇe navržen tak, že je jedna cesta dotazu od klienta pˇres server až k vyhledávacímu pluginu, ten vyhledá výsledky a pak výsledky putují formou odpovˇedí na webové služby zpˇet do kli41
ˇ 8. Z ÁV ER
Obrázek 8.1: Activity diagram vizualizace vyhledaných výsledku˚ pomocí ontologií. enta, kde se zpracují a provede se výpis pro uživatele. Problém je v tom, že v puvodním ˚ návrhu se nemyslelo na nˇejaké prubˇ ˚ ežné oznamování o stavu vyhledání klientovi cˇ i pˇrímo uživatelskému klientovi - tedy web. prohlížeˇci. Dalším faktem je to, že vyhledávací systém nyní poskytuje výsledky ve formˇe XML pomocí nové webové služby, kterou disponuje server. To otevírá cestu dalším možným nadstavbám a úpravám systému, protože se tyto výsledky mohou pomocí ruzných ˚ standardních transformací pˇrevést do ruzných ˚ užiteˇcných struktur a mohou se pak zpracovávat pomocí dalších technologií za úˇcelem získání dalších informací pro uživatele.
42
Literatura [1] Neuhold, E. a Stewart, A. a Niederée, C.: LNCS 2911 - Personalization in Digital Libraries - An extended view, Fraunhofer-IPSI, 2003. ˇ J.: Komponentová zapouzdˇrenost webových aplikací, Diplomová práce, [2] Durovec, 2006. [3] Bˇel, J.: Analýza a implementace datového úložištˇe pro vyhledávací systém nad elektronickými zdroji MU, Diplomová práce, 2005. [4] Ballard, P.: Teach Yourself Ajax in 10 Minutes, Sams, 2006, 0-672-32868-2. [5] Chappell, D. a Jewell, T.: Java Web Services, O’Reilly, 2002, 0-596-00269-6. [6] Hightower, R.: Jakarta Struts Live, SourceBeat, 2004, 0-974-88430-8. [7] PostgreSQL Global Development Group: PostgreSQL documentation, PostgreSQL Global Development Group, 2006, . [8] Kurniawan, B.: Java for the Web with Servlets, JSP, and EJB: A Developer’s Guide to J2EE Solutions, New Riders Publishing, 2002, 0-7357-1195-X. [9] Wikipedia: Web service, Wikipedia - The free encyclopedia, 2006, .
43
Rejstˇrík ACM, 16 ActiveX, 34 AJAX, 30 Apache Axis, 9 Apache Tomcat, 3 autentizace, 17
SearchService, 37 Server, 3 SOAP, 8 Struts, 11
BASE64, 8
uživatelský klient, 2 UDDI, 9
cache, 4 CCS, 16 CCS hierarchie, 25 content enrichment, 13 content pre-selection, 13 content structuring, 13 Digitální knihovna, 13 Downloader, 4 entry points, 15
Textový výpis, 25
VEZMU, 2 VezmuXmlService, 39 Webové, 7 WSDL, 9 XFire, 9 XML, 7 XML schéma, 38 XMLHTTPRequest, 34
Grafický výpis, 25 HTTP, 7 INET MUNI, 17 JDBC, 4 Klient, 3 library services, 13 Mozilla, 34 MS Internet Exporer, 34 MVC, 3 ontologie, 41 Opera, 34 OWL, 41 Personalizace, 13 pluginy, 4 PostgreSQL, 4 Postprocessing, 22 44
Pˇríloha A
Obsah pˇriloženého CD Souˇcástí této diplomové práce je i CD, na kterém je k dispozici /text Text této práce /source Zdrojové kódy všech aplikací vyhledávacího systému VEZMU /doc Dokumentace projektu VEZMU
45
