Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Bakal´ aˇ rsk´ a pr´ ace S´ emantick´ y web v EEG/ERP dom´ enˇ e

Plzeˇ n 2013

Jan Smitka

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem bakaláˇrskou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 3. kvˇetna 2013 Jan Smitka

Podˇ ekov´ an´ı Rád bych touto cestou podˇekoval Ing. Romanu Mouˇckovi, Ph.D. za odborné veden´ı práce a podnˇetné pˇripom´ınky. Dále bych chtˇel podˇekovat Ing. Vladiˇ etinové za pomoc pˇri korektuˇre textu. m´ırovi Smitkovi a Mgr. Barboˇre Stˇ

Abstract Semantic web in the EEG/ERP domain This thesis is focused on the Semantic Web technologies and storage of semantic data and metadata from neuroscience research. The thesis provides an overview of current semantic repositories. The main goal is to implement and deploy a solution for semantic annotation and search of neuroscience publications and discussions on social networks. To accomplish the task, two utilities and a vocabulary of neuroscience research terms had to be created. The first utility, KIMBridge, is used to download publications from document repository, and discussion posts from social networks. The second utility, KIM-OWLImport, is a graphical tool that adjusts vocabularies in Web Ontology Language for semantic annotation. The created vocabulary contains common event-related potentials and signal processing methods.

Obsah ´ 1 Uvod

1

2 Technologie s´ emantick´ eho webu 2.1 Resource Description Framework . . . 2.2 RDF Vocabulary Description Language 2.3 Ontologie a Web Ontology Language . 2.4 Sémantické repositáˇre . . . . . . . . . . 2.5 Jazyk SPARQL . . . . . . . . . . . . . 3 Pˇ rehled s´ emantick´ ych reposit´ aˇ r˚ u 3.1 4store . . . . . . . . . . . . . . . 3.1.1 Pˇr´ıpady pouˇzit´ı . . . . . . 3.2 Jena . . . . . . . . . . . . . . . . 3.3 Sesame . . . . . . . . . . . . . . . 3.4 OWLIM a KIM Platform . . . . . 3.4.1 Edice . . . . . . . . . . . . 3.4.2 KIM Platform . . . . . . . 3.4.3 Pˇr´ıpady pouˇzit´ı . . . . . . 3.5 BigData . . . . . . . . . . . . . . 3.6 Virtuoso . . . . . . . . . . . . . . 3.6.1 Edice . . . . . . . . . . . . 3.6.2 Pˇr´ıpady pouˇzit´ı . . . . . . 3.7 Shrnut´ı . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 . 5 . 8 . 10 . 12 . 12

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

15 16 17 17 17 18 19 19 20 21 21 21 22 22

4 KIM Platform 4.1 Znalostn´ı báze . . . . . . . . . . . . . . . 4.2 Formát dokument˚ u . . . . . . . . . . . . 4.3 Ukládán´ı a indexován´ı dokument˚ u. . . . 4.3.1 Apache Lucene . . . . . . . . . . 4.3.2 Semantic Annotation Repository 4.3.3 MÍMIR . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

23 23 23 24 24 24 24

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

4.4

4.5 4.6

Doplnˇen´ı znalostn´ı báze a vytvoˇren´ı ontologie 4.4.1 Ontologie . . . . . . . . . . . . . . . . 4.4.2 Zaveden´ı ontologie . . . . . . . . . . . Import dokument˚ u . . . . . . . . . . . . . . . Vyhledáván´ı . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 Souˇ casn´ e ontologie EEG/ERP dom´ eny

25 25 28 29 29 30

6 Specifikace poˇ zadavk˚ u a pˇ rehled ˇ reˇ sen´ı 31 6.1 Poˇzadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2 Pˇrehled ˇreˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7 Instalace KIM Platform, prototypov´ a ontologie 33 7.1 Instalace a konfigurace KIM Platform . . . . . . . . . . . . . . 33 7.2 Doménová ontologie . . . . . . . . . . . . . . . . . . . . . . . 34 8 KIMBridge 8.1 Anal´ yza . . . . . . . . . . . . . 8.1.1 Google Drive API . . . . 8.1.2 LinkedIn API . . . . . . 8.2 Popis implementace . . . . . . . 8.2.1 Google Drive . . . . . . 8.2.2 LinkedIn . . . . . . . . . 8.2.3 Sluˇzba KIMBridge . . . 8.3 Formát konfiguraˇcn´ıho souboru 9 KIM-OWLImport 9.1 Anal´ yza . . . . . . . . 9.1.1 SeRQL dotazy . 9.1.2 Uloˇzen´ı v´ ystupu 9.2 Popis implementace . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

. . . . . . . .

35 35 35 36 37 40 40 41 42

. . . .

45 45 46 47 48

10 V´ ysledky 53 10.1 Sémantická anotace . . . . . . . . . . . . . . . . . . . . . . . . 53 10.2 Vyhledáván´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 11 Z´ avˇ er

56

A Ontologie EEG/ERP komponent

63

B Ontologie metod zpracov´ an´ı sign´ alu

64

C UML diagram tˇ r´ıd v projektu KIMBridge

65

D UML diagram tˇ r´ıd v projektu KIM-OWLImport

66

E Uˇ zivatelsk´ a dokumentace k KIM-OWLImport

67

F Uˇ zivatelsk´ a pˇ r´ıruˇ cka k vyhled´ av´ an´ı F.1 Structure search . . . . . . . . . . . . . . . . . . . . . . . . . F.1.1 Vyhledán´ı dokument˚ u t´ ykaj´ıc´ıch se vybran´ ych komponent . . . . . . . . . . . . . . . . . . . . . . . . . . . F.1.2 Vyhledán´ı metod zpracován´ı signálu podle zadan´ ych podm´ınek . . . . . . . . . . . . . . . . . . . . . . . . F.2 Faceted search . . . . . . . . . . . . . . . . . . . . . . . . . .

70 . 71 . 71 . 72 . 74

G Instalace sluˇ zby KIMBridge 76 G.1 Spuˇstˇen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 G.1.1 Konzolová aplikace . . . . . . . . . . . . . . . . . . . . 76 G.1.2 Linuxová sluˇzba . . . . . . . . . . . . . . . . . . . . . . 76

´ 1 Uvod Na katedˇre informatiky a v´ ypoˇcetn´ı techniky Západoˇceské univerzity v Plzni p˚ usob´ı neuroinformatická v´ yzkumná skupina, která je zapojená do organizace International Neuroinformatics Coordinating Facility1 (INCF). Bˇehem neuroinformatick´ ych v´ yzkum˚ u vzniká mnoˇzstv´ı dat a s nimi souvisej´ıc´ıch metadat. Jedná se zejména o popis a v´ ysledky elektrofyziologick´ ych experiment˚ u. Tato data a metadata je nutné uchovávat a sd´ılet mezi jednotliv´ ymi v´ yzkumn´ ymi skupinami. Data a metadata o realizovan´ ych experimentech jsou ukládána do EE2 G/ERP portálu. Z nˇej je moˇzné tato data publikovat ve formátech sémantického webu. D´ıky pouˇzit´ı otevˇreného standardu pro v´ ymˇenu dat a integraci portálu do Neuroscience Information Framework3 (NIF) jsou pak tato data dostupná i pro dalˇs´ı v´ yzkumné skupiny. Kromˇe samotn´ ych dat z experiment˚ u existuje celá ˇrada dalˇs´ıch zdroj˚ u, ze kter´ ych je moˇzné ˇcerpat informace. Jedná se pˇredevˇs´ım o odborné publikace a ˇclánky t´ ykaj´ıc´ı se elektrofyziologick´ ych experiment˚ u. Dalˇs´ım ˇcasto vyuˇz´ıvan´ ym zdrojem jsou odborné diskuze v rámci vybran´ ych skupin na sociáln´ıch s´ıt´ıch. Vyhledáván´ı v tˇechto zdroj´ıch vˇsak nen´ı jednoduché, nebot’ jednotliv´ı autoˇri pouˇz´ıvaj´ı r˚ uzné terminologie a jednotlivá fakta oznaˇcuj´ı r˚ uzn´ ymi kl´ıˇ ˇcov´ ymi slovy. Casto se tak stává, ˇze pˇri vyhledáván´ı je nutné nˇekolikrát pˇreformulovat vyhledávac´ı dotaz pro r˚ uzná kl´ıˇcová slova, neˇz jsou poˇzadované informace nalezeny. C´ılem této práce je nalézt vhodné ˇreˇsen´ı pro agregaci a uloˇzen´ı tˇechto dat, které usnadn´ı následné vyhledáván´ı relevantn´ıch informac´ı. Snahou je vyuˇz´ıt jiˇz existuj´ıc´ı popis dat a znalost´ı z domény ve formátech sémantického webu. Práce je rozdˇelena do nˇekolika kapitol. Následuj´ıc´ı kapitola popisuje principy sémantického webu, standardizované technologie a jejich vzájemné souvislosti. 3. kapitola pak srovnává repositáˇre vhodné pro ukládán´ı sémantick´ ych dat, které umoˇzn ˇuj´ı fulltextové vyhledáván´ı. 4. kapitola popisuje základn´ı vlastnosti vybraného repositáˇre, moˇznosti definice znalost´ı o kl´ıˇcov´ ych term´ınech a nahráván´ı dokument˚ u. 5. kapitola analyzuje ontologie, které má v souˇcasnosti v´ yzkumná skupina k dispozici a které by mohly b´ yt potenciálnˇe pouˇzity pro popis znalost´ı. 6. kapitola specifikuje poˇzadavky v´ yzkumné skupiny a poskytuje celkov´ y pˇrehled realizovaného ˇreˇsen´ı. 7. kapitola se zab´ yvá instalac´ı a konfigurac´ı 1

http://www.incf.org/ http://eegdatabase.kiv.zcu.cz/ 3 http://www.neuinfo.org/ 2

1

´ Uvod platformy pro sémantické anotován´ı a prototypovou ontologi´ı, která byla vytvoˇrena pro ovˇeˇren´ı funkˇcnosti realizovaného ˇreˇsen´ı. Kapitoly 8 a 9 popisuj´ı nástroje, které byly vytvoˇreny pro usnadnˇen´ı tvorby ontologie a pro import dokument˚ u ze vzdálen´ ych u ´loˇziˇst’. 10. kapitola prezentuje v´ ysledky sémantického anotován´ı a vybraného vyhledávac´ıho scénáˇre. Posledn´ı kapitola shrnuje celou práci a nastiˇ nuje dalˇs´ı v´ yvoj realizovaného ˇreˇsen´ı.

2

2 Technologie sémantického webu Souˇcasn´ y web obsahuje velké mnoˇzstv´ı dat a informac´ı. Celá s´ıt’ je decentralizovaná a jednotlivé informace jsou uloˇzeny v podobˇe textov´ ych dokument˚ u, které jsou pˇr´ıpadnˇe obohaceny o multimediáln´ı podobu informac´ı. Tyto dokumenty jsou dostupné prostˇrednictv´ım ˇretˇezce Uniform Resource Identifier (URI), kter´ y je jedineˇcnˇe identifikuje dan´ y dokument. Tyto dokumenty jsou sice strukturované, ale jejich struktura nepˇridává k jejich textové podobˇe ˇza´dnou dodateˇcnou informaci pro strojové zpracován´ı. V´ yznam jednotliv´ ych slov a názv˚ u v dokumentu tak lze odvodit jen pomoc´ı metod pˇrirozeného zpracován´ı jazyka (NLP). To vˇsak ˇcin´ı velké problémy pˇri vyhledáván´ı ve velkém mnoˇzstv´ı dokument˚ u. Bez doplˇ nuj´ıc´ıch informac´ı o v´ yznamu slov nen´ı v nˇekter´ ych pˇr´ıpadech moˇzné z´ıskat relevantn´ı v´ ysledky pro zadan´ y dotaz, zvláˇstˇe pak pokud mohou m´ıt kl´ıˇcová slova v´ıce v´ yznam˚ u. [15] uvád´ı jako jeden z takov´ ych pˇr´ıpad˚ u slovo Marja“. To m˚ uˇze znamenat jak kˇrestn´ı jméno osoby, tak finské slovo ” oznaˇcuj´ıc´ı bobule“. ” Tento problém se snaˇz´ı ˇreˇsit sémantick´ y web. Jeho c´ılem je poskytnout technologie a standardy, které umoˇzn´ı strojové zpracován´ı a porozumˇen´ı vˇetˇs´ımu mnoˇzstv´ı dat dostupn´ ych na internetu. V´ ysledkem budou nejen pˇresnˇejˇs´ı v´ ysledky vyhledáván´ı, ale i usnadnˇen´ı v´ ymˇeny dat, integrace jednotliv´ ych sluˇzeb a automatizace z´ıskáván´ı dat. Sémantick´ y web umoˇzn ˇuje k jednotliv´ ym zdroj˚ um na internetu pˇripojit dalˇs´ı doplˇ nuj´ıc´ı informace – metadata. Je zaloˇzen na následuj´ıc´ıch 6 principech [15]: 1. Vˇ se m˚ uˇ ze b´ yt identifikov´ ano pomoc´ı URI. Kromˇe stránek maj´ı sv˚ uj jedineˇcn´ y identifikátor i jednotlivé osoby, m´ısta, události, vˇeci a dalˇs´ı objekty. D´ıky tomu se lze na kaˇzd´ y objekt odkudkoliv odkazovat. 2. Jednotliv´ e zdroje i odkazy mezi nimi mohou m´ıt definovan´ y typ. Souˇcasn´ y web je zmˇet´ı jednotliv´ ych stránek a odkaz˚ u mezi nimi. U odkaz˚ u vˇsak nen´ı pˇripojena ˇzádná informace o tom, jak´ y je vztah mezi odkazovan´ ymi stránkami. Doplnˇen´ım typu k tˇemto odkaz˚ um je moˇzné tyto vztahy pˇresnˇe popsat. 3. Ne´ upln´ e informace jsou tolerovan´ e. U souˇcasného webu m˚ uˇze jakákoliv stránka odkazovat na jakoukoliv jinou bez toho, aby se jej´ı autor musel starat o platnost tohoto odkazu. 3

Technologie sémantického webu

Pokud stránka bude pˇresunuta nebo pˇrestane existovat, zobraz´ı se uˇzivateli chyba 404. Tato vlastnost mus´ı b´ yt zachována i u sémantického webu – nedostupnost ˇca´sti informace o objektu nesm´ı znemoˇznit vyuˇzit´ı zbytku informace. 4. Absolutn´ı pravda nen´ı nutn´ a. Ne vˇsechny informace na webu jsou pravdivé a sémantick´ y web toto mus´ı zohledˇ novat. Kaˇzdá aplikace bude pravdivost a d˚ uvˇeryhodnost tvrzen´ı vyhodnocovat na základˇe jeho kontextu, tedy podle toho, kde a kdy bylo tvrzen´ı uvedeno, kdo je jeho autorem a jaké mˇel k tvrzen´ı povˇeˇren´ı. 5. Podpora v´ yvoje. Podobné koncepty jsou ˇcasto vyv´ıjeny r˚ uzn´ ymi lidmi ˇci skupinami. Sémantick´ y web mus´ı umoˇznit navázat na práci nˇekoho jiného tak, aby bylo moˇzné daná data zkombinovat a nevznikaly nejasnosti pˇri jejich interpretaci. 6. Minimalistick´ y n´ avrh. C´ılem je nestandardizovat v´ıce, neˇz je nezbytnˇe nutné. Navrˇzené technologické standardy jsou rozdˇelené do nˇekolika vrstev. Tyto vrstvy jsou znázornˇeny na obrázku 2.1.

Obrázek 2.1: Vrstvy sémantického webu. Dvˇe nejniˇzˇs´ı vrstvy, tedy Unicode“ a URI“, zajiˇst’uj´ı pouˇzit´ı mezinárodn´ı ” ” znakové sady a odkazován´ı na jednotlivé zdroje pomoc´ı jedineˇcn´ ych identifikátor˚ u. Vrstva XML, XML Namespaces, XML Schema“ definuje XML ” standardy a zajiˇst’uje, aby bylo moˇzné technologie sémantického webu integrovat s dalˇs´ımi technologiemi, které vycházej´ı z XML. Pro souˇcasn´ y sémantick´ y web maj´ı nejvˇetˇs´ı v´ yznam vrstvy RDF1 , RDF ” Schema“ a Ontology Vocabulary“. Vrstva RDF, RDF Schema“ umoˇzn ˇuje ” ” 1

Resource Description Framework

4



definovat datov´ y model a popsat fakta o jednotliv´ ych objektech. Právˇe v této vrstvˇe je moˇzné jednotliv´ ym zdroj˚ um a odkaz˚ um pˇriˇradit typ. Vrstva Onto” logy Vocabulary“ pak podporuje spojován´ı jednotliv´ ych model˚ u a vytváˇren´ı sloˇzitˇejˇs´ıch struktur – ontologi´ı. Vyˇsˇs´ı vrstvy, tedy Logic“, Proof“ a Trust“ nejsou v souˇcasnosti stan” ” ” dardizovány. Vrstva Digital Signatures“ pak zajiˇst’uje integritu dokumentu a ovˇeˇren´ı ” autenticity a d˚ uvˇeryhodnosti zdroje a jej´ıho autora. Tato vrstva je definována ve standardu [13]. Kromˇe tˇechto vrstev existuje jeˇstˇe nˇekolik dalˇs´ıch standard˚ u, které se zamˇeˇruj´ı na obohacen´ı souˇcasn´ ych HTML stránek o sémantické informace. Jedn´ım z nich je standard Microdata [11]. Umoˇzn ˇuje do stránky pˇridat sémantickou informaci o osobách, organizac´ıch, událostech, produktech, multimediáln´ıch souborech a nˇekolika dalˇs´ıch typech objekt˚ u. Schéma definic tˇechto objekt˚ u je dostupné na webu schema.org. 2 Na rozd´ıl od uveden´ ych technologi´ı se vˇsak jedná o nadstavbu nad souˇcasn´ ym standardem HTML5. Jeho c´ılem je pouze poskytnout vyhledávaˇc˚ um doplˇ nuj´ıc´ı informace. Neposkytuje takové moˇznosti jako technologie, které jsou obecnˇe oznaˇcované jako sémantick´ y web“. Data je vˇsak moˇzné trans” formovat do nˇekterého z formát˚ u, které podporuje RDF. [12]

2.1


´ Uvod do RDF [21] uvád´ı, ˇze RDF je jazyk pro reprezentaci informac´ı o zdro” j´ıch dostupn´ ych v s´ıti World Wide Web. Je urˇcen zejména k popisu metadat zdroj˚ u na webu, jak´ ymi jsou název, autor, datum modifikace webové stránky a informace o copyrightu a licencován´ı daného dokumentu. Zobecnˇen´ım konceptu zdroje vˇsak m˚ uˇze b´ yt pouˇzit i pro popis objekt˚ u, které mohou b´ yt na webu identifikovány i pˇres to, ˇze nejsou pˇr´ımo dostupné. Jako pˇr´ıklad je moˇzné uvést produkty dostupné z webového obchodu (napˇr. informace o specifikaci, cenˇe a dostupnosti), nebo popis preferenc´ı uˇzivatele pro doruˇcován´ı informac´ı.“ Jak jiˇz bylo dˇr´ıve zm´ınˇeno, RDF pouˇz´ıvá myˇslenku, ˇze na vˇsechny objekty je moˇzné se odkazovat pomoc´ı jejich URI. Vzniká tak graf, kter´ y reprezentuje jednotlivé objekty, jejich vlastnosti a vztahy s jin´ ymi objekty. Pˇr´ıklad takového grafu uvád´ı [21]. Jeho upravená varianta je znázornˇena na obrázku 2.2. Graf znázorˇ nuje popis osoby jménem Eric Miller. M˚ uˇzeme jej popsat 2

http://schema.org/docs/documents.html

5



Obrázek 2.2: Graf popisuj´ıc´ı osobu jménem Eric Miller. vˇetou Zdroj s URI http://www.w3.org/People/EM/contact#me je typu ” Osoba, jej´ıˇz celé jméno je Eric Miller, má e-mailovou adresu [email protected] a má titul Dr.“ Tu samou informaci m˚ uˇzeme vyjádˇrit také pomoc´ı jednotliv´ ych d´ılˇc´ıch tvrzen´ı: http://www.w3.org/People/EM/contact#me http://www.w3.org/People/EM/contact#me tou je Eric Miller“. ” http://www.w3.org/People/EM/contact#me hodnota je [email protected]. http://www.w3.org/People/EM/contact#me Dr.“ ”

je typu osoba. má celé jméno, jehoˇz hodnomá e-mailovou adresu, jej´ıˇz má titul, jehoˇz hodnotou je

Tato tvrzen´ı jsou v podstatˇe trojicemi (triplety) subjekt – predikát – objekt. Pomoc´ı tˇechto triplet˚ u lze reprezentovat informace obsaˇzené v libovolném grafu. Subjekt vˇzdy reprezentuje zdroj, kter´ y nab´ yvá urˇcité vlastnosti (predikát) s urˇcenou hodnotou (objekt). Objektem m˚ uˇze b´ yt bud’ pˇr´ımo textová hodnota (napˇr. Eric Miller“), nebo jin´ y objekt identifikovan´ y pomoc´ı URI ” ([email protected]). Triplety jsou základn´ım konceptem RDF. Uveden´ y pˇr´ıklad je zapsan´ y v pˇrirozeném jazyce. Pˇri strojovém zpracován´ı to vˇsak m˚ uˇze ˇcinit pot´ıˇze. Proto je moˇzné pomoc´ı URI identifikovat nejen jednotlivé zdroje (subjekty), ale i vlastnosti mezi nimi. Vztahy i hodnoty v grafu na obrázku 2.2 je tedy nutné identifikovat pomoc´ı jejich URI. 6



Dostáváme graf na obrázku 2.3.

Obrázek 2.3: Graf popisuj´ıc´ı osobu Eric Miller s vlastnostmi reprezentovan´ ymi pomoc´ı URI. Kromˇe vlastnost´ı, které je moˇzné definovat v konkrétn´ıch aplikac´ıch, lze vyuˇz´ıt i nˇekteré vlastnosti, které definuje standard RDF. Ty jsou definovány ve jmenném prostoru http://www.w3.org/1999/02/22-rdf-syntax-ns#, typicky oznaˇcovaném zkrácen´ ym prefixem rdf:. Mezi nejd˚ uleˇzitˇejˇs´ı vestavˇené vlastnosti patˇr´ı rdf:type, která byla pouˇzita v grafu na obrázku 3. Tato vlastnost slouˇz´ı k urˇcen´ı typu daného objektu. D´ıky n´ı je tedy moˇzné jednotlivé zdroje typovat. Specifikace RDF také definuje syntaxi RDF/XML [1], pomoc´ı které je moˇzné v´ yˇse uveden´ y graf zapsat v jazyce, jenˇz je podmnoˇzinou XML. Pˇr´ıklad v´ yˇse uvedeného grafu je uveden´ y ve v´ ypise 2.1. Eric Miller Dr.

V´ ypis 2.1: RDF/XML popis osoby Eric Miller 7


RDF Vocabulary Description Language

Pro uloˇzen´ı RDF triplet˚ u je moˇzné pouˇz´ıt jeˇstˇe dalˇs´ı formáty. Mezi bˇeˇznˇe podporované patˇr´ı: N-Triples [2], Turtle, Terse RDF Triple Language [3] a Notation3 (N3) [5].

Tyto formáty se zamˇeˇruj´ı na zápis samotn´ ych triplet˚ u a neumoˇzn ˇuj´ı zápis ve strukturovaném XML. Oproti RDF/XML jsou vˇsak struˇcnˇejˇs´ı.

2.2


Prostˇrednictv´ım RDF m˚ uˇzeme definovat jednotlivé zdroje a jejich vlastnosti v podobˇe trojic. RDF Vocabulary Description Language, nebo také RDF Schema, zkrácenˇe RDFS, pˇridává typov´ y systém. S jeho pomoc´ı je moˇzné definovat tˇr´ıdy podobnˇe jako v objektovˇe orientovan´ ych programovac´ıch jazyc´ıch. D´ıky tomu lze spojit vlastnosti, u kter´ ych se oˇcekává, ˇze budou pouˇzity souˇcasnˇe. Pˇr´ıtomnost vlastnosti vˇsak nem˚ uˇze b´ yt vynucena. [21] Kaˇzd´ y definovan´ y zdroj je pak instanc´ı jedné nebo v´ıce tˇr´ıd. Jednotlivé tˇr´ıdy je také moˇzné sdruˇzovat do hierarchi´ı podobn´ ym zp˚ usobem jako v objektovˇe orientovan´ ych jazyc´ıch. Podobnˇe jako zdroj m˚ uˇze b´ yt instanc´ı jedné nebo v´ıce tˇr´ıd, m˚ uˇze i tˇr´ıda b´ yt potomkem jedné nebo v´ıce tˇr´ıd. Definic´ı tˇr´ıd a jejich hierarchie pak vzniká slovn´ık“, kter´ y lze v aplikaci ” pouˇz´ıvat. V´ yhodou RDFS je, ˇze prostˇredky, které jsou pouˇzity pro popis jednotliv´ ych tˇr´ıd, jsou také slovn´ıkem, jenˇz je popsán mnoˇzinou trojic. D´ıky tomu je tak moˇzné provádˇet dotazy nejen nad instancemi, které jsou definované, ale i nad samotn´ ymi definicemi tˇr´ıd. Jednotlivé triplety popisuj´ıc´ı tento slovn´ık jsou definovány ve jmenném prostoru http://www.w3.org/2000/01/ rdf-schema# (dále oznaˇcovan´ y prefixem rdfs:). Pro vyjádˇren´ı pˇr´ısluˇsnosti instance k tˇr´ıdˇe se vyuˇz´ıvá vlastnosti rdf:type. Jednotlivé definice tˇr´ıd jsou pak instanc´ı rdfs:Class. Pro vyjádˇren´ı dˇediˇcnosti mezi dvˇema tˇr´ıdami se pouˇz´ıvá vlastnosti rdfs:subClassOf. Jednotlivé vlastnosti je moˇzné definovat ve tˇr´ıdˇe jako instance tˇr´ıdy rdfs:Property. Pro vyjádˇren´ı pˇr´ısluˇsnosti vlastnosti k dané tˇr´ıdˇe lze potom vyuˇz´ıt vlastnost rdfs:domain, obor hodnot pomoc´ı vlastnosti rdfs:range. Jako obor hodnot je moˇzné pouˇz´ıt bud’ URI tˇr´ıdy, nebo datové typy z XML Schema Definition Language (XSD). Dalˇs´ı tˇr´ıdy a vlastnosti, které definuje RDFS, lze nalézt v [9]. V pˇredchoz´ım pˇr´ıkladu by bylo moˇzné definovat tˇr´ıdu Osoba, která by definovala vlastnosti celé jméno, titul a e-mailová adresa. D´ıky tomu by byl zajiˇstˇen jednotn´ y popis i dalˇs´ıch osob, které budou definovány. 8



Pˇr´ıklad definice této tˇr´ıdy v RDF/XML je uveden ve v´ ypise 2.2. ]>

V´ ypis 2.2: Definice tˇr´ıdy osoba. Pokud bychom chtˇeli definovat napˇr´ıklad tˇr´ıdy Vˇedec a Filosof jako tˇr´ıdy podˇr´ızené tˇr´ıdˇe Osoba, mus´ıme pouˇz´ıt vlastnost rdfs:subClassOf, jak je vidˇet na v´ ypise 2.3.

9


Ontologie a Web Ontology Language

V´ ypis 2.3: Pouˇzit´ı rdfs:subClassOf.

2.3


[30] definuje ontologie3 jako soubor koncept˚ u a vztah˚ u (oznaˇcovan´ ych jako ” termy), které popisuj´ı a reprezentuj´ı urˇcitou oblast zájmu (doménu). Ontologie se pouˇz´ıvaj´ı pro klasifikaci term˚ u, které mohou b´ yt pouˇzity v dané aplikaci, charakteristiku moˇzn´ ych vztah˚ u a definici omezen´ı pro pˇr´ısluˇsné termy“. Ontologie je moˇzné pouˇz´ıt jako formát pro v´ ymˇenu dat ˇci pro uchován´ı a organizaci znalost´ı. Pro popis ontologi´ı slouˇz´ı Web Ontology Language, zkrácenˇe OWL. Jedná se o v´ ypoˇcetnˇe-logick´ y jazyk, kter´ y umoˇzn ˇuje strojové ovˇeˇren´ı jiˇz definovan´ ych znalost´ı, nebo odvozen´ı poznatk˚ u, které ze znalost´ı implicitnˇe vypl´ yvaj´ı. [16] Vycház´ı ze standard˚ u RDF a RDFS a pˇridává vlastnosti, d´ıky kter´ ym je moˇzné popsat sloˇzitˇejˇs´ı definice a vztahy. Ontologie v jazyce OWL je tedy grafem v RDF. V souˇcasné dobˇe jsou k dispozici dvˇe verze: OWL 1 a OWL 2. Druhá verze je plnˇe zpˇetnˇe kompatibiln´ı – vˇsechny OWL 1 ontologie jsou platn´ ymi OWL 2 ontologiemi. [32] Obˇe verze také pouˇz´ıvaj´ı stejné formáty pro uchován´ı dat. OWL 2 pˇridává nové funkce, rozˇsiˇruje napˇr´ıklad datové typy, pˇridává podporu pro asymetrické, tranzitivn´ı a vzájemnˇe vyluˇcuj´ıc´ı se vlastnosti a definuje nové profily pro odvozován´ı znalost´ı. Dalˇs´ı text se bude zab´ yvat novˇejˇs´ı verz´ı OWL 2. Dokumenty v OWL je moˇzné uloˇzit v nˇekolika moˇzn´ ych syntax´ıch. Tabulka 2.1 poskytuje pˇrehled základn´ıch syntax´ı, které jsou popsány v [16]. Ontologie se v jazyce OWL skládá z následuj´ıc´ıch ˇca´st´ı: [16] Axiomy: základn´ı tvrzen´ı, která jsou v ontologii vyjádˇrena. Takov´ ym tvrzen´ım m˚ uˇze b´ yt napˇr´ıklad vˇeta vˇsichni lidé jsou smrteln´ı“. ” Entity: prvky, které reprezentuj´ı objekty a vztahy z reálného svˇeta. Entity jsou pak souˇca´st´ı jednotliv´ ych tvrzen´ı v ontologii. Pokud budeme uvaˇzovat 3

W3C pouˇz´ıv´ a anglické v´ yrazy vocabulary“ (slovn´ık) a ontology“ (ontologie). Uvád´ı, ” ” ˇze hranice mezi tˇemito dvˇema v´ yrazy je nejasná a vˇetˇsinou se pouˇz´ıvá v´ yraz ontology“ ” pro komplexnˇejˇs´ı a form´ alnˇejˇs´ı soubory term˚ u, kdeˇzto vocabulary“ pro ménˇe formáln´ı ” soubory. V ˇceském prostˇred´ı se pouˇz´ıvá oznaˇcen´ı ontologie.

10



RDF/XML

Syntaxe urˇcená pro v´ ymˇenu dat, která mus´ı b´ yt podporována vˇsemi nástroji splˇ nuj´ıc´ı specifikaci OWL 2.

OWL/XML

XML serializace ontologie, usnadˇ nuje zpracován´ı v nástroj´ıch pracuj´ıc´ıch s OWL.

Functional Syntax

Umoˇzn ˇuje pˇrehlednˇejˇs´ı zápis formáln´ı struktury ontologie.

Manchester Syntax

Jednoduˇsˇs´ı zápis ontologi´ı vyuˇz´ıvaj´ıc´ıch deskripˇcn´ı logiky.

Turtle

Jednoduˇsˇs´ı zápis triplet˚ u. Tabulka 2.1: Seznam syntax´ı OWL 2.

dvojici tvrzen´ı Jana je ˇzena“ a Jana a Petr jsou manˇzelé“, tak jednotliv´ ymi ” ” entitami jsou konkrétn´ı objekty (Jana, Petr), kategorie, do které je osoba ˇrazena (ˇzena), a vztah, kter´ y mezi tˇemito osobami je (jsou manˇzelé). V jazyce OWL je konkrétn´ı objekt (v naˇsem pˇr´ıpadˇe osoby) naz´ yván individual (instance), kategorie je tˇr´ıda (class) a jednotlivé vztahy jsou jejich vlastnostmi (property). V´ yrazy: Skládán´ı jednotliv´ ych entit do sloˇzitˇejˇs´ıch konstrukc´ı. Pokud napˇr´ıklad sloˇz´ıme tˇr´ıdy ˇzena“ a rodiˇc“, dostáváme tˇr´ıdu matka“. Pomoc´ı ” ” ” v´ yraz˚ u tak vznikaj´ı nové entity. Z definovan´ ych axiom˚ u, entit a v´ yraz˚ u je moˇzné odvozovat dalˇs´ı znalosti, které nejsou v ontologii explicitnˇe vyjádˇrené. Jazyk OWL dále rozdˇeluje vlastnosti objekt˚ u do následuj´ıc´ıch kategori´ı: Object property popisuje vztah mezi dvˇema objekty. Jej´ı hodnotou je tedy URI jiného objektu. Datatype property je vlastnost objektu, jej´ıˇz hodnotou je literál, napˇr´ıklad ˇretˇezec nebo celoˇc´ıselná hodnota. Annotation property nepopisuje pˇr´ımo vlastnost objektu, ale vlastnost ontologie (nebo jej´ı ˇca´sti) samotné. Jedná se napˇr´ıklad o autora a ˇcas posledn´ı u ´pravy urˇcitého axiomu. OWL umoˇzn ˇuje mezi jednotliv´ ymi tˇr´ıdami a vlastnostmi definovat dalˇs´ı vztahy, napˇr´ıklad ekvivalenci, kardinalitu, vzájemnou v´ yluˇcnost, pˇr´ıpadnˇe dalˇs´ı omezen´ı. Podrobnˇejˇs´ı pˇrehled vlastnost´ı poskytuje [16]. 11


2.4

Sémantické repositáˇre

S´ emantick´ e reposit´ aˇ re

Sémantické repositáˇre slouˇz´ı k uchováván´ı dat sémantického webu. Jsou poˇ dobné relaˇcn´ım SRBD – umoˇzn ˇuj´ı data ukládat, modifikovat a provádˇet nad ˇ nimi dotazy. Oproti relaˇcn´ım SRBD vˇsak data nejsou uloˇzena v tabulkách, ale v RDF grafu. Do sémantického repositáˇre je tedy moˇzné uloˇzit ontologii definovanou v jazyce OWL a dále s n´ı pracovat. [24] Sémantické repositáˇre ukládaj´ı jednotlivé RDF triplety. Ty jsou typicky vkládány v nˇekterém z formát˚ u, které definuj´ı standardy RDF a OWL. V´ ystupem je opˇet nˇekter´ y z tˇechto formát˚ u. ˇ Alternativou k sémantick´ ym repositáˇr˚ um je pouˇzit´ı relaˇcn´ıho SRBD a mapován´ı záznam˚ u v nˇem uloˇzen´ ych do RDF grafu. T´ımto postupem se zab´ yvá napˇr´ıklad [20]. Nad daty uloˇzen´ ymi v sémantickém repositáˇri je moˇzné se dotazovat dotazovac´ımi jazyky, které jsou podobné jazyku Structured Query Language (SQL). W3C standardizuje jazyk SPARQL Protocol and RDF Query Language (zkrácenˇe SPARQL).

2.5

Jazyk SPARQL

Vˇsechny typy SPARQL dotaz˚ u obsahuj´ı tzv. vzor grafu. Jedná se o sadu RDF triplet˚ u, jejichˇz kaˇzdá ˇcást m˚ uˇze b´ yt nahrazena za promˇennou. V datech je pak vyhledáván takov´ y podgraf, ze kterého je moˇzné do vzoru dosadit za promˇenné hodnoty tak, aby v´ ysledné grafy byly ekvivalentn´ı. Kromˇe sady triplet˚ u je moˇzné definovat omezuj´ıc´ı podm´ınky pro jednotlivé triplety podobnˇe jako je tomu u klauzule WHERE u SQL dotaz˚ u. [10] Tyto triplety jsou zadávány v syntaxi Turtle [3]. Promˇenné jsou uvozeny znakem ?, kter´ y je následován textov´ ym identifikátorem dané promˇenné. Jazyk SPARQL definuje tˇri základn´ı typy dotaz˚ u: SELECT, CONSTRUCT a ASK. Jednotlivé typy dotaz˚ u budou demonstrovány na mnoˇzinˇe triplet˚ u, která je uvedena ve v´ ypise 2.4. Prefix foaf: je pouˇzit pro jmenn´ y prostor http://xmlns.com/foaf/0.1/. _:osobaA _:osobaA _:osobaB _:osobaB _:osobaC

foaf:name foaf:nick foaf:name foaf:nick foaf:name

"Petr" . "P´ et’a" . "Lucie" . "Lucka" . "Jakub" .

V´ ypis 2.4: Ukázková sada triplet˚ u ve formátu Turtle. Dotazy typu SELECT jsou funkˇcnˇe i syntakticky podobné stejnojmennému 12


Jazyk SPARQL

typu dotazu v jazyce SQL. V´ ysledkem dotazu je mnoˇzina n-tic, které odpov´ıdaj´ı zadan´ ym podm´ınkám. Základn´ı struktura dotazu vypadá následovnˇe: SELECT expr-list WHERE { search-graph-pattern }

expr-list je seznam v´ yraz˚ u, které budou tvoˇrit v´ ysledné n-tice. V´ yrazem m˚ uˇze b´ yt konstantn´ı hodnota, promˇenná ˇci nˇekterá z vestavˇen´ ych funkc´ı. search-graph-pattern je seznam triplet˚ u, které tvoˇr´ı vzor grafu. Pro vˇsechny nalezené podgrafy, jeˇz odpov´ıdaj´ı vzoru, je pak vrácena jedna n-tice, do n´ıˇz jsou dosazeny promˇenné ze vzoru. Pˇr´ıklad jednoduchého dotazu SELECT: SELECT ?name, ?nick WHERE { ?x foaf:name ?name ; foaf:nick ?nick . }

V´ ysledek uvedeného dotazu nad triplety z v´ ypisu 2.4 je v tabulce 2.2. Ve v´ ysledku nen´ı zahrnuta osobaC, nebot’ nemá v datech triplet s predikátem foaf:nick. name

nick

Petr

Pét’a

Lucie

Lucka

Tabulka 2.2: V´ ysledek dotazu SELECT. Pokud bychom chtˇeli do v´ ysledk˚ u zahrnout i ty osoby, které nemaj´ı ˇzádn´ y foaf:nick, museli bychom pˇr´ısluˇsn´ y triplet ve vzoru uvést v sekci OPTIONAL. ˇ adek ve v´ R´ ysledku, pro nˇeˇz by nebyl foaf:nick nalezen, by obsahoval pouze jméno a sloupeˇcek nick by nemˇel ˇza´dnou hodnotu. Dotaz by vypadal takto: SELECT ?name, ?nick WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:nick ?nick . } }

Dotazy typu CONSTRUCT jsou funkˇcnˇe velmi podobné dotaz˚ um SELECT. V´ ysledkem vˇsak nen´ı mnoˇzina n-tic, ale mnoˇzina trojic, které tvoˇr´ı graf. Základn´ı struktura je podobná: 13


Jazyk SPARQL

CONSTRUCT { result-graph } WHERE { search-graph-pattern }

result-graph je vzor v´ ysledného grafu, do nˇehoˇz jsou dosazovány promˇenné z podgraf˚ u, které odpov´ıdaj´ı vyhledávanému vzoru. Pokud je v´ ysledn´ y graf stejn´ y jako graf vyhledávan´ y, je moˇzné ˇca´st s v´ ysledn´ ym grafem vynechat a pouˇz´ıt zkrácenou formu CONSTRUCT WHERE { search-graph-pattern }

Pˇr´ıklad jednoduchého dotazu CONSTRUCT (prefix vcard: oznaˇcuje http:// www.w3.org/2001/vcard-rdf/3.0#): CONSTRUCT { ?x vcard:name ?name . } WHERE { ?x foaf:name ?name . }

V´ ysledkem tohoto dotazu nad daty z v´ ypisu 2.4 bude mnoˇzina triplet˚ u ve v´ ypise 2.5. _:osobaA _:osobaA _:osobaB _:osobaB _:osobaC

foaf:name foaf:nick foaf:name foaf:nick foaf:name

"Petr" . "P´ et’a" . "Lucie" . "Lucka" . "Jakub" .

V´ ypis 2.5: V´ ysledek jednoduchého dotazu CONSTRUCT. V´ ysledkem dotaz˚ u typu ASK je pouze logická hodnota, která ˇr´ıká, zda je moˇzné zadan´ y vzor grafu v datech nalézt. Syntaxe dotazu je velmi jednoduchá: ASK { search-graph-pattern }

Uvaˇzujme následuj´ıc´ı dotaz nad mnoˇzinou triplet˚ u z v´ ypisu 2.4: ASK { ?x foaf:name "Jakub" }

V´ ysledkem bude logická hodnota true, protoˇze existuje osoba, která se jmenuje Jakub“. V´ ysledkem následuj´ıc´ıho dotazu by byla hodnota false, pro” toˇze osoba se jménem Jakub“ nemá uvedenou ˇzádnou pˇrezd´ıvku: ” ASK { ?x foaf:name "Jakub"; foaf:nick ?y }

Dalˇs´ı podrobnosti t´ ykaj´ıc´ı se jednotliv´ ych typ˚ u dotaz˚ u, jejich vyhodnocován´ı a obecnˇe jazyka SPARQL je moˇzné nalézt ve specifikaci [10].

14

3 Pˇrehled sémantických repositáˇr˚ u Srovnán´ım v´ ykonu jednotliv´ ych repositáˇr˚ u se zab´ yvá nˇekolik benchmark˚ u, 1 napˇr´ıklad Lehigh University Benchmark (LUBM), Ontology Benchmark2 (OUBM) ˇci Berlin SPARQL Benchmark3 (BSBM). Nejaktuálnˇejˇs´ı ze jmenovan´ ych je BSBM, proto bude vyuˇzit pro srovnán´ı v´ ykonu jednotliv´ ych repositáˇr˚ u. Pˇri testován´ı repositáˇr˚ u v BSBM jsou pouˇzity dvˇe sady dat: 100M s 100 000 748 triplety a 200M s 200 031 975 triplety.

U kaˇzdého repositáˇre je mˇeˇren ˇcas importu celého datasetu a následnˇe poˇcet vykonan´ ych dotaz˚ u za jednotku ˇcasu s r˚ uzn´ ym poˇctem souˇcasnˇe pˇripojen´ ych klient˚ u. V´ ysledky z posledn´ı iterace benchmarku pro vybrané repositáˇre jsou uvedeny v tabulkách 3.1 a 3.2. Pro repositáˇr OWLIM v edici SE je pouˇzit starˇs´ı název BigOwlim. Reposit´ aˇ r

Sada 100M

Sada 200M

26min 42s

1h 12min 04s

1h 03min 47s

3h 24min 25s

17min 22s

38min 36s

TDB

1h 14min 48s

2h 45min 13s

Virtuoso

1h 49min 26s

3h 59min 38s

4store BigData BigOwlim

Tabulka 3.1: Doba naˇc´ıtán´ı jednotliv´ ych datov´ ych sad. Kompletn´ı souhrn v´ ysledk˚ u posledn´ı iterace BSBM poskytuje [6]. Následuj´ıc´ı pˇrehled popisuje v souˇcasnosti nejv´ıce rozˇs´ıˇrené a obecnˇe podporované sémantické repositáˇre. Vhodn´ y produkt pak bude vybrán na základˇe následuj´ıc´ıch kritéri´ı: 1. moˇznosti fulltextového vyhledáván´ı, 1

http://swat.cse.lehigh.edu/projects/lubm/index.htm http://link.springer.com/chapter/10.1007%2F11762256_12 3 http://wifo5-03.informatik.uni-mannheim.de/bizer/ berlinsparqlbenchmark/ 2

15

Pˇrehled sémantických repositáˇr˚ u

Reposit´ aˇ r

4store

Sada 100M

Sada 200M

4store

5589

4593

BigData

2428

1795

BigOwlim

3534

1795

TDB

2274

1443

Virtuoso

7352

4669

Tabulka 3.2: Poˇcet vykonan´ ych dotaz˚ u za hodinu. 2. v´ ykon a 3. poskytované funkce v oblasti RDF a OWL. Kritéria jsou seˇrazena od nejd˚ uleˇzitˇejˇs´ıho po nejménˇe d˚ uleˇzité.

3.1

4store

4store4 je databázov´ y server, kter´ y je urˇcen pro ukládán´ı a dotazován´ı RDF dat. Dotazovat se je moˇzné jazykem SPARQL. 4store je urˇcen hlavnˇe pro nasazen´ı do clusteru, avˇsak pro nasazen´ı s menˇs´ım mnoˇzstv´ım dat lze pouˇz´ıt jedin´ y server. 4store byl p˚ uvodnˇe vyvinut a pouˇz´ıván internˇe ve spoleˇcnosti 5 garlik, jako open-source projekt byl uvolnˇen v roce 2009. Je distribuován pod licenc´ı GNU GPLv3. Kromˇe SPARQL dotazován´ı podporuje od verze 1.0.4 i základn´ı fulltextové vyhledáván´ı. V Berlin SPARQL Benchmark V3 se um´ıstil na 2. m´ıstˇe pˇri naˇc´ıtán´ı i dotazován´ı dat. Pˇri naˇc´ıtán´ı dat byl 1,5× aˇz 2× pomalejˇs´ı neˇz OWLIM-SE, avˇsak pˇri dotazován´ı byl v závislosti na mnoˇzstv´ı dat témˇeˇr 1,5× aˇz 2,5× rychlejˇs´ı. Pro velk´ y objem dat nebylo zpomalen´ı dotaz˚ u natolik v´ yrazné jako u jin´ ych produkt˚ u. [6] 4 5

http://4store.org/ http://www.garlik.com/

16


3.1.1

Jena

Pˇ r´ıpady pouˇ zit´ı

Data Patrol Data Patrol6 je hlavn´ı produkt spoleˇcnosti garlik. Jeho c´ılem je zabránit zneuˇzit´ı osobn´ıch a firemn´ıch dat. Aktivnˇe monitoruje velké mnoˇzstv´ı webov´ ych stránek a sociáln´ı s´ıtˇe a zjiˇst’uje, zda se na nich neobjevily osobn´ı, kontaktn´ı ˇci finanˇcn´ı informace (v´ ypisy z u ´ˇct˚ u, ˇc´ısla platebn´ıch karet a jiné). Pokud nalezne nˇekteré z tˇechto dat na veˇrejnˇe pˇr´ıstupném m´ıstˇe (webu), kde existuje riziko jejich zneuˇzit´ı, upozorn´ı uˇzivatele, aby mohl podniknout pˇr´ıpadné kroky.

3.2

Jena

Jena7 je Java framework pro vytváˇren´ı aplikac´ı sémantického webu. Poskytuje nástroje pro práci s RDF ve formátech XML, N-triples a Turtle, s ontologiemi OWL a RDFS, odvozovac´ı engine pro RDFS a OWL, dotazovac´ı engine odpov´ıdaj´ıc´ı SPARQL specifikaci a u ´loˇziˇstˇe dat. Komponenta LARQ8 nav´ıc pˇridává fulltextové vyhledáván´ı. V souˇcasnosti je jiˇz pro u ´ˇcely EEG/ERP portálu Jena pouˇz´ıvána – z relaˇcn´ı databáze Oracle jsou vytváˇreny OWL ontologie. To je uskuteˇcnˇeno pomoc´ı frameworku Hibernate, kter´ y data z relaˇcn´ı databáze mapuje do POJO objekt˚ u, a rozˇs´ıˇren´ı JenaBeanExtension, které následnˇe mapuje POJO objekty do RDF modelu Jeny. V´ıce informac´ı o nástroji JenaBeanExtension a jeho pouˇzit´ı v EEG/ERP portálu popisuje [20]. Pro Jenu existuje i nativn´ı u ´loˇziˇstˇe TDB9 . To ukládá na disku pˇr´ımo RDF triplety, se kter´ ymi m˚ uˇze Jena pracovat. Poskytuje tak vyˇsˇs´ı v´ ykon neˇz ukládán´ı objekt˚ u v relaˇcn´ı databázi. Podle Berlin SPARQL Benchmark V3 z u ńora 2011 vˇsak Jena s TDB poskytuje niˇzˇs´ı v´ ykon neˇz jiné sémantické repositáˇre. [6]

3.3

Sesame

Sesame10 je, podobnˇe jako Jena, Java framework pro zpracován´ı sémantick´ ych dat a vytváˇren´ı aplikac´ı sémantického webu. Také poskytuje nástroje pro práci s RDF a ontologiemi, engine pro SPARQL dotazován´ı a u ´loˇziˇstˇe 6

http://www.garlik.com/datapatrol http://jena.apache.org/ 8 Ofici´ aln´ı web neuv´ ad´ı, zda se jedná o zkratku. 9 Ofici´ aln´ı web opˇet neuv´ ad´ı, jestli jde o zkratku. 10 http://www.openrdf.org/ 7

17


OWLIM a KIM Platform

dat. Na rozd´ıl od Jeny vˇsak poskytuje odvozovac´ı engine pouze pro RDFS. [28] Sesame je tzv. quad-store. K triplet˚ um je moˇzné nav´ıc definovat i kontext, ve kterém byl dan´ y triplet uloˇzen´ y. Pˇri v´ ybˇeru dat je pak moˇzné dotaz omezit pouze na triplety s dan´ ym kontextem. Architektura se skládá z nˇekolika vrstev: RDF model tvoˇr´ı základ celého Sesame. Definuje a implementuje vˇsechny základn´ı RDF entity a pracuj´ı s n´ım vˇsechny ostatn´ı vrstvy. Rio (RDF I/O) je sada parser˚ u a zapisovatel˚ u r˚ uzn´ ych formát˚ u RDF. Sail (Storage And Inference Layer) je n´ızko´ urovˇ nová sada rozhran´ı pro ukládán´ı RDF a pˇr´ıpadné odvozován´ı. Základn´ı bal´ıˇcek Sesame obsahuje dvˇe implementace: MemoryStore pro ukládán´ı dat v pamˇeti a NativeStore pro ukládán´ı RDF triplet˚ u na disku. Repository API poskytuje vysoko´ urovˇ nové API pro práci s RDF modelem nezávisle na pouˇzitém Sail rozhran´ı. Právˇe tuto vrstvu vyuˇz´ıvaj´ı aplikace. Zjednoduˇsená architektura je znázornˇena na obrázku 3.1.

Obrázek 3.1: Architektura Sesame. Kromˇe tˇechto vrstev obsahuje Sesame nav´ıc implementaci HTTP serveru a klienta, která umoˇzn ˇuje komunikaci Sesame s jin´ ymi aplikacemi, pˇr´ıpadnˇe komunikaci mezi jednotliv´ ymi instancemi Sesame. Pod HTTP serverem mohou bˇeˇzet i webové aplikace pro správu dat, které jsou souˇca´st´ı distribuce. V´ ykon je velmi závisl´ y na pouˇzitém Sail rozhran´ı. Existuje i celá ˇrada implementac´ı tˇret´ıch stran, z nichˇz nejv´ yznamnˇejˇs´ı a nejrozˇs´ıˇrenˇejˇs´ı je komerˇcn´ı implementace OWLIM od spoleˇcnosti Ontotext.

3.4


OWLIM11 je komerˇcn´ı sémantick´ y repositáˇr vyv´ıjen´ y spoleˇcnost´ı Ontotext AD. Jedná se o implementaci Sesame Sail rozhran´ı a pˇridává podporu pro 11

http://www.ontotext.com/owlim/

18



OWL 2. K dat˚ um je moˇzné pˇristupovat pomoc´ı repository API ze Sesame, vyˇsˇs´ı edice poskytuj´ı i adaptér pro Jenu. Podle Berlin SPARQL Benchmark V3 má tento sémantick´ y repositáˇr nejrychlejˇs´ı naˇc´ıtán´ı dat – 200 milion˚ u záznam˚ u naˇcetl za 39 minut, dalˇs´ı produkt v poˇrad´ı témˇeˇr za dvojnásobek (72 minut). Ve zpracován´ı dat se um´ıstil na druhém m´ıstˇe za sémantick´ ym repositáˇrem Virtuoso. Podle stejného benchmarku také poskytuje v závislosti na poˇctu soubˇeˇzn´ ych u ´loh 1,5× - 5× vyˇsˇs´ı v´ ykon neˇz Jena s TDB. [6]

3.4.1

Edice

OWLIM je dodáván v následuj´ıc´ıch edic´ıch: Edice OWLIM-Lite je dostupná zdarma. Jedná se o implementaci Sesame Sail API a neposkytuje ˇza´dné dalˇs´ı metody pˇr´ıstupu k dat˚ um. Podle oficia´ln´ıch propagaˇcn´ıch materiál˚ u dokáˇze pracovat aˇz s des´ıtkami milion˚ u záznam˚ u, a to i na bˇeˇznˇe dostupném hardwaru. Odvozován´ı a dotazován´ı prob´ıhá v pamˇeti, odkud jsou pak data ukládána na disk. OWMLIM-SE je v ukládán´ı a práci s RDF grafy funkˇcnˇe shodn´ y s OWLIMLite. Oproti volnˇe dostupné verzi vˇsak pouˇz´ıvá algoritmy optimalizované pro práci s vˇetˇs´ı sadou dat a pˇridává podporu pro clusterován´ı a hybridn´ı dotazován´ı, které kombinuje SPARQL, fulltextové vyhledáván´ı, prostorové funkce a podporu pro ˇrazen´ı podle relevance. OWLIM-Enterprise poskytuje vysoce dostupn´ y cluster s replikac´ı, distribuc´ı zátˇeˇze, automatick´ ym pˇrekonán´ım selhán´ı (failover), monitoringem a dalˇs´ımi vlastnostmi typick´ ymi pro ˇreˇsen´ı s vysokou dostupnost´ı.

3.4.2

KIM Platform

KIM Platform12 je produkt vyv´ıjen´ y spoleˇcnost´ı Ontotext AD. Jedná se o platformu pro automatické anotován´ı dokument˚ u a následné vyhledáván´ı. Umoˇzn ˇuje nahráván´ı dokument˚ u, jejich automatickou anotaci proti pˇripravené ontologii a následné vyhledáván´ı v anotovan´ ych dokumentech. Princip sémantického anotován´ı a jeho realizaci v KIM uvád´ı jeho autoˇri v [14]. KIM Platform je postaven´ y na sémantickém repositáˇri OWLIM. Zpracován´ı textu a jeho anotace je realizováno pomoc´ı nástroj˚ u projektu GATE. Cel´ y produkt je pro nekomerˇcn´ı pouˇzit´ı poskytován zdarma (vˇcetnˇe u ´loˇziˇstˇe OWLIM) a je moˇzné jej nainstalovat na vlastn´ı server. Licenci pro komerˇcn´ı 12

http://www.ontotext.com/kim/

19



vyuˇzit´ı je moˇzné poˇr´ıdit od e3800, jej´ı cena se ale zvyˇsuje podle poˇctu server˚ u a procesorov´ ych jader, na kter´ ych je produkt nasazen.13 Nahrané dokumenty jsou anotovány proti znalostn´ı bázi uloˇzené v sémantickém repositáˇri. Nad tˇemito dokumenty pak poskytuje komplexn´ı vyhledáván´ı. KIM Platform své funkce poskytuje pomoc´ı webové SOAP sluˇzby a rozhran´ı pro Java RMI. K dispozici je také jiˇz hotové webové rozhran´ı, které tyto funkce vyuˇz´ıvá.

3.4.3


Tento odd´ıl popisuje nˇekteré v´ yznamné aplikace OWLIM v praxi. Konkrétn´ı implementaˇcn´ı detaily nejsou zveˇrejˇ novány. Web BBC Sports [27] BBC na svém sportovn´ım webu pouˇz´ıvá RDF ke zlepˇsen´ı navigace a vytváˇren´ı automaticky aktualizovan´ ych stránek o sportovc´ıch, t´ ymech, sportovn´ıch událostech a dalˇs´ıch. Jednotlivé ˇclánky jsou pˇri psan´ı anotovány pomoc´ı RDF. Tato metadata jsou pak uloˇzena v sémantickém repositáˇri (zde OWLIM-Enterprise). Pˇri vyhledáván´ı jsou nad tˇemito metadaty pokládány SPARQL dotazy. D´ıky definované ontologii a odvozovac´ım pravidl˚ um jsou pak nab´ıdnuty vˇzdy relevantn´ı informace. Pˇri sestavován´ı stránky o t´ ymu ˇci sportovci je moˇzné pouze na základˇe ˇclánk˚ u a jejich metadat generovat tabulky soupisek, zápas˚ u, poskytovat aktuáln´ı informace o zranˇen´ıch a mnoho dalˇs´ıch informac´ı. The National Archives [22] The National Archives archivuj´ı dokumenty z webov´ ych stránek vládn´ıch organizac´ı Spojeného královstv´ı Velké Británie a Severn´ıho Irska. Tento archiv obsahoval 700 milion˚ u dokument˚ u, z nichˇz velká ˇca´st byla duplicitn´ıch. Vyhledáván´ı v tˇechto dokumentech vˇsak bylo velmi obt´ıˇzné, protoˇze jednotlivé vládn´ı organizace maj´ı rozd´ılnou organizaˇcn´ı strukturu (oddˇelen´ı na podobné u ´rovni mohou m´ıt r˚ uzné zodpovˇednosti) a t´ım i rozd´ılnou organizaci dokument˚ u. Oznaˇcen´ım dokument˚ u sémantick´ ymi metadaty a následnou deduplikac´ı se podaˇrilo poˇcet dokument˚ u sn´ıˇzit na 160 milion˚ u unikátn´ıch dokument˚ u. Oznaˇcen´ı dokument˚ u bylo moˇzné d´ıky klasifikaci dokument˚ u a následnému rozpoznáván´ı jednotliv´ ych názv˚ u v textu. 13

http://www.ontotext.com/kim/getting-started/download

20


BigData

Byla také vytvoˇrena ontologie, která zachycuje organizaˇcn´ı strukturu vládn´ıch organizac´ı a t´ım pomáhá pˇri vyhledáván´ı dokument˚ u. Kromˇe OWLIM-Enterprise zde byl pouˇzit KIM Platform.

3.5

BigData

BigData14 je, podobnˇe jako OWLIM, implementac´ı Sesame Sail rozhran´ı. Poskytuje odvozován´ı nad RDFS a pˇridává omezenou podporu OWL. Je zamˇeˇren´ y pˇreváˇznˇe na nasazen´ı v distribuovan´ ych clusterech, má tedy dobrou podporu pro shardován´ı dat a distribuci zátˇeˇze. Produkt BigData je ˇs´ıˇren pod licenc´ı GPLv2. Kromˇe SPARQL dotazován´ı poskytuje také jednoduché fulltextové vyhledáván´ı. V Berlin SPARQL Benchmark dosahuje horˇs´ıch v´ ysledk˚ u neˇz repositáˇr OWLIM, a to jak pˇri dotazován´ı, tak pˇri naˇc´ıtán´ı dat. [6] Oficiáln´ı web neuvád´ı ˇzádné projekty, které BigData pouˇz´ıvaj´ı.

3.6

Virtuoso

Virtuoso15 je databázov´ y a aplikaˇcn´ı server vyv´ıjen´ y spoleˇcnost´ı OpenLink Software. Um´ı ukládat klasická relaˇcn´ı data i RDF data. Jako dotazovac´ı jazyk pouˇz´ıvá SQL, je vˇsak schopn´ y interpretovat také SPARQL dotazy, které jsou zabalené v SQL dotazu. Aplikaˇcn´ı server podporuje skriptován´ı v PHP, ASP.NET a proprietárn´ı jazyk Virtuoso Server Pages16 (VSP). Virtuoso je moˇzné pomoc´ı oficiáln´ıch adaptér˚ u pouˇz´ıt i jako u ´loˇziˇstˇe pro Jenu a Sesame. V Berlin SPARQL Benchmark V3 zv´ıtˇezil ve v´ ykonu pˇri zpracován´ı dat. V mnoha pˇr´ıpadech byl v´ıce neˇz 2Ö rychlejˇs´ı neˇz OWLIM. [6]

3.6.1

Edice

Virtuoso je distribuováno v open-source a komerˇcn´ıch variantách. Cena komerˇcn´ıch variant je odstupˇ nována podle poˇctu pouˇzit´ ych jader a dˇel´ı se na pouˇzit´ı na pracovn´ıch stanic´ıch a serverech. Nejlevnˇejˇs´ı varianta stoj´ı $999 14

http://www.systap.com/bigdata.htm http://virtuoso.openlinksw.com/ 16 http://docs.openlinksw.com/virtuoso/vsp1.html 15

21


Shrnut´ı

a je urˇcena pro pouˇzit´ı na pracovn´ıch stanic´ıch s maximálnˇe 8 jádry a 10 vlákny. Serverová varianta se stejn´ ymi limity stoj´ı $1999.17 Open-source varianta nemá oproti komerˇcn´ı variantˇe podporu pro prostorové indexy a dotazy, clusterován´ı, replikaci a podporu pro naˇc´ıtán´ı dat i z jin´ ych datov´ ych zdroj˚ u. [26] Kv˚ uli chybˇej´ıc´ı podpoˇre jin´ ych datov´ ych zdroj˚ u je nutné m´ıt vˇsechna data uloˇzena pˇr´ımo v intern´ı databázi Virtuosa a nen´ı moˇzné pracovat s daty uloˇzen´ ymi v jiném u ´loˇziˇsti.

3.6.2


Na oficiáln´ı webu nen´ı k dispozici pˇrehled konkrétn´ıch aplikac´ı, které Virtuoso pouˇz´ıvaj´ı. [31] vˇsak uvád´ı, ˇze Virtuoso pouˇz´ıvaj´ı projekty DBPedia, Bio2RDF a LOD Cloud Cache. Web projektu DBPedia18 uvád´ı, ˇze Virtuoso pouˇz´ıvá jako backend ke svému veˇrejnému SPARQL pˇr´ıstupu. Projekt se zamˇeˇruje na extrakci strukturovan´ ych informac´ı ze svobodné encyklopedie Wikipedia a propojen´ı tˇechto informac´ı s dalˇs´ımi datov´ ymi zdroji na webu. [7] 19 Projekt Bio2RDF agreguje v souˇcasnosti 19 r˚ uzn´ ych heterogenn´ıch zdroj˚ u dat z oblasti biologie a medic´ıny, ze kter´ ych vytváˇr´ı jednotn´ y RDF v´ ystup. Uvád´ı, ˇze takto agreguje asi 1 miliardu triplet˚ u. V´ıce informac´ı o projektu je dostupn´ ych v [4]. LOD Cloud Cache20 je projekt spoleˇcnosti OpenLink Software. Jedná se opˇet o agregátor nˇekolika zdroj˚ u dat, ve kter´ ych umoˇzn ˇuje vyhledáván´ı.

3.7

Shrnut´ı

Po prozkoumán´ı dostupn´ ych ˇreˇsen´ı a jejich pouˇzit´ı se jako nejvhodnˇejˇs´ı ukazuje sémantick´ y repositáˇr OWLIM s KIM Platform. OWLIM patˇr´ı podle aktuáln´ıch benchmark˚ u k nejv´ ykonnˇejˇs´ım sémantick´ ym repositáˇr˚ um. KIM Platform pak poskytuje funkce rozˇs´ıˇreného vyhledáván´ı a automatické anotován´ı dokument˚ u. Oba tyto produkty jsou u ´spˇeˇsnˇe vyuˇz´ıvány v projektech, které zpracovávaj´ı velké mnoˇzstv´ı dat. D´ıky otevˇrené architektuˇre (vyuˇzit´ı Sesame) a standardizovanému vnˇejˇs´ımu rozhran´ı (webové sluˇzby, Java RMI) je nav´ıc toto ˇreˇsen´ı vhodné pro ˇ pˇrizp˚ usoben´ı poˇzadavk˚ um neuroinformatické skupiny ZCU.

17

http://virtuoso.openlinksw.com/pricing/ http://dbpedia.org/ 19 http://bio2rdf.org/ 20 http://lod.openlinksw.com/ 18

22

4 KIM Platform Následuj´ıc´ı pˇrehled popisuje kl´ıˇcové vlastnosti KIM Platform.

4.1

Znalostn´ı b´ aze

Základem ontologie v sémantickém repositáˇri, která tvoˇr´ı znalostn´ı bázi, je ontologie PROTON.1 Ta tvoˇr´ı ontologii nejvyˇsˇs´ı u ´rovnˇe a popisuje základn´ı koncepty. Je rozdˇelena do 3 modul˚ u: System module je jedin´ y vyˇzadovan´ y modul. Definuje koncept term´ınu, kter´ y se vyskytuje v textu a kter´ y je vyhledáván bˇehem anotace. Tento term´ın je v ontologii oznaˇcován jako entita. Top module definuje abstraktn´ı koncepty, napˇr´ıklad agenta (ˇcinitele dˇeje), roli, téma, datum, m´ısto, skupinu, událost a dalˇs´ı. Upper module rozˇsiˇruje pˇredchoz´ı modul o entity, které jsou specifické jiˇz pro konkrétn´ı domény. Jedná se napˇr´ıklad o r˚ uzné typy organizac´ı (univerzita, vláda, pojiˇst’ovac´ı spoleˇcnost, banka...), dopravn´ı prostˇredky (vozidlo, auto, letadlo...), pracovn´ı pozice (zamˇestnanec, manaˇzer, u ´ˇredn´ık, pojiˇst’ovac´ı agent...) a dalˇs´ı. Tyto moduly tvoˇr´ı vhodn´ y základ pro vlastn´ı ontologie, které budou specifické pro poˇzadovanou doménu. Na této ontologii je také postavena KIM World Knowledge Base, jeˇz je dodávána s platformou KIM. Jedná se o znalostn´ı bázi fakt z reálného svˇeta: geografická m´ısta, v´ yznamné organizace, lidé na v´ yznamn´ ych pozic´ıch a dalˇs´ı. Celkem obsahuje v´ıce neˇz 44 000 entit s 77 000 aliasy. [25] Kromˇe tˇechto pˇripraven´ ych entit je GATE schopen pˇri anotován´ı vytváˇret instance nˇekter´ ych základn´ıch entit – konkrétn´ı data, ˇc´ısla, ˇcástky. Zpracován´ı tˇechto entit v anglickém jazyce zajiˇst’uje modul ANNIE,2 kter´ y je v KIM integrován.

4.2

Form´ at dokument˚ u

Nahrávané dokumenty mohou b´ yt v následuj´ıc´ıch formátech: prost´ y text, 1 2

http://proton.semanticweb.org/ A Nearly-New Information Extraction system

23

KIM Platform

Ukládán´ı a indexován´ı dokument˚ u

HTML stránka, XML dokumenty, jiˇz anotované GATE XML dokumenty, formáty Microsoft Office 2003 - 2010: dokumenty Microsoft Word a Microsoft Powerpoint, Adobe PDF, dokumenty RTF a Open Document Format. Nˇekteré formáty mohou vyˇzadovat pro správné zpracován´ı jeˇstˇe XML metadata o jazyce, názvu dokumentu, autorovi a datu publikace. Nahrávané dokumenty musej´ı b´ yt v anglickém jazyce. Pro podporu dalˇs´ıch jazyk˚ u je nutné vyvinout jazykov´ y modul pro GATE.

4.3

Ukl´ ad´ an´ı a indexov´ an´ı dokument˚ u

V KIM je ukládán pouze text nahrávan´ ych dokument˚ u s anotacemi. Pokud je tedy zdrojem dokumentu soubor typu PDF, nelze p˚ uvodn´ı PDF z repositáˇre stáhnout. Dokumenty je moˇzné ukládat ve 3 podporovan´ ych u ´loˇziˇst´ıch. Podle typu u ´loˇziˇstˇe se mohou liˇsit moˇznosti a rychlost vyhledáván´ı.

4.3.1

Apache Lucene

Lucene je bˇeˇznˇe pouˇz´ıvaná knihovna pro indexován´ı dokument˚ u a vyhledáván´ı. Ukládá cel´ y text dokument˚ u (vˇcetnˇe anotac´ı) v indexu a poskytuje fulltextové vyhledáván´ı. Toto u ´loˇziˇstˇe je doporuˇcované spoleˇcnost´ı Ontotext AD a jedná se o v´ ychoz´ı nastaven´ı.

4.3.2

Semantic Annotation Repository

Ukládá dokumenty do vestavˇeného sémantického repositáˇre ve formátu RDF. Poskytuje také bˇeˇzné fulltextové vyhledáván´ı, avˇsak vyˇzaduje dalˇs´ı konfiguraci u ´loˇziˇstˇe OWLIM.

4.3.3

MÍMIR

MÍMIR3 je indexovac´ı a vyhledávac´ı engine, kter´ y kombinuje vlastnosti fulltextového indexován´ı a sémantického repositáˇre. Je schopen vykonávat full3

Multiparadigm Indexing and Retrieval, http://www.ontotext.com/kim/mimir

24

KIM Platform

Doplnˇen´ı znalostn´ı báze a vytvoˇren´ı ontologie

textové dotazy, SPARQL dotazy a kombinované dotazy obsahuj´ıc´ı anotaˇcn´ı vzory. Pˇr´ıkladem kombinovaného dotazu z posledn´ı kategorie je napˇr´ıklad dotaz {Organization} category:VBG {Organization} for {Money}

Tento dotaz vyhledá dokumenty, které obsahuj´ı následuj´ıc´ı sekvenci: Organization: jméno organizace, category:VBG: sloveso, Organization: dalˇs´ı jméno organizace, for: slovo for“, ” Money: ˇcástka v jakékoliv rozpoznané mˇenˇe. Pˇr´ıkladem odpov´ıdaj´ıc´ı vˇety m˚ uˇze b´ yt Oracle buying Sun Microsystems for ” $5.6 billion.“ Integrace tohoto nástroje v KIM je experimentáln´ı.

4.4

Doplnˇ en´ı znalostn´ı b´ aze a vytvoˇ ren´ı ontologie

V sémantickém repositáˇri je uloˇzena znalostn´ı báze, kterou bude KIM Platform vyuˇz´ıvat pˇri anotován´ı dokument˚ u. Tato znalostn´ı báze je definována formou ontologie. KIM Platform jiˇz má nˇekteré znalosti nadefinovány, pro pouˇzit´ı ve vlastn´ı aplikaci je vˇsak nutné dodefinovat doménovou ontologii. V této ontologii by mˇely b´ yt definovány jak tˇr´ıdy, které danou doménu popisuj´ı, tak jejich instance, jeˇz budou slouˇzit jako entity pˇri anotaci a vyhledáván´ı.

4.4.1

Ontologie

Aby mohly b´ yt tyto entity správnˇe rozpoznány, musej´ı b´ yt jejich tˇr´ıdy odvozeny od tˇr´ıdy Entity z ontologie PROTON. V následuj´ıc´ım textu budu pouˇz´ıvat prefix protons: pro odkaz na jmenn´ y prostor http://proton. semanticweb.org/2006/05/protons. Pokud máme jiˇz existuj´ıc´ı ontologii, která toto kritérium nesplˇ nuje, je nutné pˇridat vlastnost rdfs:subClassOf ke koˇrenové tˇr´ıdˇe ontologie. Pˇr´ıklad ve formátu RDF/XML je uveden ve v´ ypise 4.1

25

KIM Platform


V´ ypis 4.1: Pˇr´ıklad odvozen´ı koˇrenové tˇr´ıdy od ontologie PROTON v RDF/XML. M˚ uˇzeme vˇsak tuto definici vloˇzit také do samostatného souboru a vyhnout se tak modifikaci p˚ uvodn´ı ontologie. K definici tˇechto tˇr´ıd se hod´ı notace Turtle. Ukázkov´ y triplet je uveden ve v´ ypise 4.2. .

V´ ypis 4.2: Pˇr´ıklad odvozen´ı koˇrenové tˇr´ıdy od ontologie PROTON v notaci Turtle. Tˇr´ıda Entity pˇridá pouze nˇekteré základn´ı vlastnosti, které jsou nutné pro anotaci dokument˚ u, avˇsak doménovou ontologii nijak nenaruˇs´ı. Nejd˚ uleˇzitˇejˇs´ı vlastnost, jiˇz je nutné zohlednit, je textov´ y ˇretˇezec, kter´ y bude analyzován a vyhledáván v textu. Direktiva com.ontotext.kim.KIMConstants.ENTITY_DESCR v konfiguraˇcn´ım souboru config/install.properties urˇcuje, jaká vlastnost entity tento textov´ y ˇretˇezec vyuˇz´ıvá. Jsou 3 moˇzná nastaven´ı této direktivy: Aliases vyˇzaduje pro kaˇzd´ y alias kaˇzdé instance vytvoˇrit novou instanci tˇr´ıdy protons:Alias. Tyto instance jsou pak s instanc´ı entity svázány pomoc´ı relace protons:hasAlias, popˇr. protons:hasMainAlias, pokud se jedná o preferovan´ y název. Labels nevyˇzaduje definici nové instance pro kaˇzd´ y alias. Textové ˇretˇezce jsou vyhledávány ve vlastnostech rdfs:Label a protons:mainLabel. Custom umoˇzn ˇuje definovat seznam URI vlastnost´ı, ve kter´ ych budou textové ˇretˇezce vyhledávány. Tento seznam je dan´ y konfiguraˇcn´ı direktivou com.ontotext.kim.KIMConstants.MAIN_LABEL_PREDICATES. Rozd´ıl ve sloˇzitosti mezi prvn´ımi dvˇema volbami bude nejlépe patrn´ y na ukázce kódu. Volba Aliases vyˇzaduje definici následuj´ıc´ım zp˚ usobem: Unused Entity Label <protons:hasMainAlias rdf:resource="http://example.com/ ontology#Entity_1"/> <protons:hasAlias rdf:resource="http://example.com/ontology# Entity_2"/>

26

KIM Platform


Entity Label Entity Alias

Entita Entity má definované vlastnosti protons:hasMainAlias a protons: hasAlias. Ty referencuj´ı instance Entity_1 a Entity_2, ve kter´ ych jsou popisky uloˇzeny ve vlastnosti rdfs:label. Textov´ y popisek samotné instance Entity nebude pˇri anotován´ı pouˇzit. Oproti tomu u volby Labels staˇc´ı jen kratˇs´ı definice: <protons:mainLabel>Entity Label Entity Alias

Textové popisky entity Entity jsou uloˇzeny pˇr´ımo ve vlastnostech protons: mainLabel a rdfs:label. Ontologie v tomto formátu je jiˇz pˇripravena pro pˇripojen´ı do KIM Platform, ale zat´ım stále nebude rozpoznávána v textu. KIM sice nalezne v textu pˇridané entity, ale nemá ˇza´dná pravidla pro jejich zpracován´ı. Ta jsou v KIM definována aˇz pro konkrétnˇejˇs´ı tˇr´ıdy: protont:Object, protont:Person, protont:Organization, nebo protont:Location. Prefix protont: je zde pouˇzit pro jmenn´ y prostor http://proton.semanticweb. org/2006/05/protont. Entita samotná také mus´ı b´ yt oznaˇcena, ˇze pocház´ı z d˚ uvˇeryhodného zdroje. D˚ uvˇeryhodn´ y zdroj je zaveden´ y jako instance tˇr´ıdy protons:Trusted. Tˇr´ıda protons:Entity pro oznaˇcen´ı pˇr´ısluˇsnosti entity k danému zdroji definuje vlastnost protons:generatedBy. Nˇekolik pˇreddefinovan´ ych d˚ uvˇeryhodn´ ych zdroj˚ u je uvedeno na zaˇca´tku souboru context/default/kb/wkb.nt. Popisky takto oznaˇcen´ ych entit jiˇz budou v textu rozpoznávány, KIM ale ve v´ ychoz´ım nastaven´ı rozliˇsuje velká a malá p´ısmena. Toto nastaven´ı lze zmˇenit v souboru context/default/resources/IE.gapp. Soubory *.gapp obsahuj´ı nastaven´ı jednotliv´ ych komponent, jenˇz se pod´ılej´ı na sémantické anotaci. Vyhledáván´ı entit v ontologii zajiˇst’uje kom27

KIM Platform


ponenta LKB Gazetteer, která má vlastnost caseSensitive. Pro vypnut´ı rozliˇsován´ı velikosti p´ısmen ji staˇc´ı nastavit na false. V tomto v´ ychoz´ım nastaven´ı KIM také hledá v dokumentu kl´ıˇcová slova s vysokou frekvenc´ı v´ yskytu. Takto vˇsak m˚ uˇze b´ yt oznaˇcena i ˇca´st term´ınu, jenˇz je definován v ontologii. V takovém pˇr´ıpadˇe nen´ı term´ın z ontologie rozpoznán. Nastaven´ı IE-no-keywords.gapp ve sloˇzce context/default/ resources tato kl´ıˇcová slova neextrahuje. Pouˇzit´ y soubor s nastaven´ım sémantického anotován´ı je moˇzné zmˇenit v konfiguraˇcn´ım souboru config/nerc.properties direktivou com.ontotext.kim.KIMConstants.IE_APP.

4.4.2

Zaveden´ı ontologie

Ontologii m˚ uˇze KIM naˇc´ıtat pˇri svém prvn´ım spuˇstˇen´ı a prvotn´ım vytváˇren´ı databáze. Soubory s ontologiemi se umist’uj´ı do sloˇzky context/default/kb, pˇr´ıpadnˇe do kterékoliv z podsloˇzek. V souboru config/owlim.ttl je pak nutné ontologie pˇridat do seznamu owlim:imports a jejich v´ ychoz´ı jmenn´ y prostor do seznamu owlim:defaultNS: owlim:imports "kb/owl/owl.rdfs; kb/owl/protons.owl; ... kb/ranks.nt; kb/example.com.owl;" ; owlim:defaultNS "http://www.w3.org/2002/07/owl#; http://proton.semanticweb.org/2006/05/protons#; ... http://www.ontotext.com/kim/2006/05/wkb#; http://example.com/ontology#;"

Po pˇridán´ı ontologie je nutné zastavit KIM, smazat vˇsechny pˇridané dokumenty (sloˇzka context/default/populated) a importovat je znovu. Nové entity jiˇz budou v textech automaticky rozpoznány. Jestliˇze nen´ı ˇza´douc´ı mazat veˇskerá data, je moˇzné ontologii importovat pomoc´ı nástroje rdf import: bin/tools/rdf import [dir]

Sloˇzka [dir] mus´ı obsahovat vˇsechny soubory s ontologiemi, které chceme importovat. Po dokonˇcen´ı importu je jeˇstˇe nutné smazat cache, jeˇz se nacház´ı ve sloˇzce context/default/populated/cache. Novˇe pˇridané entity budou

28

KIM Platform

Import dokument˚ u

rozpoznány aˇz v novˇe pˇridan´ ych dokumentech. Existuj´ıc´ı dokumenty je nutné pˇreindexovat. Pokud nav´ıc chceme, aby KIM zobrazoval tˇr´ıdy a vlastnosti z námi pˇridané ontologie ve sv´ ych pˇrehledech a nab´ıdkách, je nutné pˇridat jejich URI do souboru context/default/kb/visibility.nt: "" .

4.5

Import dokument˚ u

K importu dokument˚ u slouˇz´ı nástroj bin/tools/populater. Pˇri spuˇstˇen´ı bez parametr˚ u se otevˇre jeho grafické rozhran´ı. Pokud jej chceme spustit z konzole, mus´ıme pˇridat parametr console: bin/tools/populater console

Sloˇzku, odkud má nástroj importovat dokumenty, urˇcuje konfiguraˇcn´ı soubor config/populater.xml. Jedná se o element INPUT_STORAGE_URL. Ve v´ ychoz´ım nastaven´ı se nové soubory hledaj´ı ve sloˇzce corpus, kde jsou i pˇripravené testovac´ı dokumenty. KIM obsahuje také sluˇzbu populater-service, která bude novˇe nahrané dokumenty automaticky importovat. Tyto moˇznosti vˇsak vyˇzaduj´ı, aby soubory s dokumenty byly um´ıstˇeny do souborového systému serveru. Pro automatizované nahráván´ı dokument˚ u je moˇzné pouˇz´ıt i API poskytované prostˇrednictv´ım webové sluˇzby (SOAP) a Java RMI.

4.6

Vyhled´ av´ an´ı

Vyhledáván´ı je dostupné pomoc´ı webového rozhran´ı. To je souˇcást´ı distribuce KIM Platform jako WAR archiv. Aktuáln´ı verze také poskytuje integrovan´ y Java Servlet Container Jetty, jenˇz umoˇzn ˇuje snadné spuˇstˇen´ı webového rozhran´ı spolu s KIM Platform. Moˇznosti vyhledáván´ı, které poskytuje webové rozhran´ı, jsou uvedeny v pˇr´ıloze F.

29

5 Souˇcasné ontologie EEG/ERP dom´ eny Ontologie pouˇz´ıvaná v EEG/ERP portálu v souˇcasnosti slouˇz´ı hlavnˇe jako formát pro uchován´ı a sd´ılen´ı dat. Pro sémantické anotován´ı v KIM Platform je vˇsak potˇreba ontologie, která bude popisovat znalosti z dané domény a bude definovat a klasifikovat pouˇz´ıvané term´ıny a kl´ıˇcová slova. Ontologie EEG/ERP portálu sice nˇekterá kl´ıˇcová slova, jeˇz by mohla b´ yt z ontologie extrahována, obsahuje v názvech tˇr´ıd a vlastnost´ı, avˇsak pˇri anal´ yze ontologie byly zjiˇstˇeny nˇekteré nedostatky. Vlastnost title má jako rdfs:domain, tedy tˇr´ıdu, které tato vlastnost náleˇz´ı, uvedenu tˇr´ıdu ResearchGroup, ale vlastnost samotná je chybnˇe pouˇzita i u instanc´ı nˇekolika dalˇs´ıch tˇr´ıd, napˇr´ıklad u popisu hardwaru ˇci scénáˇr˚ u. T´ım se tyto instance pˇri odvozován´ı automaticky stávaj´ı i instancemi ResearchGroup, coˇz zavád´ı nejednoznaˇcnost a kl´ıˇcová slova by tedy nebylo moˇzné spolehlivˇe automaticky extrahovat a klasifikovat. V rámci Electrophysiology Task Force1 organizace INCF vzniká nová ontologie, která bude slouˇzit k popisu elektrofyziologick´ ych dat a metadat. Ontologie je rozdˇelená do dvou ˇca´st´ı: ˇcást popisuj´ıc´ı zaˇr´ızen´ı a metody pouˇzité pˇri elektrofyziologick´ ych experimentech a ˇcást popisuj´ıc´ı neurofyziologické koncepty.

Obˇe ˇca´sti jsou ve v´ yvoji paralelnˇe, prvn´ı verze ontologie by vˇsak mˇela obsahovat pˇreváˇznˇe data z prvn´ı ˇcásti. Tato prvn´ı verze vˇsak bude dostupná nejdˇr´ıve v létˇe 2013 a prozat´ım jsou k dispozici pouze návrhy nˇekter´ ych term´ın˚ u, proto zat´ım nem˚ uˇze b´ yt pouˇzita pro sémantické anotován´ı. Protoˇze existuj´ıc´ı ontologie neobsahuje potˇrebné informace a nová ontologie je stále ve v´ yvoji, je nutné pro zajiˇstˇen´ı základn´ı funkˇcnosti vytvoˇrit prototypovou ontologii, která bude popisovat alespoˇ n ˇca´st znalost´ı z EEG/ERP domény.

1

http://www.incf.org/programs/datasharing/electrophysiology-task-force

30

6 Specifikace poˇzadavk˚ u a pˇ rehled ˇ reˇ sen´ı Jak jiˇz bylo uvedeno, c´ılem práce je navrhnout ˇreˇsen´ı pro agregaci vybran´ ych dat z EEG/ERP domény a následné vyhledáván´ı.

6.1

Poˇ zadavky

Indexovány budou následuj´ıc´ı typy dokument˚ u: Odborné ˇcl´ anky a dalˇs´ı publikace, které budou dostupné typicky ve formátu PDF a diskuze v odborn´ ych neuroinformatick´ ych skupinách na sociáln´ı s´ıti LinkedIn.

S ˇcleny v´ yzkumné skupiny byly sestaveny následuj´ıc´ı pˇr´ıklady scénáˇr˚ u vyhledáván´ı: 1. Chci naj´ıt informace o vˇsech experimentech, které se zamˇeˇruj´ı na po” zornost ˇridiˇce, P3 komponentu, poskytuj´ı seznam pouˇzitého hardwaru a byly provedeny na skupinˇe nejménˇe 10 lid´ı.“ 2. Chci naj´ıt studii zamˇeˇrenou na pohybové poruchy dˇet´ı ve ˇskoln´ım ” vˇeku, ve které byla ˇcást v´ yzkumu provedena s vyuˇzit´ım EEP/ERG metod a vizuáln´ı stimulace.“ 3. Chci naj´ıt diskuzi o metodˇe matching pursuit vyˇsetˇruj´ıc´ı existenci P3 ” komponenty.“ C´ılem navrˇzeného ˇreˇsen´ı je nalezen´ı relevantn´ıch informac´ı pro tyto typy vyhledávac´ıch dotaz˚ u. Z v´ ysledk˚ u vyhledáván´ı dále mus´ı b´ yt moˇzné snadno pˇrej´ıt k p˚ uvodn´ımu dokumentu.

6.2

Pˇ rehled ˇ reˇ sen´ı

ˇ sen´ı lze rozdˇelit do tˇr´ı ˇca´st´ı: Reˇ 1. instalace a konfigurace platformy umoˇzn ˇuj´ıc´ı sémantické anotován´ı a vyhledáván´ı,

31

Specifikace poˇzadavk˚ u a pˇrehled ˇreˇsen´ı

Pˇrehled ˇreˇsen´ı

2. sestaven´ı znalostn´ı báze (ontologie) EEG/ERP domény, která umoˇzn´ı rozˇs´ıˇrené vyhledáván´ı, a 3. stahován´ı, ukládán´ı a indexován´ı dokument˚ u z vybran´ ych zdroj˚ u. Produkt KIM Platform byl nainstalován na virtuáln´ı server s operaˇcn´ım systémem GNU/Linux, konkrétnˇe jeho distribuc´ı Debian. Webové rozhran´ı KIM Platform bylo nasazeno do Java Servlet containeru Tomcat a nebylo dále upravováno. Protoˇze ontologie, které jsou v souˇcasnosti v´ yzkumné skupinˇe dostupné, jsou v raném stádiu v´ yvoje, nebo neobsahuj´ı poˇzadovaná data, bylo nutné pro ovˇeˇren´ı funkˇcnosti ˇreˇsen´ı vytvoˇrit prototypovou ontologii, jeˇz bude popisovat ˇcást znalost´ı EEG/ERP domény. Ontologie je navrˇzena tak, aby umoˇznila realizaci 3. vyhledávac´ıho scénáˇre. Ostatn´ı scénáˇre vyˇzaduj´ı ontologii s obsáhlejˇs´ım souborem term´ın˚ u. KIM Platform klade na vytvoˇrené term´ıny poˇzadavek, ˇze musej´ı b´ yt oznaˇcené jako vytvoˇrené d˚ uvˇeryhodn´ ym zdrojem. Pˇri tvorbˇe ontologie je vˇsak v´ yhodnˇejˇs´ı se zamˇeˇrit na popis samotn´ ych znalost´ı a tyto doplˇ nuj´ıc´ı definice vygenerovat aˇz pozdˇeji. K tomuto u ´ˇcelu byl vytvoˇren program KIM-OWLImport. Ten umoˇzn ˇuje pro vybrané ontologie vygenerovat pˇr´ısluˇsné definice, které budou importovány spolu s ontologi´ı do KIM Platform. Po dalˇs´ım rozˇs´ıˇren´ı také m˚ uˇze slouˇzit jako transformaˇcn´ı nástroj, jenˇz bude z vybrané ontologie extrahovat kl´ıˇcové term´ıny a vytváˇret novou ontologii ve struktuˇre, která bude odpov´ıdat ontologii PROTON. Pro automatické stahován´ı a anotován´ı dokument˚ u byl vytvoˇren program KIMBridge. Ten pˇristupuje k vzdálenému u ´loˇziˇsti dokument˚ u a sluˇzbˇe LinkedIn, stahuje nové dokumenty a diskuze a s vyuˇzit´ım Java RMI je importuje do KIM Platform. KIMBridge je implementovan´ y jako sluˇzba, která pobˇeˇz´ı na stejném serveru jako KIM. Nové dokumenty a pˇr´ıspˇevky v diskuz´ıch jsou stahovány periodicky.

32

7 Instalace KIM Platform, prototypov´ a ontologie 7.1

Instalace a konfigurace KIM Platform

KIM platform je moˇzné provozovat na vˇsech operaˇcn´ıch systémech, na kteˇ jsme zvolili virtuáln´ı stroj r´ ych je dostupná Java SE. V prostˇred´ı KIV ZCU s operaˇcn´ım systémem GNU/Linux, distribuc´ı Debian. Produkt je distribuován jako ZIP archiv. V nˇem je obsaˇzen samotn´ y server daemon s nakonfigurovan´ ym sémantick´ ym repositáˇrem a webová aplikace v podobˇe WAR archivu. Server je po rozbalen´ı moˇzno ihned spustit. Je moˇzné jej zastavovat a spouˇstˇet pomoc´ı pˇr´ıkazu bin/kim start|stop

Webová aplikace mus´ı b´ yt nasazena do Java servlet containeru, jak´ ym je napˇr´ıklad Tomcat. Od verze 3.6 obsahuje KIM Platform také integrovan´ y servlet container Jetty, s jehoˇz zprovoznˇen´ım jsem vˇsak mˇel pˇri instalaci pot´ıˇze. Proto bylo webové rozhran´ı nasazeno do containeru Tomcat 7. Bal´ıˇcek bohuˇzel neobsahuje ˇza´dné inicializaˇcn´ı scripty, musel b´ yt tedy napsán základn´ı initscript pro Debian. Script je k dispozici na pˇriloˇzeném CD. Uloˇzené dokumenty a pouˇz´ıvaná ontologie je standardnˇe uloˇzená ve sloˇzce context/default. V n´ı se nacház´ı i konfigurace sémantického repositáˇre OWLIM-SE. Ve vytvoˇrené ontologii byly textové popisky jednotliv´ ych entit um´ıstˇeny pˇr´ımo ve vlastnostech protons:mailLabel a rdfs:label. Direktiva com. ontotext.kim.KIMConstants.MAIN_LABEL_PREDICATES tedy byla nastavena na hodnotu Labels. Ontolgie KIM World Knowledgebase, která poˇc´ıtá s nastaven´ım na Aliases, nebyla do repositáˇre importována. Pro sémantické anotován´ı byla pouˇzita konfigurace IE-no-keywords. gapp, která neextrahuje kl´ıˇcová slova s vysokou frekvenc´ı v´ yskytu v textu. Pro tuto konfiguraci bylo také vypnuto rozliˇsován´ı velk´ ych a mal´ ych p´ısmen v názvech entit. V´ıce informac´ı o instalaci a konfiguraci je k dispozici v oficiáln´ı dokumentaci. [23] Bˇehem poˇca´teˇcn´ıch test˚ u byly zaznamenány problémy se zpracován´ım textu nˇekter´ ych PDF dokument˚ u. Ty jsou podle v´ yjimek, které jsou vyvolány bˇehem jejich zpracován´ı, zp˚ usobeny starˇs´ı verz´ı knihovny PDFBox (1.4.0), jeˇz je souˇca´st´ı KIM. Tato knihovna byla v instalaci aktualizována na verzi 33

Instalace KIM Platform, prototypová ontologie

Doménová ontologie

1.8.1, avˇsak nˇekteré dokumenty stále nelze kv˚ uli nevyˇreˇsené chybˇe v knihovnˇe zpracovat.1

7.2

Dom´ enov´ a ontologie

Pro zajiˇstˇen´ı základn´ı funkˇcnosti bylo proto nutné vytvoˇrit novou ontologii, která bude popisovat ˇcást znalost´ı z EEG/ERP domény. Pro u ´ˇcely testován´ı byly vybrány znalosti potˇrebné pro realizaci 3. vyhledávac´ıho scénáˇre: Chci naj´ıt diskuzi o metodˇe matching pursuit vyˇsetˇruj´ıc´ı existenci P3 kom” ponenty.“ Jako základ této ontologie byl vytvoˇren souhrn komponent evokovan´ ych potenciál˚ u a jednotliv´ ych metod, které jsou pouˇz´ıvány pˇri zpracován´ı namˇeˇren´ ych signál˚ u. Z popisu jednotliv´ ych komponent v [19] byl sestaven graf, jenˇz uvád´ı jednotlivé komponenty, jejich polaritu a zaˇrazen´ı do skupin. K jednotliv´ ym komponentám také byly pˇriˇrazeny aliasy, pod kter´ ymi m˚ uˇze b´ yt daná komponenta nalezena v odborné literatuˇre. Pˇri volbˇe tˇechto alias˚ u bylo pˇrihl´ıˇzeno ke zvyklostem, jeˇz autoˇri v literatuˇre pouˇz´ıvaj´ı. [19] napˇr´ıklad uvád´ı, ˇze komponentou P3 autoˇri témˇeˇr v´ yhradnˇe mysl´ı komponentu P3b, proto je P3 pˇriˇrazeno jako alias k P3b, aˇckoliv z hlediska formáln´ıho popisu jde o nadˇrazen´ y pojem oznaˇcuj´ıc´ı danou rodinu komponent. V´ ysledn´ y graf je k nahlédnut´ı v pˇr´ıloze A. Z tohoto grafu byla poté sestavena ˇca´st ontologie v jazyce OWL, která strukturou odpov´ıdá podm´ınkám, jeˇz klade KIM Platform. Graf druhé ˇcásti ontologie, tedy jednotlivé metody pouˇz´ıvané pˇri zpracoˇ ván´ı signál˚ u, zpracoval Ing. Tomáˇs Rond´ ık. Jednotlivé metody jsou rozdˇeleny do kategori´ı podle jejich principu a podle typického pouˇzit´ı. V grafu jsou také znázornˇeny základn´ı vztahy mezi jednotliv´ ymi metodami. Graf je k nahlédnut´ı v pˇr´ıloze B. Z grafu byla opˇet sestavena ontologie v jazyce OWL. Pˇred importem do KIM byla ontologie doplnˇena nástrojem KIM-OWLImport o triplety, které jednotlivé entity definuj´ı jako vytvoˇrené d˚ uvˇeryhodn´ ym zdrojem. Obˇe sestavené ontologie vˇcetnˇe ilustraˇcn´ıch graf˚ u jsou k dispozici na pˇriloˇzeném CD.

1

https://issues.apache.org/jira/browse/PDFBOX-1512

34

8 KIMBridge KIMBridge je sluˇzba, která bˇeˇz´ı na stejném serveru jako KIM platform a periodicky stahuje nové dokumenty z vybran´ ych zdroj˚ u (repositáˇr˚ u) dat. Periodu stahován´ı nov´ ych dokument˚ u lze nastavit v konfiguraˇcn´ım souboru. Tyto dokumenty jsou importovány do KIM, kde prob´ıhá jejich anotace. Do KIM jsou ukládány PDF dokumenty z Google Drive a texty diskuz´ı ve vybran´ ych skupinách na sociáln´ı s´ıti LinkedIn. Implementace repositáˇr˚ u s dokumenty je vˇsak obecná, takˇze je moˇzné KIMBridge v budoucnu snadno rozˇs´ıˇrit i o dalˇs´ı zdroje dat. Struˇcn´ y popis instalace a spuˇstˇen´ı sluˇzby je k dispozici v pˇr´ıloze G.

8.1

Anal´ yza

Pˇri importu dokument˚ u do KIM Platform je moˇzné je uloˇzit jako soubory na serveru. Tam je lze periodicky importovat pomoc´ı nástroje populater, pˇr´ıpadnˇe prostˇrednictv´ım sluˇzby populater-service. To vˇsak vede k duplicitˇe dat na serveru – text dokument˚ u je uloˇzen jednou ve sloˇzce s dokumenty a jednou anotovan´ y ve fulltextovém indexu. Dokumenty je také moˇzné do KIM Platform nahrávat pomoc´ı webov´ ych sluˇzeb, nebo prostˇrednictv´ım Java RMI. Podle dokumentace nelze pomoc´ı webové sluˇzby manipulovat s jiˇz existuj´ıc´ımi dokumenty v repositáˇri, proto bylo pro KIMBridge zvoleno rozhran´ı Java RMI. Anotovány budou dva typy dokument˚ u: odborné ˇclánky a publikace, které budou uloˇzeny typicky ve form´ atu PDF, a odborné diskuze z profesnˇe zamˇeˇren´ ych skupin v sociáln´ı s´ıti LinkedIn.

Jako u ´loˇziˇstˇe dokument˚ u byla vybrána sluˇzba Google Drive, do n´ıˇz je moˇzné nahrávat libovolné dokumenty. Nahrané dokumenty jsou poté pˇr´ıstupné pomoc´ı Google Drive API. Odborné diskuze ze sociáln´ı s´ıtˇe LinkedIn lze stahovat pomoc´ı API, které sluˇzba poskytuje.

8.1.1

Google Drive API

Pro pˇr´ıstup k Drive API je nutné nejdˇr´ıve vytvoˇrit klientské kl´ıˇce v Google APIs Console. Na v´ ybˇer jsou tˇri typy klientsk´ ych kl´ıˇc˚ u:

35

KIMBridge

Analýza

Web Application urˇcen´ y pro webové aplikace, do nichˇz se pˇrihlaˇsuj´ı uˇzivatelé, kteˇr´ı musej´ı aplikaci povolit pˇr´ıstup k jejich uˇzivatelsk´ ym dat˚ um, Service Account, pomoc´ı kterého aplikace do API nepˇristupuje jako pˇrihláˇsen´ y uˇzivatel, ale pod vlastn´ım u ´ˇctem, a Installed Application, jenˇz slouˇz´ı pro pˇr´ıstup z aplikac´ı, které má uˇzivatel nainstalované v PC nebo mobiln´ıch zaˇr´ızen´ıch. Pro stahován´ı dokument˚ u je nejvhodnˇejˇs´ı vytvoˇrit Service Account. Pro aplikaci bude vytvoˇren u ´ˇcet Google s e-mailovou adresou v doménˇe developer. gserviceaccount.com. S t´ımto u ´ˇctem je moˇzné sd´ılet dokumenty ˇci sloˇzky, do kter´ ych má aplikace m´ıt pˇr´ıstup. API sluˇzby je zdokumentováno v oficiáln´ı dokumentaci [8]. Pomoc´ı tohoto API je moˇzné z´ıskávat bud’ seznamy soubor˚ u a sloˇzek, které jsou se sluˇzbou sd´ıleny, nebo seznam upraven´ ych a pˇridan´ ych dokument˚ u (obecnˇe seznam zmˇen v dokumentech). Kaˇzdá zmˇena je oznaˇcena sv´ ym poˇradov´ ym ˇc´ıslem. Pˇri stahován´ı seznamu zmˇen lze uvést nejniˇzˇs´ı ˇc´ıslo zmˇeny, jeˇz má b´ yt v seznamu zahrnuto. Uchováván´ım ˇc´ısla posledn´ı zmˇeny je tak moˇzné stahovat seznam pˇridan´ ych a upraven´ ych dokument˚ u od posledn´ı kontroly. Souˇca´st´ı kaˇzdé zmˇeny je i URL souboru, ze kterého lze dan´ y soubor dalˇs´ım volán´ım API stáhnout. Dokumenty ve formátech Google Docs (jejich MIME-Type je ve formátu application/vnd.google-apps.*) nen´ı moˇzné pˇr´ımo stahovat, jsou urˇceny k zobrazen´ı a editaci ve webové aplikaci Google Docs a je nutné je ze seznamu zmˇen filtrovat. Protoˇze je vˇsak naprostá vˇetˇsina odborn´ ych publikac´ı ve formátu PDF, lze stahovat pouze dokumenty s MIME-Type application/pdf. Soubory PDF nejsou urˇceny k u ´pravám, proto staˇc´ı stahovat jen nové dokumenty a nen´ı nutné aktualizovat jiˇz importované dokumenty. Google omezuje poˇcet moˇzn´ ych volán´ı na jejich API, avˇsak pro sluˇzbu Drive jsou tyto limity tak vysoké (10 000 000 poˇzadavk˚ u za den), ˇze pro aplikaci nepˇredstavuj´ı ˇza´dn´ y problém. Pˇr´ıstup do API je moˇzn´ y pomoc´ı oficiáln´ıch klientsk´ ych knihoven, které jsou k dispozici pro vˇsechny jazyky pouˇz´ıvané pˇri v´ yvoji modern´ıch aplikac´ı, vˇcetnˇe jazyka Java.

8.1.2

LinkedIn API

Pro pˇr´ıstup k API sluˇzby LinkedIn je téˇz potˇreba vytvoˇrit klientské kl´ıˇce. Na portálu pro v´ yvojáˇre je nutné vytvoˇrit novou aplikaci. Aplikace pak ke sluˇzbˇe pˇristupuje pomoc´ı 4 kl´ıˇc˚ u: 2 jsou specifické pro uˇzivatele, k jehoˇz dat˚ um aplikace pˇristupuje, a zbylé dva jsou spoleˇcné pro celou aplikaci.

36

KIMBridge

Popis implementace

Po vytvoˇren´ı aplikace jsou vygenerovány pˇr´ıstupové kl´ıˇce pro aktuáln´ıho uˇzivatele. Je moˇzné pˇridat dalˇs´ı osoby jako v´ yvojáˇre aplikace, kter´ ym budou také vygenerovány pˇr´ıstupové u ´daje, pˇr´ıpadnˇe si aplikaci m˚ uˇze uˇzivatel pˇridat v nastaven´ı svého u ´ˇctu. K API lze pˇristupovat bud’ z JavaScriptové knihovny, jeˇz je urˇcena pro pouˇzit´ı v prohl´ıˇzeˇci, nebo pomoc´ı REST API. Toto API [17] poskytuje volán´ı, pomoc´ı nˇehoˇz je moˇzné stáhnout seznam posledn´ıch pˇr´ıspˇevk˚ u ve skupinˇe s dan´ ym ID. M˚ uˇzeme také specifikovat datum, od kterého maj´ı b´ yt pˇr´ıspˇevky staˇzeny. Toto datum vˇsak udává pouze datum vytvoˇren´ı pˇr´ıspˇevku. Pokud byl pˇr´ıspˇevek vytvoˇren pˇred zadan´ ym datem a po daném datu byl pouze modifikován, nebo k nˇemu byl pˇridán komentáˇr, nebude v seznamu uveden. U diskuz´ı je vˇsak nutné stahovat nejen nové pˇr´ıspˇevky, ale i nové komentáˇre, které byly k pˇr´ıspˇevku pˇridané. API neposkytuje ˇza´dné volán´ı, pomoc´ı nˇehoˇz by bylo moˇzné stáhnout nové komentáˇre, pˇr´ıpadnˇe pˇr´ıspˇevky s nov´ ymi komentáˇri. Je tak nezbytné pro kaˇzd´ y pˇr´ıspˇevek provést volán´ı na z´ıskán´ı seznam komentáˇr˚ u. Protoˇze sluˇzba LinkedIn omezuje poˇcet volán´ı, které je za den moˇzné provést, nelze toto volán´ı na seznam komentáˇr˚ u opakovat pro kaˇzd´ y pˇr´ıspˇevek v databázi. Podle [18] je moˇzné provést za den 1000 poˇzadavk˚ u na nové pˇr´ıspˇevky ve skupinˇe a 1000 poˇzadavk˚ u na komentáˇre ke konkrétn´ımu pˇr´ıspˇevku. Volán´ı je tedy nutné omezit pouze na ty diskuze, u nichˇz je pˇredpokládána aktivita diskutuj´ıc´ıch. V aplikaci tedy bude pro kaˇzdou skupinu udrˇzována fronta diskuz´ı s omezenou délkou, ve které budou jednotlivé diskuze seˇrazeny podle aktivity. Nové a aktualizované diskuze budou zaˇrazeny vˇzdy na zaˇca´tek fronty. Pokud nˇekterá z diskuz´ı nebude dlouho aktivn´ı, propadne se na konec fronty, odkud bude posléze odstranˇena. T´ımto pˇr´ıstupem bude zajiˇstˇeno, ˇze poˇcet volán´ı API nepˇresáhne stanovené limity.

8.2

Popis implementace

Zjednoduˇsen´ y diagram nejd˚ uleˇzitˇejˇs´ıch tˇr´ıd a rozhran´ı v KIMBridge je znázornˇen na obrázku 8.1. Podrobnˇejˇs´ı UML diagram tˇr´ıd a vztah˚ u mezi nimi, vˇcetnˇe signatur d˚ uleˇzit´ ych metod, je v pˇr´ıloze C. Základn´ı tˇr´ıdou programu je tˇr´ıda KIMBridge. Ta obsahuje reference na jednotlivé repositáˇre dokument˚ u (Google Drive, jednotlivé skupiny na LinkedIn) a po zavolán´ı metody annotateNewDocuments() stáhne nové dokumenty a nahraje je do KIM Platform. Spojen´ı s KIM Platform zajiˇst’uje tˇr´ıda KIMConnector. Ta vyuˇz´ıvá nˇekolika 37

KIMBridge

Popis implementace

1 KIMBridge

fetches new documents from

1..*

«interface»

IDocumentRepository

1 fetches text

creates

«interface»

IDocument uploads documents to 1 KIMConnector

«interface»

ITextDocument «interface»

IBinaryDocument

DriveRepository

LinkedInRepository

Obrázek 8.1: Diagram základn´ıch tˇr´ıd a rozhran´ı KIMBridge. rozhran´ı z KIM a zajiˇst’uje vytváˇren´ı, ukládán´ı a anotaci dokument˚ u. Je také schopná zajistit reanotaci urˇcitého dokumentu, nebo aktualizaci jeho obsahu podle novˇe vytvoˇreného dokumentu. Pro pˇripojen´ı ke KIM vyuˇz´ıvá Java RMI. Repositáˇr dokument˚ u je tˇr´ıda implementuj´ıc´ı rozhran´ı IDocumentRepository. Volán´ım metody getNewDocuments() repositáˇre dojde ke staˇzen´ı nov´ ych dokument˚ u. Dokument je instance tˇr´ıdy, která implementuje rozhran´ı ITextDocument, nebo rozhran´ı IBinaryDocument. KIMBridge tyto dokumenty pomoc´ı KIMConnector importuje do KIM Platform. Po u ´spˇeˇsné anotaci a uloˇzen´ı dokumentu je nad repositáˇrem zavolána metoda documentIndexed(). Ta m˚ uˇze b´ yt vyuˇzita napˇr´ıklad pro vytvoˇren´ı vazby mezi dokumentem v KIM Platform a dokumentem v repositáˇri dokument˚ u, aby dokument v KIM mohl b´ yt pozdˇeji aktualizován. Vytváˇren´ı jednotliv´ ych repositáˇr˚ u pˇri startu sluˇzby zajiˇst’uj´ı tˇr´ıdy implementuj´ıc´ı rozhran´ı IRepositoryFactory. Konfigurace továren a repositáˇr˚ u dokument˚ u je uloˇzena v konfiguraˇcn´ım XML souboru. Z nˇej jsou naˇc´ıtány tˇr´ıdou Configurator. Ta je schopná naˇc´ıtat v´ıce konfiguraˇcn´ıch soubor˚ u a jejich direktivy sluˇcovat. Konfigurace má 3 ˇcásti: obecnou konfiguraci KIMBridge, konfiguraci továren repositáˇr˚ u a konfiguraci jednotliv´ ych repositáˇr˚ u. Vytvoˇren´ı a registraci továren a repositáˇr˚ u z konfigurace zajiˇst’uje tˇr´ıda RepositoryConfigurator. Jej´ı metoda intitializeRepositories má jeden parametr: instanci KIMBridge, do které maj´ı b´ yt repositáˇre zaregistrovány. Tˇr´ıda pˇri volán´ı této metody nejprve vytvoˇr´ı vˇsechny definované továrny. Továrna po vytvoˇren´ı dostane svou konfiguraci ve tˇr´ıdˇe FactoryConfiguration. V n´ı jsou uvedeny napˇr´ıklad pˇr´ıstupové kl´ıˇce k API a dalˇs´ı parametry, jeˇz jsou potˇrebné k navázán´ı spojen´ı s danou sluˇzbou. Vytvoˇrené továrny jsou pouˇzity k vytvoˇren´ı jednotliv´ ych repositáˇr˚ u. Metodˇe createRepository je pˇredán ˇretˇezec s intern´ım názvem repositáˇre a kon38

KIMBridge

Popis implementace

KIMBridge

1

registers repositories to fetches new documents from Configurator

1 gets configuration from

1 RepositoryConfigurator

1

1 creates 1..*

1..* 1..*

1

1

FactoryConfiguration

1..*

«interface»

creates

IRepositoryFactory

«interface»

IDocumentRepository

uses to configure repositories

RepositoryConfiguration

Obrázek 8.2: Diagram tˇr´ıd zajiˇst’uj´ıc´ıch vytvoˇren´ı repositáˇr˚ u dokument˚ u. figurace repositáˇre ve tˇr´ıdˇe RepositoryConfiguration. V´ ysledkem volán´ı je nov´ y repositáˇr s danou konfigurac´ı, kter´ y je následnˇe zaregistrován do KIMBridge. Diagram tˇr´ıd, jeˇz zajiˇst’uj´ı naˇc´ıtán´ı konfigurace a vytváˇren´ı repositáˇr˚ u, je na obrázku 8.2. Po u ´spˇeˇsné synchronizaci a pˇri ukonˇcován´ı KIMBridge je uchován stav vˇsech repositáˇr˚ u. Repositáˇr pˇri ukládán´ı vytvoˇr´ı instanci tˇr´ıdy, která implementuje rozhran´ı IRepositoryState. V této tˇr´ıdˇe m˚ uˇze b´ yt uloˇzeno napˇr´ıklad datum a ˇcas posledn´ı synchronizace, seznam aktivn´ıch diskuz´ı, pˇr´ıpadnˇe libovolná jiná data, jeˇz je nutné uchovat pˇri restartu sluˇzby. Po opˇetovném startu je stav repositáˇre opˇet obnoven. Uloˇzen´ı a naˇc´ıtán´ı stavu zajiˇst’uje tˇr´ıda SyncStatePersister. Ta stav repositáˇr˚ u serializuje do binárn´ıho souboru. Vˇsechny ˇcleny tˇr´ıdy implementuj´ıc´ı IRepositoryState proto musej´ı implementovat rozhran´ı Serializable. Diagram tˇr´ıd, které zajiˇst’uj´ı ukládán´ı a obnovu stavu repositáˇr˚ u, je znázornˇen na obrázku 8.3. passes repository state to and from

1 SyncStatePersister

loads from and saves to binary file

1 1 KIMBridge

1..*

stores state in and restores state from

«interface»

IDocumentRepository

«interface»

IRepositoryState

Obrázek 8.3: Tˇr´ıdy zajiˇst’uj´ıc´ı ukládán´ı a naˇc´ıtán´ı stavu repositáˇr˚ u.

39

KIMBridge

8.2.1

Popis implementace

Google Drive

Repositáˇr pro Google Drive vyuˇz´ıvá Google Drive API Client s vygenerovan´ ym modelem pro sluˇzbu Google Drive. Tato knihovna je dostupná z adresy https://code.google.com/p/google-api-java-client/wiki/APIs# Drive_API. Pro tuto knihovnu byl vytvoˇren adaptér DriveConnector, jenˇz poskytuje metody potˇrebné pro stahován´ı seznamu zmˇen a soubor˚ u. Adaptér je vytváˇren továrnou DriveRepositoryFactory a pro pˇripojen´ı potˇrebuje následuj´ıc´ı konfiguraˇcn´ı direktivy: appName – název aplikace, kter´ y bude hláˇsen sluˇzbám Google, accountId – ID vytvoˇreného service account a privateKey – cesta k souboru service account. ID u ´ˇctu a soubor s privátn´ım kl´ıˇcem lze nalézt v Google APIs Console. Dokument reprezentovan´ y tˇr´ıdou DriveDocument stahuje data aˇz v okamˇziku ukládán´ı do KIM Platform, mus´ı mu tedy pˇri vytváˇren´ı b´ yt pˇredána instance DriveConnector. Pˇri ukonˇcován´ı KIMBridge si Google Drive repositáˇr ukládá ve tˇr´ıdˇe DriveRepositoryState poˇradové ˇc´ıslo posledn´ı zmˇeny. Jednotlivé tˇr´ıdy Google Drive repositáˇre a vztahy mezi nimi jsou znázornˇeny na obrázku 8.4. «interface»

«interface»

«interface»

IRepositoryFactory

IDocumentRepository

IBinaryDocument

1

DriveRepositoryFactory 1 creates

creates

1

fetches changes from

1 creates 0..*

DriveRepository

DriveDocument

0..*

0..* stores state to and restores state from

1 DriveConnector 1

DriveRepositoryState

«interface»

IRepositoryState

fetches raw binary data from

Obrázek 8.4: UML diagram tˇr´ıd Google Drive repositáˇre.

8.2.2

LinkedIn

Repositáˇr pro stahován´ı diskuz´ı ze skupin na LinkedIn vyuˇz´ıvá knihovnu linkedin-j, která je dostupná z adresy https://code.google.com/p/linkedin-j/. 40

KIMBridge

Popis implementace

Pro knihovnu byl opˇet vytvoˇren adaptér LinkedInConnector, jenˇz poskytuje metody pro stahován´ı nov´ ych pˇr´ıspˇevk˚ u ve skupinˇe a stahován´ı konkrétn´ıch pˇr´ıspˇevk˚ u vˇcetnˇe jejich komentáˇr˚ u. Adaptér je vytváˇren továrnou LinkedInRepositoryFactory a vyˇzaduje v konfiguraci následuj´ıc´ı autorizaˇcn´ı kl´ıˇce: consumerKey – kl´ıˇc rozhran´ı API, consumerSecret – tajn´ y kl´ıˇc, token – autorizaˇcn´ı uˇzivatelsk´ y kl´ıˇc a tokenSecret – autorizaˇcn´ı tajná vˇeta. Vˇsechny tyto kl´ıˇce je moˇzné naj´ıt v nastaven´ı aplikace na portálu pro v´ yvojáˇre LinkedIn. Pro kaˇzd´ y staˇzen´ y pˇr´ıspˇevek je vytvoˇrena instance tˇr´ıdy LinkedInDocument. Pˇri ukládán´ı dokumentu je z pˇr´ıspˇevku vytvoˇren ˇretˇezec obsahuj´ıc´ı autora pˇr´ıspˇevku, ˇcas vytvoˇren´ı, text pˇr´ıspˇevku a vˇsechny komentáˇre vˇcetnˇe jejich autora a textu. Jednotlivé pˇr´ıspˇevky jsou vkládány do fronty, která je reprezentovaná tˇr´ıdou PostQueue. Do n´ı se ukládá jen ID pˇr´ıspˇevku ve sluˇzbˇe LinkedIn, ID v repositáˇri KIM Platform a poˇcet komentáˇr˚ u. Pokud pˇri kontrole pˇr´ıspˇevk˚ u poˇcet komentáˇr˚ u vzroste, je pˇr´ıspˇevek pˇresunut na zaˇcátek fronty a jeho obsah v KIM je aktualizován. Pˇri ukonˇcen´ı kontroly nov´ ych pˇr´ıspˇevk˚ u jsou z fronty vyjmuty prvky, jeˇz pˇresahuj´ı jej´ı kapacitu. Kontrola nov´ ych komentáˇr˚ u u sledovan´ ych pˇr´ıspˇevk˚ u prob´ıhá nejdˇr´ıve po 12 hodinách, aby nedoˇslo k vyˇcerpán´ı limitu poˇctu volán´ı, které je moˇzné za den provést. Pˇri ukonˇcován´ı KIMBridge si LinkedIn repositáˇre ukládaj´ı datum a ˇcas posledn´ı kontroly nov´ ych pˇr´ıspˇevk˚ u, datum a ˇcas posledn´ı kontroly nov´ ych komentáˇr˚ u a aktuáln´ı frontu pˇr´ıspˇevk˚ u. Jednotlivé tˇr´ıdy LinkedIn repositáˇre a vztahy mezi nimi jsou znázornˇeny na obrázku 8.5.

8.2.3

Sluˇ zba KIMBridge

KIMBridge je moˇzné s vyuˇzit´ım knihovny Apache Commons Daemon a nástroje jsvc spustit jako sluˇzbu, která bude bˇeˇzet na pozad´ı a periodicky stahovat dokumenty z repositáˇr˚ u. Pˇri tomto pouˇzit´ı je nutné v konfiguraˇcn´ım souboru specifikovat vˇsechny cesty absolutnˇe. Hlavn´ı tˇr´ıda sluˇzby, KIMBridgeDaemon, implementuje rozhran´ı Daemon. Pˇri inicializaci naˇcte konfiguraˇcn´ı soubor, vytvoˇr´ı KIMConnector, KIMBridge a jednotlivé repositáˇre. Stav repositáˇr˚ u je obnoven z binárn´ıho souboru. 41

KIMBridge

Formát konfiguraˇcn´ıho souboru

«interface»

IRepositoryState

«interface»

«interface»

IRepositoryFactory

IDocumentRepository

LinkedInRepositoryState

stores state to and restores state from

LinkedInRepositoryFactory

1

creates 1..*

0..*

1 fetches new posts

creates 1

LinkedInRepository

1

LinkedInConnector

1 maintains 1

PostQueue

addNewPost(post: Post) : PostInfo postUpdated(post: PostInfo) : void cropQueue() : void

1 creates 0..*

LinkedInDocument

«interface»

ITextDocument

1 contains 0..* PostInfo

getId() : String getKimDocumentId() : long setKimDocumentId(docId: long) : void hasNewComments(newPost: Post) : boolean setCommentCountFromPost(newPost: Post) : void

Obrázek 8.5: UML diagram tˇr´ıd LinkedIn repositáˇre. Pˇri spuˇstˇen´ı sluˇzby je spuˇstˇen plánovaˇc, jenˇz periodicky spouˇst´ı u ´lohu definovanou ve tˇr´ıdˇe KIMIndexTask. Ta pˇri svém spuˇstˇen´ı nechá KIMBridge stáhnout a anotovat nové dokumenty. Pˇri ukonˇcen´ı sluˇzby je plánovaˇc zastaven a sluˇzba ukonˇcena. Diagram tˇr´ıd pro sluˇzbu KIMBridge je znázornˇen na obrázku 8.6.

8.3

Form´ at konfiguraˇ cn´ıho souboru

Konfiguraˇcn´ı soubor má nˇekolik sekc´ı. Obsahuje konfiguraci celého KIMBridge, jednotliv´ ych továren repositáˇr˚ u a poté jednotliv´ ych repositáˇr˚ u, ze kter´ ych jsou stahovány nové dokumenty. Základn´ı struktura konfiguraˇcn´ıho souboru je uvedena ve v´ ypise 8.1.

42

KIMBridge


Configurator

SyncStatePersister

1

KIMConnector

1

1

1

1 1

KIMBridgeDaemon

1

1

1

KIMIndexTask

«interface»

«interface»

Daemon

TimerTask

KIMBridge

Obrázek 8.6: Diagram tˇr´ıd sluˇzby KIMBridge. 300 <syncFile>./state.bin

V´ ypis 8.1: Prázdn´ y konfiguraˇcn´ı soubor s v´ ychoz´ım nastaven´ım. Struktura XML dokumentu je rozdˇelena do 3 sekc´ı: configuration – globáln´ı konfigurace KIMBridge, factories – konfigurace jednotliv´ ych továren pro repositáˇre a repositories – konfigurace jednotliv´ ych repositáˇr˚ u. Jednotlivé elementy v sekci configuration pˇredstavuj´ı konfiguraˇcn´ı direktivy. Název elementu odpov´ıdá konfiguraˇcn´ı direktivˇe, text uvnitˇr elementu jej´ı hodnotˇe. Kaˇzdá továrna repositáˇr˚ u má v sekci factories vlastn´ı element. Název elementu je identifikátor továrny a povinn´ y atribut class urˇcuje tˇr´ıdu továrny. Továrna je vytváˇrena pomoc´ı reflexe volán´ım v´ ychoz´ıho konstruktoru bez parametr˚ u. Tˇr´ıda implementuj´ıc´ı továrnu tedy mus´ı m´ıt veˇrejn´ y bezparametrick´ y konstruktor. Jednotlivé elementy uvnitˇr konfigurace továrny pˇredstavuj´ı jej´ı parametry. Pˇr´ıklad konfigurace továren je ve v´ ypise 8.2. V tomto v´ ypise má to43

KIMBridge


várna googleDrive parametr appName s hodnotou KIMBridge. Druhá továrna, linkedIn, nemá ˇza´dné parametry. KIMBridge

V´ ypis 8.2: Pˇr´ıklad konfigurace továren. V sekci repositories jsou pak definovány jednotlivé repositáˇre, které maj´ı b´ yt vytvoˇreny pomoc´ı továren. Název elementu je opˇet identifikátor repositáˇre, atribut type urˇcuje název továrny, pomoc´ı n´ıˇz má b´ yt dan´ y repositáˇr vytvoˇren. Vnitˇrn´ı elementy jsou opˇet parametry repositáˇre. Pˇr´ıklad je uveden ve v´ ypise 8.3. 123456 654321

V´ ypis 8.3: Pˇr´ıklad konfigurace repositáˇr˚ u. Ve v´ ypise jsou definovány celkem 3 repositáˇre. Repositáˇr drive bude vytvoˇren továrnou, která byla ve v´ ypise 8.2 definována v elementu googleDrive. Repositáˇre group1 a group2 budou vytvoˇreny továrnou linkedIn a kaˇzd´ y má jako sv˚ uj jedin´ y parametr ID skupiny, z n´ıˇz budou stahovány diskuzn´ı pˇr´ıspˇevky. Pˇri spuˇstˇen´ı z pˇr´ıkazové ˇrádky program vyhledává konfiguraˇcn´ı soubor config.xml ve svém pracovn´ım adresáˇri. Pˇri spuˇstˇen´ı jako sluˇzby je nutné specifikovat celou cestu ke konfiguraˇcn´ımu souboru jako prvn´ı parametr sluˇzby.

44

9 KIM-OWLImport KIM-OWLImport je nástroj, jenˇz dovoluje doplnit jiˇz existuj´ıc´ı ontologii tak, aby bylo moˇzné ji pouˇz´ıt v KIM Platform. Typicky se jedná o doplnˇen´ı triplet˚ u, které jednotlivé entity oznaˇcuj´ı jako vytvoˇrené d˚ uvˇeryhodn´ ym zdrojem. Nástroj je ale navrˇzen´ y tak, aby jej ˇslo pozdˇeji rozˇs´ıˇrit o dalˇs´ı pravidla, jeˇz umoˇzn´ı extrakci informac´ı z jiˇz existuj´ıc´ı ontologie a vytvoˇren´ı ontologie nové, která bude odpov´ıdat struktuˇre, jiˇz pouˇz´ıvá KIM Platform. Nástroj má grafické uˇzivatelské rozhran´ı, v nˇemˇz je moˇzné pˇridávat ontologie z r˚ uzn´ ych zdroj˚ u. Pro jednotlivé ontologie pak lze definovat sadu pravidel, která budou na ontologii aplikována. Struˇcná uˇzivatelská dokumentace je k dispozici v pˇr´ıloze E. Grafické rozhran´ı i uˇzivatelská dokumentace pouˇz´ıvaj´ı Farm-Fresh Web Icons1 od spoleˇcnosti FatCow Web Hosting, které jsou dostupné zdarma pod licenc´ı Creative Commons Attribution 3.0.

9.1

Anal´ yza

Aby ontologie mohla b´ yt pouˇzita v KIM Platform, je nutné s n´ı provést následuj´ıc´ı kroky: 1. Doplnit pro jednotlivé entity vlastnost protons:generatedBy, jej´ıˇz hodnotou bude d˚ uvˇeryhodn´ y zdroj (instance tˇr´ıdy protons:Trusted). Je moˇzné pouˇz´ıt nˇekter´ y z jiˇz pˇreddefinovan´ ych zdroj˚ u v KIM Platform, nebo tento zdroj vytvoˇrit. 2. Vˇsechny tˇr´ıdy musej´ı b´ yt potomky protons:Entity, pˇr´ıpadnˇe nˇekteré konkrétnˇejˇs´ı tˇr´ıdy (protont:Object, protont:Person, protont:Organization, nebo protont:Location). Pro tˇr´ıdy, které tvoˇr´ı koˇreny hierarchie a nemaj´ı tedy v rámci ontologie definovanou rodiˇcovskou tˇr´ıdu, je nutné tuto vazbu doplnit. Pˇri automatickém doplnˇen´ı je moˇzné pouˇz´ıt obecn´ y protont:Object. 3. Aby se jednotlivé tˇr´ıdy a jejich vlastnosti zobrazovaly v nab´ıdkách webového rozhran´ı, musej´ı m´ıt v souboru visibility.nt uvedenou vlastnost kimso:visibilityLevel1.2 Pro vˇsechny definované tˇr´ıdy a vlastnosti je proto nutné záznamy do tohoto souboru vygenerovat. 1 2

http://www.fatcow.com/free-icons http://www.ontotext.com/kim/2006/05/kimso#visibilityLevel1

45

KIM-OWLImport

Analýza

Základn´ım formátem, jenˇz mus´ı nástroje pracuj´ıc´ı s ontologiemi v jazyce OWL3 podporovat, je RDF/XML. Do tohoto formátu lze také ontologie pˇrevést z libovolného jiného formátu, kter´ y uvád´ı specifikace [32]. S ontologiemi by tedy bylo moˇzné pracovat jako s libovoln´ ym XML dokumentem. Tento pˇr´ıstup by vˇsak byl pomˇernˇe obt´ıˇzn´ y a implementaˇcnˇe nároˇcn´ y. Pro jazyk Java existuje celá ˇrada knihoven, které práci s ontologiemi (a obecnˇe RDF) usnadˇ nuj´ı. Umoˇzn ˇuj´ı jednotlivé ontologie naˇc´ıst do pamˇeti a pracovat s nimi jako s grafem: iterovat nad jednotliv´ ymi triplety, vyhledávat triplety odpov´ıdaj´ıc´ı danému vzoru a provádˇet SPARQL dotazy. Jedná se napˇr´ıklad o knihovny Jena a Sesame, jeˇz uˇz byly zm´ınˇeny v souvislosti se sémantick´ ymi repositáˇri. S vyuˇzit´ım tˇechto knihoven bude moˇzné celou ontologii naˇc´ıst do pamˇeti a pomoc´ı SPARQL dotaz˚ u CONSTRUCT pak jednotlivé triplety, které musej´ı b´ yt do ontologie doplnˇeny, vygenerovat. Tˇr´ıdy a jejich vlastnosti jsou také definovány jako triplety, proto se lze dotazovat i nad hierarchi´ı tˇr´ıd. Pomoc´ı SPARQL dotaz˚ u pak také bude moˇzné transformovat ontologie s r˚ uzn´ ymi strukturami tˇr´ıd a instanc´ı tak, aby je ˇslo pouˇz´ıt i v KIM Platform. V tuto chv´ıli vˇsak nen´ı k dispozici ˇza´dná ontologie, která by poskytovala potˇrebná kl´ıˇcová slova, proto jsou definována jen pravidla pro vytváˇren´ı doplˇ nuj´ıc´ıch triplet˚ u. Pro pouˇzit´ı v nástroji KIM-OWLImport byl vybrán sémantick´ y repositáˇr OWLIM-Lite, jenˇz je dostupn´ y zdarma. Uchovává data primárnˇe v pamˇeti a na disk jsou ukládána aˇz dodateˇcnˇe. Ukládán´ı je vˇsak moˇzné vypnout v konfiguraci repositáˇre. K repositáˇri je zajiˇstˇen pˇr´ıstup pomoc´ı API, které poskytuje Sesame. Kromˇe SPARQL podporuje také vlastn´ı dotazovac´ı jazyk SeRQL. Ten poskytuje podobné moˇznosti jako jazyk SPARQL, avˇsak jeho syntaxe se v´ıce podobá jazyku SQL a je tedy pro vˇetˇsinu v´ yvojáˇr˚ u srozumitelnˇejˇs´ı. Kompletn´ı popis jazyka je k dispozici v dokumentaci Sesame [29].

9.1.1

SeRQL dotazy

V´ yˇse zm´ınˇené operace s ontologi´ı je moˇzné doc´ılit pomoc´ı následuj´ıc´ıch dotaz˚ u: Doplnˇ en´ı protons:generatedBy CONSTRUCT DISTINCT {Entity} protons:generatedBy {_sourceUri} FROM {Entity} rdf:type {Type}, {Type} sesame:directType {ClassType} 3

Plat´ı pro obˇe verze – OWL 1 i OWL 2.

46

KIM-OWLImport

Analýza

WHERE ClassType = owl:Class USING NAMESPACE protons =

Dotaz najde vˇsechny entity, jejichˇz typ je pˇr´ımou instanc´ı (sesame:directType) typu owl:Class. Pokud by nebyla pouˇzita podm´ınka pˇr´ımé instance, zahrnoval by v´ ystup i definice vlastnost´ı, které maj´ı omezen´ı kardinality nebo hodnoty, protoˇze tˇr´ıda owl:Restriction je podtˇr´ıdou owl:Class. Pro nalezené entity vygeneruje triplet ve tvaru uvedeném v klauzuli CONSTRUCT. Za parametr _sourceUri je nutné doplnit URI instance d˚ uvˇeryhodného zdroje. Doplnˇ en´ı rodiˇ covsk´ e tˇ r´ıdy protont:Object ke koˇ ren˚ um hierarchie tˇ r´ıd CONSTRUCT {Class} rdf:type {_protontObj} FROM CONTEXT _context {Class} rdf:type {ClassType}; [sesame:directSubClassOf { Super}] WHERE ClassType = owl:Class AND NOT BOUND(Super)

Dotaz vybere vˇsechny tˇr´ıdy, jeˇz v kontextu _context nemaj´ı definovanou ˇzádnou rodiˇcovskou tˇr´ıdu – nepovinná vazba sesame:directSubClassOf na tˇr´ıdu Super nebude naplnˇena. Vˇsechny definované tˇr´ıdy jsou implicitnˇe podtˇr´ıdami owl:Thing, proto je nutné omezit kontext. Vygenerov´ an´ı visiblity.nt CONSTRUCT {Class} kimso:visibilityLevel1 "" FROM CONTEXT _context {Class} sesame:directType {ClassType} WHERE ClassType = owl:Class OR ClassType = owl:ObjectProperty OR ClassType = owl:DatatypeProperty USING NAMESPACE kimso =

Dotaz vygeneruje pro vˇsechny tˇr´ıdy a vlastnosti definované v kontextu _context triplet s predikátem kimso:visibilityLevel1.

9.1.2

Uloˇ zen´ı v´ ystupu

V´ ystup z v´ yˇse uveden´ ych dotaz˚ u je moˇzné uloˇzit opˇet pomoc´ı Sesame API. To poskytuje tˇr´ıdy pro zápis jednotliv´ ych triplet˚ u v r˚ uzn´ ych formátech. 47

KIM-OWLImport

Popis implementace

Problémem pˇri uloˇzen´ı v´ ystupu z nˇekolika dotaz˚ u mohou b´ yt jmenné prostory. Formáty zaloˇzené na XML (napˇr´ıklad RDF/XML) vyuˇz´ıvaj´ı pro simulaci jmenn´ ych prostor˚ u XML entit, které mohou b´ yt definovány pouze na zaˇcátku dokumentu v deklaraci DOCTYPE. To m˚ uˇze b´ yt problém, pokud by jednotlivé dotazy pouˇz´ıvaly r˚ uzné jmenné prostory. Bylo by nutné nejprve vykonat vˇsechny dotazy, zapsat vˇsechny jmenné prostory najednou a teprve poté zapsat v´ ysledky dotaz˚ u. Pro proudov´ y zápis jednotliv´ ych v´ ysledk˚ u je vhodnˇejˇs´ı formát, jenˇz nemá ˇzádné omezen´ı na um´ıstˇen´ı deklarace jmenného prostoru. Takov´ ymi formáty jsou N3 a Turtle. Pro KIM-OWLImport byl zvolen formát Turtle, jehoˇz specifikace je ve vyspˇelejˇs´ım stádiu.4

9.2

Popis implementace

Diagram nejd˚ uleˇzitˇejˇs´ıch tˇr´ıd a rozhran´ı programu KIM-OWLImport jsou znázornˇeny na obrázku 9.1. GUI 1

1

1

1

SourceManager

RepositoryManager

1

RuleManager

1 creates and shutdowns 1..*

creates

«interface»

RepositoryWrapper

imported to

IRuleFactory queries

1..* «interface»

ISourceFactory

creates

creates AbstractSource 1

AbstractRule

exported by

1..*

Obrázek 9.1: UML diagram základn´ıch tˇr´ıd a rozhran´ı programu KIMOWLImport. Podrobnˇejˇs´ı UML diagram d˚ uleˇzit´ ych tˇr´ıd a vztah˚ u mezi nimi je v pˇr´ıloze D. Jednotlivé soubory s ontologiemi jsou naˇc´ıtány do sémantick´ ych repositáˇr˚ u. Vytváˇren´ı tˇechto repositáˇr˚ u zajiˇst’uje tˇr´ıda RepositoryManager. Kaˇzd´ y 4

Specifikace form´ atu Turtle [3] je ve stádiu Candidate Recommendation, oproti tomu specifikace N3 [2] je pouze ve stádiu Team Submission a zat´ım nebyla zaˇrazena mezi ofici´ aln´ı specifikace W3C.

48

KIM-OWLImport

Popis implementace

vytváˇren´ y repositáˇr mus´ı m´ıt vlastn´ı konfiguraci. Sesame (t.j. i OWLIM-Lite) jsou konfigurovány pomoc´ı RDF grafu. ˇ Sablona tohoto grafu je uloˇzena mezi zdrojov´ ymi soubory v souboru repository/config/owlim.ttl. Pˇri vytváˇren´ı repositáˇre je nutné do ˇsablony dosadit pouze jeho název, ostatn´ı parametry mohou b´ yt spoleˇcné pro vˇsechny repositáˇre. Konfigurace v ˇsablonˇe napˇr´ıklad vyp´ıná ukládán´ı dat v repositáˇri na disk a vyp´ıná odvozován´ı nad naˇctenou ontologi´ı. Popis jednotliv´ ych konfiguraˇcn´ıch direktiv je k dispozici v dokumentaci k OWLIM-Lite.5 Vytvoˇren´ y repositáˇr je pak k dispozici pomoc´ı obálky RepositoryWrapper. Ta poskytuje metody na import ontologi´ı ze soubor˚ u ve filesystému, import ze zadaného URL a pokládán´ı SeRQL dotaz˚ u. Aby bylo moˇzné ontologii importovat jak ze souboru, tak z URL, je reprezentována abstraktn´ı tˇr´ıdou AbstractSource. Jej´ı vytvoˇren´ı zajiˇst’uje tˇr´ıda realizuj´ıc´ı ISourceFactory. Parametry pro vytvoˇren´ı daného zdroje (URL, cesta k souboru) jsou pˇredávány ve tˇr´ıdˇe implementuj´ıc´ı ISourceParams. Z grafického rozhran´ı zajiˇst’uje nastaven´ı tˇechto parametr˚ u tˇr´ıda ISourceParamsComponent. Vˇsechna tato rozhran´ı a abstraktn´ı tˇr´ıda musej´ı b´ yt pro dan´ y zdroj implementována. Import lokáln´ıch soubor˚ u tak zajiˇst’uj´ı tˇr´ıdy FileSource, FileSourceFactory a FileSourceParams. Konfiguraci z uˇzivatelského rozhran´ı zajiˇst’uje tˇr´ıda FileParamsComponent. Obdobné tˇr´ıdy pak implementuj´ı i naˇc´ıtán´ı ontologie z URL. Vˇsechny zdroje a jejich továrny jsou spravovány tˇr´ıdou SourceManager. Diagram tˇechto tˇr´ıd je znázornˇen na obrázku 9.2. Ke kaˇzdému zdroji m˚ uˇze b´ yt pˇriˇrazeno nˇekolik pravidel, jeˇz zajiˇst’uj´ı vytváˇren´ı nov´ ych triplet˚ u. Architektura je velmi podobná správˇe jednotliv´ ych zdroj˚ u ontologi´ı – pravidla implementuj´ıc´ı AbstractRule jsou vytváˇrena továrnami IRuleFactory. Parametry pravidla jsou reprezentovány tˇr´ıdami implementuj´ıc´ımi rozhran´ı IRuleParams. Konfiguraci parametr˚ u z uˇzivatelského rozhran´ı zajiˇst’uje tˇr´ıda IRuleParamsComponent. Jednotlivé továrny jsou opˇet spravovány tˇr´ıdou RuleManager, pravidla jsou agregována v kolekci zdroje, kterému náleˇz´ı. Oproti zdroj˚ um ontologi´ı nejsou parametry pravidla pouˇz´ıvány pˇri jeho vytváˇren´ı, ale jsou konfigurovány aˇz po jeho vzniku. Pˇri vytváˇren´ı vzniká pouze instance s v´ ychoz´ım nastaven´ım. Metoda getStatements() pravidla provád´ı dotaz na sémantick´ y repositáˇr a vrac´ı v´ ysledek. Jednotlivé triplety jsou uloˇzeny v kolekci implementuj´ıc´ı rozhran´ı Iteration, jeˇz poskytuje Sesame. Ten také poskytuje dalˇs´ı tˇr´ıdy pro 5

https://confluence.ontotext.com/display/OWLIMv53/OWLIM-Lite+ Configuration

49

KIM-OWLImport

Popis implementace

FileSource

SourceManager

FileSource

1 UrlSource

UrlSource

1..*

1..*

1

creates

«interface»

AbstractSource

ISourceFactory

exported by 1..*

imported to uses to create new source

«interface»

queries

RepositoryWrapper

FileParams

ISourceParams

AbstractRule

UrlParams

creates

«interface»

FileParamsComponent

ISourceParamsComponent

UrlParamsComponent

Obrázek 9.2: Diagram tˇr´ıd, které zajiˇst’uj´ı naˇc´ıtán´ı ontologie. filtrován´ı, spojován´ı a skládán´ı tˇechto kolekc´ı, takˇze je moˇzné v rámci jednoho pravidla provést dotaz˚ u v´ıce, pˇr´ıpadnˇe triplety vygenerovat nezávisle na repositáˇri a poté je pˇridat k v´ ysledku dotazu. Tyto tˇr´ıdy jsou opˇet znázornˇeny na obrázku 9.3. RuleManager

RepositoryWrapper

1 queries 1..* creates

«interface»

AbstractRule

IRuleFactory

1

creates for rule configuration

1 «interface»

1

configures

IRuleParamsComponent

1

«interface»

IRuleParams

Obrázek 9.3: Diagram tˇr´ıd, které vytváˇrej´ı a reprezentuj´ı pravidla pro dopln ˇován´ı a transformaci ontologi´ı. KIM-OWLImport poskytuje následuj´ıc´ı pravidla: ExportClassesRule exportuje vˇsechny tˇr´ıdy, jeˇz jsou v ontologii definovány. Slouˇz´ı hlavnˇe ke sluˇcován´ı nˇekolika ontologi´ı do jednoho v´ ysledného souboru. 50

KIM-OWLImport

Popis implementace

ExportInstancesRule exportuje vˇsechny instance, které jsou v ontologii definovány. Aby byla instance exportována, mus´ı b´ yt jej´ı tˇr´ıda definovaná ve stejné ontologii. Nelze exportovat instanci tˇr´ıdy, jej´ıˇz definice je definována v jiné ontologii. Podobnˇe jako pˇredchoz´ı pravidlo slouˇz´ı hlavnˇe ke sluˇcován´ı ontologi´ı. ExportTitleRule exportuje textové popisky instanc´ı. Popisek je vybrán z uˇzivatelem zvolené vlastnosti a je exportován jako vlastnost rdf:label. Toto pravidlo slouˇz´ı jako ukázka transformace ontologi´ı do struktury, jeˇz je pouˇz´ıvána KIM Platform. ProtonAlignRule najde vˇsechny tˇr´ıdy, které nemaj´ı v ontologii definovanou rodiˇcovskou tˇr´ıdu, a vytvoˇr´ı triplet, jenˇz tyto tˇr´ıdy odvozuje od protont:Object. TrustedSourceRule vytvoˇr´ı definici d˚ uvˇeryhodného zdroje a pro vˇsechny entity vygeneruje pravidlo, které je oznaˇc´ı jako vygenerované t´ımto d˚ uvˇeryhodn´ ym zdrojem. Dalˇs´ı pravidla je moˇzné pomˇernˇe snadno nadefinovat. Pro jejich pouˇzit´ı staˇc´ı jejich továrny zaregistrovat do RuleManager. Vykonán´ı pravidel pro jednotlivé ontologie a jejich zapsán´ı do v´ ysledného souboru zajiˇst’uje tˇr´ıda Exporter. Pro zadan´ y seznam ontologi´ı vykoná vˇsechna pravidla a jejich v´ ystupy zap´ıˇse ve formátu Turtle do vybraného souboru. Vygenerován´ı pravidel viditelnosti do souboru visibility.nt provád´ı tˇr´ıda VisibilityGenerator. Dotazem do repositáˇre vygeneruje pro vˇsechny tˇr´ıdy, jeˇz jsou v ontologii definované, seznam triplet˚ u s predikátem kimso: visibilityLevel1 a v´ ysledek uloˇz´ı do uˇzivatelem vybraného souboru ve formátu N-Triple. Diagram tˇr´ıd, které zajiˇst’uj´ı export ontologi´ı, je na obrázku 9.4. Vˇsechny definované ontologie a pravidla je moˇzné uloˇzit ve formátu XML. Vytvoˇren´ı a opˇetovné naˇcten´ı tohoto souboru zajiˇst’uj´ı tˇr´ıdy ProjectWriter a ProjectReader. Mezi uˇzivatelské rozhran´ı a aplikaˇcn´ı a datov´ y model nen´ı vloˇzena ˇza´dná doplˇ nuj´ıc´ı vrstva abstrakce. Formuláˇre vyuˇz´ıvaj´ı layout manager GridLayoutManager od tv˚ urc˚ u IntelliJ. Pro pˇreklad a spuˇstˇen´ı aplikace je tak potˇreba pˇribalená knihovna forms_rt.jar.

51

KIM-OWLImport

Popis implementace

generates visiblity for

1

1..*

AbstractSource 1..*

AbstractRule 1 imported to

queries

1 RepositoryWrapper

exports rules in

queries

Exporter

VisiblityGenerator

Obrázek 9.4: UML diagram tˇr´ıd pro export ontologi´ı.

52

10 Výsledky Funkˇcnost ˇreˇsen´ı je prezentována na dvou ˇca´stech: ovˇeˇren´ı sémantické anotace podle vytvoˇrené ontologie a realizaci vybraného vyhledávac´ıho scénáˇre. Obˇe ˇca´sti byly provedeny jak s testovac´ımi dokumenty, u kter´ ych je pˇredem znám oˇcekávan´ y v´ ysledek, tak se skuteˇcn´ ymi dokumenty, jeˇz byly do KIM Platform nahrány pomoc´ı nástroje KIMBridge.

10.1

S´ emantick´ a anotace

Pro ovˇeˇren´ı funkˇcnosti sémantické anotace byl vytvoˇren testovac´ı textov´ y dokument, kter´ y obsahuje vˇsechny term´ıny z ontologie vˇcetnˇe jejich alias˚ u. Vˇsechny term´ıny byly um´ıstˇeny do jednoduché vˇety, která simuluje okoln´ı text term´ınu. Tento textov´ y dokument byl do KIM Platform nahrán pomoc´ı nástroje populater. Ukázka anotovaného dokumentu je na obrázku 10.1.

ˇ ast anotovaného dokumentu zobrazená ve webovém rozhran´ı Obrázek 10.1: C´ KIM UI. Anotované term´ıny jsou zv´ yraznˇeny tuˇcnˇe. Aˇz na jedin´ y term´ın byla vˇsechna kl´ıˇcová slova správnˇe rozpoznána. Problémem byl term´ın ART2“, kter´ y ve svém názvu obsahuje nˇekolik p´ısmen ” a ˇc´ıslovku. Z term´ınu bylo rozpoznáno pouze ˇc´ıslo, jeˇz bylo oznaˇceno jako ˇc´ıs53

Výsledky

Vyhledáván´ı

lovka, a zbytek term´ınu rozpoznán nebyl. Term´ıny obsahuj´ıc´ı jedno p´ısmeno následované jednou nebo nˇekolika ciframi byly rozpoznány správnˇe. Dále byla spuˇstˇena sluˇzba KIMBridge, jenˇz stahuje dokumenty z Google Drive a diskuze z vybran´ ych skupin na sociáln´ı s´ıti LinkedIn. Ve sluˇzbˇe Google Drive bylo uloˇzeno nˇekolik odborn´ ych publikac´ı, které se t´ ykaj´ı pˇreváˇznˇe ERP komponent. Vˇsechny tyto dokumenty byly anotovány v KIM Platform. Celkem bylo zpracováno 76 z 94 dokument˚ u, u zbyl´ ych dokument˚ u se nepodaˇrilo extrahovat text kv˚ uli dˇr´ıve zm´ınˇené chybˇe v knihovnˇe PDFBox. Pˇr´ıklad anotovaného PDF dokumentu je na obrázku 10.2.

Obrázek 10.2: Anotovan´ y PDF dokument o komponentách P3a a P3b zobrazen´ y ve webovém rozhran´ı KIM UI.

10.2

Vyhled´ av´ an´ı

V rámci ovˇeˇren´ı funkˇcnosti vyhledáván´ı byl realizován 3. vyhledávac´ı scénáˇr ze specifikace poˇzadavk˚ u: Chci naj´ıt diskuzi o metodˇe matching pursuit vy” ˇsetˇruj´ıc´ı existenci P3 komponenty.“ Vyhledávac´ı dotaz tedy bude obsahovat následuj´ıc´ı kl´ıˇcová slova: matching pursuit“, P3“, existence“. ” ” ”

54

Výsledky

Vyhledáván´ı

Pro otestován´ı byla vytvoˇrena sada celkem 15 textov´ ych dokument˚ u. Tyto dokumenty jsou podle obsahu kl´ıˇcov´ ych slov rozdˇeleny do následuj´ıc´ıch 3 skupin: 1. Neobsahuj´ıc´ı ˇza´dná kl´ıˇcová slova dotazu. Ve v´ ysledku vyhledáván´ı by se tyto dokumenty nemˇely objevit. 2. Obsahuj´ıc´ı ˇcást kl´ıˇcov´ ych slov z dotazu, pˇr´ıpadnˇe aliasy entit P3“ ” a matching pursuit“. Tyto dokumenty by do v´ ysledku vyhledáván´ı ” nemˇely b´ yt zahrnuty. 3. Obsahuj´ıc´ı vˇsechna kl´ıˇcová slova z dotazu a aliasy entit P3“ a match” ” ing pursuit“. Vˇsechny tyto dokumenty by mˇely b´ yt zahrnuty do v´ ysledku. Dokumenty byly importovány do KIM Platform pomoc´ı nástroje populater a pˇres webové rozhran´ı byl v sekci Faceted Search“ zadán v´ yˇse uveden´ y ” vyhledávac´ı dotaz. Detail v´ ysledku vyhledáván´ı je na obrázku 10.3.

Obrázek 10.3: Detail v´ ysledku vyhledáván´ı entit P3b“, Matching Pursuit“ ” ” a kl´ıˇcového slova existence“. ” Podle pˇredpokladu byly ve v´ ysledc´ıch vyhledáván´ı zahrnuty jen dokumenty, které obsahovaly vˇsechna kl´ıˇcová slova. Pˇri zadáván´ı dotazu je moˇzné zadávat libovoln´ y alias pro vybranou entitu. Kromˇe entit z ontologie je moˇzné zadat libovolné kl´ıˇcové slovo, které bude vyhledáváno fulltextovˇe. Vyhledávac´ı dotaz byl poloˇzen také na dokumentech importovan´ ych z Goˇ ogle Drive a z diskuz´ı na sociáln´ı s´ıti LinkedIn. Zádn´ y dokument vyˇsetˇruj´ıc´ı existenci P3 komponenty metodou matching pursuit nebyl v dokumentech z Google Drive zahrnut. Pˇri upˇresˇ nován´ı dotazu vˇsak bylo nalezeno nˇekolik dokument˚ u ˇreˇs´ıc´ıch problematiku P3a a P3b komponent.

55

11 Závˇer Prvn´ı ˇca´st práce se zab´ yvá principy a technologiemi sémantického webu. Popisuje pˇredevˇs´ım struktury, které se pouˇz´ıvaj´ı pro definici ontologi´ı v jazyce OWL, a jejich souvislosti se standardy RDF a RDF Schema. Dále se také zab´ yvá moˇznostmi, jak´ ymi lze sémantická data uchovávat, a jazykem SPARQL, j´ımˇz je moˇzné se na uloˇzená sémantická data dotazovat. Na prvn´ı ˇca´st navazuje pˇrehled u ´loˇziˇst’ sémantick´ ych dat (sémantick´ ych repositáˇr˚ u), které jsou v praxi nejv´ıce rozˇs´ıˇrené a které jsou srovnávané v aktuáln´ıch testech v´ ykonu. Na základˇe vlastnost´ı a jejich pouˇzit´ı v reáln´ ych projektech bylo vybráno u ´loˇziˇstˇe OWLIM a KIM Platform od spoleˇcnosti Ontotext AD. Produkt KIM Patform umoˇzn ˇuje sémantické anotován´ı dokument˚ u na základˇe ontologie, jeˇz je uloˇzena v sémantickém repositáˇri, kter´ y je souˇca´st´ı KIM Platform. V anotovan´ ych dokumentech je moˇzné vyhledávat a d´ıky vyuˇzit´ı term´ın˚ u z ontologie z´ıskat v´ıce relevantn´ı v´ ysledky neˇz v pˇr´ıpadˇe bˇeˇzného fulltextového vyhledáván´ı. Pouˇzitá ontologie mus´ı vycházet z ontologie PROTON a pro plnou funkˇcnost produktu mus´ı splˇ novat nˇekolik dalˇs´ıch podm´ınek. Sémantické anotován´ı vyˇzaduje ontologii, jeˇz obsahuje definice a klasifikaci term´ın˚ u z EEG/ERP domény. Anal´ yzou ontologie, která je v souˇcasnosti pouˇz´ıvaná v EEG/ERP portálu, bylo zjiˇstˇeno, ˇze tato ontologie potˇrebné term´ıny neobsahuje. Ontologie vytváˇrená v´ yzkumnou skupinou v rámci organizace INCF bude dostupná aˇz v pr˚ ubˇehu léta 2013, proto bylo nutné pro ovˇeˇren´ı funkˇcnosti ˇreˇsen´ı vytvoˇrit prototypovou ontologii obsahuj´ıc´ı ˇcást znalost´ı ERP domény. Pro usnadnˇen´ı tvorby ontologie, jeˇz bude splˇ novat poˇzadavky KIM Platform, byl vytvoˇren nástroj KIM-OWLImport. Tento nástroj je schopen naˇc´ıst vybranou ontologii do sémantického repositáˇre v pamˇeti a na základˇe definovan´ ych pravidel ontologii doplnit tak, aby ji bylo moˇzné pouˇz´ıt pro sémantické anotován´ı. Pro import dokument˚ u do KIM Platform byl vytvoˇren program KIMBridge. Ten bˇeˇz´ı jako sluˇzba na serveru a periodicky stahuje nové dokumenty z vybran´ ych zdroj˚ u dat. KIMBridge podporuje stahován´ı PDF dokument˚ u z Google Drive a stahován´ı textu diskuz´ı na sociáln´ı s´ıti LinkedIn. Staˇzené dokumenty jsou anotovány a indexovány v KIM Platform. Následné vyhledáván´ı je umoˇznˇeno d´ıky webovému rozhran´ı, které je souˇcást´ı KIM. Funkˇcnost vyhledáván´ı byla ovˇeˇrena na testovac´ı sadˇe dokument˚ u i na nˇekolika odborn´ ych publikac´ıch o neuroinformatickém v´ yzkumu. V rámci práce tak bylo nasazeno a otestováno komplexn´ı ˇreˇsen´ı pro sé56

Závˇer

mantické anotován´ı a vyhledáván´ı odborn´ ych dokument˚ u a diskuz´ı na socia´ln´ıch s´ıt´ıch. Toto ˇreˇsen´ı odpov´ıdá poˇzadavk˚ um v´ yzkumné skupiny, a proto byl c´ıl práce splnˇen. V rámci dalˇs´ıho v´ yvoje je nutné nahradit prototypovou ontologii ontologi´ı, jeˇz bude obsahovat vˇetˇs´ı mnoˇzstv´ı kl´ıˇcov´ ych term´ın˚ u z EEG/ERP domény. Jako základ této ontologie je moˇzné pouˇz´ıt ontologii vznikaj´ıc´ı v rámci organizace INCF. Pro automatizovan´ y pˇrevod libovolné ontologie do struktury, která odpov´ıdá ontologii PROTON a kterou vyˇzaduje KIM Platform, je moˇzné pouˇz´ıt nástroj KIM-OWLImport. Ten je snadno rozˇsiˇriteln´ y o dalˇs´ı pravidla a m˚ uˇze se tak stát plnohodnotn´ ym transformaˇcn´ım nástrojem.

57

Seznam pouˇ zit´ ych zkratek API ASP BSBM EEG ERP GNU GPL HTML INCF LUBM MIME NIF NLP OUBM OWL PHP REST RDF RMI SOAP SPARQL SQL URI VSP WAR XML XSD

Application Programming Interface Active Server Pages Berlin SPARQL Benchmark Elektroencefalogram Event-Related Potentials GNU’s Not Unix! General Public License HyperText Markup Language International Neuroinformatics Coordinating Facility Lehigh University Benchmark Multipurpose Internet Mail Extensions Neuroscience Information Framework Natural Language Processing Ontology Benchmark Web Ontology Language PHP: Hypertext Preprocessor Representational State Transfer Resource Description Framework Remote Method Invocation Simple Object Access Protocol SPARQL Protocol and RDF Qury Language Structured Query Language Uniform Resource Identifier Virtuoso Server Pages Web application ARchive Extensible Markup Language XML Schema Definition Language

58

Literatura [1] BECKETT, D. RDF/XML Syntax Specification (Revised). Recommendation, W3C, u ńor 2004. Dostupné z: http://www.w3.org/TR/2004/ REC-rdf-syntax-grammar-20040210/. [2] BECKETT, D. – GRANT, J. RDF Test Cases. Recommendation, W3C, u ńor 2004. Dostupné z: http://www.w3.org/TR/2004/ REC-rdf-testcases-20040210/. [3] BECKETT, D. et al. Turtle: Terse RDF Triple Language. Candidate Recommendation, W3C, u ńor 2013. Dostupné z: http://www.w3.org/ TR/2013/CR-turtle-20130219/. [4] BELLEAU, F. et al. Bio2RDF: Towards a mashup to build bioinformatics knowledge systems. Journal of Biomedical Informatics. 2008, 41, 5, s. 706 – 716. Dostupné z: http://www.sciencedirect.com/science/ article/pii/S1532046408000415. [5] BERNERS-LEE, T. – CONNOLLY, D. Notation3 (N3), A readable RDF syntax. Team Submission, W3C, bˇrezen 2011. Dostupné z: http: //www.w3.org/TeamSubmission/2011/SUBM-n3-20110328/. [6] BIZER, C. – SCHULTZ, A. BSBM V3 Results. Technical report, Freie Universität Berlin, u ńor 2011. [7] BIZER, C. et al. DBpedia: Querying Wikipedia like a Database, kvˇeten 2007. 16th International World Wide Web Conference Developers Track presentation. Dostupné z: http://wifo5-03.informatik. uni-mannheim.de/bizer/pub/DBpedia-WWW2007-draft-slides.pdf. [8] Google Drive API Reference. Google Inc., 2013. [cit. 3. 4. 2013]. Dostupné z: https://developers.google.com/drive/v2/reference/. [9] GUHA, R. V. – BRICKLEY, D. RDF Vocabulary Description Language 1.0: RDF Schema. Recommendation, W3C, u ńor 2004. Dostupné z: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. 59

LITERATURA

LITERATURA

[10] HARRIS, S. – SEABORNE, A. SPARQL 1.1 Query Language. Recommendation, W3C, bˇrezen 2013. Dostupné z: http://www.w3.org/TR/ 2013/REC-sparql11-query-20130321/. [11] HICKSON, I. HTML Microdata. Technical Draft, W3C, ˇr´ıjen 2012. Dostupné z: http://www.w3.org/TR/2012/WD-microdata-20121025/. [12] HICKSON, I. et al. Microdata to RDF: Transformation from HTML+Microdata to RDF. Interest Group Note, W3C, ˇr´ıjen 2012. Dostupné z: http://www.w3.org/TR/2012/ NOTE-microdata-rdf-20121009/. [13] HIRSCH, F. et al. XML Signature Syntax and Processing (Second Edition). Recommendation, W3C, ˇcerven 2008. Dostupné z: http: //www.w3.org/TR/2008/REC-xmldsig-core-20080610/. [14] KIRYAKOV, A. et al. Semantic Annotation, Indexing, and Retrieval. In 2nd International Semantic Web Conference. Springer-Verlag Berlin Heidelberg, 2003. Dostupné z: http://www.ontotext.com/sites/ default/files/publications/SemAIR_ISWC169.pdf. [15] KOIVUNEN, M.-R. – MILLER, E. W3C Semantic Web Activity [online]. 2001. [cit. 30. 3. 2013]. Dostupné z: http://www.w3.org/2001/ 12/semweb-fin/w3csw. ¨ [16] KROTZSCH, M. et al. OWL 2 Web Ontology Language Primer. W3C Recommendation, W3C, prosinec 2012. http://www.w3.org/TR/2012/REC-owl2-primer-20121211/. [17] REST API – LinkedIn Developer Network. LinkedIn Corporation, 2013. [cit. 3. 4. 2013]. Dostupné z: http://developer.linkedin.com/rest. [18] Throttle Limits – LinkedIn Developer Network. LinkedIn Corporation, 2013. [cit. 3. 4. 2013]. Dostupné z: http://developer.linkedin.com/ documents/throttle-limits. [19] LUCK, S. J. An Introduction to the Event-Related Potential Technique. Cambridge, MA : MIT Press, 1st edition, 2005. ISBN 978-0262621960. [20] MARKVART, F. EEG/ERP portál – transformace do sémantického webu. Bakaláˇrská práce, Západoˇceská univerzita v Plzni, Plzeˇ n, 2011. [21] MILLER, E. – MANOLA, F. RDF Primer. Recommendation, W3C, u ńor 2004. Dostupné z: http://www.w3.org/TR/2004/ REC-rdf-primer-20040210/. 60

LITERATURA

LITERATURA

[22] Ontotext AD. The National Archives: Semantic Knowledge Base [online]. [cit. 21. 10. 2012]. Dostupné z: http://www.ontotext.com/case/ nationalArchives-skb. [23] KIM 3.6 Documentation. Ontotext AD, 2013. [cit. 30. 3. 2013]. Dostupné z: https://confluence.ontotext.com/display/Kim36Docs. [24] Ontotext AD. Semantic Repository [online]. [cit. 31. 3. 2013]. Dostupné z: http://www.ontotext.com/semantic-repository. [25] Ontotext AD. KIM Platform: Knowledge Base Statistics [online]. listopad 2011. [cit. 21. 10. 2012]. Dostupné z: http://www.ontotext.com/ sites/default/files/kim/KB_statistics.pdf. [26] OpenLink Software. Virtuoso Universal Server - Feature Comparison Matrix [online]. [cit. 21. 10. 2012]. Dostupné z: http://virtuoso. openlinksw.com/features-comparison-matrix/. [27] RAYFIELD, J. Sports Refresh: Dynamic Semantic Publishing [online]. 17. 4. 2012. [cit. 21. 10. 2012]. Dostupné z: http://www.bbc.co.uk/ blogs/bbcinternet/2012/04/sports_dynamic_semantic.html. [28] Sesame User Guide: rdf:about Sesame 2. Sesame developers, 2012. [cit. 21. 10. 2012]. Dostupné z: http://www.openrdf.org/doc/sesame2/ users/ch01.html. [29] Sesame User Guide: The SeRQL query language (revision 3.1). Sesame developers, 2012. [cit. 4. 4. 2013]. Dostupné z: http://www.openrdf. org/doc/sesame2/users/ch09.html. [30] W3C. Vocabularies [online]. [cit. 30. 3. 2013]. Dostupné z: http://www. w3.org/standards/semanticweb/ontology. [31] OpenLink Virtuoso – Semantic Web Standards wiki [online]. 2012. [cit. 21. 10. 2012]. Dostupné z: http://www.w3.org/2001/sw/wiki/ OpenLink_Virtuoso. [32] W3C OWL Working Group. OWL 2 Web Ontology Language Document Overview (Second Edition). W3C Recommendation, W3C, prosinec 2011. Dostupné z: http://www.w3.org/TR/2012/ REC-owl2-overview-20121211/.

61

Pˇ r´ılohy

62

A Ontologie EEG/ERP komponent

63

B Ontologie metod zpracován´ı sign´ alu ˇ Autorem seznamu metod, jejich rozˇclenˇen´ı a grafu je Ing. Tomáˇs Rond´ ık.

64

65

Configurator

1

1

1

1

1

1

1

1

1

1..*

1..*

AbstractConfiguration

FactoryConfiguration

1

1

RepositoryConfiguration

KIMConnector

creates, annotates, and stores

KIMBridgeDocument(kimDocument: KIMDocument)

KIMBridgeDocument

IRepositoryFactory

«interface»

1..*

creates and configures

1

RepositoryConfigurator(config: Configurator) initializeRepositories(bridge: KIMBridge) : void

RepositoryConfigurator

1

registers repositories

creates

1 uploads documents to 1

KIMBridge

0..*

«interface»

getId() : long isNew() : boolean getTitle() : String

IDocument

«interface»

0..*

creates

1

getId() : String getNewDocuments() : List documentIndexed() : void getState() : IRepositoryState setState(state: IRepositoryState) : void

IDocumentRepository

1..*

fetches documents from

1

«interface»

persists

getExtension() : String getData() : byte[]

IBinaryDocument

«interface»

getContents() : String

ITextDocument

«interface»

stores state in

IRepositoryState

KIMBridge(connector: KIMConnector, syncState: SyncStatePersister) annotateNewDocuments() : void

1

1

SyncStatePersister(syncFile: File) load() : void restoreState(repositoryId: String) : IRepositoryState storeState(repositoryId: String, repoState: IRepositoryState) : void save() : void

setConfiguration(configuration: FactoryConfiguration) : void createRepository(id: String, configuration: RepositoryConfiguration) : IDocumentRepository

1 loads repository config 1

KIMConnector(host: String, port: int) getDocument(id: long) : KIMBridgeDocument createDocumentFromString(text: String) : KIMBridgeDocument createDocumentFromBinaryData(bytes: byte[], extension: String) : KIMBridgeDocument annotateDocument(document: KIMBridgeDocument) : void storeDocument(document: KIMBridgeDocument) : void synchronizeDocument(document: KIMBridgeDocument) : void removeDocument(document: KIMBridgeDocument) : void updateDocument(id: long, updatedDocument: KIMBridgeDocument) : KIMBridgeDocument

1

loadDefaults() : void load(configStream: InputStream) : void loadFile(configFile: File) : void getFactories() : Map<String, FactoryConfiguration> getRepositories() : Map<String, RepositoryConfiguration>

CorporaAPI

«interface»

DocumentRepositoryAPI

«interface»

SemanticAnnotationAPI

«interface»

KIMService

«interface»

KIMDocument

«interface»

SyncStatePersister

C UML diagram tˇr´ıd v projektu

KIMBridge

D UML diagram tˇr´ıd v projektu KIM-OWLImport RepositoryManager

RepositoryWrapper creates

createRepository(id: String) : RepositoryWrapper getRepository(id: String) : RepositoryWrapper importSource(source: AbstractSource) : void importSources(sources: List) : void close() : void

importFile(file: File, baseUrl: String, context: String) : void importUrl(owlUrl: String, baseUrl: String, context: String) : void executeGraphQuery(query: String, params: Map<String, Value>) : GraphQueryResult close() : void

imports

FileSourceParams

writeSources(sources: List) : void

AbstractSource(srcTitle: String, owlBaseUrl: String) importToRepository(repository: RepositoryWrapper) : void saveLocation(writer: XMLStreamWriter) : void getTitle() : String getBaseUrl() : String addRule(rule: AbstractRule) : void getRules() : List

URLSourceParams

configures

«interface»

Exporter

AbstractSource

loadXml(reader: XMLStreamReader) : void

FileSource

1

0..*

ISourceParams

URLSource

«interface»

ISourceParamsComponent loads and creates

ProjectWriter

provides

save(sources: List) : void

creates «interface»

ISourceFactory

getCreatedClass() : Class createSource(title: String, baseUrl: String, parameters: ISourceParams) : AbstractSource loadParams(reader: XMLStreamReader) : ISourceParams createGuiComponent() : ISourceParamsComponent

1..*

1

1

SourceManager

registerSourceFactory(factory: ISourceFactory) : void getSourceFactories() : List getFactoryFor(className: String) : ISourceFactory addSource(source: AbstractSource) : void getSources() : List loadProject(inputFile: File, rlManager: RuleManager) : void saveProject(outputFile: File) : void

FileSourceFactory populates URLSourceFactory

provides

AbstractRule

initializes configures ProjectReader

load() : List

«interface»

IRuleParamsComponent

«interface»

IRuleParams 1

1

setRuleParams(params: IRuleParams) : void getRuleParams() : IRuleParams createGuiComponent() : IRuleParamsComponent getStatements() : Iteration<Statement, Exception> getSource() : AbstractSource getTitle() : String getGuiComponent() : IRuleParamsComponent saveParams(writer: XMLStreamWriter) : void getRepository() : RepositoryWrapper

saveXml(writer: XMLStreamWriter) : void loadXml(reader: XMLStreamReader) : void creates

«interface»

RuleManager

IRuleFactory 1

uses to create rules registerFactory(factory: IRuleFactory) : void getFactories() : List getFactoryFor(className: String) : IRuleFactory

66

1..* getCreatedClass() : Class createRule(title: String) : AbstractRule loadParams(reader: XMLStreamReader) : IRuleParams

0..*

E Uˇzivatelská dokumentace k KIM-OWLImport Zdrojové kódy KIM-OWLImport jsou k dispozici ve veˇrejném Git repositáˇri: https://github.com/NEUROINFORMATICS-GROUP-FAV-KIV-ZCU/KIM-OWLImport

Program je moˇzné pˇreloˇzit nástrojem ant: ant -f owlimport.xml

Ve sloˇzce out/artifacts/OWLImport_jar bude vytvoˇren spustiteln´ y JAR soubor. Do stejného adresáˇre budou také nakop´ırovány vˇsechny potˇrebné závislosti. Hlavn´ı okno programu (obrázek E.1) je rozdˇeleno do 4 ˇca´st´ı: 1. 2. 3. 4.

Nástrojová liˇsta, seznam ontologi´ı, seznam pravidel aktuálnˇe vybrané ontologie a nastaven´ı právˇe vybraného pravidla.

Obrázek E.1: Hlavn´ı okno programu Práci s programem je moˇzné zaˇc´ıt bud’ naˇcten´ım jiˇz dˇr´ıve vytvoˇreného projektu tlaˇc´ıtkem Load Project, nebo rovnou pˇridán´ım ontologie tlaˇc´ıtkem Import OWL. Pˇri importu OWL souboru (obrázek E.2) je nutné zadat název ontologie (bude pouˇzit v nab´ıdkách a pro vygenerován´ı URL d˚ uvˇeryhodného zdroje entit), základn´ı URL ontologie a vybrat jej´ı typ. V souˇcasné verzi je podporováno pˇridáván´ı soubor˚ u uloˇzen´ ych na disku a ontologi´ı dostupn´ ych pˇres s´ıt’ pomoc´ı protokolu HTTP. 67

Uˇzivatelská dokumentace k KIM-OWLImport

Ontologie m˚ uˇze b´ yt uloˇzená v jednom z následuj´ıc´ıch formát˚ u:

RDF/XML, OWL/XML, Turtle, N-Triples a Notation-3 (N3).

V pˇr´ıpadˇe lokáln´ıho souboru i ontologie um´ıstˇené na webu je nutné, aby soubor mˇel pˇr´ıponu odpov´ıdaj´ıc´ı danému formátu.

Obrázek E.2: Import ontologie. Pˇridaná ontologie se objev´ı v seznamu ontologi´ı. Jej´ım vybrán´ım v seznamu je moˇzné definovat pravidla pro export ˇci transformaci ontologie pomoc´ı tlaˇc´ıtka Add Rule. Pˇri pˇridáván´ı pravidla (obrázek E.3) je nutné zadat jeho název, kter´ y bude zobrazen v seznamu, a vybrat typ pravidla. Dalˇs´ı volby konfigurace budou dostupné aˇz po pˇridán´ı pravidla.

Obrázek E.3: Pˇridán´ı pravidla. Po pˇridán´ı pravidla se opˇet objev´ı v seznamu pravidel. Jeho vybrán´ım je moˇzné pravidlo konfigurovat v pravém panelu. Pˇr´ıklad konfigurace pravidla 68

Uˇzivatelská dokumentace k KIM-OWLImport

je znázornˇen na obrázku E.4. Nˇekterá pravidla nemaj´ı ˇza´dné moˇznosti konfigurace. Pro doplnˇen´ı triplet˚ u k ontologii, která jiˇz má strukturu vyˇzadovanou KIM Platform, je nutné pˇridat následuj´ıc´ı pravidla: Generate Trusted Source for All Entities a Align Root Classes to Proton Ontology (pouze pokud jiˇz tˇr´ıdy v ontologii nedˇed´ı od tˇr´ıd definovan´ ych v ontologii Proton).

Pravidla pro transformaci ontologi´ı, jeˇz jeˇstˇe nejsou ve struktuˇre pro KIM, jsou závislá na formátu ontologie a je nutné pro nˇe dodefinovat pravidla programovˇe. Pravidlo je moˇzné odstranit jeho vybrán´ım v seznamu a následn´ ym stiskem tlaˇc´ıtka Remove Rule.

Obrázek E.4: Konfigurace pravidla. Po pˇridán´ı vˇsech ontologi´ı a definici pravidel pro export zb´ yvá jen provést export. Tlaˇc´ıtkem Export lze zahájit k exportu vˇsech pˇridan´ ych ontologi´ı podle k nim definovan´ ych pravidel. V´ ysledn´ y soubor je ve formátu Turtle. Tlaˇc´ıtko Generate Visibility vygeneruje pravidla pro zobrazen´ı tˇr´ıd v ontologii v uˇzivatelském rozhran´ı KIM Platform. Triplety z vytvoˇreného souboru je nutné pˇridat do visibility.nt v datech KIM. Definovaná pravidla je moˇzné uloˇzit k pozdˇejˇs´ımu pouˇzit´ı pomoc´ı tlaˇc´ıtka Save Project. Do v´ ysledného XML souboru jsou uloˇzeny jen cesty k ontologi´ım, soubory proto mus´ı i po opˇetovném otevˇren´ı existovat.

69

F Uˇzivatelská pˇr´ıruˇcka k vyhledáván´ı Dokumenty jsou stahovány z Google Drive a z diskuz´ı v sociáln´ı s´ıti LinkedIn nástrojem KIMBridge. Pro staˇzen´ı dokumentu ve formátu PDF z Google Drive jej staˇc´ı nasd´ılet s uˇzivatelem 380431440078-079h1ai8dhiq3q57ks1og2fuu70f79k4@ developer.gserviceaccount.com. Z LinkedIn jsou stahovány pˇr´ıspˇevky z následuj´ıc´ıch skupin: Brain Pages – Where Professionals And Consumers Meet For Brain Health1 , Brain-Computer Interface group2 , Computational Neuroscience3 , EEG Signal Processing4 a Neurofeedback5 .

Testovac´ı webové rozhran´ı vyhledáván´ı je k dispozici na adrese http:// ´ eeg.kiv.zcu.cz:8080/KIM/. Uvodn´ ı obrazovka obsahuje struˇcné informace o jednotliv´ ych typech vyhledáván´ı a seznam posledn´ıch dokument˚ u. Webové rozhran´ı KIM poskytuje následuj´ıc´ı moˇznosti vyhledáván´ı: Structure search umoˇzn ˇuje vyhledat ve znalostn´ı bázi entity, které spln ˇuj´ı definované podm´ınky. Je moˇzné urˇcit tˇr´ıdu, omezen´ı jednotliv´ ych datov´ ych atribut˚ u ˇci vztahy k jin´ ym entitám. Vyhledáván´ı také umoˇzn ˇuje vyhledat dokumenty, jeˇz obsahuj´ı v´ yskyty entit splˇ nuj´ıc´ıch dané podm´ınky. Tomuto vyhledáván´ı je podobn´ y Pattern serach, kter´ y obsahuje pˇreddefinované podm´ınky a vztahy mezi jednotliv´ ymi entitami, do nichˇz jen uˇzivatel vypln´ı hodnoty, které chce vyhledat. Tyto vzory vyhledáván´ı jsou vˇsak nadefinovány pˇr´ımo ve zdrojov´ ych kódech webové aplikaci a nelze je tedy snadno upravovat. Boolean search umoˇzn ˇuje poloˇzit textov´ y dotaz obsahuj´ıc´ı logické operátory AND a OR. Zadané term´ıny jsou vyhledány v dokumentech fulltextov´ ym vyhledáván´ım a aliasy jednotliv´ ych entit nejsou zohlednˇeny. Sekce Ontology zobrazuje ontologii, která je obsaˇzena ve znalostn´ı bázi. Je moˇzné procházet jednotlivé tˇr´ıdy a jejich vlastnosti. 1

http://www.linkedin.com/groups?gid=4166025 http://www.linkedin.com/groups?gid=1103077 3 http://www.linkedin.com/groups?gid=1376707 4 http://www.linkedin.com/groups?gid=959647 5 http://www.linkedin.com/groups?gid=1825465 2

70

Uˇzivatelská pˇr´ıruˇcka k vyhledáván´ı

Structure search

Faceted search umoˇzn ˇuje postupnˇe vyb´ırat ze seznam˚ u jednotlivé entity, jeˇz chceme v dokumentech vyhledávat, a postupnˇe tak zpˇresˇ novat a filtrovat vyhledávac´ı dotaz. Pro uˇzivatele jsou nejuˇziteˇcnˇejˇs´ı sekce Structure search a Faceted search, proto budou nyn´ı rozebrány podrobnˇeji.

F.1

Structure search

Formuláˇr na vyhledáván´ı entit ve znalostn´ı bázi podle zadan´ ych podm´ınek je znázornˇen na obrázku F.1. Umoˇzn ˇuje definovat podm´ınky podobnˇe jako kdybychom skládali SPARQL dotaz.

Obrázek F.1: Formuláˇr pro structure search. Jeho funkci pˇredvedeme na 2 pˇr´ıkladech vyhledáván´ı: vyhledán´ı dokument˚ u, které se t´ ykaj´ı ERP komponent souvisej´ıc´ıch se zpracován´ım jazyka s kladnou polaritou, a vyhledán´ı filtraˇcn´ıch metod zpracován´ı signálu, jeˇz je moˇzné pouˇz´ıt ke korekci baseline.

F.1.1

Vyhled´ an´ı dokument˚ u t´ ykaj´ıc´ıch se vybran´ ych komponent

ERP komponenty v ontologii jsou rozdˇeleny do nˇekolika tˇr´ıd. Tyto tˇr´ıdy pˇredstavuj´ı kategorie. Zaˇcneme v´ ybˇerem Language Related Component“ u po” l´ıˇcka X is an“. T´ım urˇc´ıme typ neznámé entity X. ” Po v´ ybˇeru tˇr´ıdy dostaneme v sekci Attribute restrictions“ moˇznost defi” novat omezen´ı pro jednotlivé vlastnosti entity. ERP komponenty v ontologii maj´ı jedin´ y atribut: polarity“. Ten vybereme v nab´ıdce. V pravé ˇcásti for” muláˇre poté m˚ uˇzeme zadat hodnotu. Pokud bychom tak neuˇcinili, byly by 71


Structure search

vyhledávány pouze komponenty, které maj´ı uvedenou polaritu libovolné hodnoty. Webové rozhran´ı bohuˇzel neum´ı pracovat s omezen´ımi vlastnost´ı, proto nedostaneme na v´ ybˇer seznam hodnot, jak´ ych m˚ uˇze nab´ yvat. Lze vˇsak vybrat operátor starts with“ a následnˇe zadat jen zaˇcátek slova positive“. ” ” Dalˇs´ı moˇzné hodnoty vlastnosti jsou negative“ a variable“. ” ” Vyplnˇen´ y formuláˇr je znázornˇen na obrázku F.2.

Obrázek F.2: Vyplnˇené hodnoty pro vyhledán´ı kladn´ ych komponent souvisej´ıc´ıch se zpracován´ım jazyka. Vyhledán´ı provedeme klepnut´ım na tlaˇc´ıtko Documents“ v odd´ıle Search ” ” for“. V´ ysledek je zachycen na obrázku F.3.

Obrázek F.3: V´ ysledek vyhledáván´ı kladn´ ych komponent souvisej´ıc´ıch se zpracován´ım jazyka.

F.1.2

Vyhled´ an´ı metod zpracov´ an´ı sign´ alu podle zadan´ ych podm´ınek

I metody pro zpracován´ı signálu jsou rozdˇeleny do tˇr´ıd. Pokud chceme vyhledat filtraˇcn´ı metody zpracován´ı, které lze pouˇz´ıt ke korekci baseline, m˚ uˇzeme 72


Structure search

postupovat dvˇema zp˚ usoby: Vybrat pro nezn´ amou entitu X tˇr´ıdu Filter“, jako vztah k neznámé ” entitˇe Y vybrat Method Usage“ a jako název entity Y zvolit baseline ” ” correction“. Vybrat pro nezn´ amou entitu X tˇr´ıdu Signal Processing Method Usa” ge“, jej´ı název zvolit baseline correction“, vztah k entitˇe Y Method“ ” ” a tˇr´ıda entity Y Filter“. ”

V´ ysledky obou dotaz˚ u jsou stejné, budou jen prohozeny entity X a Y. Ve druhém pˇr´ıpadˇe také mus´ıme vybrat v sekci Interested in“ hodnotu X and ” ” Y“, jinak bychom ve v´ ysledku nedostali poˇzadovan´ y seznam metod. Vyplnˇen´ y formuláˇr pro druh´ y zp˚ usob zadán´ı je znázornˇen na obrázku F.4.

Obrázek F.4: Vyhledán´ı metody zpracován´ı signálu podle jej´ıho moˇzného pouˇzit´ı. Vyhledáván´ı metod zaháj´ıme tlaˇc´ıtkem Entities“ v sekci Search for“. Tla” ” ˇc´ıtkem Documents“ bychom opˇet vyhledávali dokumenty, jeˇz obsahuj´ı vy” brané entity. V´ ysledek vyhledáván´ı je zachycen na obrázku F.5.

Obrázek F.5: V´ ysledek vyhledán´ı filtraˇcn´ıch metod zpracován´ı signálu, které je moˇzné pouˇz´ıt ke korekci baseline.

73


F.2

Faceted search

Faceted search

Tento typ vyhledáván´ı umoˇzn ˇuje postupnˇe filtrovat dokumenty, jeˇz obsahuj´ı v´ yskyty zadan´ ych entit a kl´ıˇcov´ ych slov. Hlavn´ı obrazovka vyhledáván´ı je znázornˇena na obrázku F.6. Ve v´ ychoz´ım nastaven´ı umoˇzn ˇuje webové rozhran´ı filtrovat pouze entity typu osoba, organizace a m´ısto. Pro filtraci entit typu ERP Component“ ” a Signal Processing Method“ je nutné v pravém horn´ım rohu klepnout na ” odkaz Options“ a vybrat vlastn´ı kategorie pro filtraci. Moˇzné nastaven´ı je ” znázornˇeno na obrázku F.7. Po nastaven´ı kategori´ı je moˇzné zaˇc´ıt zadávat názvy entit, které chceme v dokumentech vyhledat. V seznamu pod textov´ ym pol´ıˇckem budou viditelné dalˇs´ı entity, jeˇz jsou ve zb´ yvaj´ıc´ıch dokumentech jeˇstˇe obsaˇzeny. Jejich v´ ybˇerem m˚ uˇzeme vyhledáván´ı postupnˇe upˇresˇ novat. V levé ˇca´sti obrazovky je pol´ıˇcko Document keyword filter“. Do nˇej m˚ u” ˇzeme zadat kl´ıˇcová slova, která chceme v dokumentech vyhledávat fulltextovˇe. Pˇr´ıklad v´ ysledku vyhledáván´ı je znázornˇen na obrázku 10.3 v sekci V´ ysledky.

Obrázek F.6: Faceted search.

74


Faceted search

Obrázek F.7: Nastaven´ı kategori´ı pro filtraci.

75

G Instalace sluˇzby KIMBridge Zdrojové kódy KIMBridge jsou k dispozici ve veˇrejném Git repositáˇri: https://github.com/NEUROINFORMATICS-GROUP-FAV-KIV-ZCU/KIMBridge

Program KIMBridge je moˇzné zkompilovat nástrojem ant: ant -f kimbridge.xml

Ve sloˇzce out/artifacts/KIMBridge_jar bude vytvoˇren spusiteln´ y JAR soubor. Do stejné sloˇzky budou také pˇribaleny vˇsechny závislosti potˇrebné pro spuˇstˇen´ı a pˇr´ıklad konfigurace v souboru config.example.xml.

G.1

Spuˇ stˇ en´ı

Pˇred spuˇstˇen´ım sluˇzby KIMBridge je nutné nastavit pˇr´ıstupové kl´ıˇce k API vzdálen´ ych sluˇzeb a nastavit jednotlivé repositáˇre. Konfigurace je popsána v kapitole 8. Sluˇzba se pˇripojuje k instanci KIM Platform na lokáln´ım stroji, proto mus´ı b´ yt nastavena na stroj, kde sluˇzba KIM bˇeˇz´ı. KIMBridge m˚ uˇze bˇeˇzet ve dvou reˇzimech: konzolová aplikace a linuxová sluˇzba. V obou pˇr´ıpadech je nutné sluˇzbu pouˇstˇet s následuj´ıc´ımi parametry, jinak nebude Java RMI dostupné: -Djava.security.manager -Djava.security.policy=security.policy

G.1.1

Konzolov´ a aplikace

Pˇred spuˇstˇen´ım konzolové aplikace je nutné vytvoˇrit konfiguraˇcn´ı soubor config.xml a um´ıstit jej do pracovn´ıho adresáˇre aplikace. Aplikaci je moˇzné spustit pˇr´ıkazem java: java -Djava.security.manager -Djava.security.policy=security.policy -jar KIMBridge.jar

Veˇskeré záznamy o pr˚ ubˇehu synchronizace budou vypisovány do konzole. Bˇeh aplikace je moˇzné ukonˇcit klávesami Ctrl-C.

G.1.2

Linuxov´ a sluˇ zba

Pro spuˇstˇen´ı v reˇzimu linuxové sluˇzby je potˇreba m´ıt nainstalovan´ y nástroj jsvc. V distribuci Debian je k dispozici ve stejnojmenném bal´ıˇcku. Spouˇstˇen´ı a zastavován´ı sluˇzby je moˇzné inicializaˇcn´ım skriptem, kter´ y je pˇriloˇzen ve 76

Instalace sluˇzby KIMBridge

Spuˇstˇen´ı

sloˇzce init.d se sestaven´ ym JAR souborem. Pˇred jeho pouˇzit´ım je nutné nastavit následuj´ıc´ı promˇenné na zaˇca´tku inicializaˇcn´ıho skriptu: KB_HOME – sloˇzka s KIMBridge, JDK_HOME – cesta k instalaci Javy, JSVC – cesta ke spustitelnému souboru jsvc a CONFIG – um´ıstˇen´ı konfiguraˇcn´ıho souboru. Vˇsechny cesty musej´ı b´ yt uvedeny absolutnˇe. Záznamy o bˇehu sluˇzby jsou vypisovány do soubor˚ u kimbridge.out a kimbridge.err.

77

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Recommend Documents