}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Flexibilní kategorizace a vyhledávání obsahu v systému Searchisko pomocí štítku˚ ˇ B AKALÁ RSKÁ PRÁCE
Jiˇrí Mauritz
Brno, Jaro 2015
Prohlášení Prohlašuji, že tato bakaláˇrská 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.
Jiˇrí Mauritz
Vedoucí práce: RNDr. Adam Rambousek iii
Podˇekování Tímto bych rád podˇekoval RNDr. Adamovi Rambouskovi za odborné vedení práce, objektivní kritiku a cenné rady poskytnuté bˇehem její realizace. Velké díky také patˇrí Ing. Vlastimilovi Eliášovi za technickou podporu, aktivní spolupráci, trpˇelivost a vynaložený cˇ as. Dále moje podˇekování patˇrí rodiˇcum ˚ a pˇrátelum ˚ za podporu bˇehem celého bakaláˇrského studia.
v
Shrnutí Bakaláˇrská práce se zamˇerˇ uje na rozšíˇrení systému na správu obsahu Searchisko o podporu práce s uživatelskými štítky. V práci je popsán moderní trend využívání uživatelských štítku˚ pro kategorizaci zdroju˚ uživateli, který se nazývá folksonomie. Dále je tento trend srovnán s dalšími zpusoby ˚ tˇrídˇení zdroju. ˚ Práce popisuje implementaci správy uživatelských štítku˚ do systému Searchisko a pˇrístup k nim pomocí navrženého rozhraní. Zabývá se také návrhem podpory synonym pˇri vyhledávání štítku˚ pomocí sémantické sítˇe slov WordNet. Na závˇer analyzuje data v podobˇe štítku˚ v systému Searchisko a ovˇerˇ uje platnost tvrzení, která byla uˇcinˇena v souvislosti s folksonomií.
vii
Klíˇcová slova štítek, Searchisko, Elasticsearch, Java, synonymum, WordNet, folksonomie, kategorizace, power law, Representational State Transfer
ix
Obsah 1 2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kategorizace obsahu pomocí štítku˚ . . . . . . . . . . . . . 2.1 Vysvˇetlení pojmu˚ . . . . . . . . . . . . . . . . . . . . . 2.1.1 Folksonomie . . . . . . . . . . . . . . . . . . . . Široká folksonomie . . . . . . . . . . . . . . . Úzká folksonomie . . . . . . . . . . . . . . . . 2.1.2 Social bookmarking . . . . . . . . . . . . . . . 2.1.3 Kategorizace a klasifikace . . . . . . . . . . . . Nevýhody klasifikace . . . . . . . . . . . . . . Nevýhody kategorizace . . . . . . . . . . . . . 2.1.4 Tag spamming . . . . . . . . . . . . . . . . . . 2.2 Formalizace modelu kolaborativního štítkování . . . 2.2.1 Tripartitní model . . . . . . . . . . . . . . . . . 2.2.2 Informaˇcní hodnota štítku . . . . . . . . . . . . 2.2.3 Zákony distribuce štítku˚ . . . . . . . . . . . . . 2.3 Služby využívající kolaborativní štítkování . . . . . . 2.3.1 YouTube . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Flickr . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Delicious . . . . . . . . . . . . . . . . . . . . . . 2.3.4 IS MUNI . . . . . . . . . . . . . . . . . . . . . . Popis systému Searchisko . . . . . . . . . . . . . . . . . . . 3.1 Principy fungování a architektura systému Searchisko 3.1.1 Struktura dokumentu . . . . . . . . . . . . . . 3.1.2 Kontrola pˇrístupu . . . . . . . . . . . . . . . . . 3.2 Technologie používané systémem Searchisko . . . . . 3.2.1 Representational State Transfer . . . . . . . . . 3.2.2 Elasticsearch . . . . . . . . . . . . . . . . . . . . Návrh a implementace služby pro práci se štítky . . . . . 4.1 Objekt „štítek“ . . . . . . . . . . . . . . . . . . . . . . 4.2 DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Návrh REST API . . . . . . . . . . . . . . . . . . . . . 4.3.1 Proˇc byla vybrána architektura REST . . . . . 4.3.2 Autorizace . . . . . . . . . . . . . . . . . . . . . 4.3.3 Metody aplikaˇcního rozhraní . . . . . . . . . . 4.3.4 Chování metod a reakce na chyby . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 5 5 5 7 7 7 8 10 10 11 12 12 13 14 15 15 15 16 16 17 18 20 21 21 21 22 25 27 27 29 29 30 31 31 xi
4.4 Reakce na události v Searchisku . . . . . . . 5 Využití synonym . . . . . . . . . . . . . . . . . . 5.1 WordNet . . . . . . . . . . . . . . . . . . . . 5.1.1 Použitá verze WordNetu . . . . . . . 5.2 Návrh pro systém Searchisko . . . . . . . . 5.2.1 Vyhledávání synonym podle prefixu 6 Analýza dat . . . . . . . . . . . . . . . . . . . . . 6.1 Nasbíraná data . . . . . . . . . . . . . . . . 6.2 Ovˇerˇ ení platnosti zákonu˚ distribuce štítku˚ . 6.3 Synonyma . . . . . . . . . . . . . . . . . . . 7 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . A Pˇríloha . . . . . . . . . . . . . . . . . . . . . . . . A.1 Adresáˇrová struktura . . . . . . . . . . . . . A.2 Implementaˇcní zmˇeny . . . . . . . . . . . . A.3 Návod ke spuštˇení systému Searchisko . .
xii
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
32 33 34 34 35 38 41 41 43 46 49 51 51 52 53
1 Úvod S narustajícím ˚ množstvím dat se zvyšuje potˇreba vyhledávat relevantní informace. Od doby vzniku Internetu se vˇedˇení lidstva pˇresunulo do elektronické podoby a je dohledatelné na jedné síti, což klade na vyhledávání informací velké nároky. Existuje nˇekolik metod pro vyhledávání ve velkém množství dat. Nejznámˇejší je full-textové1 vyhledávání, které používají nejrozšíˇrenˇejší vyhledávaˇce, napˇríklad Google. Takové vyhledávání je vhodné pro data v podobˇe nestrukturovaných dokumentu. ˚ Další metodou je klasifikace dokumentu˚ a následné vyhledávání pomocí jejich metadat. Pokud máme možnost k dokumentum ˚ pˇridat strukturované informace, mužeme ˚ vyhledávat s vˇetší pˇresností i pokrytím dat. Pod metadaty si lze pˇredstavit cokoliv, co nám pomuže ˚ urˇcit hledaný dokument, napˇríklad jméno autora, téma nebo datum vytvoˇrení. Velmi pomocnou položkou metadat jsou tzv. štítky, což jsou krátké (ˇcasto jednoslovné) popisky, které se vztahují k dokumentu. Štítky jsou de facto lidské asociace vázané k danému dokumentu v podobˇe textu. U fáze vyhledávání také vytváˇríme asociaci, která pˇripomíná štítek, a proto mohou být klíˇcovými pomocníky v této problematice. Cílem této práce je rozšíˇrení aplikace na správu obsahu Searchisko [7] o podporu uživatelských štítku. ˚ Systém Searchisko slouží k všestranné správˇe heterogenního obsahu. Je urˇcen pˇrevážnˇe pro velké projekty, které mají informace fragmentovány v ruzných ˚ podobách, napˇríklad diskuzní fóra, dokumentace nebo blogy. Systém dovoluje agregovat dokumenty, konfigurovat jejich metadata, analyzovat jejich použití, ale hlavnˇe je efektivnˇe prohledávat. Uživatelé systému Searchisko vznesli požadavek na pˇridání rozhraní pro práci se štítky. Nˇekteˇrí uživatelé navíc chtˇejí používat štítky jako jejich vlastní klasifikátor dokumentu, ˚ což vyžaduje rozdˇelení štítku˚ na typy podle jejich využití. Inspiraci lze hledat v mnoha webových aplikacích s podporou štítku, ˚ napˇríklad Flickr [39], Youtube [13] nebo projekt pˇrímo zamˇerˇ ený na štítky – Delicious [6]. 1. (z ang. full – celý, plný) vyhledávání v celém obsahu dokumentu˚ pro porovnání slov s klíˇcovým dotazem
1
1. Ú VOD V práci nejprve popisuji základní princip kolaborativního štítkování a vysvˇetluji pojem folksonomie, což je nový trend využívání štítku˚ pro kategorizaci zdroju˚ uživateli. Velmi dobˇre zpracovaný je v bakaláˇrské práci Folksonomie [33], ze které jsem cˇ erpal. Organizování obsahu formou „lidé lidem“ je souˇcást fenoménu Web 2.02 a stává se stále populárnˇejší. Dále srovnávám kategorizaci pomocí štítku˚ a formální klasifikaci a uvádím jejich výhody a nevýhody. Do nevýhod kategorizace patˇrí i lexikální pestrost jazyka, která zpuso˚ buje složité vztahy mezi slovy a jejich významy. Pozdˇeji konstruktivnˇe rˇ eším problém zpusobený ˚ synonymy. Dále v práci popisuji návrh a implementaci správy štítku˚ do systému Searchisko. Souˇcástí je návrh autorizace uživatele pomocí rolí v systému. Jako rozhraní této služby používám REST API3 . Také se v práci vˇenuji vylepšení vyhledávání štítku˚ díky zvládnutí problému se synonymy. K tomu využívám Princeton University WordNet [25], což je sémantická sít’ slov, která zachycuje synonyma, homonyma, hyperonyma další lexikální vztahy. V závˇeru práce analyzuji data a zejména štítky systému Searchisko. Ovˇerˇ uji platnost obecných zákonu˚ distribuce štítku, ˚ které definovala práce The Structure of Collaborative Tagging Systems [14], kde jsou zpracovány data služby Delicious. Dále ukazuji, jak konkrétnˇe synonyma pomáhají systému zlepšit vyhledávání. Ukázalo se, že využití slovníku WordNet jako databáze sémantických znalostí je velmi výhodná, pokud jde o zvládnutí lexikálních pˇrekážek pˇri vyhledávání. WordNet nabízí v budoucnu rˇ ešení i dalších problému˚ zpusobených ˚ hyperonymy (pˇríp. hyponymy), homonymy a jiných lexikálních jevu. ˚ Další výzva do budoucna je rozšíˇrení slovníku o jiné jazyky než angliˇctinu nebo pˇrímo tvorbu vlastního slovníku tématických slov. Navržená služba pro práci se štítky je zatím bez rozšíˇrení o synonyma souˇcást systému Searchisko používán uživateli komunity JBoss [30] od jejího zavedení v dubnu 2015. Stále více služeb rozšíˇrených o uživatelské štítky je dukazem, ˚ že obohacují systém a podporují socializaci v prostˇredí internetu. 2. obchodní revoluce v informaˇcních technologiích, která je zapˇriˇcinˇená prudkým rozmachem internetu a snahou, aby byl internet co nejvíc pˇrínosný lidem [27] 3. Representational State Transfer Application Programming Interface– architektura rozhraní umožnující ˇ pˇristupovat ke zdrojum ˚ pˇres protokol HTTP (Hypertext Transfer Protocol), kterou navrhl v roce 2000 Roy Fielding
2
2 Kategorizace obsahu pomocí štítku˚ Tato kapitola pˇredstaví obecný model štítkování, budou vysvˇetleny základní pojmy, které se týkají kategorizace pomocí štítku˚ a matematické nástroje používané k formalizování a predikci chování systému pracujícího se štítky, které v poslední kapitole využijeme k analýze systému Searchisko.
2.1 Vysvˇetlení pojmu˚ 2.1.1 Folksonomie Puvod ˚ slova folksonomie hledejme ve slovech „taxonomie“ , což je vˇední obor zabývající se tˇrídˇením organismu, ˚ ale v poslední dobˇe je zobecnován ˇ na tˇrídˇení cˇ ehokoli a výraz „folks“ , který lze pˇreložit jako „lidé“ [11]. Proto folksonomie je tzv. „lidové tˇrídˇení“ , tedy proces volného popisování informací a objektu˚ lidmi pro osobní potˇrebu a zpˇetného získávání [36]. Tvurce ˚ výrazu folksonomie pan T. Vander Wall definuje folksonomii takto: „Folksonomy is the result of personal free tagging of information and objects (anything with a URL) for one’s own retrieval. The tagging is done in a social environment (usually shared and open to others). Folksonomy is created from the act of tagging by the person consuming the information.“ Tím pˇrímo spojuje folksonomii se štítkováním, avšak prvky „lidového tˇrídˇení“ mužeme ˚ pozorovat i v obecnˇejším mˇerˇ ítku, napˇríklad na Wikipedii lidé tˇrídí znalostí do cˇ lánku. ˚ V našem pˇrípadˇe jde však pˇredevším o lidové tˇrídˇení pomocí štítku, ˚ kterému budeme rˇ íkat kolaborativní štítkování. Folksonomie se rˇ adí mezi moderní trendy fenoménu Web 2.0. Internet se v posledních letech vyvíjí smˇerem, jehož znaky jsou právˇe volnost a možnost vyjadˇrovat se ruznými ˚ zpusoby. ˚ Souˇcástí fenoménu Web 2.0 jsou napˇríklad blogy, sociální sítˇe nebo recenze. Kolaborativní štítkování patˇrí do aktivit, které podporují socializaci na 3
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ internetu a myšlenku webu tvoˇreného lidmi. Logo Webu 2.0 mužeme ˚ dokonce velmi cˇ asto vidˇet jako štítkové mraˇcno (angl. tag cloud). Je to typický prvek tohoto fenoménu [33].
Folksonomii lze rozdˇelit na širokou a úzkou v závislosti na vazbách mezi entitami (uživatel, štítek, zdroj) a právech v systému kolaborativního štítkování.
Obrázek 2.1: Ukázka široké folksonomie (inspirováno prezentací Folksonomy [37]) 4
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ Široká folksonomie Hlavní rys široké folksonomie je ten, že je štítek vázaný ke zdroji i k uživateli [33]. Každý uživatel vytváˇrí svoji množinu štítku˚ ke každému zdroji nezávisle na ostatních uživatelích. Zdroj potom muže ˚ mít stejný štítek více než jedenkrát. Na obrázku 2.1 mužeme ˚ pozorovat, že zdroj má teoreticky tolik množin štítku, ˚ kolik je uživatelu. ˚ V takových systémech se snadno ukazuje, jak se navzájem uživatelé ovlivnují ˇ u vytváˇrení štítku˚ a celkovˇe jsou statistky pˇresnˇejší ˇ z duvodu ˚ vyššího poˇctu štítku. ˚ Cetnost štítku˚ také vylepšuje vyhledávání, protože jim mužeme ˚ pˇridat urˇcitou relevanci. Služba Delicious je typický pˇríklad široké folksonomie, více v sekci 2.3.3. Úzká folksonomie Úzká folksonomie se používá tam, kde štítky netvoˇrí hlavní vyhledávací mechanismus, ale spíše ho jen doplnují. ˇ Rozdíl oproti široké folksonomii je ten, že štítek je vázaný pouze na zdroj. Z toho vyplývá, že zdroj bud’ štítek má nebo nemá (nepoˇcítají se cˇ etnosti), jak ˇ mužeme ˚ vidˇet na obrázku 2.2. Casto také právo na pˇridání štítku ke zdroji je omezeno jen pro nˇekteré uživatele. Antonín Vaishar ve své práci o Folksonomii [33] mimo jiné uvádí, že úzká folksonomie je urˇcena jen pro kategorizaci multimédií, které nemají textový popis. Proto jsme ale nenašli žádný duvod ˚ a systém Searchisko je dukazem, ˚ že úzká folksonomie muže ˚ fungovat i s textovými zdroji. 2.1.2 Social bookmarking Štítky se mohou pˇridávat k jakýmkoli zdrojum, ˚ mezi jimiž jsou nejoblíbenˇejší webové stránky. Protože je na internetu velké množství informací na ruzných ˚ stránkách, lidé mají potˇrebu je organizovat a tˇrídit si je. Do urˇcité chvíle postaˇcí záložky v internetovém vyhledávaˇci, ale pokud si potˇrebujete uchovat stovky cˇ lánku˚ v podobˇe URL, potˇrebujete jiný nástroj. Social bookmarking je spojení repozitáˇre na URL a štítky spolu se sociálním prostˇredím na internetu. Uživatelé pˇridávají štítky k internetovým stránkám a zárovenˇ vidí oblíbené stránky jiných uživatelu, ˚ které lze vyhledávat podle štítku. ˚ 5
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ Prukopníkem ˚ v oblasti social bookmarking je služba Delicious, která inspirovala další.
Obrázek 2.2: Ukázka úzké folksonomie (inspirováno prezentací Folksonomy [37]) 2.1.3 Kategorizace a klasifikace V dnešní dobˇe se cˇ asto vedou diskuze, jak nejlépe organizovat velké množství informací. Ve stˇretu jsou potom formalizovaná klasifikace provádˇená experty za úˇcelem vytvoˇrení sémantického webu a kategorizace prostˇrednictvím kolaborativního štítkování [31]. Významy slov klasifikace a kategorizace zde hrají významnou roli [16].
6
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ •
Kategorizaci chápeme jako rozdˇelení svˇeta do kategorií, kde všechny entity jedné kategorie mají nˇejakou podobnost. Entita muže ˚ sdílet ruzné ˚ spoleˇcné rysy s ostatními v rámci jedné kategorie. Tento jev je duležitý ˚ pro flexibilitu systému, protože entity v jedné kategorii mají slabší vazbu v porovnání s tˇrídami klasifikace.
•
Klasifikace vyžaduje uspoˇrádaný a systematický výbˇer každé entity, která se zaˇradí právˇe do jedné tˇrídy v systému disjunktních tˇríd. Proces spojování entit a tˇríd má pˇredem urˇcená pravidla, což umožnuje ˇ formalizovat systém.
Organizování informací pomocí kolaborativního štítkování je flexibilní, adaptabilní a poddajné uživatelum, ˚ jejichž potˇreby se mˇení v cˇ ase. Uživatelé se nemusí shodnout na žádné detailní taxonomii nebo hierarchii štítku, ˚ staˇcí se shodnout obecným rozumem [22]. Porovnání s detailní taxonomií vytvoˇrenou experty ukazuje, že lze dosáhnout 90% kvality, ale desetkrát snadnˇeji a levnˇeji [2]. Dva kvalitní a používané klasifikaˇcní systémy jsou Dewey Decimal Classification (DDC)1 a novˇejší Library of Congress Classification (LCC)2 [34]. Klasifikaci internetu podle DDC vytvoˇril David A. Mundie s názvem CyberDewey [26]. Server CyberStack(sm) vytvoˇril klasifikaci podle schématu LCC [5]. Obˇe schémata byla vytvorˇ ena v 19. století a byla urˇcena pro tˇrídˇení knih, což je hlavní du˚ vod, proˇc se neprosadila jako klasifikaˇcní schémata internetu. Proto moderní vyhledávaˇce (napˇr. Yahoo! Search) používají vlastní klasifikaˇcní schémata. Spoleˇcnost Yahoo shodou okolností mezi lety 2005 a 2008 vlastnila i systém tˇrídící web pomocí kolaborativního štítkování – Delicious. Díky tomu má k dispozici dobré srovnání tˇechto pˇrístupu˚ a mohla by ovˇerˇ it platnost tvrzení poslední vˇety pˇredchozího odstavce. 1. systém tˇrídˇení obsahu knihovny na základˇe znalostí deseti skupin, které se dál dˇeli pomocí desetinného rozvoje, vytvoˇreno 1876 americkým knihovníkem Melvilem Deweyi [8] 2. systém organizace knihovního obsahu; vytvoˇren v USA Knihovnou Kongresu v roce 1897, rozdˇeluje témata na tˇrídy A až Z [19]
7
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ Nevýhody klasifikace Rozdˇelení univerza do disjunktních tˇríd pomocí klasifikace není jednoduché (ne-li nemožné) [14]. Pro ilustraci hledejme všechny projekty napsané v jazyce Java, které mají zárovenˇ otevˇrený zdrojový kód. Tyto dvˇe množiny mají prunik, ˚ ale nejsou totožné, tedy existuje projekt v jazyce Java, který nemá otevˇrený zdrojový kód a naopak. Potom máme tˇri možnosti, jak sestavíme taxonomii. 1.
/project/java/open_source/ Mužeme ˚ kvalifikovat kritérium programovacího jazyka jako významnˇejší a kritérium licence bude podskupina každého jazyka.
2.
/project/open_source/java Mužeme ˚ kvalifikovat kritérium licence jako významnˇejší a kritérium programovacího jazyka bude tvoˇrit podskupiny každého typu licence.
3.
/project/java & /project/open_source Mužeme ˚ uznat kritéria jako rovnocenná a zaˇradit ja na stejnou úroven. ˇ
První možnost má jasnou nevýhodu v tom, že pˇri hledání všech projektu˚ s otevˇreným zdrojovým kódem se musíme podívat do všech skupin programovacích jazyku. ˚ Druhá možnost je analogická k té první. Tˇretí možnost neumožnuje ˇ zaˇradit projekty, které jsou zárovenˇ napsané v jazyce Java a zárovenˇ s otevˇreným zdrojovým kódem. U kategorizace tento problém nehrozí, protože jsme schopni vyhledávat projekty, které jsou oznaˇceny jak štítkem Java, tak štítkem Open source. Nevýhody kategorizace Hlavní nevýhody kategorizace se zakládají na shodˇe významu slov v daném jazyce. Mužeme ˚ mluvit o sémantických problémech [14]: •
8
synonyma – pokud se v systému objeví ruzné ˚ štítky pro stejný objekt, nemužeme ˚ si být jisti, zda na dotaz byla vrácena kompletní množina požadovaných zdroju˚
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ •
homonyma (pˇríp. polysémie) – stejný štítek u ruzných ˚ zdroju˚ zpusobí ˚ vyhledání nerelevantních zdroju˚
•
hyperonyma (pˇríp. hyponyma) – pomocí štítku s nadˇrazeným slovem se nám v dotazu nevrátí relevantní zdroje oznaˇcené štítkem s konkrétnˇejším významem
Synonyma lze rˇ ešit slovníkem synonym (viz. kapitola 5). Polysémii (pˇríp. homonyma) je velmi obtížné rˇ ešit, protože by v praxi musel uživatel jak pˇri vytváˇrení štítku, tak pˇri vyhledávání, specifikovat jeden z významu˚ zadaného slova. Vzhledem k rˇ ídkým výskytum ˚ homonym v jazyce se však tento problém vˇetšinou neˇreší. Hyperonyma a hyponyma lze opˇet rˇ ešit vhodným slovníkem sémantických vazeb. 2.1.4 Tag spamming Komunita internetu je už dobˇre obeznámena s problémy rozesílání spamu elektronickou poštou a spamování vyhledávací služby (angl. spamdexing) [17]. Tag spamming (spamování pomocí štítku) ˚ je oproti nim relativnˇe nový problém, a proto zatím nejsou dobˇre vytvoˇrené taktiky, jak se bránit. Principem je tag spamming a spamdexing velmi podobný: útoˇcník vytváˇrí ke zdroji takový obsah, aby ho vyhledávací služby ohodnotili vyšší relevancí. U spamdexingu jde o pˇridání slov na stránku a u tag spammingu o pˇridání velkého množství štítku˚ k danému zdroji. Pˇritom slova (štítky) nemusejí s daným zdrojem nijak souviset, cˇ ímž donutí vyhledávací službu vracet nerelevantní odpovˇedi. Motivace k tag spammingu muže ˚ být ruzná. ˚ Politicky motivovaný útoˇcník oznaˇcí dokument o nˇejakém poslanci stovkami štítku˚ s textem „Hitler“ a uživatel pˇri vyhledávání tohoto slova najde dokument o zmínˇeném poslanci. Obchodem motivovaný útoˇcník muže ˚ dokument o jedné znaˇcce poˇcítaˇcu˚ oznaˇcit velkým množstvím štítku˚ s textem „buy computer“ , a proto se ve vyhledávání objeví dokument o konkurenˇcní znaˇcce jako ménˇe relevantní. Bránit se tag spammingu není jednoduchý úkol. Nˇekteré služby ho rˇ eší omezením práv uživatelu. ˚ Pˇríkladem je služba Flickr, která 9
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ dovoluje autorovi fotky urˇcit uživatele, kteˇrí mohou pˇridávat štítky k fotce. Podobným zpusobem ˚ funguje štítkování v systému Searchisko, viz sekce 4.3.2. Pokud však nechceme omezovat uživatele, musíme vytvoˇrit složitˇejší mechanismy, které nejsou obsahem této práce. Kvalitní zpracování tohoto tématu nabízí práce Combating Spam in Tagging Systems [17].
2.2 Formalizace modelu kolaborativního štítkování 2.2.1 Tripartitní model Abychom byli schopni o procesu štítkování nˇeco pˇredpokládat, formalizujeme ho tzv. tripartitním modelem, který byl již definován v ruzných ˚ pracích [21, 31]. Základními entitami jsou: 1.
Uživatel : iniciátor, který pˇridává štítky ke zdrojum ˚
2.
Štítek : oznaˇcuje zdroj
3.
Zdroj : jakákoli entita, ke které lze pˇridat štítek (obrázek, video, komentáˇr, URI, ...), v našem pˇrípadˇe dokument
Obrázek 2.3: Tripartitní model 10
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ Štítek je v modelu spojovník mezi uživatelem a zdrojem a je tedy vždy v urˇcitém kontextu. Instancí štítkování budeme oznaˇcovat cˇ tverˇ ici: uživatel, štítek, zdroj a datum pˇridání. 2.2.2 Informaˇcní hodnota štítku Informaˇcní hodnota je subjektivní veliˇcina, protože popisovaný pojem muže ˚ nést ruznou ˚ informaci v závislosti na tom, v jakém je kontextu. Navíc informace muže ˚ mít pro nˇekoho menší a pro jiného vˇetší hodnotu. Kdybychom informaˇcní hodnotu definovali jako entropii z teorie informatiky oznaˇcovanou S, hodnota štítku by byla poˇcet bitu, ˚ na které jsme schopni uložit štítek. Štítky s delšími slovy by mˇely mnohem vˇetší informaˇcní hodnotu než ty s kratšími, což pro nás není relevantní. Oznaˇcme naši informaˇcní hodnotu I a definujme ji následovnˇe. Štítky jsou v systému zavedeny ve vˇetšinˇe pˇrípadu˚ z duvodu ˚ vyhledávání a právˇe to je pro nás smˇerodatné pˇri definici informaˇcní hodnoty. Abychom byli schopni o štítku rˇ íct, jaké množství informace nese, musíme zjistit, jak moc nám pomuže ˚ pˇri vyhledávání. V praxi to znamená, že štítek, který se objevuje u všech zdroju, ˚ nenese žádnou informaci, protože pˇri vyhledávání neomezí výbˇer zdroju, ˚ proto I = 0. Stejnˇe tak platí pro štítek, který neoznaˇcuje žádný zdroj. Naopak pro štítek oznaˇcující jeden zdroj klademe I = 1. [31] Samozˇrejmý pˇredpoklad je, že relevantní štítky oznaˇcují relevantní zdroje. Obecnˇe pro štítek t, oznaˇcující k zdroju˚ v systému s celkovým pocˇ tem N zdroju˚ platí ( 0 k =0 I (t ) = N −k (2.1) jinak N −1 Hodnotu informace lze zkoumat i na více štítcích. Neplatí však, že I (t1 , t2 ) = I (t1 ) + I (t2 ), tedy že je informaˇcní hodnota aditivní [31]. Opˇet si musíme uvˇedomit, jak nám více štítku˚ pomuže ˚ pˇri vyhledávání. Pokud se v požadavku objeví dva štítky, které nemají žádný prunik ˚ oznaˇcených zdroju, ˚ vyhledávání nevrátí žádný zdroj, a proto 11
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ je jejich informaˇcní hodnota nulová. Naopak, pokud jejich prunik ˚ je jen jeden zdroj, informaˇcní hodnota musí být maximální.
Proto: pro štítky t1 , t2 , ..., tm a množiny jejich zdroju˚ s1 , s2 , ...sm platí ( I (t1 , t2 , ..., tm ) =
0 N− p N −1
p=0 kde p = |s1 ∩ s2 ∩ ... ∩ sm | jinak
(2.2)
2.2.3 Zákony distribuce štítku˚ Vˇedecké práce zbývající se distribucí štítku˚ dokázali, že v systému nastává tzv. stabilizovaný stav [31, 14]. Pokud je distribuce stabilizovaná, znamená to, že po pˇridání dalších štítku˚ se jejich frekvence proporciálnˇe nemˇení (zachová se jejich pomˇer). Pro širokou folksonomii lze stabilitu sledovat u každého dokumentu zvlášt’, pro úzkou ji lze sledovat jen pro systém jako celek. Stabilita je také ekvivalentní s ponˇetím uživatelu˚ o tom, které štítky nejˇcastˇeji popisují jaké zdroje. Mu˚ žeme tvrdit, že uživatelé si tvoˇrí jazyk popisu zdroju˚ a stabilita znaˇcí shodu tohoto jazyka u vˇetšiny uživatelu. ˚ Podle S. Goldera a B. Hubermana [14] nastává stabilita po 100 štítcích u jednoho zdroje. Stabilitˇe napomáhá také skuteˇcnost že uživatel vidí štítky ostatních uživatelu. ˚
Uvedené vˇedecké práce kromˇe existence stability ukázali také typ distribuce štítku, ˚ který nastává, pokud je stabilní. Jedná se o mocninnou závislost (angl. power law) frekvence štítku na jeho poˇradí podle frekvence. Matematicky: y = c · xα kde x je pozice štítku, pokud je seˇradíme podle cˇ etnosti, c je frekvence nejˇcastˇejšího štítku, y je frekvence štítku a α je parametr odlišný pro každý systém (vˇetšinou záporný). Závislosti se rˇ íká i Zipfuv ˚ zákon. 12
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚
2.3 Služby využívající kolaborativní štítkování Následnˇe rozebereme aplikace na sdílení fotek, videí a dokumentu, ˚ které pracují se štítky. Pokud se podíváme na aplikace, jako jsou YouTube, Flickr.com, Delicious nebo IS MUNI, zjistíme, že každá na nˇe má odlišný pohled a využívá štítku˚ k ruzným ˚ úˇcelum. ˚ 2.3.1 YouTube Štítky v aplikaci YouTube mohou vytváˇret jen autoˇri videí, kteˇrí pomocí nich zaˇrazují svoje video do kategorií. V tomto pˇrípadˇe je úˇcel štítku˚ jen jeden, a to je zlepšení fulltextového vyhledávání. Uživatel nemá možnost vyhledávat videa jen s urˇcitým štítkem, ani jednoduše zjistit o videu, jaké štítky pro nˇej byly použity. Na zdrojové HTML stránce videa jsou sice štítky ukryté v elementu meta s oznaˇcením keyword, ale bˇežný uživatel je nenajde. Nejedná se o kolaborativní štítkování, protože štítky nepˇrispívají k tvorbˇe spoleˇcného kontextu. 2.3.2 Flickr V aplikaci Flickr, na rozdíl od YouTube, vidí uživatelé štítky všech fotek. Pˇri vyhledávání se kromˇe názvu˚ fotek prohledávají i štítky. Stejnˇe jako u služby YouTube, muže ˚ štítky upravovat primárnˇe jen autor fotky. Vývojáˇri se ale snaží o kolaborativní štítkování a autor muže ˚ povolit urˇcitým uživatelum ˚ oznaˇcovat jeho fotky. To je hlavní duvod, ˚ proˇc se muže ˚ mluvit o folksonomii v souvislosti se službou Flickr. Konkrétnˇe se jedná o úzkou folksonomii, protože každá fotka má jednu množinu štítku˚ pro všechny uživatele a pozdˇeji uvidíme, že je tento návrh nejvíce podobný návrhu systému Searchisko. Flickr navíc umožnuje ˇ vyhledat všechny fotky oznaˇcené urˇcitým štítkem. Díky tomu není problém vyhledat všechny fotky, na kterých je napˇríklad žirafa nebo Špilberk (pokud jsou oznaˇceny štítky). U médií, jako jsou videa nebo právˇe fotky, jsou štítky velmi duležité. ˚ Hlavní duvod ˚ je ten, že zatím neexistuje algoritmus, který by umˇel dobˇre prohledávat v grafické reprezentaci fotky nebo videa, na rozdíl od klasického full-textového vyhledávání, které dobˇre funguje na textových dokumentech. 13
2. K ATEGORIZACE OBSAHU POMOCÍ ŠTÍTK U˚ 2.3.3 Delicious Služba Delicious zachází se štítky opˇet trochu jinak než pˇredchozí dvˇe. Štítky jsou pˇrístupné všem a mužete ˚ pomocí nich vyhledávat dokumenty podobnˇe jako u služby Flickr. Kromˇe toho má uživatel možnost oštítkovat nejen svuj ˚ pˇríspˇevek, ale i jakýkoli jiný. Pokud chce uživatel oštítkovat cizí dokument, musí si ho pˇridat do svého repozitáˇre zdroju, ˚ a následnˇe pˇridává štítky k tomuto odkazu. Odkaz muže ˚ být soukromý nebo veˇrejný, cˇ ímž má uživatel možnost zpˇrístupnit další informace o dokumentu v podobˇe štítku. ˚ V tomto pˇrípadˇe mužeme ˚ mluvit o typickém pˇredstaviteli široké folksonomie. 2.3.4 IS MUNI Informaˇcní systém Masarykovy univerzity je jeden z mála cˇ eských systému, ˚ které používají kolaborativní štítkování [33]. Inspirují se službou Delicious, a proto se jedná také o širokou folksonomii. Systém omezuje správu štítku˚ jen pro uživatele informaˇcního systému, což je dobrá obrana proti tag spammingu, za kterým vˇetšinou stojí anonymní uživatelé. Díky akademickému prostˇredí se štítky vˇetšinou pˇridávají ke studijním kurzum ˚ nebo vˇedeckým pracím.
14
3 Popis systému Searchisko Štítky vˇetšinou doplnují ˇ systémy, které z duvodu ˚ vyššího poˇctu dokumentu˚ potˇrebují pokroˇcilejší techniky pro jejich utˇrídˇení a vyhledávání, než jen získání dokumentu podle konkrétního klíˇce. Searchisko typovˇe zapadá do této kategorie, a proto jsem se do nˇej rozhodl implementovat práci se štítky. Searchisko je open source1 projekt, který umožnuje ˇ jednoduše vybudovat službu na indexování, vyhledávání, získávání a agregování dokumentu˚ z heterogenních zdroju˚ [9]. Požadavky na indexování dokumentu˚ z konkrétních zdroju˚ mohou být libovolnˇe konfigurovány [7]. Požadavek na vytvoˇrení systému Searchisko vzešel z potˇreby vývojových týmu, ˚ kteˇrí si vyberou vlastní verzovací systém, službu na vedení repozitáˇre, mailing listy2 , wiki stránky, dokumentace projektu, fórum. Tyto a další služby mají ruznou ˚ strukturu dat, ale zárovenˇ sdílí informace a autory. Samozˇrejmˇe existují centralizované služby, které sjednocují vše dohromady, ale autoˇri Searchiska si uvˇedomují, že nˇekteˇrí vývojáˇri budou vždy vybírat podle vlastních preferencí z ruzných ˚ zdroju. ˚ Hlavní cíl systému Searchisko je tedy centrálnˇe indexovat dokumenty ze všech zdroju˚ a umožnit v nich vyhledávat. Systém byl vytvoˇren pro vývojáˇre vˇetších projektu, ˚ ale díky jeho obecné povaze ho lze použít na vše, co má textový charakter a je zapotˇrebí se zdroji pracovat podobným zpusobem. ˚ Komunikace probíhá pˇres webové rozhraní REST API pomocí jazyka JSON3 . Systém využívá fulltextový vyhledávaˇc Elasticsearch [1], který umožnuje ˇ ukládat data do indexu˚ a velmi rychle nad nimi vyhledávat. Searchisko doplnuje ˇ Elasticsearch o persistenci a bezpeˇcnost dat. 1. poˇcítaˇcový software s dostupným zdrojovým kódem pro veˇrejnost 2. služba, která pˇrijme elektronickou poštu na jednu adresu a rozešle ji na další uložené adresy 3. JavaScript Object Notation je zpusob, ˚ jak zapsat textovˇe programová data, napˇríklad objekty, seznamy nebo cˇ ísla
15
3. P OPIS SYSTÉMU S EARCHISKO
3.1 Principy fungování a architektura systému Searchisko Komponenty systému Searchisko jsou rozdˇeleny na tˇri vrstvy, kde jen ta nejvyšší komunikuje s klienty. Následující popis vrstev a interakce komponent s klienty bude vycházet z nákresu architektury na obrázku 3.1.
Obrázek 3.1: Model systému searchisko [35]
Nejspodnˇejší vrstva systému se stará o uchování dat a jejich indexování pro efektivní vyhledávání. Komponenta nazvaná „Search subsystem“ je Elasticsearch, tzn. dokumenty uložené v indexech pˇripravené na rychlé prohledávání jejich hodnot. Informace v systému Elasticsearch nejsou trvale uloženy a vlivem jakékoli významnˇejší zmˇeny se musí dokumenty znovu indexovat [9]. Tím jsou dokumenty stále pˇripraveny k efektivnímu prohledávání, ale za cenu uchování dat mimo systém Elasticsearch. To obstarává komponenta 16
3. P OPIS SYSTÉMU S EARCHISKO „Persistent store“ , což je databáze používaná pomocí Java Persistence API implementované jako Hibernate4 . Komponenty v prostˇrední vrstvˇe architektury tvoˇrí základ všech služeb, které Searchisko poskytuje. Využívá data ze spodní vrstvy a nabízí operace nad daty aplikaˇcnímu rozhraní ve tˇretí vrstvˇe. Zapadá sem komponenta na správu obsahu, vyhledávací komponenta, správa hodnocení obsahu, konfigurace a patˇrí sem i nová komponenta pro správu štítku. ˚ Nejvyšší vrstva komunikuje pomocí REST architektury popsané v sekci 3.2.1. Další možnost komunikace je aktivní stahování pˇres protokol Atom Syndication Format5 [9]. Komponenta „Content retrieval/search API“ je urˇcena pro klienty, kteˇrí vyhledávají obsah v systému. Vyhledávání umožnuje ˇ vˇetšinu silných nástroju˚ pro získání požadovaného výsledku, které poskytuje Elasticsearch: agregaci obsahu, ohodnocení relevance dokumentu, ˚ štítková mraˇcna a další (viz. dokumentace Elasticsearch [1]). Nicménˇe ne všechny, protože Elasticsearch neˇreší bezpeˇcnost a kontrolu pˇrístupu a nˇekteré dotazy by mohli vracet víc informací než je uživateli dovoleno. Další duležitá ˚ komponenta slouží pro vkládání obsahu, která se dál dˇelí podle zpusobu ˚ vkládání. „Content PUSH API“ reaguje jako klasický server a po klientovˇe POST požadavku uloží dokument do databáze a do indexu v systému Elasticsearch. Jinak funguje komponenta „Pull indexer“ , která využívá aplikaˇcního rozhraní klienta k tomu, aby si sama stahovala a ukládala dokumenty. Komponenta „Administration API“ slouží pro manipulaci celé platformy administrátory. Zejména mohou spustit pˇreindexování dokumentu, ˚ monitorovat parametry systému nebo konfigurovat indexy, strukturu dokumentu˚ a role uživatelu. ˚ Searchisko rozdˇeluje klienty na ty, kteˇrí vkládají dokumenty do systému a ty, kteˇrí je vyhledávají. V praxi se mohou role prolínat, 4. aplikaˇcní rozhraní pro mapování objektu˚ v jazyce Java na prvky relaˇcního schématu databáze 5. formát založený na XML, který popisuje informace posílané z jedné webové služby na všechny, kteˇrí o to zažádají; je to nástupce protokolu RSS
17
3. P OPIS SYSTÉMU S EARCHISKO ale pro návrh systému je to více praktické. „Content consumers“ jsou oznaˇcováni klienti, kteˇrí vyhledávají. Pˇríkladem jsou webové stránky s full-textovým vyhledáváním založeným na systému Searchisko nebo tzv. „Planet“ weby, které agregují pˇríspˇevky z ruzných ˚ blogu˚ a vystavují je na jedné stránce. „Searchisko powered apps“ uloží svuj ˚ obsah do Searchiska a následnˇe ho aktivnˇe používají (napˇr. pˇrímo ho zobrazují na svých stránkách). Klienti pro ukládání obsahu se nazývají „Content providers“ neboli poskytovatelé obsahu a jsou opˇet rozdˇeleni podle toho, zda využívají „Content PUSH API“ nebo „Pull indexer“ . 3.1.1 Struktura dokumentu Oˇcekává se, že dokumenty vkládané do systému Searchisko budou mít strukturu JSON objektu, kde klíˇce jsou názvy vlastností dokumentu a hodnoty pˇredstavují tyto vlastnosti. Poskytovatel obsahu si muže ˚ sám urˇcit, které atributy dokumentu bude vkládat, jak je rozdˇelí a pojmenuje. Searchisko je v tomto smˇeru velmi flexibilní. Na druhou stranu, jsou pˇreddefinovány systémové klíˇce zaˇcínající prefixem sys_ , které využívá aplikaˇcní rozhraní pro vyhledávání [9]. Ty duležité ˚ klíˇce se pˇriˇrazují každému dokumentu implicitnˇe a poskytovatel obsahu má možnost je pˇrepsat pˇri vkládání dokumentu. Nejduležitˇ ˚ ejší z nich jsou: •
sys_type – typ obsahu (napˇr. pˇríspˇevek na blogu nebo email)
•
sys_project – název projektu
•
sys_contributors – autoˇri dokumentu
•
sys_tags – štítky
•
sys_content – samotný obsah dokumentu
Všechny systémové klíˇce jsou dohledatelné v dokumentaci systému Searchisko [7]. 18
3. P OPIS SYSTÉMU S EARCHISKO 3.1.2 Kontrola pˇrístupu Jak jsem zmínil, klienti se rozdˇelují na klasické uživatele a poskytovatele obsahu. K obˇema se pˇristupuje jinak i ve fázi autentizace. Zatímco poskytovatel obsahu se pˇrihlašuje jednoduchým ovˇerˇ ením pˇrístupu (angl. Basic access authentication6 ), uživatel se pˇrihlašuje pˇres Single Sign-On server. Služba Single Sign-On (SSO) uživateli poskytuje bezpeˇcnou a jednoduchou autentizaci do ruzných ˚ prostˇredí v poˇcítaˇcové síti [15]. Pˇrihlášení se potom dˇeje jen jednou v první službˇe, kterou používá. Po pˇrechodu uživatele na jinou službu si údaje o nˇem služby pošlou a nemusí dojít k dalšímu autentizaˇcnímu procesu. Zjednodušuje se i správa práv uživatelu. ˚ Searchisko autorizaci rˇ eší pomocí rolí, kterých muže ˚ mít uživatel nebo poskytovatel obsahu více. Základní role jsou ADMIN , PROVIDER ˇ napˇríklad role PROJECTS_MANAGER a CONTRIBUTOR , které doplnuje nebo role pro správu uživatelských štítku˚ (více v sekci 4.3.2).
3.2 Technologie používané systémem Searchisko 3.2.1 Representational State Transfer Abychom byli schopni vytváˇret interoperabilní webové služby, musíme se držet standardu. ˚ Jedním z nich je architektura Representational State Transfer neboli REST. Je to idealizovaný model interakcí v rámci webových aplikací, který se používá ve více cˇ i ménˇe zjednodušené formˇe [23]. REST se pomocí svých pravidel a omezení snaží minimalizovat latenci a sít’ovou komunikaci a souˇcasnˇe maximalizovat nezávislost a škálovatelnost. Používá URI7 jako identifikátor zdroju, ˚ se kterými pracuje. Zdroj se nyní chápe jako stav (proto je v názvu State), který ale musí být reprezentován daty v urˇcitém formátu. Stejný zdroj potom mužeme ˚ získat v ruzném ˚ formátu v závis6. jednoduché ovˇerˇ ení pˇrístupu používané v protokolu HTTP, které vyžaduje pro pˇrihlášení jméno a heslo [12] 7. jednoznaˇcný textový identifikátor zdroje v rámci poˇcítaˇcové sítˇe
19
3. P OPIS SYSTÉMU S EARCHISKO losti na tom, jaký typ je v hlaviˇcce HTTP požadavku [10]. Searhisko pracuje pouze s formátem JSON, který je úspornˇejší, než jazyky z rodiny XML. REST také definuje hierarchický jmenný prostor zdroju, ˚ ale implementaˇcní detaily schované za rozhraním jsou nezávislé na jmenném prostoru [10]. Každý požadavek je míˇren na konkrétní zdroj, který je urˇcen cˇ ástmi cesty. Napˇríklad /blog/ odkazuje na kolekci cˇ lánku˚ blogu, /blog/1 oznaˇcuje první cˇ lánek a mohli bychom pokraˇcovat s komentáˇri ke cˇ lánku /blog/1/comments/ a konkrétním komentárˇ em /blog/1/comments/6 [18]. Standardizované metody protokolu HTTP používané REST architekturou (tzv. „RESTful“ metody) jsou: •
GET – získání zdroje
•
PUT – vložení zdroje
•
POST – vložení nebo pˇridání zdroje do kolekce
•
DELETE – smazání zdroje
3.2.2 Elasticsearch Elasticsearch je projekt s otevˇreným zdrojovým kódem vytvoˇrený a publikovaný Shay Banonem v roce 2010. Následnˇe ho zaˇcalo používat hodnˇe lidí jako dokumentovou databázi kvuli ˚ jeho rychlosti a distribuované povaze [18]. Také Searchisko je oddˇeleno od systému Elasticsearch, který je distribuovaný na více serveru. ˚ Základními prvky systému Elasticsearch jsou index, dokument, pole a typ dokumentu. Indexem se chápe místo, kde se ukládají data. Pokud bychom chtˇeli Elasticsearch porovnat s relaˇcními databázemi, index by byl tabulka. V systému Searchisko je index urˇcen pro odlišení typu˚ dokumentu, ˚ ale existují i další úˇcely (napˇríklad ke statistikám). Do indexu potom ukládáme dokument, což je v jazyce relaˇcních databází rˇ ádek v tabulce. Odpovídá pˇresnˇe tomu, cˇ emu v systému Searchisko rˇ íkáme také dokument. Skládá se z polí (sloupce 20
3. P OPIS SYSTÉMU S EARCHISKO tabulky), jejichž poˇcet a typy však nemusí být pro dokumenty v jednom indexu stejné. To je hlavní rozdíl oproti relaˇcní databázi, a také duvod ˚ flexibility systému Searchisko. Searchisko dovoluje poskytovateli obsahu pomocí nich libovolnˇe rozdˇelovat a konfigurovat dokumenty. Elasticsearch je široce a jednoduše konfigurovatelný. Index se nastavuje pomocí definice pojmenované „mapping“ , která urˇcuje celkovou strukturu indexu. „Mapping“ si mužeme ˚ pˇredstavit jako seznam polí, které budou mít dokumenty v daném indexu. Navíc každému poli mužeme ˚ nastavit analyzátor, který upraví záznam vždy pˇredtím, než se uloží do pole. Pˇríklad analyzátoru muže ˚ být rozdˇelení jednoho záznamu na více záznamu˚ podle bílých znaku˚ ( „whitespace“ ) nebo zmˇena písmen na malá ( „lowercase“ ). Analyzátor se skládá z jednoho nebo více tzv. filtru˚ a díky tomu muže ˚ upravovat záznam více zpusoby. ˚ Všechny konfigurace jsou ve formátu JSON.
21
4 Návrh a implementace služby pro práci se štítky Systém Searchisko je navržen tak, aby byl jednoduše rozšiˇritelný, což znaˇcnˇe zjednodušilo doplnˇení rozhraní pro práci se štítky. Software je kompletnˇe vyvíjen v jazyce Java EE 6 s použitím Contexts and Dependency Injection1 . Jako databázová technologie je použito aplikaˇcní rozhraní Java Persistence API konkrétnˇe implementované jako Hibernate pro dlouhodobé uchování dat, REST API pro komunikaci pˇres protokol HTTP a Enterprise Java Beans2 pro zjednodušení návrhu softwaru. Každá skupina metod obsluhující jednu funkci systému (služba) má cˇ tyˇri cˇ ásti, v Javˇe reprezentované tˇrídami. První je objektový základ funkcionality – jeden nebo více objektu, ˚ jejichž atributy se ukládají do databáze a další složky s nimi pracují. Druhá cˇ ást zavádí metody, které obsluhují databázi a objekty, tzv. Data Access Object (DAO). Tˇretí tvoˇrí aplikaˇcní rozhraní pomocí REST API, které umožnuje ˇ pˇristupovat k metodám zvenku. Poslední slouží k vytvoˇrení reakcí na události v Searchisku. Pˇríkladem takto zavedených služeb v Searchisku jsou •
Provider Service pro správu údaju˚ o poskytovatelích obsahu a pro konfiguraci struktury dokumentu˚
•
Content Service pro správu dokumentu˚
•
Search Service pro správu vyhledávání
Správa uživatelských štítku˚ je další z tˇechto služeb a její cˇ tyˇri cˇ ásti jsou popsány v následujících sekcích a oˇcíslovány na obrázku 4.1. 1. jeden z prvku˚ pˇridaných do Java EE 6, který umožnuje ˇ vkládat kontext a závislosti mezi klasickými Java Beans do programu˚ napsaných v jazyce Java 2. architektura na stranˇe serveru pro vývoj distribuovaných objektovˇe orientovaných aplikací v jazyce Java [32]
23
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY
Obrázek 4.1: Komunikace cˇ tyˇr cˇ ástí služby pro správu uživatelských štítku˚
24
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY
4.1 Objekt „štítek“ V první fázi bylo duležité ˚ rozhodnout, jaké informace uchovat pro každý štítek jako objekt. Základní atributy jsou textový rˇ etˇezec reprezentující daný štítek a jednoznaˇcné oznaˇcení dokumentu, ke kterému náleží (tzv. content id). Otázka je, zda je potˇreba si pamatovat autora štítku. Pokud se podíváme na aplikace založené na široké folksonomii (napˇr. Delicious), zjistíme, že autorství štítku˚ je velmi duležité. ˚ Náš návrh je založen na úzké folksonomii, kde každý dokument má jednu množinu štítku˚ a jejich autoˇri nejsou pro uživatele nˇejak dule˚ žití. Pˇresto jsme se rozhodli autora štítku ukládat. Duvodem ˚ je vˇetší kontrola nad systémem a také lepší a zajímavˇejší analýzy distribuce štítku˚ v systému. Ze stejného duvodu ˚ si objekt „štítek“ pamatuje datum vytvoˇrení (pˇríp. pˇrepsání). Potom jsme schopni analyzovat jazyk pomocí závislosti cˇ etnosti slov na poˇctu uživatelu, ˚ kteˇrí je používají. Také nám atributy umožní analyzovat vývoj jazyka (jednotlivých uživatelu˚ nebo všech) v cˇ ase. Takto vytvoˇrené objekty reprezentují pouze uživatelské štítky. Navíc se v Searchisku pro každý dokument ukládají štítky vytvoˇrené a pˇridané autorem dokumentu, tzv. autorské štítky. Jejich správa je povolena jen autorovi, ale pˇri vyhledávání se prohledávají uživatelské i autorské štítky bez rozdílu. V nastavení Elasticsearch jsou vytvoˇrena dvˇe pole: tags pro uchování autorských štítku˚ a sys_tags pro všechny štítky, pˇres které se vyhledává. Pˇri každé zmˇenˇe se spojí uživatelské štítky z databáze s autorskými štítky z pole tags a uloží se do pole sys_tags.
4.2 DAO Ve vrstvˇe obsluhující databázi bylo klíˇcové vymezit rozhraní, které bude následnˇe používat vyšší vrstva – REST API. Zvolili jsem následující metody rozhraní: •
getTagsByContent(contentId) – vrací štítky pro jeden dokument 25
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY •
getTagsByContentType(contentType) – vrací štítky pro všechny dokumenty jednoho typu
•
createTag(tag) – vytvoˇrí štítek
•
deleteTag(contentId, tagLabel) – smaže štítek tagLabel z daného dokumentu
•
deleteTagsForContent(contentId) – smaže všechny štítky jednoho dokumentu
•
changeOwnershipOfTags(contributorFrom,contributorTo) – zmˇení autora štítku
Rozhraní se podobá návrhu CRUD (Create, Read, Update, Delete)3 nicménˇe chybí operace pro úpravu (Update), protože jediná informace, která nese význam u objektu „štítek“ , je textový rˇ etˇezec, který ho reprezentuje. Potom jeho zmˇena v podstatˇe odpovídá smazání starého a vytvoˇrení nového štítku, proto by byla metoda updateTag pˇrebyteˇcná. Další odlišnost od klasického CRUD návrhu je závislost na kontextu v rámci systému Searchisko. Napˇríklad cˇ tecí metody (Read) vrací štítky pro jeden dokument nebo pro všechny dokumenty jednoho typu. Pro lepší pˇredstavu: typ dokumentu muže ˚ být fórum, blog nebo sociální sít’, takže metodou getTagsByContentType získáme všechny štítky použité pro cˇ lánky na blogu, pˇríspˇevky v diskuzi nebo na sociální síti. Stejným stylem jsou navrženy metody pro mazání štítku. ˚ Zárovenˇ bych rád poznamenal, že metoda vracející jeden štítek je zbyteˇcná, protože uživatel nezná žádné identifikaˇcní cˇ íslo štítku4 ,a proto by musel pro identifikaci použít samotný textový rˇ etˇezec, cˇ ímž použitelnost metody pˇrestává dávat smysl. 3. zkratka pro cˇ tyˇri základní operace nad záznamem v trvalém úložišti dat [4] 4. identifikaˇcní cˇ íslo (id) systém vede pro všechny databázové objekty (tedy i štítky), ale jejich správa je cˇ istˇe interní záležitost
26
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY Pro vlastní povahu štítku˚ jsme rozhodli, že se se všemi štítky bude pracovat bez rozdílu velkých a malých písmen. U uvedených metod to pˇredstavuje zmˇenu createTag metody tak, aby pˇred uložením ˇ pˇrevedla všechny písmena na malá. Ctecí metody (Read) tento návrh neovlivní, ale mazací (Delete) musí pˇred porovnáním zadaného štítku s existujícími pˇrevést stejnou metodou na malá písmena. Dále návrh poˇcítá s uložením rˇ etˇezce jakýchkoli Unicode5 znaku. ˚ To znamená, že jazyk štítku muže ˚ být jakýkoli. Jediná nevýhoda pro jiné jazyky než angliˇctinu je ta, že náš návrh využití WordNetu pro synonyma (5) zatím umí pracovat jen s anglickými slovy. Neomezovali jsme ani poˇcet slov, tzn. mezera je validní znak ve štítku.
4.3 Návrh REST API V této sekci zduvodním ˚ výbˇer architektury, uvedu metody aplikaˇcního rozhraní pro správu uživatelských štítku, ˚ chování služby v chybových situacích a návrh autorizace této služby. 4.3.1 Proˇc byla vybrána architektura REST Pro komunikaci mezi serverem (Searchisko) a klientem pˇres protokol HTTP bylo potˇreba zvolit vhodnou architekturu rozhraní. V úvahu pˇricházejí dvˇe architektury: Representational State Tranfer (REST) a Remote Procedure Call (RPC). První je pˇredstaven v kapitole 3.2.1 a druhý pˇredstavím v následujícím odstavci. RPC je obecná architektura, která dovoluje vykonat metodu na stranˇe serveru iniciovanou na stranˇe klienta [23]. Konkrétní pˇríklad protokolu založeném na RPC je Simple Object Access Protocol (SOAP) spolu s jazykem Web-service Description Language (WSDL). Poskytují sjednocení typového systému, deskriptivního jazyka, adresovacího modelu a zabezpeˇcení. Protokoly jsou procedurálnˇe založeny (na rozdíl od datovˇe založeného REST), což znamená, že umožnují ˇ definovat mnoho operací nad velkým množstvím objektu. ˚ 5. mezinárodnˇe uznávaný standard, který urˇcuje pˇrevod cˇ ísla na znak
27
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY Všechny služby systému Searchisko používají pro komunikaci architekturu REST, což byl hlavní duvod, ˚ proˇc jsme se rozhodli zvolit stejnou architekturu i pro službu pro správu uživatelských štítku. ˚ I kdyby tomu tak nebylo, architektura REST je v tomto pˇrípadˇe vhodnˇejší z nˇekolika duvod ˚ u. ˚ Adresování má u REST API jasnou strukturu a podle URL se okamžitˇe urˇcí volaná metoda [23]. Lomítkem se v URL muže ˚ tvoˇrit hierarchická struktura, což je vhodné pro systémy s logicky rozdˇeleným aplikaˇcním rozhraním, jako mužeme ˚ vidˇet v systému Searchisko. Naopak SOAP nezná žádné globální adresovací schéma. Další vhodná vlastnost REST architektury je jeho standardní množina typu˚ metod (GET, POST, PUT, DELETE), které jsou v Searchisku podporované. 4.3.2 Autorizace Pˇri návrhu aplikaˇcního rozhraní je potˇreba si rozmyslet, kdo k nˇemu bude mít pˇrístup, pˇrípadnˇe k jakým pod-ˇcástem. Inspiraci jsem hledal u služeb se štítky, které jsem uvedl v kapitole 2.3. Vzhledem k tomu, že v mém pˇrípadˇe má být systém založen na kolaborativním štítkování, nehodí se použít uzavˇrenou autorizaci, jakou používá služba YouTube, která povoluje úpravy jen autorum. ˚ Na druhou stranu úzká folksonomie systému Searchisko nám nedovolí použít návrh služby Delicious. Návrh autorizace systému Searchisko má nejvíce spoleˇcného s návrhem u služby Flickr, ale pˇresto jsme chtˇeli uživateli dát více volnosti. Co se týˇce autorských štítku, ˚ autorizace je vyˇrešena tím, že jejich pˇridání je možné pouze spolu s dokumentem, a proto naše aplikaˇcní rozhraní s nimi nemusí pracovat. Aplikaˇcní rozhraní pro uživatelské štítky musí mít autorizaci vyváženou tak, aby mˇelo co nejvíc uživatelu˚ právo štítkovat, a tím vznikala bohatá folksonomie spolu s kvalitním základem pro vyhledávání a zárovenˇ uživatelé nemohli zneužívat štítky pro tag spamming, jak jsem popsal v kapitole 2.1.4. Náš návrh vychází vstˇríc poskytovatelum ˚ obsahu a dává jim právo vybrat uživatele, kteˇrí mohou pˇridávat štítky k dokumentum ˚ jeho typu. Každý uživatel muže ˚ mít více rolí, jak je popsáno v kapitole 28
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY 3.1.2, a tím muže ˚ pˇrispívat i k více typum ˚ dokumentu˚ najednou. Role pro uživatele jsou potom oznaˇceny TAGS_MANAGER_contentType , pokud mají povoleno spravovat štítky pro typ contentType . 4.3.3 Metody aplikaˇcního rozhraní Metody využívají již uvedených metod z rozhraní DAO ve vztahu 1:1. Mají tedy stejný význam a stejnˇe je i pojmenujeme (až na metodu createTag → postTag ). Ke všem metodám našeho rozhraní se pˇristupuje pomocí URL s prefixem tagging/ , stejnˇe jako napˇríklad služba pro správu obsahu používá prefix content/ . Pro metody spravující štítky na úrovni dokumentu se za prefixem oˇcekává oznaˇcení dokumentu tagging/{contentId} – platí pro následující metody: getTagsByContent , postTag a deleteTag . Metody pracující s typem dokumentu jsou dostupné z URL rozšíˇreného o další zanoˇrení takto tagging/type/{contentType} – platí pouze pro metodu getTagsByContentType . Metodu deleteTagsForContent voláme pomocí sufixu _all v URL, aby se rozlišilo mezi mazání jednoho štítku nebo všech v rámci jednoho dokumentu. 4.3.4 Chování metod a reakce na chyby Aby klient vˇedˇel, zda byla operace úspˇešná, používáme standardní stavové kódy protokolu HTTP. U všech metod platí, že stavový kód 200 znamená úspˇešnou operaci. Metoda postTag štítek vytvoˇrí jen pokud u daného dokumentu ještˇe neexistuje, v opaˇcném pˇrípadˇe neprovede žádnou operaci. Chtˇeli jsme však klienta informovat o tom, který pˇrípad nastal, a proto pˇri opravdovém vytvoˇrení vracíme stavový kód 201 (CREATED) . Metody get odpovídají statusem 404 , pokud neexistuje žádný štítek pro dokument (pˇríp. všechny dokumenty jednoho typu). Tento status je v odpovˇedi i v pˇrípadˇe, že nebyl nalezen dokument (pˇríp. typ dokumentu), pro který hledáme, vkládáme nebo mažeme štítek. Poslední používaný stavový status je 400 (BAD_REQUEST) , který se pošle klientovi v pˇrípadˇe špatného formátu oznaˇcení dokumentu nebo špatného formátu JSON struktury u metod POST a DELETE .
29
4. N ÁVRH A IMPLEMENTACE SLUŽBY PRO PRÁCI SE ŠTÍTKY
4.4 Reakce na události v Searchisku Poslední cˇ ást služby na správu uživatelských štítku˚ reaguje na události v systému Searchisko. Tyto události jsou vyvolány jednou ze služeb (4) a nesou duležitou ˚ zprávu, která muže ˚ zmˇenit hodnoty v dalších službách. Služba spravující uživatelské štítky tyto události nevytváˇrí, protože žádné lokální úpravy nemají vliv na ostatní služby. Odchytávané události jsou následující: •
contentDeletedEvent Událost znaˇcí smazání dokumentu Reakce smazání všech uživatelských štítku˚ pro daný dokument
•
contentBeforeIndexed Událost posílá se pˇred uložením dokumentu (nového nebo aktualizujeme starý) Reakce spojení všech autorských štítku˚ v poli tags a uživatelských štítku˚ do pole sys_tags (v pˇrípadˇe vytváˇrení nového dokumentu dojde jen k pˇrekopírování polí, protože nemohou ještˇe existovat uživatelské štítky)
•
contributorMergedEvent Událost oznamuje spojení identit uživatelu˚ Reakce sjednocení atributu autor štítku pro všechny štítku od tohoto uživatele
•
contributorCodeChangedEvent Událost upozornuje ˇ na pˇrejmenování uživatele Reakce pˇrejmenování atributu autor štítku u všech štítku˚ tohoto uživatele
30
5 Využití synonym V sekci 2.1.3 jsme zmínili nevýhody kategorizace pomocí štítku, ˚ mezi které patˇrí i synonymická slova ve štítcích. Problém nastává zejména tehdy, je-li v systému vˇetší množství slov oznaˇcující stejný objekt. Pro ilustraci uved’me štítky television a tv. Uživatel pˇri vyhledání štítku tv uvidí pouze zdroje oznaˇcené tv a rovnocennˇe relevantní zdroje oznaˇcené television ne. Jako rˇ ešení problému se nabízí dvˇe varianty: 1.
Ve fázi vyhledávání si necháme vygenerovat seznam všech synonym pomocí slovníku synonym. Poté v odpovˇedi vrátíme všechny zdroje, které jsou oznaˇceny alesponˇ jedním štítek s nˇekterým synonymem (pˇríp. pˇrímo vyhledávaným slovem).
2.
Synonyma vygenerujeme ve fázi vytváˇrení štítku a všechna je uložíme spolu s vytvoˇreným štítkem. Fázi vyhledávání nemusíme nˇejak mˇenit, protože platí tvrzení: pokud je nˇejaký zdroj oznaˇcen synonymem k hledanému slovu, musí být oznaˇcen i hledaným slovem.
První varianta je cˇ asové nároˇcná na fázi vyhledávání, ale pamˇet’ovˇe nˇejak nároˇcná není. U druhé varianty potˇrebujeme pamˇet’ k uchování synonym1 , ale zhoršuje se cˇ asová složitost vytváˇrení štítku. V systému Searchisko dochází k fázi vyhledávání mnohem cˇ astˇeji než k fázi vytváˇrení štítku. Zárovenˇ velikost použité pamˇeti nehraje v systému Searchisko duležitou ˚ roli, protože je pˇripravené na uložení velkého množství dat. Z tˇechto duvod ˚ u˚ jsme se rozhodli pro druhou variantu. Další rozhodnutí je tˇreba uˇcinit ve výbˇeru slovníku synonym. Pro nás velmi vhodnou volbou je tzv. sémantická sít’ WordNet, která nenabízí jen synonyma, ale další vazby mezi slovy, které v budoucnu umožní rˇ ešit ostatní uvedené problémy s kategorizací (homonyma a hyperonyma). Konkrétnˇe používáme jeden z nejrozšíˇrenˇejších a nejlépe rozpracovaných WordNetu˚ pro angliˇctinu, který byl vytvoˇren na univerzitˇe v Princetonu pod vedením profesora George A. Millera [29]. 1. podle Lindén a Carlsona je prumˇ ˚ erný poˇcet synonym na jedno slovo ve WordNetu 1,8 [20]
31
5. V YUŽITÍ SYNONYM
5.1 WordNet WordNet je lexikografická databáze slov v elektronické podobˇe urcˇ ená pro poˇcítaˇcové zpracování [25]. Slova ve WordNetu nejsou jen rˇ etˇezce znaku, ˚ ale nabývají významu díky vazbám s ostatními slovy. Díky spojení slov se sémantikou je WordNet cˇ asto používaný jako prostˇredek pro zpracování pˇrirozeného jazyka. Po vzniku princetonského WordNetu vznikly další WordNety pro jiné jazyky než angliˇctinu, ale dále se budeme zabývat pouze WordNetem z Princetonské Univerzity, protože ho používáme v systému Searchisko. Podstatná jména, slovesa, pˇrídavná jména a pˇríslovce jsou organizovaná do synonymických rˇ ad, které jsou pospojované sémantickými vazbami [24]. Slova ve slovníku WordNetu jsou dvojce ( f , s), kde f ( f orm) je rˇ etˇezec znaku˚ a s (sense) je význam [25]. Slovo muže ˚ mít více významu˚ (polysémie) nebo naopak více slov muže ˚ sdílet stejný význam (synonymum). Význam je reprezentován jako synonymická rˇ ada (jedno nebo více synonym). WordNet obsahuje více než 118 000 slovních forem a 90 000 významu, ˚ které tvoˇrí více než 166 000 dvojic. Pˇribližnˇe 17 % slov WordNetu jsou polysémie a 40 % má jedno nebo více synonym. WordNet zná i morfologické vazby jazyka. Pro angliˇctinu jsou to odvozování, ohýbání a skládání slov. 5.1.1 Použitá verze WordNetu WordNet se aktualizuje a zlepšuje, a proto se vydávají stále nové verze. Mužeme ˚ ho používat i v ruzných ˚ formátech. Data i další software WordNetu vytvoˇreného na princetonské univerzitˇe je chránˇen licencí BSD, která dovoluje data bezplatnˇe používat. K rozšíˇrení systému Searchisko byl použit WordNet verze 3.0, který je napsaný ve formátu jazyka Prolog2 . Duvodem ˚ je kompatibilita se systémem Elasticsearch, který umožnuje ˇ pˇrímo generovat synonyma, ale požaduje prologovský formát, který je ve tvaru
2. programovací jazyk založený na predikátové logice prvního rˇ ádu, který k výpoˇctum ˚ využívá klauzule a rezoluˇcní pravidlo
32
5. V YUŽITÍ SYNONYM
s(synset_id,w_num,’word’,ss_type,sense_number,tag_count). kde operátor s pˇredstavuje synonymickou rˇ adu, synset_id je jednoznaˇcné oznaˇcení synonymické rˇ ady, w_num je cˇ íslo slova v rámci významu, 0 word0 je slovo jako rˇ etˇezec znaku, ˚ ss_type urˇcuje slovní druh, sense_number je cˇ íslo významu a tag_count je poˇcet vyjadˇrující, kolikrát byl význam oznaˇcen v seznamu sémantických konkordancí [38]. Následující pˇríklad obsahuje záznamy jedné synonymické rˇ ady pro význam slova osoba.
s(100007846,1,’person’,n,1,6833). s(100007846,2,’individual’,n,1,51). s(100007846,3,’someone’,n,1,17). s(100007846,4,’somebody’,n,1,0). s(100007846,5,’mortal’,n,1,2). s(100007846,6,’soul’,n,2,6). Všechna slova tedy mají stejný význam, stejné cˇ íslo synonymické rˇ ady a pro nás nejduležitˇ ˚ ejší poznatek je, že všechna jsou navzájem synonyma.
5.2 Návrh pro systém Searchisko Díky tomu, že systém Elasticsearch umí pracovat se synonymy, zavedení jejich použití spoˇcívalo zejména v konfiguraci systému ElasticSearch a poskytnutí slovníku synonym. Následující popis konfigurace používá pojmu˚ uvedených v sekci 3.2.2. Základem bylo vytvoˇrit filtr, který umí generovat synonyma pomocí WordNetu. Konfigurace 5.1 ukazuje nastavení filtru „synonym“ . Pokud je klíˇc „format“ nastaven na „wordnet“ , v klíˇci „synonym_path“ se oˇcekává cesta k souboru s WordNetem v prologovském formátu. Dále byl vytvoˇren analyzér (5.2), který používá uvedený filtr. Rozdˇelování záznamu na další nastavuje klíˇc „tokenizer“ , který v tomto pˇrípadˇe má hodnotu „keyword“ , což znamená, že se štítek nerozdˇeluje. Povolujeme totiž víceslovné štítky. 33
5. V YUŽITÍ SYNONYM
" filter " : { " synonym " : { " type " : " synonym " , " format " : " wordnet " , " synonym_path " : " analysis / wn_s . pl " } }
1 2 3 4 5 6 7
Obrázek 5.1: Konfigurace filtru pro generování synonym
" analyzer " : { " synonym " : { " tokenizer " : " keyword " , " filter " : [" synonym "] } }
1 2 3 4 5 6
Obrázek 5.2: Konfigurace analyzéru pro synonyma K nastavení ukládání synonym pˇri vytváˇrení štítku˚ zbývá poslední krok. Bylo potˇreba vytvoˇrit pole indexu, do kterého se ukládají synonymické štítky. Pro podobné úˇcely byla vytvoˇrena v systému Elasticsearch tzv. „multipole“ (multifields), která rozdˇelují jedno pole na další. Pro každou operaci v Elasticsearch je viditelné jen jedno pole, které je pro tuto operaci nejvhodnˇejší. Napˇríklad pˇri výpisu se zobrazí jen originální štítky, ale pˇri vyhledávání se prochází i synonyma. Konfigurace 5.3 ukazuje nastavení „multipole“ pro synonymické štítky. Je to nastavení indexu, tedy „mapping“ , jak jsme ho popsali v sekci 3.2.2. Pro vkládané štítky se aplikuje analyzér „sys_tags“ , který provádí klasické úpravy štítku a zmˇeny jsou uloženy do podpole „sys_tags“ . Na synonyma se uplatní analyzér „synonym“ a jsou uloženy do dalšího podpole, ve kterém se bude vyhledávat. Nakonec je tˇreba konfigurovat vyhledávání. Protože se poˇcítá se zmˇenou výbˇeru polí, ve kterých se vyhledává, konfigurace probíhá 34
5. V YUŽITÍ SYNONYM 1 2 3 4
5
6 7
" sys_tags : { " type " : " multi_field " , " fields " : { " synonyms " : { " type " : " string " , " analyzer " : " synonym " , " store " : " yes " } , " sys_tags " : { " type " : " string " , " analyzer " : " sys_tags " , " store " : " yes " } } } Obrázek 5.3: Konfigurace analyzéru pro synonyma za bˇehu systému. Pˇres REST API metodou POST vložíme konfiguraci jménem search_fulltext_query_fields s JSON daty, které popisují vyhledávací pole.
1
{ " sys_title " : " 2 . 5 " , " sys_description " : "" , " sys_project_name " : " 2 " , " sys_tags " : " 1 . 5 " , " sys_tags . synonyms " : "" , " sys_contributors . fulltext " : ""
2 3 4 5 6 7 8
} Obrázek 5.4: Konfigurace analyzéru pro synonyma V konfiguraci 5.4 klíˇce pˇredstavují pole, ve kterých se bude vyhledávat, a hodnoty pˇredstavují váhu (duležitost) ˚ pole pˇri vyhledávání. Pokud je hodnota prázdná, váha je 1. Mužeme ˚ vidˇet, že vyhledávání upˇrednostnuje ˇ obsah titulku a jméno projektu, ale sleduje také popis dokumentu, štítky a jména uživatelu. ˚ Ke staré konfiguraci jsme pˇridali pouze rˇ ádek cˇ .6. Nyní se bude vyhledávat pˇres pole synonym, ale originální štítky (pole sys_tags) budou lehce upˇrednostnovány. ˇ 35
5. V YUŽITÍ SYNONYM 5.2.1 Vyhledávání synonym podle prefixu Moderní vylepšení vyhledávání je našeptávání slov podle prefixu. Pˇri každém vloženém znaku se pošle dotaz a uživatel uvidí nabídku možných slov. Vytvoˇrili jsme zajímavé vylepšení systému Searchisko, které takto nabízí nejen štítky s daným prefixem, ale i štítky související významem. Nastavení je opˇet ukázkovým pˇríkladem jednoduché konfigurovatelnosti systému Elasticsearch. Dovoluje registrovat uživatelské dotazy, které upravují klasické vyhledávání podle potˇreb. Mohou mít mnoho voleb, ale nejduležitˇ ˚ ejší jsou dvˇe informace: v jakých polích se bude vyhledávat (sys_tags.synonyms) a obsah jakých polí bude v odpovˇedi (sys_tags). Jinými slovy jsou v odpovˇedi všechny štítky z dokumentu, ˚ které jsou oznaˇceny alesponˇ jedním štítkem se zadaným prefixem nebo libovolným synonymem ke štítkum ˚ s tímto prefixem.
Obrázek 5.5: Synonyma použitá pro doplnování ˇ štítku˚ Problém je, že štítky jednoho dokumentu spolu nemusí souviset, a proto se u doplnˇení mohou nabízet nerelevantní slova. Bohužel Elasticsearch nenabízí pˇrímoˇcaré rˇ ešení na tento problém. Klient muže ˚ tuto situaci vyˇrešit opˇetovným posláním dotazu a použitím analyzéru na synonyma, díky kterému muže ˚ filtrovat jen relevantní slova. 36
6 Analýza dat Souˇcástí této práce je analýza dat systému Searchisko. Nejprve uvedeme hlavní informace a zajímavosti o nasbíraných datech (zejména štítcích). Potom ovˇerˇ íme, zda distribuce štítku˚ systému Searchisko odpovídá pˇredpokladu z kapitoly 2.2.3 a na závˇer ukážeme, jak synonyma vylepšují výsledky vyhledávání.
6.1 Nasbíraná data Data byla stažena se svolením administrátoru˚ ze serveru http:// dcp2-jbossorgdev.rhcloud.com/. Používá ho komunita JBoss nˇekolik let pro vyhledávání zdroju˚ z ruzných ˚ služeb v závislosti na typu dokumentu: •
JBoss Blog – data pro server http://planet.jboss.org, která se pomocí protokolu RSS1 sbírají z ruzných ˚ blogu˚ na internetu pˇribližnˇe 4 roky
•
JBoss Forum – data z diskuzních fór k produktum ˚ spoleˇcnosti JBoss ze stránky https://developer.jboss.org sbírané pˇribližnˇe 2 roky
•
Solution – cˇ lánky týkající se JBoss produktu˚ z databáze znalostí spoleˇcnosti RedHat hostované na stránce https://access.redhat.com/search/#/knowledgebase
Data byla stažena na lokální instanci systému Searchisko aktualizovaného o zpracování uživatelských štítku˚ a vyhledávání štítku˚ s pomocí synonym. Všechny štítky jsou autorské, tedy vložené autorem zárovenˇ s dokumentem, protože uživatelských štítku˚ v dobˇe analýzy nebylo dostateˇcné množství. Celkem budeme pracovat s 47 310 (3497 1. formát založený na XML, který popisuje kódování informací posílaných z jedné webové služby na všechny, kteˇrí o to zažádají
37
6. A NALÝZA DAT ruznými) ˚ štítky z 21 449 dokumentu˚ (2,2 štítku na dokument). Z tohoto vzorku bylo odebráno 18 408 štítku˚ (246 ruzných), ˚ které se generovali automaticky a nepˇridávali žádnou hodnotu pro analýzu. Data tvoˇrilo celkem 2407 uživatelu˚ ruzných ˚ národností. Ve srovnání množství štítku˚ se serverem Delicious jich máme mnohem ménˇe, ale na analýzu je množství postaˇcující. V práci The Complex Dynamics of Collaborative Tagging [31] analyzují pˇribližnˇe milion štítku˚ (25 ruzných). ˚ Je ale potˇreba si uvˇedomit, že Delicious je založen na široké folksonomii, což se projevuje velkým množstvím opakujících se štítku. ˚ Proto jim k analýze staˇcí 25 nejˇcastˇejších štítku˚ oproti našim 3497.
Obrázek 6.1: Štítky s nejvyšším poˇctem výskytu˚ v systému Na grafu 6.1 jsou znázornˇeny štítky s nejvyšší frekvencí. Na první pohled je zˇrejmé, že štítkum ˚ dominují první tˇri, z nichž mužeme ˚ urˇcit 38
6. A NALÝZA DAT hlavní téma dokumentu. ˚ Štítek JBoss nemusíme vysvˇetlovat a EAP neboli Enterprise Application Platform je jeden z hlavních projektu˚ této komunity. První tˇri štítky tvoˇrí témˇerˇ jednu cˇ tvrtinu všech pˇridaných štítku˚ v našich datech. Další štítky se drží pod tisíci výskyty. Prumˇ ˚ erný poˇcet výskytu˚ jednoho štítku je 13,53. Z toho mužeme ˚ usoudit, že se uživatelé ovlivnují ˇ a pˇridávají stejné štítky. Dále vidíme velký vliv vývojáˇrské komunity na tématické zamˇerˇ ení štítku. ˚ Slova jako java, configuration nebo weservice jasnˇe vyjadˇrují, že se nacházíme v oblasti informaˇcních technologií. 583 štítku˚ obsahujících mezeru je dukazem, ˚ že uživatelé používají i víceslovné štítky. Tvoˇrí asi 17 % ze všech zkoumaných.
6.2 Ovˇerˇení platnosti zákonu˚ distribuce štítku˚
Obrázek 6.2: Distribuce štítku˚ v bodech V kapitole 2.2.3 jsme pˇredstavili, jak vypadá obecná oˇcekávaná distribuce štítku˚ v systému. Nyní ovˇerˇ íme, zda platí i pro rozložení na39
6. A NALÝZA DAT šich dat. Graf 6.2 znázornuje ˇ distribuci štítku˚ v bodech, abychom si mohli pˇredstavit, kde jsou data hustá a kde rˇ ídká. Mužeme ˚ si všimnout, že štítku˚ s vysokou frekvencí je zanedbatelné množství a naopak velké množství štítku˚ je pouze s jedním výskytem. Druhý fakt se nazývá dlouhý chvost (angl. long tail), což znaˇcí velké množství dat s nízkým výskytem. Štítku˚ s jediným výskytem bylo celkem 2072, se dvˇema 500 atd. Abychom poˇcítali distribuci s cˇ istými daty, odebereme uvedené odchylky. Konkrétnˇe nebudeme uvažovat prvních 10 nejfrekventovanˇejších štítku˚ a odebereme štítky s menším poˇctem výskytu˚ než 10.
Obrázek 6.3: Distribuce štítku˚ Na grafu 6.3 pozorujeme podobnost mocninné funkce y = c · x α pro α < 0. Rozumnˇejší výsledky dostaneme zlogaritmováním obou parametru˚ neboli pˇrevedením grafu do prostoru log − log. Práce The Complex Dynamics of Collaborative Tagging [31] uvádí, že nezáleží na bázi logaritmu, proto jsme zvolili dvojkový logaritmus. Následnˇe neporovnáváme hodnoty s mocninou funkcí, ale s pˇrímkou. 40
6. A NALÝZA DAT
Obrázek 6.4: Distribuce štítku˚ v prostoru log − log Zda naše data splnují ˇ oˇcekávanou distribuci lze nejlépe vidˇet na grafu 6.4. K porovnání jsme použili lineární regresi, kterou znázornuje ˇ svˇetlá pˇrímka sestrojená pomocí metody nejmenších cˇ tvercu. ˚ V grafu jsou hodnoty i pro dlouhý chvost, protože ilustrují zajímavé „schody“ v grafu. Jev porušuje mocninný zákon (power law) relativnˇe málo, protože „schody“ stále protínají regresní pˇrímku. Hodnoty s mírnou nepˇresností souhlasí od štítku s poˇradím cˇ íslo 32 (25 ). Mocninný zákon platí pro hodnoty 32 až 3497, což je drtivá vˇetšina. Prvních 32 (resp. 42) štítku˚ má neoˇcekávanˇe nízkou frekvenci z neprozkoumaných duvod ˚ u. ˚ Prumˇ ˚ erná odchylka spoˇcítaná pomocí metody nejmenších cˇ tvercu˚ pro všechny štítky je ±3, 16. Pokud uvážíme pouze štítky od poˇradí 32, sníží se odchylka na ±2, 75. Neuvažujeme-li navíc do výpoˇctu dlouhý chvost, je odchylka pouze ±1, 24. Výsledky nyní mužeme ˚ srovnat s odchylkami pro službu Delicious. V pˇrípadˇe nejfrekventovanˇejších zdroju˚ se byla spoˇcítána odchylka pouze ±0, 03 a u ménˇe 41
6. A NALÝZA DAT frekventovaných zdroju˚ je odchylka ±4, 63 [31]. Z uvedených cˇ ísel vyplývá, že distribuce štítku˚ v našich datech zatím nedosáhla stability, kterou pˇredstavuje odchylka ±0, 03, ale je relativnˇe konzistentní s teorií oˇcekávané distribuce.
6.3 Synonyma Ukážeme, jak synonyma pomáhají pˇri vyhledávání na konkrétních pˇríkladech. Dotazy prohledávají pole se štítky a jejich synonymy. Odpovˇedi jsou struktury ve formátu JSON obsahující všechny relevantní dokumenty, ale z úsporných duvod ˚ u˚ zde pouze struˇcnˇe popíšeme, o jaké dokumenty jde. Dotaz: protection V odpovˇedi se vyskytly dokumenty napˇríklad o zašifrování Apache serveru nebo o nastavení serveru EAP tak, aby fungovala captcha2 . Dokumenty bezpochyby souvisí s ochranou dat stejnˇe jako s bezpeˇcností. Jsou oznaˇceny štítkem security , synonymem k protection . Podobnˇe na našich datech pomáhají synonyma napˇríklad u tˇechto slov: development / evolution information / data example / instance / illustration
Dotaz: behaviour V tomto pˇrípadˇe není tak duležité ˚ téma dokumentu, ˚ ale hledaná synonyma. WordNet má uložená jako synonyma i slova, která se liší v psané podobˇe vlivem kulturního, geografického nebo jiného faktoru. Proto se v odpovˇedi objevily dokumenty se štítkem americky psaného slova behavior . Podobnˇe funguje dvojce colour a color , programming a programing a další. 2. technologie, která chrání webové stránky proti automatum ˚ pomocí generování testu, ˚ ve kterých dokáže uspˇet jen cˇ lovˇek [3]
42
6. A NALÝZA DAT Dotaz: talk Kromˇe dokumentu se štítkem speak a dalšími synonymy se hledají i dokumenty se štítkem talking . Vidíme, že WordNet obsahuje i synonymum v gerundiu, pokud má stejný význam a je to stále podstatné jméno. Další pˇríklady slov v našich datech na stejném principu: cluster / clustering model / modelling Synonyma se využívají v mnoha systémech s kvalitním vyhledáváním a jejich pomoc je zˇrejmá. Míra jejich pomoci vždy záleží na tom, jaká slova jsou ve slovníku synonym. WordNet obsahuje mnoho slov a významu, ˚ ale bohužel neobsahuje názvy produktu˚ a zkratky, které se v našich datech také objevovaly (viz. graf 6.1). V budoucnu by se mohlo uvažovat o rozšíˇrení WordNetu o tématická slova této komunity, která by ještˇe vylepšila vyhledávání pomocí synonym.
43
7 Závˇer První cˇ ást práce si klade za cíl informovat o zpusobu ˚ tˇrídˇení zdroju˚ pomocí kolaborativního štítkování. Odbornˇe ho popsal a pojmenoval pan Thomas Vander Wal jako folksonomie, souˇcást fenoménu Web 2.0. Dále je tento zpusob ˚ oznaˇcen jako kategorizace a uvádíme srovnání s formální klasifikací. Ve srovnání jsou uvedeny nevýhody kategorizace pomocí štítku, ˚ které jsou lexikálního charakteru a ty pozdˇeji rˇ ešíme v sekci o využití synonym. Zárovenˇ práce shrnuje poznatky z dosud napsaných prací, které se zabývají kolaborativním štítkováním. Poznatky jsou zejména o distribuci štítku˚ v systému. Dále je výsledkem práce funkˇcní rozšíˇrení systému Searchisko podporou uživatelských štítku. ˚ Kód je kompletnˇe v jazyce Java a jsou použity technologie využívané systémem Searchisko, jako je EJB, JPA, Hibernate a rozhraní REST. Použité technologie jsou popsány a uvedeny k nim odkazy na dokumentaci. Návrh je rozdˇelen na cˇ tyˇri cˇ ásti odpovídající tˇrídám v jazyce Java, kde každá z nich má svou úlohu. Objektová cˇ ást a DAO poskytují pˇrístup k databázi a definují CRUD operace se štítky. Vrstva REST API slouží k zabezpeˇcené komunikaci s uživatelem a poslední vrstva reaguje na události vyvolané dalšími službami v systému Searchisko. Systém jsme se rozhodli zárovenˇ obohatit o vyhledávání štítku˚ pomocí synonym, které pomohlo odstranit bˇežný problém, kdy zdroje ˇ oznaˇcují ruzné ˚ štítky se stejným významem. Rešení spoˇcívá v konfiguraci systému Elasticsearch a použití vhodného slovníku synonym. V kapitole 3.2.2 jsme podrobnˇe popsali konfiguraci a v kapitole 5 zduvodnili ˚ použití sémantické sítˇe WordNet jako slovníku synonym. Také je pˇredstaveno použití synonym k netradiˇcnímu doplnování ˇ slov, které našeptává nejen slova s daným prefixem, ale i synonyma k tˇemto slovum. ˚ Na závˇer jsme pˇredstavili data, která jsme získali z jednoho ze serveru˚ systému Searchisko. Ovˇerˇ ili jsme, že platí obecné zákony distribuce štítku˚ v systému a ukázali jeho cestu k tzv. stabilitˇe. Na konkrét45
ˇ 7. Z ÁV ER
ních pˇríkladech je demonstrována využitelnost WordNetu a použití synonym ve vyhledávání. Další užiteˇcné rozšíˇrení systému by mohlo být doplnˇení databáze slov WordNet o tématická slova a zkratky, které používají uživatelé systému Searchisko. Samozˇrejmˇe by se musely definovat i významy a vztahy slov, aby nadále fungovalo vyhledávání. Štítky jsou vˇetšinou v anglickém jazyce, protože i komunity píšící jiným jazykem oznaˇcují štítky anglickými výrazy. Pˇresto se nabízí rozšíˇrení pro další jazyky s použitím existujících WordNetu. ˚ Díky množství dobˇre propracovaných vazeb mezi slovy WordNetu se systém muže ˚ dále zdokonalit zvládnutím homonym, hyperonym (pˇríp. hyponym) a dalších lexikálních vztahu. ˚ Systém Searchisko je jeden z mnoha systému, ˚ které se snaží zapojit moderní prvky webu do výbˇeru svých služeb a kolaborativní štítkování je jedním z nich.
46
Bibliografie 1 APACHE SOFTWARE FOUNDATION. Elasticsearch [online]. [cit. 2014-03-23]. Dostupný z WWW: hhttps : / / www . elastic . co / products/elasticsearchi. 2 BUTTERFIELD, Stewart. Folksonomy: Social Classification. 2004. 3 Captcha. : Telling Humans and Computers Apart Automatically [online]. [cit. 2015-05-09]. Dostupný z WWW: hhttp://www.captcha. neti. 4 CRUD. : Wikipedia, poslední aktualizace 6.1.2015 [online]. [cit. 201504-28]. Dostupný z WWW: hhttp : / / cs . wikipedia . org / wiki / CRUDi. 5 CyberStack(sm). [online]. 1998 [cit. 2015-05-04]. Dostupný z WWW: hhttp : / / www . public . iastate . edu / ~CYBERSTACKS / homepage . htmli. 6 DELICIOUS SCIENCE, LLC. Delicious [online]. [cit. 2014-11-17]. Dostupný z WWW: hhttps://delicious.com/i. 7 DEVELOPMENT TEAM, jboss.org. Searchisko [online]. 2014 [cit. 201403-20]. Dostupný z WWW: hhttps://github.com/searchisko/ searchiskoi. 8 Dewey Decimal Classification. Encyclopædia Britannica. 2014. 9 ELIÁŠ, Vlastimil. Searchisko Basic Principles and Architecture [online]. [cit. 2014-03-23]. Dostupný z WWW: hhttps://github.com/ searchisko / searchisko / blob / master / documentation / basic _ principles_and_architecture.mdi. 10 FIELDING, Roy T.; TAYLOR, Richard N. Principled design of the modern web architecture. ACM Transactions on Internet Technology (TOIT). 2002, roˇc. 2, cˇ . 2, s. 115–150. 11 Folksonomie. : Wikipedia, poslední aktualizace 23.9.2013 [online]. [cit. 2015-04-23]. Dostupný z WWW: hhttp://cs.wikipedia.org/ wiki/Folksonomiei. 12 FRANKS, John et al. HTTP authentication: Basic and digest access authentication. 1999. Dostupný také z WWW: hhttp://www.hjp. at/doc/rfc/rfc2617.htmli. 47
BIBLIOGRAFIE 13 GOOGLE. Youtube.com [online]. [cit. 2014-11-17]. Dostupný z WWW: hhttps://www.youtube.com/i. 14 HUBERMAN, SGBA. The Structure of Collaborative Tagging Systems. 2005. 15 HURSTI, Jani. Single sign-on. In. Proc. Helsinki Uiniversity of Technology Seminar on Network Security. 1997. Dostupný také z WWW: hhttp://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_ sign-on.htmli. 16 JACOB, Elin K. Classification and categorization: A difference that makes a difference. Library Trends. 2004, roˇc. 52, s. 2004. 17 KOUTRIKA, Georgia et al. Combating Spam in Tagging Systems. In. Proceedings of the 3rd International Workshop on Adversarial Information Retrieval on the Web. Banff, Alberta, Canada: ACM, 2007, s. 57–64. AIRWeb ’07. Dostupný také z WWW: hhttp://doi. acm.org/10.1145/1244408.1244420i. ISBN 978-1-59593-732-2. 18 KUC, R.; ROGOZINSKI, M. ElasticSearch server. 2013. Community experience distilled. ISBN 9781849518444. 19 Library of Congress Classification. Encyclopædia Britannica. 2014. 20 LINDÉN, Krister; CARLSON, Lauri. FinnWordNet–Finnish WordNet by Translation. LexicoNordica–Nordic Journal of Lexicography. 2010, roˇc. 17, s. 119–140. 21 MARLOW, Cameron; MOR NAAMAN Marc Davis, Danah Boyd. Position Paper,Tagging,Taxonomy,Flickr,Article,ToRead. Collaborative Web Tagging Workshop at WWW’06. 2006. 22 MATHES, Adam. Folksonomies: Cooperative classification and communication through shared metadata [online]. 2014 [cit. 2015-0418]. Dostupný z WWW: hhttp://www.adammathes.com/academic/ computer-mediated-communication/folksonomies.htmli. 23 MICHAEL, Jakl. Representational State Transfer. Citeseer. 2008. Dostupný také z WWW: hhttp://citeseerx.ist.psu.edu/viewdoc/ download?doi=10.1.1.97.7334%5C&rep=rep1%5C&type=pdfi. 24 MILLER, G.A. et al. Introduction to wordnet: An on-line lexical database. International Journal of Lexicography. 1990, roˇc. 3, cˇ . 4, s. 235–244. ISSN 09503846. 48
BIBLIOGRAFIE 25 MILLER, George A. WordNet: A Lexical Database for English. Communications of the ACM. 1995, roˇc. 38, cˇ . 11, s. 39–41. 26 MUNDIE, David A. Cyber Dewey: A Catalogue for the World Wide Web [online]. Pittsburgh: Polymath Systems, 1995 [cit. 2015-0504]. Dostupný z WWW: hhttp://library.tedankara.k12.tr/ dewey/i. 27 O’REILLY, Tim. Web 2.0 Compact Definition: Trying Again [online]. [cit. 2015-04-23]. Dostupný z WWW: hhttp : / / radar . oreilly . com/2006/12/web-20-compact-definition-tryi.htmli. 28 PETERS, Isabella; BECKER, Paul. Folksonomies : Indexing and Retrieval in Web 2.0. 2009. Knowledge & Information: Studies in Information Science. ISBN 9783598251795. 29 PRINCETON UNIVERSITY, The Trustees of. WordNet : A lexical database for English [online]. [cit. 2015-05-07]. Dostupný z WWW: hhttps://wordnet.princeton.edui. 30 RED HAT, Inc. JBoss Developer [online]. [cit. 2014-11-25]. Dostupný z WWW: hhttps://www.jboss.org/i. 31 SHEPHERD, Hana. The Complex Dynamics of Collaborative Tagging: Proceedings of the 16th International Conference on the World Wide Web (WWW’07). ACM Press. 2007, s. 211–220. 32 UWEASSMANN, Prof. Dr. Enterprise Java Beans [online]. 2010 [cit. 2015-03-27]. Dostupný z WWW: hhttp://st.inf.tu- dresden. de/files/teaching/ss10/cbse/05-ejb.pdfi. 33 VAISHAR, Antonín. Folksonomie: Bakaláˇrská práce. Brno: Ústav cˇ eské literatury a knihovnictví, FF MUNI, 2007. 72 s. 34 VIZINE-GOETZ, Diane. Using library classification schemes for internet resources. 1999. 35 VLASTIMIL ELIÁŠ, Lukáš Vlˇcek a. Searchisko [online]. [Cit. 201403-24]. Dostupný z WWW: hhttp://devconf.cz/filebrowser/ download/372i. 36 WAL, Thomas Vander. Folksonomy: vanderwal.net [online]. [cit. 201504-23]. Dostupný z WWW: hhttp://vanderwal.net/folksonomy. htmli.
49
BIBLIOGRAFIE 37 WAL, Thomas Vander. Folksonomy [online]. London, UK: prezentováno na: Online Information 2005, [cit. 2015-05-04]. Dostupný z WWW: hhttp://vanderwal.net/essays/051130/folksonomy. pdfi. 38 WordNet. : Description of Prolog database files [online]. [cit. 201505-08]. Dostupný z WWW: hhttps://wordnet.princeton.edu/ wordnet/man/prologdb.5WN.htmli. 39 YAHOO!, Inc. c/o. Flickr.com [online]. [cit. 2014-11-17]. Dostupný z WWW: hhttps://secure.flickr.com/i.
50
A Pˇríloha Pˇríloha této práce obsahuje kompletní zdrojové kódy systému Searchisko spoleˇcnˇe s implementovanou službou spravující uživatelské štítky. Následuje hrubá adresáˇrová struktura odevzdaných souboru, ˚ popis pˇridaných a upravených souboru˚ v adresáˇri searchisko, které pˇredstavují implementaˇcní cˇ ást této práce a návod na spuštˇení systému Searchisko.
A.1 Adresáˇrová struktura / zmeny.txt wordnet wn_s.pl license.txt searchisko apiary.apib configuration index_templates/data_defaults.json data/config/search_fulltext_query_fields.json documentation ftest api src/main/java/org/searchisko/api/rest src/main/java/org/searchisko/api/service src/main/java/org/searchisko/persistence src/test Soubor zmeny.txt obsahuje všechny zmˇeny souboru, ˚ které souvisí s touto prací (viz. A.2). Adresáˇr wordnet obsahuje sémantickou sít’ slov WordNet spoleˇcnˇe s jeho licencí. Dále je souˇcástí celý systém Searchisko, který má hlavní dokumentaci v adresáˇri documentation a popis REST API v souboru apiary.apib. Konfigurace systému Elasticsearch je v adresáˇri configuration. Integraˇcní testy nalezneme v adresáˇri ftest a jednotkové testy v adresáˇri api/src/test. Adresáˇr api obsahuje veškerý funkˇcní kód. 51
ˇ A. P RÍLOHA
A.2 Implementaˇcní zmˇeny Vytvoˇrené soubory: V adresáˇri /api/src/main/java/org/searchisko/ : persistence/jpa/model/Tag.java persistence/service/CustomTagPersistenceService.java persistence/service/JpaCustomTagPersistenceService.java api/rest/CustomTagRestService.java api/service/CustomTagService.java V adresáˇri /api/src/test/java/org/searchisko/ : api/service/CustomTagServiceTest.java api/rest/CustomTagRestServiceTest.java persistence/service/JpaCustomTagPersistenceServiceTest.java
configuration/data/query/suggest_tags_synonyms_prefix.json Upravené soubory: /apiary.apib Pˇridána dokumentace aplikaˇcního rozhraní REST pro uživatelské štítky.
/api/src/main/java/org/searchisko/api/security/Role.java Byla pˇridána role pro práci se štítky: Role.TAGS_MANAGER. /documentation/rest-api/README.md Pˇridány informace o rolích pro správu štítku. ˚ /api/src/test/resources/META-INF/persistence.xml Pˇridána tabulka Tag pro funkci jednotkových testu. ˚ /configuration/data/config/search_fulltext_query_fields.json Pˇridáno pole sys_tags.synonyms, aby se v nˇem vyhledávalo. /configuration/index_templates/init_templates.sh Pˇridán mapping, analyzér a filtr pro konfiguraci synonym. 52
ˇ A. P RÍLOHA
A.3 Návod ke spuštˇení systému Searchisko Návod na spuštˇení systému Searchisko je dobˇre popsán jeho vývojáˇri na stránce https://github.com/searchisko/searchisko/blob/ master/documentation/development.md. Také ho lze najít v souboru /searchisko/documentation/development.md . Pro správnou funkci služby podporující synonyma je zapotˇrebí adresáˇr wordnet správnˇe umístit do konfigurace vašeho EAP serveru, konkrétnˇe do adresáˇre bin/config.
53
