Nyelvtechnológiai alkalmazások integrálása keresőmotor(ok)ba

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "Nyelvtechnológiai alkalmazások integrálása keresőmotor(ok)ba"

Átírás

1 Eötvös Loránd Tudományegyetem Informatikai Kar Nyelvtechnológiai alkalmazások integrálása keresőmotor(ok)ba Dr. Prószéky Gábor egyetemi docens PPKE ITK Orosz György nappali tagozat programtervező matematikus Budapest, 2010.

2 A diplomamunka bekötve kell, hogy tartalmazza a kitöltött és jóváhagyott diplomamunka témabejelentőt. Ennek a lapnak a helyére kell bekötni. * * *

3 3

4 Tartalomjegyzék 1. Bevezetés 7 2. Természetes nyelv és keresők kapcsolata Nyelvi szöveg számítógépes reprezentációja ASCII ISO Windows kódlapok Unicode Természetes-nyelvi feldolgozás Történet Alkalmazások Keresőrendszerek Internetes keresők története Vertikális keresés Nyelvi eszközök keresőrendszerekben A megfelelő keresőrendszer választása Szempontok Vizsgált keresőrendszerek OpenFTS Terrier Lucene Datapark Search Engine Egothor Xapian ht://dig Lemur/Indri

5 3.3. A Lemur és az Indri működése Indexelés Lekérdezés Egyéb alprogramok Nyelvi kereső létrehozása Szótövező modul Lemur, Indri Tövező integrációja Tiltólistás szavak Stopword szűrés az Indriben Szavak választása, megvalósítás Dátumok használata Motiváció Dátumok kategorizálása Dátumkezelés az Indriben Magyar nyelvű dátumok kezelése A megoldás korlátai Mennyiségek használata Motiváció Mennyiségek indexelése, keresése az Indriben Általános megoldás mennyiségek használatára Megoldatlan problémák Szinonimák használata Motiváció Rokon értelmű szavak használata az Indrivel Automatikus szinonimahasználat A megoldás korlátai Az elkészült rendszer értékelése Teljesítmény Indexelési idő Index mérete Lekérdezési idő Relevancia Módszer

6 Mérési eredmények Összefoglalás Köszönetnyilvánítás 54 Függelék 55 Tiltólistás szavak Konfigurációs fájl Felhasználói dokumentáció Fejlesztői dokumentáció Irodalomjegyzék 87 6

7 1. fejezet Bevezetés Az elmúlt két évtizedben az internet elterjedésével a keresőrendszerek népszerűsége hatalmas mértékben növekedett. A világhálón található mérhetetlen információmennyiség használata, mára aligha lehetséges keresők nélkül. Erre az igényre éreztek rá a múlt század végén olyan nemzetközi nagyvállalatok, mint a Google, Yahoo, Microsoft. Az is igaz, hogy a keresők használata a mai ember számára már-már alapvető szükségűvé vált, így a fejlesztő cégek nagy energiát fektetnek ezek használhatóbbá tételére. Az utóbbi néhány évben azt a tendenciát figyelhetjük meg, hogy mind gyakrabban találkozhatunk intelligens eszközökkel a keresések során. Ezen eszközökkel a vállalatok célja az, hogy minél közelebb vigyék a keresőrendszert a felhasználókhoz. Magyarországon is egyre több cég érez potenciális üzleti lehetőséget intelligens keresők fejlesztésében. Ilyen hazai próbálkozás például a PolyMeta, mely a világcégek keresőinek eredményeit aggregálva dolgozik. A fentebb intelligensnek nevezett modulok legtöbbször olyan szoftvert takarnak, melyek a természetes nyelvi megértést segítik. Nyilván az emberi kommunikáció számítógéppel való teljes megértése csak egy távolban lebegő cél a kutatók előtt, de ezek szoftverek jó tulajdonságokkal rendelkezhetnek információ keresési alkalmazásokban. A dolgozattal és a hozzá tartozó programmal a témakiíráshoz kapcsolódó következő feladatot oldottam meg: Vizsgáljuk meg a keresőrendszerek működését, majd azt, hogy általában milyen lehetőségek kínálkoznak a rendszer teljesítményének javítására magyar nyelvű környezetben! Egy választott keresőrendszert egészítsünk ki a Morpho- Logic által rendelkezésre bocsátott szótövezővel és szinonima szótárral, majd vizsgáljuk meg milyen további lehetőségek vannak még a kereső fejlődését tekintve! Készítsük el a rendszer fejlődését segítő eszközöket, majd mérjük meg az így kapott magyar nyelvű kereső eredményességét, teljesítményét! A fenti méréshez szolgáljon alapul az 1994 és 2008 között született parlamenti naplók adatbázisa! 7

8 2. fejezet Természetes nyelv és keresők kapcsolata Ebben a fejezetben áttekintem a nyelvtechnológiával, keresőrendszerekkel, szövegek tárolásával kapcsolatos alapfogalmakat és ezek kapcsolatát.[6] 2.1. Nyelvi szöveg számítógépes reprezentációja A ma használatos számítógépeken futó szoftverek egy dokumentumot karakterek halmazaként kezelik, így egy szöveg reprezentálása is egymást követő karakterek reprezentálásával valósul meg. Nyilván egy természetes nyelven íródott szöveg szerkezete ettől az egyszerű leképezéstől jóval összetettebb, de ezek a struktúrák is kifejezhetőek megfelelően választott karaktersorozatokkal. Ha picit elidőzünk azon, hogy miért éppen egy karakter a tárolás alapegysége, elgondolkodhatunk azon, hogy más reprezentáció is létezhetne (pl.: a nyelv szavainak tárolásával), de ezek nem illeszkednének a digitális számítógép működési elvéhez oly mértékben, mint a jelenlegi. Folytatva a gondolatmenetet: egy dokumentum tárolásának feladata helyett, elegendő egy karakter tárolásának feladatát megoldani. Számítógépeink alapvetően számokkal végzett műveletek végrehajtására képesek, ezért a karakterek is számokként kerülnek tárolásra. Most a karakter alapú dokumentum tárolással kapcsolatos alapfogalmakat fogom áttekinteni.[6, 15]. Karakter A számítógép alapú kommunikáció alapegysége. Egy karakter lehet betű, szám, írásjel vagy egyéb nem látható vezérlőkarakter. A Unicode szabvány definíciója szerint az adat szervezésére, ellenőrzésére vagy megjelenítésére használt elemek halmazának egy tagja. Karakterkészlet Karakterek rendezetlen halmaza. Egy karakterkészlet a gyakorlatban 8

9 úgy szokás megadni, hogy a karakterek nevei mellett annak képi ábrázolását 1, is megjelenítjük. Az is előfordulhat, hogy több különböző karakternek azonos a megjelenése. Karakterkód Minden karakterhez a karakterkészletből hozzárendelünk egy nem negatív egészet, így kapjuk annak kódját. Fontos megjegyezni, hogy ez a leképezés nem feltétlenül monoton. Karakterkódolás Olyan algoritmus, mely karakterkódokhoz oktettek 2 sorozatát rendeli. Az alábbiakban egy szabványt teljesnek fogok nevezni, ha definiál karakterkészletet, karakterkódokat és karakterkódolást is. Az idők során számos módszer alakult ki és terjedt el karakterek reprezentálására. Most áttekinteném a ma legszélesebb körben használatosakat ASCII Ebben a teljes szabványban a használható karakterek halmaza az angol ábécé betűin kívül csak néhány speciális szimbólumból és vezérlőkarakterekből áll. A karakterkészlet összesen 128 jelet tartalmaz, melyekhez a kódolás pontosan egy oktettet rendel. A szabványt a digitális kommunikáció hőskorában fejlesztették ki, amikor az adatátviteli technológiák még korántsem voltak tökéletesek, így az oktettek tárolásakor fennmaradó 1 bitet adatátvitel-ellenőrzési célokra tartották fent. Legnagyobb hiányossága, hogy nem támogatja az angol ábécén kívül eső nemzeti írásjelek használatát. Előnye ugyanakkor, hogy e nyelv használatára hatékony eszközt ad ISO 8859 Az ASCII kódolás gyengeségeinek kiküszöbölését megcélozva jött létre az ISO 8859 szabvány. Ez tekinthető elődje egy bővítésének, mely a korábban ellenőrzésre fenntartott 8. bitet is tárolásra használja, így lehetővé téve 256 karakter tárolását. A nemzeti írásjelek sokfélesége miatt a szabvány 15 variánssal rendelkezik, attól függően, hogy a fennmaradt 128 helyre mely nemzet(ek) különleges szimbólumai kerülnek. Néhány példa: (Latin-1) - nyugat-európai nyelvek támogatása 1 más néven glifa 2 0 és 255 közötti egész szám - használata bájt alapú számítógépek esetén kényelmes, ekkor ugyanis minden oktet egy bájton tárolódhat 9

10 (Latin-2) - közép-európai nyelvek támogatása (magyar is) (Latin-3) - dél-európai nyelvek támogatása A szabvány teljes és kompatibilis elődjével, ami ebben az eseteben azt jelenti, hogy az első 128 egészhez rendelt karakterek megegyeznek mindkét karakterkódolási eljárásban. Hátrányai között említendő egyrészt, hogy használata többnyelvű környezetben nehézkes, másrészről több karakterkódolást is tartalmaz egyes nemzetek karaktereihez ( / ) Windows kódlapok Látva az ASCII hiányosságait a Microsoft is elkészítette saját kiterjesztését. Ez a módszer is teljes, és felülről kompatibilis elődjével. Az előzőekhez hasonlóan csak korlátozott mennyiségű karakter használatát teszi lehetővé. Az eljárás úgynevezett kódlapokból áll, amik arra szolgálnak hogy az ASCII-t egy vagy több nemzet karaktereivel kiegészítve karakterkészletet, karakterkódokat és kódolást definiáljanak. Ezek közül a magyar ábécét teljesen egészében tartalmazó kódlap a CP-1250, a nyugat európai pedig a CP Legnagyobb különbség a 8859 szériához képest, hogy míg az ISO szabvány a értékekhez csak vezérlő karaktereket rendel, addig a kódlapok ezen értékeken nyomtatható karaktereket is tárolnak. Ezzel sajnos elveszti az ISO 8859 szabvánnyal való kompatibilitását. A kódlapok bár széles körben használtak különösen Windows operációs rendszerekben nem képezik egyetlen nemzetközi szabvány részét sem Unicode Az internet megjelenésével, előretörésével szükségessé vált, hogy többnyelvű szövegeket is tudjunk kezelni. Erre az igényre nem adott kielégítő választ egyik korábbi eljárás sem, hiszen lehetőségeik csak néhány nemzet ábécéjének tárolására korlátozódtak. Válaszolva a kor kihívásaira jött létre a Universal Character Set 3, ami a karakterkészlet minden eleméhez karakterkódot rendel. A szabvány 4 folyamatosan bővül és mára már több tízezer jelet tartalmaz. A Unicode szabvány az UCS egy olyan kiterjesztése, mely karakterkódolást is definiál. Ez a kódolás eredetileg az ún. UCS-2 volt, ami fix 2 bájton tárolja a karaktereket. Később a karakterkészlet bővülése során ezt elvetették, és helyette 3 UCS - Általános Karakterkészlet 4 ISO

11 az alábbi négy UTF 5 kódolási algoritmus valamelyike használandó. Itt fontos még megjegyezni, hogy az egyszerűbb implementáció miatt, létezik egy jól körülhatárolt részhalmaza az UCS-nek, amit BMP 6 -nek nevezünk és a 0..FFFF hexadecimális tartományban vannak a kódjai. UTF-32 Minden karakterkód 4 byte-os egészként reprezentálódik, így a jelenleg a szabványba tartozó összes jelet egyszerűen tudjuk kezelni. Hatékonysága viszont messze nem kielégítő, hiszen ha csak egyszerű angol nyelvű szövegekkel dolgozunk, akkor a tárigénye négyszeres az ASCII-hoz képest. UTF-16 A korábban említett UCS-2 kódolás szuperhalmaza, ami azt jelenti, hogy csak a BMP-re korlátozva az UCS-2 kódolást, az UTF-16 ot kapjuk. Az UTF-32 től eltérően ez egy változó hosszúságú kódolás: BMP-beli elemeket 2 byte-on míg a többieket 4 byte-on tárolja. UTF-8 Ez a kódolási eljárás kompatibilis az ASCII-val, tehát a tartományba eső kódokat ugyanúgy tárolja mint elődje, viszont az e fölöttiekre egy kissé bonyolult, de tárolási értelemben hatékony változó hosszúságú leképezést alkalmaz. UTF-7 Olyan változó hosszúságú karakterkódolás, melyben minden karakterkód legalább egy, legfeljebb négy tartományba tartozó oktettel van reprezentálva. Nem kompatibilis az ASCII-val Természetes-nyelvi feldolgozás A természetes-nyelvi feldolgozás 7, az informatika olyan résztudománya, mely természetes nyelvi jelenségeket, problémákat az informatikai oldaláról közelíti meg. 8 A tudományág a mesterséges intelligencia kutatások és nyelvészet határterületén van. A kutatások alapvetően négy területre bonthatóak. Egyrészt beszélhetünk nyelvi elemzésről és generálásról, másrészt pedig a feldolgozás tárgya lehet írott szöveg, vagy maga a beszéd. Egy ettől részletesebb kategorizálást találhatunk a Számítógépes Nyelvészet[5] c. könyvben. 5 Universal Transformation Format 6 Basic Multilingual Plane - Alapvető Többnyelvű Karakterkészlet 7 szakirodalomban NLP - Natural Language Processing 8 11

12 Történet A tudományág gyökerei a második világháború végéhez nyúlnak vissza, amikor is tudósok az akkori számítógépeket a kódtörésen kívül automatikus fordításra is megpróbálták felhasználni. A korai lelkesedésre jellemző, hogy ez időben számos kutatás indult a gépi fordítás témakörében. Ekkoriban sokan még azt az egyszerű nézetet vallották, hogy a nyelvek közötti egyetlen különbség a szókincsük és a mondatok szavainak sorrendje. Így az akkor született megoldások is csak valamiféle automatikus szótározó rendszerek lettek. Mint azt ma már tudjuk, ez az út hamarosan zsákutca lett. Az ezt követő években a korai sikertelenség miatt visszaesett a számítógépes nyelvészet iránti érdeklődés. Ezt a negatív folyamatot erősítette az ALPAC os éves jelentése, mely a gépi fordítás ideájának akkori megvalósulását kétségbevonta. Mindeközben 1957 ben megjelent Chomsky cikke a generatív nyelvtanokról, ami új megvilágításba helyezte a számítástudomány és a nyelvészet viszonyát. Mint említettem a 70 években bár jelentősen csökkent az érdeklődés a téma iránt, de a kutatások teljes egészében nem álltak le. Az ekkoriban folyó tudományos munkák elsősorban jelentés reprezentációra és a számítástudomány világába a korábbiaktól jobban illeszkedő elméletek kidolgozására összpontosult. Az elméleti kutatások mellet számos kézzel fogható eredmény is született, úgymint az ELIZA - az első mesterséges beszélgetőrobot, SHRDLU - egy olyan szerkezet, ami képes volt angol nyelvű utasítások megértésére (persze csak korlátozott módon). Az évtized végére és a 80 évek derekára előtérbe került a természetes nyelvi generálás problémaköre is, mint például a nyelvi feldolgozás statisztikai oldalról való megközelítése is. Az elmúlt két évtizedben eddig soha nem látott növekedésnek indult a tudományterület. Ez valószínűleg a megnövekedett számítási kapacitásoknak, az Internet előretörésének és a növekvő mennyiségű elektronikus dokumentumhalmaznak köszönhető. A ma használt szoftverek nagy részének már szerves alkotóját képezik nyelvi megoldások. Úgymint pl.: Google kereső automatikus szótövezés, szinonima keresés, 9 Automated Language Processing Advisory Committee of the National Academy of Science - National Research Council 12

13 Microsoft Office irodai programcsalád nyelvhelyesség ellenörző, szinonima szótár, Mozilla Firefox böngésző helyesírás ellenőrző, Webforditás.hu online, többnyelvű gépi fordító rendszer, A Magyarországon folyó kutatások a 90 évek elején kaptak nagy lendület, amikor is Dr. Prószéky Gábor vezetésével megalakult a MorphoLogic. A cég a kezdetektől fogva nyelvészet kutatásokat és azok gyakorlati alkalmazásait tűzte ki célul. Azóta számos, nap mint nap használt szoftver nyelvi modulját készítették el, továbbá jelentős eredményeket értek el a gépi fordítás és a nyelvi elemzés területen Alkalmazások Ma az informatika területén gyakorlatilag minden olyan feladatnak, problémának, mely szövegekkel dolgozik, célja lehet valamilyen NLP eszköz alkalmazása. A leggyakoribbak ezek közül: Információ visszakeresési alkalmazások Adatbányászati feladatok Kérdés-válasz rendszerek Szöveg kivonatolás Gépi fordítás Párbeszédes rendszerek 2.3. Keresőrendszerek Napjainkban mind többször találkozunk olyan rendszerekkel, programokkal, melyek dokumentumok halmazához férnek hozzá, és ezekhez biztosítanak keresési szolgáltatást. Ilyen esetekben a felhasználótól a rendszer egy keresőkifejezést vár, melyet értelmezve létrehozza az eredmények listáját. Ez a lista dokumentumhivatkozásokat tartalmaz, melyek tartalma a felhasználó szempontjából relevánsnak mondhatóak. Egy keresőrendszer vázlatos felépítése látható a 2.1 ábrán. A vázolt feladat megoldására a legegyszerűbb módszer 13

14 Keresőkifejezés Dokumentumtár és keresőgép Dokumentumlista 2.1. ábra. Keresőrendszer egyszerűsített felépítése az, hogy ha a lekérdezést a rendszer egyszerű string kereső algoritmussal próbálja megoldani végigpásztázva a dokumentumtárat. Ennek időigénye nyilván arányos a tár méretével, ami hatékonyság szempontjából nagyon rossz. Ehelyett az adathalmazt célszerű elő-feldolgozni Indexelésnek hívjuk azt a folyamatot, amikor a keresőrendszer a rendelkezésére álló dokumentumok halmazából létrehoz egy ún. indexet, mely tartalmaz kulcsszavakat és dokumentumhivatkozásokat is. Alapvetően kétféle indexet különböztetünk meg: Kulcsszóindexet, mely létrehozásakor a dokumentumokhoz párosított kulcsszavakat tároljuk az adatbázisban. Tartalomindexet, melyet úgy készítünk, hogy az összes feldolgozandó fájlt végigolvassuk, eközben minden egyes dokumentumnál összegyűjtjük a rá jellemző szavak, kifejezések halmazát, majd ezeket tároljuk az adatbázisban. A gyakorlatban az a jellemző, hogy a két módszert együttesen alkalmazzák. A feldolgozandó dokumentumok halmazát megkaphatjuk a felhasználótól, de gyakori az is, hogy a keresőrendszer egy modulja végzi ennek létrehozását. Ez az alrendszer egy kezdeti dokumentumhalmazban található hivatkozásokat rekurzívan végigjárva igyekszik bővíteni azt. Az ilyen alprogramokat, (web)crawler-nek, spider-nek vagy robot-nak hívjuk. Mint azt korábban említettem egy keresőrendszeren lekérdezéseket futtatni keresőkifejezésekkel lehet. Egy ilyen kifejezés általában nyelvi szavak és speciális karaktersorozatok kombinációja. Az hogy a rendszer milyen típusú kifejezéseket támogat jól jellemzi működését, használhatóságát: Használhatunk-e reguláris kifejezéseket? Szótövezést használ-e? Korlátozhatjuk-e a keresést valamilyen előre megadott típusú adatokra? (mezők használata) 14

15 Szűkíthetjük-e a keresést dátumra, nyelvre, területre? Használhatunk-e logikai műveleteket? (Pl.:AND,OR,NOT... ) Milyen egyéb műveleteket használhatunk még? (Pl.:NEAR) Ezektől kicsit elrugaszkodva, feltehetjük még a kérdést, hogy a lekérdezőnyelv támogatja-e természetes nyelvi kérdések használatát. Használat alatt itt azt értem, hogy a program megpróbálja értelmezni a kérdést, és arra választ találva létrehozni a találati listát. Egy lekérdezés futtatása után a találatok általában rendezett listában jelennek meg. Sok esetben az alkalmazás kigyűjti a keresőkifejezéshez legszorosabban kötődő 10 szavakat is, így tovább finomíthatjuk a találati listánkat. Keresők teljesítményét, hasznosságát több szempont szerint szokás mérni: 1. számítási teljesítmény szerint: (a) indexelési időben óránként feldolgozott adatmennyiség illetve az ehhez szükséges memória mérésével, (b) index mérete a tárolt adat mennyiségének viszonyában. (c) lekérdezés során az eredménylista elkészítéséhez szükséges átlagos idő alapján, 2. indexelt oldalak mennyisége alapján, 3. találati lista alkalmassága alapján. A találati lista értékeléséről a 5. fejezetben írok részletesebben. Újragondolva a keresőrendszer működését, tovább finomíthatjuk a keresőrendszer működését bemutató ábrát. Ezt láthatjuk a 2.2 ábrán Internetes keresők története Az internet hőskorában[13] még csak néhány számítógép volt hálózatba kapcsolva, így ezek nyilvántartása nem okozott különösebb nehézséget. Ezt a feladatot akkoriban Tim Berners-Lee látta el a CERNS szerverét használva. Aztán 1992 ben érkezett el az az időszak, amikor a hálózaton lévő gépeket már nehézkessé vált nyilvántartani. 10 a találatokban a kifejezések egy környezetében leggyakrabban előforduló szavak 15

16 Robot keresőkifejezés dokumentumlista új dokumentum Keresőgép Indexkészítő gép Index Dokumentumtár 2.2. ábra. Keresőrendszer felépítése A következő mérföldkő a történetben Matthew Gray alkalmazása 1993 ból, ami a világ első mai értelemben vett, webrobot-a. Ezzel célja a Web méretének meghatározása volt, amit 1995 ig sikeresen el is látott Az első keresőrendszernek az Aliweb-et nevezhetjük, mely 1993 novemberében tűnt fel. Ez az alkalmazás még csak azt tette lehetővé, hogy a weboldalak gazdái metainformációkat töltsenek fel honlapjukkal kapcsolatban a rendszerbe, amin utána a felhasználók kereséseket futtathattak. Ugyanezen év decemberében jelent meg a JumpStation nevű alkalmazás, aminek a működési elve a mai napig is meghatározó (robot-indexelés-keresés). Sajnos ez még nem volt képes a dokumentumokban való keresésre, csak annak címében tárolt információkkal tudott dolgozni. Az egyik első teljes tudású 11 kereső a WebCrawler volt. Ezzel egy időben jelent meg 11 a szó azon értelmében, hogy a rendszer rendelkezik robottal, indexszel, formon keresztül végezhetünk lekéréseket és a dokumentumok teljes szövegében is képes keresni 16

17 a Lycos, mely már üzleti sikereket is elért. Az ezt követő években számos kereső jelent meg a piacon és tett nagy népszerűségre szert: Magellan, Excite, Infoseek, Inktomi, Altavista... Mindezek között mégis a Yahoo! volt a legnépszerűbb, melynek működése alapvetően különbözött a többitől. A Yahoo! a saját ún. web directory-jában végezte a kereséseket, ugyanakkor lehetőséget biztosított ennek böngészésére is. Az igazi áttörést a versenyben a Google hozta 2000 tájékán, az új eddigiektől különböző relevancia meghatározási algoritmusával, a Pagerankkal. Ez a módszer azon alapszik, hogy a weboldalra mutató külső hivatkozások számával iteratív módon próbáljuk becsülni a felhasználó oldalra jutásának valószínűségét, majd ezt felhasználva rendezzük a találati oldalakat. Ebben az időben a Yahoo! az Inktomi technológiáját használta, majd csak 2003 ban váltott a Google-éra től pedig saját fejlesztésű keresőmotorral működött a Yahoo! Search, egészen a 2009 es Microsofttal kötött szerződésig ban indult útnak a Microsoft első keresője az MSN Search, amely akkor még szintén az Inktomi technológiáját használta. Később a redmondi vállalat az Altavista-ét liszenszelte, majd 2004 ben állt elő sajátjával. Az óriásvállalat 2009 ben indította útjára megújított keresőjét a Bing-et Vertikális keresés A történeti áttekintésben sorra vett keresőrendszerek többsége abból a célból született, hogy az interneten teljes tartalmán biztosítson hatékony keresést. Egy ilyen általános célú kereső sok esetben nem működik hatékonyan, nem ad releváns találatokat. Például, ha csak valamely tudományterület anyagai között szeretnénk keresést végezni, akkor egy általános felhasználású kereső, sok olyan találatot adhat, melyek nem relevánsak. Erre a problémára adott válasza a kor informatikusainak a vertikális keresés módszerének bevezetése. Vertikális keresésről beszélünk akkor, ha a keresés az internet egy szeletén, vagy valamilyen kritérium mentén szűkített dokumentumhalmazon történik. Ez a kritérium leggyakrabban egy témakör, de lehet fájlformátum, dokumentumtípus, stb. is. Napjainkban egyre több vertikális kereső szolgáltatás jelenik meg a weben: Google Books - digitalizált könyvek tartalmában való keresés Google Scholar - tudományos cikkek közötti keresés Árukereső - kereskedelmi termékek közti kereső Budapest Explorer - szórakozóhely kereső 17

18 Használtautó.hu - használt autók keresője Kayak.com - utazás kereső HealthMash - egészségügyi kereső 2.4. Nyelvi eszközök keresőrendszerekben Ahogy azt a részben is írtam, nyelvi eszközök informatikai alkalmazások számos területén jól használhatók. Most szeretnék rövid áttekintést adni arról, hogy melyek azok a módszerek, amelyek leggyakrabban megjelennek egy-egy keresőrendszerben. Mint azt láthattuk az internet hőskorában a keresők sokszor csak a fájlok címében, esetleg a hozzájuk kapcsolt metaadatok között tudtak keresni. A WebCrawler óta már a fájlok tartalmát is látjuk. Ez a korábbiakhoz képest nagy előrelépés, de egy átlagos felhasználónak még mindig nehéz dolga akad, egy olyan csekély tudású rendszerben, ami esetleg csak string-egyezőség alapján ad találatokat. Gondoljunk bele, sokszor mennyire nehéz jó keresőkifejezést találni, hogy az eredmények közt szerepeljen a kívánt információ. Ráadásul számos agglutináló 12 nyelv esetén a feladat még nehezebb, mert ekkor nem elég megtalálni a használandó kulcsszavakat, de a keresést úgy érdemes futtatni, hogy azok toldalékolt alakjaira is rábukkanhassunk. Ezt feladatot szokás szótövezéssel megoldani, mégpedig a következő módon: indexeléskor a rendszer a szavakat, kifejezéseket tövezett alakban tárolja, majd kereséskor a kifejezésben is megkeresi a szavak tövét, végül az így kapott kulcsszavakkal történik a keresés az új indexen. Hasznos funkció még, hogy ha a keresőrendszer - a felhasználó kérésére - lehetőséget biztosít szinonimák keresésére is. Ez a gyakorlatban azt jelenti, hogy a lekérdezés futtatásakor megadott keresőkifejezésben, a megjelölt szavak szinonimáit tartalmazó dokumentumok is megjelenhetnek a találati listában. Angol nyelvterületeken jelentős eredményeket[2] értek még el szókapcsolatok statisztikai felismerésének használatával. A módszer általában a következő: a dokumentumtár dokumentumait megvizsgálva kigyűjtjük azon szó-párakat, melyek nem tartalmaznak tiltólistás szót, majd a leggyakoribbakat felhasználjuk indexelésre is. Így tároljuk azokat a kifejezéseket, melyekről azt feltételezhetjük, hogy kereséskor gyakran előfordulnak, ezzel segítve a nagyobb találati pontosságot. Ezen módszernél az igazi nehézség az, hogy tudnunk kell kezelni, megkülönböztetni olyan keresőkifejezéseket, melyek a szóösszetétel egészére vonatkoznak, csak egy elemére, vagy egyikre sem. Például a Nobel-díj 12 toldalékokat halmozó 18

19 kifejezés esetén, mind a Nobel, mind a díj, mind pedig a Nobel-díj keresőkifejezéseket jónak gondoljuk, míg a New York városnév esetén, csak a New York -ot egyben tartalmazó kifejezésekre szeretnék, ha megjelenne a találatok között az eredeti összetételt tartalmazó dokumentum. Számos nyelv, köztük a magyar is, képes összetett szavak képzésére. Ezeket megfigyelve felmerülhet a kérdés, hogy vajon az összetételek szétválasztásával és egyenkénti tárolásával lehetséges-e növelni a találati pontosságot. A válasz itt sem egyértelmű, hiszen szétválasztással az eredeti szó értelme elveszhet, jelentősen módosulhat. Egyszerű és nem is kifejezetten NLP technika, de gyakran alkalmazott módszer, hogy betűszavak és rövidítések felismerésére tesznek kísérletet. Ezt általában szótárakkal valósítják meg. Nyilván nehéz általános, teljes szótárakat készíteni, viszont vertikális keresőrendszereknél, ahol szűkebb témájú dokumentumokkal dolgozunk, érhetünk el jobb eredményeket. Jelentés egyértelműsítési módszerek célja, hogy a többértelmű szavak szövegkörnyezetbeni jelentését meghatározzuk, és tároljuk. Keresésnél pedig lehetőséget biztosítsunk az ezek közti választásra. Ezekhez általában ún WordNet 13 -et használnak. Gyakori az is, hogy a lekérdezés elindítás után a rendszer további kapcsolódó kulcsszavakat ajánl fel, melyekkel a találati lista mérete csökkenthető. Ezt általában úgy valósítják meg, hogy az indexelt dokumentumokban leggyakrabban előforduló szókapcsolatokat tárolják, majd kereséskor ezt használják fel a javaslatokhoz. Manapság egyre inkább előtérbe kerülnek, olyan technológiák, melyek az indexelt dokumentumokhoz, automatikusan metainformációkat rendelnek. Leggyakrabban a következő tulajdonságokat használják: helyszín, időpont, valamilyen mennyiség (ár, súly mérték, hossz mérték). Ezen mezők tárolásával kereshetővé válnak az említett tulajdonságok, ami ismét csak egy pontosabb találati listához vezethet. Mostanában előtérbe kerültek olyan szolgáltatások, melyek nyelvfüggetlenül tudnak keresést végezni. Ekkor szükséges, hogy a rendszer többféle nyelvű dokumentumokat is indexeljen. Egy ilyen alkalmazás a következő módon működhet: 1. indexeléskor minden fájlhoz tárolják annak nyelvét (nyelveit) 2. keresőkifejezés fordítása több nyelvre 3. keresés futtatása az összes dokumentumon 4. találati lista dokumentumainak forrásnyelvre való fordítása 13 Főneveket, igéket, mellékneveket és határozószókat szervez kognitív szinonima halmazokba (synsetek), amelyeknek mindegyike eltérő fogalmat fejez ki. 19

20 Ilyen például a Google valamint a Webfordítás. Talán a legösszetettebb szolgáltatást azok a keresők nyújtják, melyek a felhasználó áltat megfogalmazott kérdésekre próbálnak választ találni az eredményhalmaz generálásakor. Ez a feladat igen bonyolult, hiszen nem elég a kérdésben megtalálni a kulcsszavakat, a kérdést meg kell érteni a gépnek, hogy válaszolni tudjon rá. Erre tett kísérletet például a Powerset kereső, mely tudásbázisként az angol nyelvű Wikipédia anyagát használja. 20

21 3. fejezet A megfelelő keresőrendszer választása A dolgozat megírásával, célom annak megvizsgálása volt, hogy milyen lehetőségek vannak nyelvi eszközök használatára keresőrendszerekben. Ennek gyakorlati aspektusait is szerettem volna megtapasztalni, ezért munkám végén tervem, hogy egy kész rendszeren méréseket végezzek az eszközök hatékonyságát illetően. A gyakorlati oldalt illetően alapvetően három út állt előttem: Közismert keresőrendszer felhasználása, kiegészítése. Pl.: Google, Bing... Nyílt forráskódú keresőrendszer kiegészítése. Saját rendszer fejlesztése az alapoktól. Egy teljesen új rendszer fejlesztése túlmutatna e dolgozat céljain, lehetőségein. Közismert kereső választása és felhasználása nehéz feladat, mert ezek a rendszerek a legtöbb esetben zárt forráskódúak és alkalmazás-programozási felületük is nagyon korlátozott. Így úgy döntöttem, hogy a nyílt forráskódú rendszerek felé fordulok Szempontok Mielőtt elkezdtem a volna a keresők közötti böngészést és azok tanulmányozását, megfogalmaztam néhány olyan szempontot, melyekről azt gondolom, szükségesek ahhoz, hogy munkámban bármiféle sikert is érjek el. A használandó alkalmazás C++ vagy JAVA nyelven íródjon mivel ezekben szereztem az elmúlt években jártasságot, és a dolgozat készítése során sokkal inkább a 21

22 feladatra, mint egy új nyelv elsajátítására szerettem volna koncentrálni. Ezt a szempontot erősítette az is, hogy a MorphoLogictól kapott nyelvi eszközök is C nyelvű API 1 -val rendelkeznek. Szerettem volna, ha a keresőrendszernek van egy jól meghatározott alkalmazásprogramozási felülete, hogy a fejlesztés során megjelenő esetleges új verziók ne akadályozzák a munkámat. Azért is tartom lényegesnek ezt a kérdést, mert ennek hiánya esetén a kód bővítése nehézkes, a vártnál sokkal több időt igényelhet. Elvártam a programtól, hogy létezzen stabil verziója, és legyen mögötte egy olyan fejlesztői csoport, akik folyamatosan karbantartják. Előnyt élveztek a kiválasztás során azok a programok, melyek már rendelkeztek valamilyen természetes nyelvi feldolgozó eszközzel. Úgy gondolom, hogyha egy keresőben például már van szótövező, akkor egy új tövező integrálásához a létező rendszer implementációja alapján találok útmutatást. A fejlesztéshez szükséges, hogy a projekt jól dokumentált legyen. Fontos, hogy a kiválasztott rendszer jól kezelje a magyar nyelven írott szövegeket, ehhez pedig az szükséges, hogy tudjon kezelni az alábbi karakterkódolások közül legalább egyet: UTF valamelyik típusa, elsősorban UTF-8 ISO WINDOWS CP Vizsgált keresőrendszerek Munkám során igyekeztem a lehető legtöbb rendszert górcső alá vetni. Ezek felkutatásához elsősorban az alábbi dokumentumokat vettem alapul: Emmanuel Eckard és Jean-Cédric Chappelierés - Free Software for research in Information Retrieval and Textual Clustering[4] Christian Middleton és Ricardo Baeza-Yates - A Comparison of Open Source Search Engines[9] 1 Application Programming Interface - Alkalmazás-programozási felület 22

23 OpenFTS Az OpenFTS 2 fejlesztését már 5 éve leállították, továbbá a felhasználói fórumon kívül nem sok dokumentációt találtam. Egységes programozói felületet sem találtam az eszközhöz, így mindezek tekintetében nem is folytattam a vizsgálatot Terrier Ez az keresőrendszer JAVA nyelven íródott, bővíthetőségét biztosíték a jól dokumentált API. A programozási nyelv garantálja az UTF-8 támogatást, tehát a magyar nyelvi szövegek kezelésével sincs probléma. Indexelés folyamán a rendszer egy ún. pipeline 3 -on keresztül dolgozza fel az indexelendő kifejezéseket. Fejlesztése folyamatos, a támogatás biztosított. Szótövező használatára - az említett csővezeték kialakítás miatt - ad lehetőséget, de más nyelvi modulokat nem használ Lucene Lucene egy teljes értékű kereső, mely JAVA nyelven íródott. A Terrierhez hasonlóan a magyar nyelv írásjeleit is tökéletesen kezeli. Jól dokumentált alkalmazás-programozási felülettel rendelkezik. Legfőbb erőssége, hogy jól skálázható és nagy teljesítményű indexelő program biztosítja az adatok gyors feldolgozását. Képes dátumok szerinti keresésre, mezők kezelésére, egyszerre több indexben való keresésre. Többféle lekérdezés típust támogat. A projekt rendkívül jól támogatott, dokumentált. Nyelvi eszközök kapcsán az mondható el róla, hogy többféle szótövezőt és azok integrálását támogatja Datapark Search Engine A Datapark Search egy C nyelven íródott kereső, melynek API-ja csak kis mértékben enged beavatkozni a rendszer működésébe. Ezt is elsősorban olyan esetekben használják, amikor a szoftvert egy komplex programba, vagy weboldalba építik be. Némi dokumentáció is fellelhető a világhálón, de ez korántsem teljes. Több karakterkészletet is támogat, viszont nyelvi eszközökkel csak nehézkesen gyarapítható. Szótövezés csak Aspell illetve 2 Open Source Full Text Search engine 3 csővezeték - mint fogalmat metaforikusan használják a számítástechnikában akkor, amikor több program láncba való összekapcsolása történik. Ilyenkor az egyik elem kimenete a másik elem bemenetére kerül. 23

24 Ispell programokon keresztül valósítható meg, illetve szinonimák és mozaikszavak felismeréséhez csak szótárfájlok használatával van lehetőség Egothor Az Egothor egy 2006 ban készült nagy teljesítményű keresőrendszer. A rendszer motorját újratervezik és újraírják. A projekt dokumentáltsága olyannyira nem kielégítő, hogy nyelvi eszközökről csakúgy mint API-ról említést sem találtam. Így ezt a rendszert is idejekorán elvetettem Xapian A Xapian egy olyan eszközkészlet, melyet teljes egészében C++-ban írtak, de használható több más népszerű programozási nyelvvel, úgymint PERL, Python, PHP, JAVA, C#... Egy ráépülő népszerű keresőrendszer az Omega, mellyel együtt számos fájlformátum indexelésére képesek. Továbbá jó néhány integrált nyelvi eszközzel rendelkezik, úgymint pl. szótövező (magyar nyelvű is!), szinonima használat keresés közben. Képes még több adatbázis egyidejű indexként való használatára. A projekt jól dokumentált és folyamatosan karbantartott. Sajnos ennek az API-ját is úgy tervezték, készítették, hogy elsősorban a program beágyazását tegye lehetővé, nem pedig a bővítését ht://dig A kereső több alprojektből áll, melyek fejlesztése 2002 ben abbamaradt. A rendszer amúgy angol nyelvű szavak szótövezését és szinonimák használatát is támogatja. Elsősorban Internet oldalak keresésére készítették. Alkalmazás-programozási felületről nem találtam információt Lemur/Indri A Lemur eszközkészlet a Carnegie Mellon University és a University of Massachusetts támogatásával készült. Céljuk egy olyan keretrendszer létrehozása volt, mely nyelvmodellezési és adatbányászati kutatásokhoz jól használható. A program C++ nyelven íródott, de rendelkezik JAVA, PHP, és C# API-val is. A projekt több éves múltra tekint vissza, és félévente új kiadásokkal jelentkezik. A Lemur többféle dokumentum típus indexelését támogatja: HTML, XML, PDF, Szöveges fájl, Microsoft Word, Microsoft PowerPoint. Az angol nyelvi szövegeken kívül kínait és arabot is támogat, továbbá beépített angol 24

25 szótövezővel és mozaikszó felismerővel is rendelkezik. A rendszer a dokumentumok feldolgozását pipeline-szerűen végzi, képes több indexfájl egyidejű használatára. Beépített nyelvi eszközei: angol nyelvű szótövező (2 db), arab nyelvű tövező, betűszó felismerés és stopword 4 támogatás. Az Indri egy olyan keresőrendszer, mely a Lemur eszközkészletére épül. A fentieken kívül fontos tulajdonsága, hogy támogatja az UTF-8 kódolású dokumentumokat is. A kereső rendelkezik még több fajta grafikus felhasználói felülettel. A projekt példákkal illusztrált, jól használható dokumentációval van ellátva. A fentebb részletezett szempontok alapján az Indri keresőrendszer tűnt a legjobb választásnak, így a továbbikban ennek részletes működését vizsgálom meg A Lemur és az Indri működése A fejlesztés fázisa alatt a programcsomag 4.8-as verziója volt elérhető, ezért ezzel foglalkozom 5. A Lemur eszközkészletet abból a célból hozták létre, hogy elősegítse információ visszakeresési (IR 6 ) és nyelvmodellezési feladatok kutatását. A rendszer[7] alapja egy olyan architektúra, mely támogatja a következő technológiákat: ad-hoc és elosztott lekérdezések futtatása nyelvek közötti lekérdezések futtatása strukturált lekérdezések futtatása mező szerinti szűrések használata dokumentum kategorizálás összefoglalás készítés Az Indri eredetileg önálló keresőrendszerként indult, majd az évek során a fejlesztők beolvasztották a Lemur projektbe. Jelenleg az Indri nagy részben a Lemurra épül, bár 4 tiltólistás szavak - olyan szavak halmaza, melyek az indexelés és keresés szempontjából nem rendelkeznek releváns információ tartalommal 5 A dolgozat írása során jelentek meg újabb verziók is. 6 Infomration Retrival 25

26 nem támogatja, nem használja annak minden funkcióját, de számos új eszközzel egészíti ki. Ezek közül is talán a legfontosabb, hogy képes mezőket és metainformációkat 7 kezelni és UTF-8 kódolással készült dokumentumokat használni. Mint a legtöbb keresőrendszer, az Indri is tartalmaz indexelő, lekérdező és robot alkalmazást. Ezeken kívül számos egyéb kisebb alprogram is a fejlesztők, felhasználók rendelkezésére áll. Az alábbiakban részletesen ismertetem ezek működését, használatukat és ott ahol szükséges az alkalmazás-programozási felületet is. Általánosságban elmondható az Indri alprogramokról, hogy a felhasználóval való kommunikációra paraméter 8 fájlokat használatnak, melyből kinyerik a futáshoz szükséges technikai információkat: mennyi memóriát használhat, dokumentumtár helye, szótövező típusa stb Indexelés A Lemur projekt alprogramjai alapvetően két féle index készítésére, használatára képesek. Ezek a következők: KeyFile Index, Indri Index. A két index típus közötti alapvető különbségeket az 3.1 táblázatba gyűjtöttem össze. A projekt több alkalmazást is tartalmaz, melyek az indexelés fázisához kapcsolódnak. BuildIndex A Lemur alapértelmezett indexelő alkalmazása. Egyszerű szöveges fájlok feldolgozására alkalmas. Mezők és metaadatok indexelését nem támogatja. IndriBuildIndex Az Indri alapértelmezett indexkészítő alkalmazása. Az Indri alkalmazás többi alprogramja, csak az ez által készített indexel dolgozik. Az alprogram képes feldolgozni többek közt PDF, DOC, PPT kiterjesztésű fájlokat is. Mezők és metaadatok feldolgozására is fel van készítve. BuildPropIndex Az alprogram egy olyan indexet készít a rendelkezésre álló dokumentumok halmazából, melyben a szavakhoz, termekhez tulajdonságokat, metainformációt is rendelhetünk. BuildDocMgr Dokumentumkezelőt készítő alkalmazás. A gyakorlatban ez azt jelenti, hogy az indexelt dokumentumokat későbbiekben az így készített adatbázison keresztül lehet elérni. 7 A fejlesztők terminológiája szerint a mezők a szövegben fellelhető kiemelt információk, melyeket akár lekérdezések futtatásakor is igénybe vehetünk. Pl.:dátumok, nevek, helyszínek... Míg a metainformációkat tartalmazó mezők, nem biztos, hogy láthatóak a szövegben, nem lehet az indexben tárolni őket mint kereshető adatelemeket, de lekérdezéskor kinyerhetőek az adatbázisból. Pl.: URL, dokumentumsorszám... 8 A paramétere fájlok használatáról bővebb információ: doxygen/lemur/html/indriparameters.html 26

27 3.1. táblázat. A Lemur index típusainak összehasonlítása Tulajdonság Keyfile Index Indri Index Tárolható dokumentumformák Az index tárhely használata a dokumentumtár méretéhez képest TREC Text, TREC Web, HTML, Szöveges fájl 1,2x 2x Metaadatok használata igen igen Mezők használata nem igen Létező index bővítése igen, de csak offline, azaz ha éppen nincs használatban TREC Text, TREC Web, HTML, Szöveges fájl, XML, PDF, MBox, Microsoft Word és PowerPoint igen, használat közben is Használható lekérdezőnyelvek InQuery Indri Query Language Helyettesítő karakterek nem igen használata (Pl.: *,?) Indexelő alprogramok BuildIndex IndriBuildIndex, Build- Index Lekérdező alprogramok RetEval IndriRunQuery, RetEval A keresőrendszer bővítése során nyilván szükségem lesz egy indexelő alkalmazásra, és mivel ezt a munkát sem célom az alapoktól kezdeni, ezért közelebbről megvizsgálom a IndriBuildIndex alprogramot. Először vegyük szemügyre, az alprogram API-ját, azt hogy milyen lehetőségeket kínál a fejlesztőknek. Az indexek kezelésére az API-ban az indri::api::indexenvironment osztály szolgál. Ennek műveletei: open(std::string &repositorypath) egy létező index megnyitása create(std::string &repositorypath, IndexStatus *callback) új index készítése addfile(std::string &filename) egy fájl hozzáadása az indexhez (ez a fájl a függvény hívását követően feldolgozásra kerül) addstring(std::string &documentstring, std::string &fileclass, std::vector<indri::parse::metadatapair> &metadata) egy 27

28 string-ként tárolt dokumentum hozzáadása az indexhez (a dokumentum a függvény hívását követően feldolgozásra kerül) addparseddocument(indri::api::parseddocument *document) egy már feldolgozott dokumentum hozzáadása az indexhez setindexedfields(std::vector<std::string> &fieldnames) az indexelendő mezők beállítását szolgáló függvény Látható, hogy az alkalmazásprogramozási felület nem sok hozzáférést enged az indexelés folyamatának belső történéseihez. Így szükségesnek láttam, hogy a program egyes elemeit módosítva, nagyobb teret kapjak a nyelvi eszközök integrációjához. Ehhez jobban meg kellett ismernem a modul működését. Az IndriBuildIndex alkalmazást futtatva a következő műveletsor fut le: 1. A paraméter fájl beolvasása, feldolgozása. 2. Az index létrehozása, vagy ha már létezik, akkor megnyitása. 3. A dokumentumhalmaz állományainak egyenkénti, pipeline-szerű feldolgozása. (a) Fájl beolvasása. (b) Tokenizer 9 meghívása a beolvasott dokumentumon. (c) Parser 10 meghívása, a tokenekre bontott dokumentumon. (d) Transformation típusú objektumok meghívása az elemzett dokumentumon. Ebben a fázisban hajtódik végre például a szótövezés, dátumfeldolgozás, mezők feldolgozása, tiltólistás szavak elhagyása, stb. 4. A teljesen feldolgozott adathalmaz tárolása az indexben. 5. Index bezárása. A fenitekből az látszik számomra, hogy ha egy új eszközt szeretnék a feldolgozási láncba beilleszteni, akkor, ahhoz a Transformation interfészt kell megvalósítanom, majd beillesztenem az indexelési pipelineba. 9 a bemeneti dokumentumot elemi egységekre ún. tokenekre bontja 10 szintaktikai elemző 28

29 Lekérdezés Már láttuk az indextípusok összehasonlításánál, hogy több lekérdező alkalmazásunk is van, melyekhez más-más lekérdezőnyelvet használhatunk. Az InQuery nyelvet használó alprogramok a ParseInQueryOp és a StructQueryEval, míg a RetEval és a IndriRun- Query az Indri Query Language-el dolgoznak. Ezeken az alkalmazásokon kívül lekérdezéseket futtathatunk még az alkalmazásprogramozási felületen keresztül és egy démon segítségével is. Mivel az Indri Query Language az InQuery nyelv egy kiterjesztése, így a továbbiakban ezt fogom használni. Most pedig megvizsgálom, milyen képességekkel rendelkezik. Az Indri Query Language egyik előnyös tulajdonsága, hogy automatikusan tövezi a keresőkifejezés szavait, a választott indexnek megfelelően. Ez azt jelenti, hogy ha egy saját szótövezést beépítettem az indexelés folyamatába, akkor az így létrehozott indexen futtatott lekérdezéseket is ez szótövező fogja feldolgozni. Ezzel együtt a lekérdezőnyelv, többféle operátort támogat, melyekkel pontosítható a találati lista. Először is léteznek úgynevezett közelségi operátorok, melyekkel a kifejezésben megadott szavak egymástól számított távolságára 11 adhatunk feltételeket. Pl.: #1(általános célú) a két szó szomszédságára és sorrendjére adott feltétel. Használhatunk olyan kifejezéseket is, mellyel arra utasíthatjuk a lekérdezőprogramot, hogy a paraméterben kapott szavakat, tekintse rokon értelmű szavaknak, továbbá ezek között súlyozást is definiálhatunk.(#syn(...), {...}, <...>, #wsyn(...)) Lekérdezésekben helyettesítő karakterként *-ot használhatunk, melynek operátor párja a #wildcard(...). Mezőkre szűrési lehetőséget is biztosít a nyelv. Ha például indexeléskor használtunk weight típusú mezőt, akkor az olyan dokumentumokat, melyekhez tárolt a rendszer ilyen típusú tulajdonságot, az #any(weight) operátorral tudjuk lekérdezni. Ha a mező értékére is akarunk feltételt adni, arra a. operátort használjuk. Például ha a Erdős Pál dokumentumaira szűrnénk, és indexeléskor az author mezőt is használtuk akkor a #uw1(erdős Pál).author feltétellel tehetjük ezt meg. Úgynevezett számszerű 12 mezőknél még több lehetőségünk van, ekkor ugyanis az értékre nemcsak egyenlőségi feltételt adhatunk, hanem relációs feltételekkel is élhetünk. A numeric típusú mezők egy speciális fajtája használható dátum szűrésére is. Ezeken kívül használhatunk még logikai és súlyozható egyesítő 13 operátorokat, és a dokumentumok közötti szűrésre, prioritások kezelésére is lehetőségünk van. Most pedig nézzük, hogyan történik egy a nyelvben meg- 11 két szó távolsága, úgy kapjuk, hogy ha a köztük lévő szavak számából levonunk egyet 12 az alkotók terminológiájában numeric 13 két keresőkifejezés összeolvasztására szolgál 29

30 fogalmazott kérés feldolgozása, kiértékelése. A lekérdezés folyamata 8 lépésből áll, melyet a 3.1 ábra[7] szemléltet. 1. Parser 14 objektum létrehozása, mely megkezdni a felhasználó kérésének feldolgozását. Ez a lépés 3 részből áll: lexikális elemző(k) létrehozása, szintaktikus elemző(k) létrehozása, majd ezek egy objektumba zárása. 2. Szintaktikus elemzés: melynek során létrejön a szintaktikus fa. 3. Megszorítás a mezőkre: ha a lekérdezésben valamilyen mező(k)re van hivatkozás, akkor a szintaktikus fa felcímkéződik, így a későbbiekben a kiértékelés folyamán ezek megfelelő pontszámokat 15 kapnak. 4. Azon ún. nyers 16 csúcsok meghatározása a szintaktikus fában, melyek pontozhatóak. 5. Feldolgozatlan csúcsokhoz tartozó kifejezésekből statisztika készítése. 6. Csillapító paraméterek alkalmazása a fára. 7. A már feldolgozott kérés kiértékelés úgy történik, hogy az újonnan kapott fa leveleit átvizsgálva: az ún. Stopwords halmaz elemeit elhagyva, a fa leveleiben található szavakat tövezett formájával történik az indexben található dokumentumokkal való összevetés, majd pedig az eredményhalmaz létrehozása. 8. A találati lista szűkítése és rendezése a pontok alapján Egyéb alprogramok Az eszközkészlet számos egyéb alprogramot is tartalmaz. Ezek közül számomra a következők fontosak: Daemon megnyit egy Indri index fájlt, és lekérdezéseket futtató alkalmazások kéréseit szolgálja ki socketen keresztül. JAVA GUI SWING alapú grafikus felület a lekérdező és indexelő alkalmazásokhoz. PHP webes felület PHP4 nyelven íródott grafikus felület, melyen keresztül lekérdezéseket hajthatunk végre. 14 szintaktikai elemző 15 ugyanis a találati lista elemeinek sorrendje a ún. pontok alapján kerül meghatározásra 16 feldolgozatlan 30

31 JSP webes felület az előzőhöz hasonló JSP technológiát használó webes interfész. 31

32 3.1. ábra. Indri Query Language egy kifejezésének feldolgozása 32

33 4. fejezet Nyelvi kereső létrehozása Ebben a részben áttekintem, hogy milyen új funkcionalitásokkal láttam el az Indrit, részletezem megvalósításukat és ezek korlátait. A fejlesztés során, sok esetben olyan döntéshelyzetbe kerültem, amikor több megoldás is jónak látszott, attól függően, hogy milyen korpusszal használjuk az alkalmazást. Ezért úgy döntöttem, hogy egy jól körülhatárolt témakörű szövegeken fogom futtatni az alkalmazást, így tudom majd ahhoz igazítani kiegészítő moduljaim egyes funkcionalitásait. Ezzel egy időben konzulensemtől, Dr. Prószéky Gábortól kaptam egy adatbázist, mely az Országgyűléseken elhangzott beszédeket tartalmazta. További munkáim alapját ez az anyag képezte Szótövező modul Mielőtt részletezném munkám technikai oldalát, kitérnék arra, hogy pontosan mit is jelent egy szó tövét meghatározni[6]. A szótő-előállítás vagy lemmatizálás olyan művelet, mely adott természetes nyelv (lehetőleg) minden szóalakjából előállítja annak egyetlen tövét (szótári alakját, lemmáját). Ily módon a lemmatizálás a nyelv szóalakjait ekvivalenciaosztályokba sorolja, ahol az azonos tőre visszavezető szóalakok tartoznak egy osztályba. Sajnos ez az osztályokba sorolás mégsem tökéletes, különösen a magyar nyelvben, ahol a képzők használata megsokszorozhatja a lehetséges tövek számát. Például az adósság szónál az első szótő a adós lehetne, de fel kell ismernünk, hogy ez is egy képzett alak, így akár az adó vagy az ad is egy-egy szótő lehet. Másrészről az is előfordulhat, hogy egy szó tövei egymástól nagyon eltérő jelentést hordoznak. Ilyenkor az ideális választás igazodik a szövegkörnyezethez. A modern keresőrendszerek szerves részét képezik szótövező algoritmusok, ez ért- 33

34 hető, hiszen jobban belegondolva, ezek nélkül rengeteg potenciálisan jónak mondható dokumentum kiesne a találati listából. Egy ilyen program létrehozása időigényes, nehéz és mélyebb nyelvészeti ismereteket feltételező feladat. Diplomamunkám célja alapvetően keresőrendszer fejlesztésére irányul, ezért egy nyelvészeti eszközöket tartalmazó modult kértem és kaptam a MorphoLogic Kft.-től. A továbbiakban ennek integrációjának részleteit írom le Lemur, Indri Első ötletem az integrációval és a fejlesztéssel kapcsolatban az volt, hogy a Lemur eszközkészletet veszem munkám alapjául, és azt bővítve haladok. Sajnos közelebbről vizsgálva a Lemurt rá kellet ébrednem, hogy bár többnyelvű környezethez fejlesztették mégsem támogatja a magyar nyelv egyes ékezetes magánhangzóinak használatát. Ez abból az egyszerű okból fakad, hogy a program indexelő részének Parser moduljai közt nincs olyan, ami a magyar nyelvvel kompatibilis karakterkódolást támogatna. Így újra kellett gondolnom a tervemet, és végül is az Indri kiegészítése mellett döntöttem. Szerencsére az említett kereső a dokumentumok belső reprezentáláskor az UTF-8 karakter kódolási szabványt használja Tövező integrációja A cégtől kapott szótövező az elemezendő karaktersorozatokat mindig valamely Windows kódlap karakterkódolása szerint értelmezik. Ezek közül a magyar írásjeleket tartalmazó a 852-es és 1250-es sorszámú. A 1250-es kódlap használata mellett döntöttem, mivel ez egy modernebb variánsa az 852-esnek. Az integrációhoz szükséges volt, hogy alkalmazzak egy karakterkonverziós lépést, mely az UTF-8 kódolással reprezentált stringeket CP-1250-es reprezentációra alakítja és vissza. Ehhez a konverzióhoz az iconv 1 programkönyvtárat használtam. Mint korábban említettem, az Indri az indexelés folyamatában, a feldolgozandó dokumentumokat egy pipeline szerűen dolgozza fel. Ebben a folyamatban minden feldolgozó objektum a Transformation absztrakt osztály egy példánya. Így elég a 4.1 ábrán látható interfészt megvalósítani. A felsorolt műveletekből egyedül a transform az ami igazán fontos, mert a többi művelet a pipeline elemeinek összekapcsolásáért felelős. Ennek a függvénynek az implementálásval lehet a paraméterként kapott dokumentum szavait egyenként feldolgozni. Az 1 34

35 indri::api::transformation +handle(document:parseddocument*): void +sethandler(handler:objecthandler<parseddocument>&): void +-Transformation() +transform(document:parseddocument*): ParsedDocument* 4.1. ábra. A Transformation típus általam megvalósított integráció a következőképen működik: 1. üres 2 term vagy szám esetén továbblép, hiszen ezek nem szavak 2. Humor tövező meghívása az aktuális szóra 3. a szótövezőtől kapott tövek közül az első tárolása(ha létezik) Az Indri és ezzel együtt az általam készített továbbfejlesztése is alkalmas arra, hogy egy szóhoz, több tövet is tároljon. A megfelelő szótő megtalálása, mint korábban írtam, egyáltalán nem egyszerű feladat, és nem is képezi dolgozatom vizsgálódásának tárgyát, ezért szelekció nélkül a lemmatizáló modul által visszaadott első tövet eltároltatom. A másik lehetőségem az lett volna, hogy minden szóhoz az összes szótövet tárolom, ezt viszont azért nem találtam praktikusnak (és vetettem el), mert lekérdezéskor túl nagy zajt okozhat a sok szótő Tiltólistás szavak A legtöbb keresőrendszer az indexelés és lekérdezés folyamán bizonyos szavakat nem indexel, nem vesz figyelembe. Róluk azt mondjuk, hogy a Stopwords halmazba, más néven tiltólistás szavak halmazába tartoznak. Ezek egy adott nyelvben azon leggyakoribb szavak, melyek nem hordoznak jelentős információtartalmat és tipikusan: kötőszavak, névelők, igekötők, határozószavak, névmások. Sok esetben ez a halmaz nem határozható meg egyértelműen, így fontos, hogy az adott célra - különösen vertikális keresés esetén - testreszabjuk, átgondoljuk, hogy mely szavakat szeretnék kihagyni az indexelés, lekérdezés folyamatából. 2 nulla hosszú string 35

36 Stopword szűrés az Indriben A használt kereső két opciót is kínál a tiltólistás szavak szűrésére. Egyrészt lehetőségünk van az indexeléskor megadott paraméter fájl kiegészítésére, másrészt a feldolgozási lácba fűzhetünk egy saját készítésű Stopper típusú objektumot. Nyilvánvalóan a második opció szabadabb kezet ad a szavak szűrésében, de a legtöbb esetben elég a listás megoldás használata is Szavak választása, megvalósítás Mivel adatbázisom témái és nyelvezete elég jellegzetesek, úgy döntöttem, hogy a szövegekben található szavakból gyakorisági statisztikát készítek. Tehát megvizsgáltam, mik a legtöbbször előforduló szavak, és ezek közül kiválasztottam azokat, amik megfelelnek a fent adott definíciónak. Ezekhez még hozzávettem egy az interneten fellelhető 3 általános magyar nyelvű stopword halmazt. Az így kapott szóhalmazt hozzáfűztem az paraméterfájl megfelelő szekciójához. A kiválasztott szavak jegyzéke a függelékben található Dátumok használata Motiváció Országgyűlési naplókban gyakoriak az utalások különböző eseményekre, dátumokra. Másrészről minden lejegyzés egy adott nap felszólalásait tartalmazza. Látható hogy az egyes dokumentumok több időhöz kapcsolódó információt is hordoznak. Így arra gondoltam, hogy nagy könnyebbség lenne a végfelhasználóknak, ha tudnának a dokumentumok között dátum szerinti kereséseket is végezni. Ugyanakkor tudom azt, hogy dátumokat a magyar nyelvben és különösen írásos szövegekben nagyon sokféleképpen lehet kifejezni. Így célom az volt, hogy készítendő modul működése testreszabható legyen, és a lehető legtöbbféle formában megjelenő egységeket legyen képes felismerni, kereshetővé tenni Dátumok kategorizálása Ehhez először megvizsgáltam, hogy milyen típusú dátumok léteznek nyelvi szövegekben

37 Pontosság szerint: évszázad pontos, pl.: XX. század, Kr.e. 3. sz. évtized szerint pontos, pl.: kilencvenes évek évre pontos, pl.: 1986 hónap vagy évszak pontos, pl.: 1956 ősze, 1848 márciusa napra pontos, pl.: szeptember 1. órára, percre, napszakra stb.-re pontos, pl.: április 30. reggele, :00 Környezetfüggőség szerint: környezetfüggőnek nevezek olyan dátumokat, melyek csak a szövegkörnyezetükben értelmezhetőek pl.: tegnap, előző héten környezetfüggetlennek nevezek minden olyan dátumot, mely önmagában is egy időpontot jelöl, pl.: 1989, Dátumkezelés az Indriben Az általam használt keresőrendszer rendelkezik dátumok kezelésének képességével. Ez a funkció nem csak az index létrehozásakor elérhető, hanem ahogy arról a részben is kitértem lekérdezésekkor is kitűnően használható. Indexeléskor a rendszer olyan dátumokat képes tárolni az adatbázisban, amiket a felhasználó a feldolgozandó dokumentumban dátummezőként előre jelzett. Ezek közül is csak azokat dolgozza fel, amik a következő formában vannak megadva: dd month yyyy dd-mon-yy dd-mon-yyyy Month dd yyyy mm/dd/yy mm/dd/yyyy 37

38 Ahol a(z) dd hónap egy napját jelöli, mely lehet egy vagy két számjegyű. month kisbetűs angolul írt hónapnév. Month nagybetűvel kezdődő angolul írt hónapnév. MON egy hónap angol nevévenk első három betűje. mm egy hónap sorszámát jelöli. yy két jegyű év jelölés, mely 1900-tól kezdődően értelmeződik. yyyy évet jelöl. Ezeket a speciális date típusú fieldeket, a feldolgozási láncban egy Transformation típusú objektum dolgozza fel, mégpedig úgy, hogy minden felismert dátumhoz hozzárendel egy egész számot. Ennek a megfeleltetésnek az alapja 1600 január elseje, aminek az indexben tárolt értéke 0. Minden ettől eltérő dátum az azóta eltelt napok számával kerül tárolásra (negatív értékek is). Dokumentumok közti keresésnél úgy tudunk dátumokra szűrni, hogy ha a lekérdezésbe beillesztjük az alábbi operátorok egyikét: #dateafter(d) D utáni dátumokra illeszkedik #datebefore(d) D előtti dátumokra illeszkedik #datebetween(da DF) DA és DF közé eső (szigorú értelemben) dátumokra illeszkedik #dateequals(d) D dátumra illeszkedik A D, DA és DF paraméterek az indexelésnél említett formában használhatóak. Ezekből látható, hogy a rendszer csak az előre beégetett (angol nyelvterületen használt) dátumformákat képes kezelni. Ezért úgy döntöttem, hogy továbbfejlesztem a rendszert úgy, hogy az a lehető legtöbb formájú dátumot tudja kezelni. 38

39 Magyar nyelvű dátumok kezelése Úgy gondolom, hogy a dátumok kereshetővé tétele akkor használható egyszerűen, ha nem a felhasználónak kell az indexelendő dokumentumokban egyesével bejelölnie az általa dátumnak gondolt szövegrészeket. Ezért mindenképpen szerettem volna egy olyan eszközt is biztosítani, beépíteni a keresőbe, ami a felhasználó helyett elvégzi ezt a feladatot. Mindezzel együtt, az alábbi két megoldási utat láttam: 1. A szövegfeldolgozási láncba beavatkozva, a szöveg tokenekre bontása előtt feldolgozni és felülírni a dokumentumot reprezentáló objektumot úgy, hogy az összes dátum kerüljön megjelölésre. A dátumok feldolgozását ezután egy általam készített modul végezné, ami az eredetit helyettesíti. 2. A feladat két részre (külön alkalmazásra) bontása. Először a szöveges fájlokat tartalmát módosítanám, majd az előzőekhez hasonlóan a dátumfeldolgozó modult cserélném le. Azt tapasztaltam, hogy az első megoldási út, nem szerencsés, mivel módosítani egy fájl tartalmát, csak a szintaktikus elemző után tudnám. Ez viszont azért problémás, mert az elemző a beolvasás során az egyes termekhez, pozíciókat is rendel, és felülírva a tartalmat, a hivatkozások érvénytelenné válnának. A második út már nehézségek nélkül megvalósítható, viszont itt azzal a kényelmetlenséggel kell számolni, hogy a felhasználónak az indexelés előtt futtatnia kell egy előfeldolgozó programot. Így a második út mellett döntöttem, tehát egy előfeldolgozó programot, és egy dátumfeldolgozó modult készítettem. Figyelembe véve az Indri dátumfeldolgozását a dátumtípusok közül is csak azokkal tudtam foglalkozni, melyek legalább napra pontosak. Azzal a könnyítéssel is éltem még, hogy csak a környezetfüggetlen dátumokkal foglalkoztam, hiszen a környezetfüggőek értelmezése a szöveg mélyebb elemzését igényli. Ez pedig, indexelési időben az Indrivel nem kivitelezhető. A két részfeladatból az első tehát az, hogy az annotáló program a felismert dátumokat a szövegben dátum mezőkké alakítsa. Így például egy elvárt működés, hogy a ből <date> </date>-t készítsen. Az alkalmazás a dátumformákat egy konfigurációs fájlból 4 olvassa. A megadható dátumformák halmaza, megegyezik az alábbi nyelv elemeivel. (Ahol a Σ ábécé a Unicode karakterkészletnek felel meg.) 4 A konfigurációs fájlról bővebben a függelék megfelelő fejezetében írok. 39

40 Date Form1 Form2 Form3 Form4 Form5 Form6 Form1 Seps Year Seps Month Seps Day Seps Form2 Seps Year Seps Day Seps Month Seps Form3 Seps Month Seps Year Seps Day Seps Form4 Seps Month Seps Day Seps Year Seps Form5 Seps Day Seps Month Seps Year Seps Form6 Seps Day Seps Year Seps Month Seps Year yyyy yy Month mm m month mon Day ddd Seps Seps Sep Sep Sep Available ε Available Σ \ Reserved Reserved y d m o n t h A program úgy dolgoz fel egy dátumformát, hogy reguláris kifejezéssé alakítja. Az így kapott új kifejezést, pedig már könnyűszerrel használhatjuk a Boost Regex függvénykönyvtárral[1], melynek replace műveletét felhasználva megtörténik a dokumentumszöveg módosítása. Jól látható, hogy a program lényegi része egy leképezés, mely a dátumnyelvből reguláris kifejezést készít. Ez a következőképpen történik. yyyy \d{4} yy \d{2} mm (01;02;03;04;05;06;07;08;09;10;11;12) m (1;2;3;4;5;6;7;8;9;10;11;12) month (január;...;december) mon jan;...;dec dd ((0[1-9]) [12][0-9] 30 31) d (([1-9]) [12][0-9] 30 31) A második program, beépülve az Indri mezőket-feldolgozó folyamatába, dátum fieldeket dolgoz fel. Első lépésként a kapott dátumban megpróbálja meghatározni az év, hónap, nap mezők sorrendjét, ezek után től számított egész számmá alakítja azt. 40

41 Fontos megjegyezni, hogy nem javasolt az olyan dátumformák megadása a konfigurációs fájlban, melyek a ütközhetnek. Két dátumformát ütközőnek nevezek, ha létezik olyan dátum, mely mindkét formának megfelel. Például: mm/dd/yy, dd/mm/yy és a hozzájuk tartozó dátum: 01/10/09. Ekkor ugyanis nem dönthető el egyértelműen, hogy pontosan milyen időpontot is jelöl a dátum A megoldás korlátai Ahogy korábban is írtam környezetfüggő és nem legalább napra pontos dátumokkal nem foglalkoztam. Ezeken kívül a dátumformák toldalékos alakjaival adódhat még problémája a programnak. Ha a megadott forma yyyy. month d. és a dátum január 11. de a szövegben úgy szerepel mint január 11-én, akkor a ez indexelő nem dolgozza fel. Ennek kiküszöbölésére két út lehetséges. Az első, hogy a szótövezést előbb használjuk, mint a dátumfelismerést, így minden dátumnak csak az eredeti alakjával kellene foglalkoznunk. Sajnos ez az Indri esetében ez kivitelezhetetlen, ugyanis a feldolgozási láncban a a mezők feldolgozása, megelőzi a szótövezést. A másik járható út az, hogy a felhasználóban tudatosítjuk a rendszer korlátait, és ebben az esetben arra buzdítjuk, hogy egészítse ki a konfigurációs fájlt a példának megfelelő yyyy. month d- formával is Mennyiségek használata A mennyiség egy mérés eredményére vonatkozó kifejezés, mely a dolgok számát, irányát, számosságát határozza meg, vagy dolgok csoportjának, gyűjteményének megnevezést ad a számossága alapján (például tucat). Többnyire a mennyiséget számmal jelöljük (mérőszám), amelyet egy mértékegység követ (ha szükséges), majd ezután megemlítjük magát a dolgot, aminek mennyiségét meghatározzuk. A pontos fogalmazáshoz mindkét részre szükség van Motiváció Írásos dokumentumainkban gyakran használunk sokféle mennyiséget, melyek különleges információtartalommal bírnak. Sajnos a legtöbb keresőrendszerben nincs lehetőségünk mennyiségek mentén szűkíteni a találatainkat, mivel az indexelőprogramok gyakran csak egy-egy szó tárolásával foglalkoznak, szókapcsolatok, kifejezések elemzésével már 41

42 nem. Így fordulhat elő, hogy egy olyan kifejezésnek mint pl.: 1000 euró-nak a valódi jelentése elveszhet, és az indexbe csak mint egy szám és egy szó tárolódik. Ha a dolgozatom témáját tekintem, azaz az országgyűlési naplókat, akkor az figyelhető meg, hogy ezekben a szövegekben gyakran esik szó pénz mennyiségről. Ezen kívül csak elvétve találunk más mennyiséget, úgy mint a hosszmérték. Adódott az ötlet, hogy megvizsgáljam miként lehetséges mennyiségeket kezelni az Indri keresőrendszerben. A vizsgálódásomat az alábbi szempontok mentén végeztem: Lehetséges-e több féle mennyiség kezelése? Ha igen, hogyan? Lehetséges-e a felhasználó által megadott mértékegységek használata, kereshetővé tétele? Használhatunk-e negatív értékeket? Használhatunk-e nem egész értékeket is? Hogyan végezhetünk kereséseket? Lehet-e valamilyen módon mennyiségi összehasonlításokat használni? Azonos mennyiséget jelölő, különböző formában adott mennyiségek kezelhetőek-e egységesen? Pl.: 1000 g = 1 kg? Lehetséges-e betűvel írt mennyiség értékének indexelése? És ha igen, hogyan? Ezek után pedig úgy bővítettem a rendszert, hogy az említett két mennyiségi információt indexelés és keresés során a lehető legjobban kezelje a rendszer Mennyiségek indexelése, keresése az Indriben Első megközelítésben azt állapítottam meg, hogy az Indrivel maximum arra van lehetőségem, hogy az összertozó mennyiségi kifejezéseket együtt tároljam. Aztán közelebbről megvizsgálva a rendszert azt láttam, hogy keresővel használhatóak számszerű mezők. Ez pedig a következő módon működik: Az indexeléskor használt paraméterfájlban megadhatjuk, hogy mely mezőket kezelje, ezek számszerűek-e, illetve mely elemző dolgozza fel őket. A dátumokhoz hasonlóan ezek a mezők is előjel nélküli egészként tárolódnak. Így az indexelés folyamán, a már korábban látottakhoz hasonlóan, beiktatható egy újabb saját modul, ami a jelölt mennyiségeket feldolgozza. Kereséshez az alábbi kulcsszavakkal állnak rendelkezésünkre: 42

43 #less(fieldname value) fieldname mezők értékei közül azokat választja ki, melyek kisebbek value-nál #greater(fieldname value) fieldname mezők értékei közül azokat választja ki, melyek nagyobbak value-nál #between(fieldname value1 value2) fieldname mezők értékei közül azokat választja ki, melyek value1 és value2 között vannak #equals(fieldname value) fieldname mezők értékei közül azokat választja ki, melyek értéke pontosan value Általános megoldás mennyiségek használatára A numerikus mezők előnyös tulajdonságaira alapozva az alábbi megoldást dolgoztam ki. A megvalósított kiegészítő modul a dátumfelismeréshez hasonlóan, két részből áll. Az első rész, a korábban leírtakhoz nagyon hasonlóan azt hivatott szolgálni, hogy a forrásfájlokban mezőket hozzunk létre, melyek mennyiségeket jelölnek. A fentiekhez képest itt annyival nehezebb a feladat, hogy tudnunk kell különbséget tennünk mértékek között. Ezt úgy sikerült elérnem, hogy a fieldek létrehozásakor, minden mértékhez más-más címkét rendelek. Pl.: súlymérték esetén a konfigurációs fájlban megadott weight címkét rendelek a kg,g,dkg,stb. mértékeggel rendelkező mennyiségekhez, pénzösszegek esetében pedig a deviza kulcsszót használom. A magyar nyelvben a jelzős szerkezeteknek kötött a formája: a jelző megelőzi a jelzett szót. Mivel így tekinthetünk egy mennyiségi kifejezésre is, ezért joggal feltétezhettem, hogy egy mértékegység láttán, az azt megelőző szóval vagy számmal biztosan összetartoznak. Ezeket tudva, az első modul működése odáig egyszerűsödött, hogy elég megtalálni egy mértékegységet jelző szót, és az azt megelőzővel/megelőzőekkel létrehozni egy mezőt. A gyakorlatban azonban ez a módszer messze nem tökéletes, mert előfordulhat - és elő is fordul - olyan szövegkörnyezet, ami például magáról a mértékegységről szól. Ekkor az előtte álló szóval ritkán alkot mennyiségi kifejezést. Pl.: A gramm a súlymérték alapegysége.... az euró bevezetése... Ilyen esetekben a modulom, a mezőhöz extremális értéket rendel, hogy kereséskor minél inkább elkerüljem a rossz találatokat. Egy másik olyan hiba, amivel a program fejlesztése során találkoztam, az hogy az országgyűlési naplókban gyakoriak az olyan pénzösszegeket kifejező mennyiségek, melyekben vegyesen használnak betűvel és számmal írt mennyiséget, pl.: 70 milliárd forint. Felfedezve 43

44 ezeket a kivételeket javítottam az alprogram működésén, hogy az ilyen kifejezéseket is megtalálja, tárolja. A második modul, mely beépül a szövegfeldolgozási láncba, a mezők feldolgozásáért, reprezentálásáért felelős. Ez mikor végigjárja az indexelendő dokumentum összes mezőjét, csak azokat dolgozza fel, melyek mértékegységet tartalmaznak. Ezeket pedig úgy, hogy a mennyiségeket átváltjuk az SI megfelelőjükre. Nem egészek tárolása - az Indri korlátaiból fakadóan - csak egészként valósíthatóak meg, mégpedig úgy, hogy a tárolható számok mennyiségét csökkentve, helyet nyerve a tizedes jegyeknek. A készített modul egy gyakorlatban is sokat alkalmazható funkcionalitása, hogy képes betűvel írt 5 számok felismerésére, átváltására. Ezt úgy sikerült elérnem, hogy amikor elemzésre kerül a mennyiségi érték, és a modul felismeri hogy nem numerikus alakról van szó, meghív egy szövegfelismerő függvényt. Ez a magyar nyelv sajátosságait kihasználva a számot milliárdos, milliós, ezres, százas illetve tízes egységekre bontja, majd ezeket egyenként kiértékeli és összeadja Megoldatlan problémák A modul nem kezel olyan tört számokat, melyek hagyományos tehát nem tizedes alakban fordulnak elő. Ezek indexeléskor kimaradnak az adatbázisból így nem lesznek kereshetőek. Az intervallumként megadott értékeknél a program a várttól eltérően működik. Pl.: millárd forintnyi tartozás. A felhasználó jogosan azt várná, hogy pl.: "kevesebb, mint 15 milliárd forint"-szerű lekérdezések esetén a fenti szöveget tartalmazó dokumentum is szerepeljen a találati listában. Ez sajnos nem fog megtörténni, mivel a modul csak az intervallum felső korlátját tekinti, mint értéket és ezt teszi kereshetővé. Egyébként a használt keresőrendszer ettől sokkal többet nem is enged meg, hiszen egy numerikus mezőhöz pontosan egy értéket lehet hozzárendelni. Országgyűlési naplók használata során sok olyan mondatba botlottam, mikor egy-egy felszólaló az euróról vagy más pénznemekről beszél mennyiségi környezet nélkül. Ekkor, a felismerő modul az ilyen környezeteket is megjelöli, viszont feldolgozás során ez a megjelölt környezete értelmezhetetlen lesz. Pl.: az euró. 5 csak magyar nyelven megfogalmazott 44

45 4.5. Szinonimák használata A szinonímia, azaz rokonértelműség az a jelenség, amikor egy fogalmat több különféle szóval is kifejezhetünk. Szinonimák, vagyis rokon értelműek azok a szavak, amelyek különböző alakúak, de azonos vagy hasonló dolgot jelentenek Motiváció Mint azt mindennapi életünkben is tapasztaljuk, mind írásban, mind pedig beszédben igyekszünk elkerülni a szóismétléseket, ehhez pedig a legkézenfekvőbb eszköz a rokon értelmű szavak használata. Parlamenti felszólalások esetén a képviselők talán még nagyobb hangsúlyt fektetnek a szabatos fogalmazásra, így feltételezhetem, hogy ezekben a dokumentumokban az átlagosnál több szinonima használat fordul elő. Dokumentumok közötti keresések esetén, gyakran találkozhatunk azzal a problémával, hogy ha nem tudunk nagyon pontos keresőkifejezést összeállítani, a keresett dokumentumokat nem, vagy csak részben találhatjuk meg. Lássuk hogyan kaphatunk pontosabb találati listát csupán az alaprendszer által biztosított eszközök használatával! Rokon értelmű szavak használata az Indrivel A használt keresőrendszer lekérdezőnyelve az IndriQuery Language lehetőséget ad, olyan lekérdezések futtatására, melyben megadhatunk szócsoportokat, melyek elemeinek jelentése egyező vagy hasonló. Ennek használatával úgy érhetünk el jobb találati pontosságot, hogy ha keresőkifejezésünkbe a nyelv szintaxisával megadjuk, hogy mely szavak hordoznak hasonló jelentéstartalmat. A következő operátorokat használhatjuk: #syn(...) {...} <...> #wsyn(...) Az első három kifejezés egymással ekvivalens, míg az utolsónál a rokon értelmű szavakhoz súlyokat is rendelhetünk. Pl.: {országgyűlés parlament}, #syn(kutya eb), #wsyn(1.0 országgyűlés 0.8 parlament) 45

46 Automatikus szinonimahasználat A MorphoLogictól kapott nyelvi eszközök között szerepelt szinonima szótár is, így adva volt a lehetőség hogy ezzel egészítsem ki az Indri funkcionalitását. A szótár alkalmazásprogramozási felülete úgy működik, hogy egy lekérdezéskor, egy szóra az azzal rokonértelmű szavak csoportjával tér vissza. Szerettem volna, hogyha a felhasználónak nem maga kell kitalálnia keresőkifejezésben egy-egy szóhoz a rokonértelmű szavakat, hanem egy speciális karakterrel 6 utasíthatja a keresőt, hogy egy szó szinonimáit is vegye a találatok közé. Ezt úgy valósítottam, meg, hogy beavatkozva a lekérdezési folyamatba, a lekérdezést elő-feldolgozom, és minden egyes jelölt szó helyére beillesztem annak rokon értelmű párjait is. Például a ~parlament kifejezés #syn(parlament országgyűlés országház) alakúra transzformálódik A megoldás korlátai Mivel a fenti átalakítás automatikus, így könnyen bekerülhetnek olyan rokon értelmű szavak a keresőkifejezésbe, amik az eredeti jelentéstartalomtól távol állnak, és az így kapott lekérdezésben nagy lesz a zaj. Továbbá az is igaz, hogy bár ezzel a megoldással könnyítünk a felhasználó dolgán, csökkentjük a döntéshelyzetek számát, ugyanakkor egy fontos ponton vonjuk meg tőle a mérlegelés jogát. Egy jól használható megoldás lehetne, hogy ha már a lekérdezőfelületen kiválaszthatná a felhasználó a használandó szinonimákat. Ez funkció nem került megvalósításra a fejlesztés során. 6 ez a karakter a jel lett 46

47 5. fejezet Az elkészült rendszer értékelése Ebben a fejezetben célom, hogy megvizsgáljam a kiegészített keresőrendszert, és több szempont mentén összehasonlítsam az Indrivel. Nyilvánvalóan nem tudom az összes új modul hatását teljes körűen mérni, mert néhányuk olyan új funkcionalitást ad az eszköznek, melyek nem vagy alig összehasonlíthatóak az eredeti program működésével Teljesítmény Első lépésben azt vizsgáltam meg, hogy a keresőrendszer teljesítménye hogyan változik az általam készített eszközök hatására. Ez három helyen érhető tetten: indexelési idő változása, index méretének változása, keresési idő változása Indexelési idő Az indexelési időt úgy mértem, hogy a rendelkezésemre álló dokumentumokat, azok keletkezési éve szerint csoportosítottam, majd ezekre futtattam az alkalmazást. A 5.1 ábrán az látható, hogy egy-egy adathalmaz méretének függvényében, hogyan változott az annak feldolgozásával töltött idő. Ezek alapján megállapítható, hogy a szótövezés jelentősen lassította az indexelés folyamatát. Viszont az is észrevehető, hogy a tiltólistás szavak szűrésével, ez a teljesítménybeli visszaesés mérsékelhető. A fenti tényekre magyarázatot adhat, hogy a szótövezés költséges művelet és a szöveg majdnem minden szavára végrehajtjuk. Azt is meg kell még említeni, hogy az indexelés 47

48 5.1. ábra. Indexelési idő az adathalmaz méretének függvényében 5.2. ábra. Index mérete az adathalmaz méretének függvényében a keresések előkészítéséül szolgál, és egy dokumentumhalmazra csak egyszer kell lefuttatni. Így az itt vesztett idő a végfelhasználó számára észrevétlen maradhat Index mérete Inkrementális indexelést végezve azt vizsgáltam, hogy hogyan változnak a készített indexek méretei, az eszközök használatának, illetve, az adatmennyiség függvényében. Ennek a mérésnek az eredményét szemlélteti a 5.2 ábra. Mint arra számítottam, az index mérete csökkent szótövezés és stopword szűrés esetén. Tiltólistás szavak szűrésének alkalmazásakor, ez annak az egyszerű ténynek a következménye, hogy kevesebb kifejezés kerül az indexbe. Szótövezéskor, pedig egy szó különböző ragozott alakjai ugyanahhoz a kifejezéshez tárolódnak. Az így nyert tárhely- 48

49 növekedés a program eredeti működéséhez viszonyítva (átlagosan): szótövezéssel 22%, tiltólistás szavak szűrésével 6%, szótövezéssel és tiltólistás szavak szűrésével 28%. Látható, hogy e két egyszerű eszköz használatával érzékelhetően lehet javítani a keresőrendszer tárhely gazdálkodásán Lekérdezési idő Azt gondoltam, hogy ahogy csökkent az index mérete, azzal valamilyen arányban csökkenhet egy lekérdezés átlagos ideje. Azzal is számoltam, hogy ez az idő valószínűleg összefüggésben áll a keresőkifejezés hosszával. Ezért az irodalomban leggyakoribb keresőkifejezés hosszakra vizsgáltam azt, hogy hogyan változik a teljesítménye a keresőrendszernek ábra. Lekérdezési idő a keresőkifejezés hosszának függvényében Mérésem eredményei a 5.3 ábrán látható. Amit ezek alapján biztosan állíthatok az az, hogy a szótövezés nem befolyásolta érzékelhetően a lekérdezési időt. Másrészt a két eszköz együttes használata esetén sem mutatható ki egyértelműen javulás vagy romlás. Fontos még megjegyezni, hogy a kapott értékek milliszekundumos nagyságrendűek, így nem zárhatom ki a pontatlanságból fakadó ingadozásokat. 49

50 5.2. Relevancia Módszer A relevancia egész általánosan az információ fontossága, jelentősége. Valamivel szűkebb értelemben az adott kérdésre kapott információk meghatározó, lényeges volta. Az adott keresőkérdés vonatkozásában relevánsak a visszakeresett tételek, amelyek objektív értelemben megfelelnek a feltett kérdésnek. [12] Nézzük, hogyan alkalmazhatjuk ezt a fogalmat egy keresőrendszer értékelésénél! A dokumentumtár elemeit, egy lekérdezés eredményére vonatkozóan, négy diszjunkt halmazba oszthatjuk, melyet a 5.1 táblázat szemléltet táblázat. Információ a relevancia szempontjából releváns nem releváns megtalált A B nem megtalált C D Az egyes csoportokat a következőképpen szokás nevezni: A (megtalált releváns elemek) találatok (hits) B (megtalált nem releváns elemek) zaj (noise) C (releváns kihagyott elemek) veszteség (misses, losses) D (nem releváns kihagyott elemek) érdektelen információk 5.1 jelöléseit alkalmazva további fogalmakat definiálhatunk, melyekkel már leírható egy keresés eredményessége. Pontosság 1 Annak számossága, hogy a keresés eredményei között mennyi releváns: Teljesség 2 A / A B A / A C A megtalált és az összes releváns elem mennyiségének hányadosa: Ezekkel a mutatókkal már sok minden kifejezhető, de mivel egymástól nem függetlenek, önmagukban nem adnak egzakt módszert egy keresőrendszer eredményességének 1 angol nyelvű szakirodalomban precision 2 angol nyelvű szakirodalomban recall 50

51 mérésére. Az is nyilvánvaló, hogy a két mennyiség egymással fordított arányban áll: növelve egy rendszer pontosságát, veszíthetünk a teljességéből, és a teljességet célul tűzve a pontossági érték romolhat. Ezek miatt a két mutató valamilyen kombinációját szokás alkalmazni. A legelterjedtebb mérték az ún. F mérték, mely az alábbi képlettel számolható: F β = (1+β2 ) (P R) (β 2 P +R), ahol P a pontosságot, míg R a teljességet jelöli. A β paraméter a P és az R értékek súlyát határozza meg a súlyozott harmonikus középértékben, és leggyakrabban értékét 1-nek választják. A fentiek jól alkalmazhatóak olyan keresőrendszerekre, amik az eredménylistában nem határoznak meg rangokat 3. Más a helyzet viszont az olyan keresők esetén, ahol az eredménylista az elemekhez rendelt rang alapján rendezett halmaz. Ekkor az F mérték, figyelmen kívül hagyja ezt a rangsorolást. Ennek kiküszöbölésére a kutatók több módszert is javasolnak[16, 8], melyekből az egyik legjobb tulajdonságokkal bíró metrika az ún. Mean Average Precision 4. Ezt a követező módon számolhatjuk: N r=1 (P (r) rel(r)) R, ahol N a találati listában szereplő elemek száma, rel(x) értéke 1, ha az x-edik elem a listában releváns, egyébként 0, P (x) a pontosság a találati lista első x elemére szűkítve, R pedig a tárban található releváns dokumentumok számossága. Már láttuk, hogy egy eredményhalmazt hogyan tudunk értékelni, ha meg tudjuk különböztetni a releváns dokumentumokat a nem relevánsoktól. Arról még nem ejtettem szót, hogy mihez viszonyítva is határozzuk meg egy dokumentum alkalmasságát: a szakirodalomban[8] a relevancia meghatározása mindig az információ igényeknek megfelelően történik. Ez a gyakorlatban azt jelenti, hogy nem a keresőkifejezéshez viszonyítjuk a találatokat, hanem egy előre megfogalmazott kérdéshez (aminek már csak egy reprezentációja a keresőkifejezés). Mindezek alapján a méréshez szükségem van: 1. természetes nyelven megfogalmazott, egzakt információ igényekre, melyek a kereső nyelvén is kifejezhetőek, 2. az igényeknek megfelelő keresőkifejezésekre, 3. jól körülhatárolt dokumentumhalmazra, melyekben az egyes igényeknek megfelelően osztályozva vannak a releváns és nem releváns dokumentumok, 4. metrikára. 3 minden elemet egyformán jónak minősítenek 4 a továbbiakban MAP 51

52 5.2. táblázat. A továbbfejlesztett rendszer és az Indri eredményességének összehasonlítása a MAP metrika segítségével Indri 54% szótövezéssel 69% szinonimákkal 69% mennyiségfelismeréssel 57% dátumfelismeréssel 59% eszközök együttes 59% használatával Mérési eredmények A kereső értékelésének vizsgálatához elkészítettem egy jól körülhatárolt dokumentumhalmazt, meghatároztam olyan természetes nyelvi kérdéseket, melyekről azt gondoltam, hogy parlamenti naplókat olvasva választ találok, a kérdéseket többféleképpen kifejeztem az Indri Query Language segítségével (ahol a hozzáadott funkcióktól javulás volt várható javítottam az eredeti kifejezésen), és a kérdéseknek megfelelően osztályoztam a dokumentumokat. A lekérdezésének eredményességét a MAP metrikával vizsgáltam. Lefuttatva és értékelve a kereséseket, majd átlagolva ezek eredményét, a 5.2 táblázatban látható relevancia értékeket kaptam. A mérési eredményeket vizsgálva fontos szem előtt tartani, hogy keresőrendszerek értékelése során különösen a keresőkifejezések létrehozásakor számos olyan döntést hoztam, melyeknél nem állt rendelkezésemre egzakt eszköz a lehetőségek vizsgálatára. Így a mérés eredménye a szubjektivitásból adódóan megfelelő fenntartással kezelendő. Ennek ellenére most megpróbálom ezek mentén értékelni munkámat. A számadatokból első pillantásra az olvasható ki, hogy bár nem sokkal, de mindegyik eszköz képes javítani a találati pontosságon. A mérések során a pontossággal és teljességgel kapcsolatban változó tapasztalatokat szereztem. Sokszor fordult elő az, hogy például szinonimákat használva az eredménylista zaja nőtt, a pontosság helyett. Hasonló tapasztalataim voltak a mennyiség és dátumfelismeréssel, míg a szótövezés szinte mindig növelte az eredményességet. 52

53 Úgy gondolom, hogy ezeket a negatív kilengéseket számos tényező okozhatta. Szinonimák használata esetén azt tapasztaltam, hogy az olyan keresőszavak használatánál, melyek amúgy is rontottak a pontosságon, hozzávéve annak rokon értelmű párjait katalizáltam ezt a rossz folyamatot. Másrészről hasznos eszköznek bizonyult akkor, amikor köznapi nyelven megfogalmazott kifejezésre alkalmaztam, ugyanis a parlamenti naplókban gyakran találkoztam hivataloskodó szóhasználattal, amit tartalmazó szövegrészeket így el tudtam érni. A mennyiség és dátumfelismeréskor megélt kudarcokat többségében annak tulajdonítom, hogy egy-egy parlamenti napló a méreténél fogva számos témát ölel fel. A rendszer nem képes elkülöníteni ezeket egymástól, így a bennük található mennyiségekre és dátumformákra keresve sokszor inkább csak a zaj növekszik. Ugyanakkor úgy gondolom az sem véletlen, hogy mégis sikerült kimutatható javulást elérni ezek használatával: dátumokat gyakran használunk, és ha rendelkezünk az információ igényhez kapcsolódó időponthoz köthető kiegészítő adatokkal, akkor jelentős javulást érhetünk el Összefoglalás Összességében elmondható, hogy a készített eszközök mind teljesítményben, mind pedig relevancia szempontjából nem rontottak az eredeti kereső működésén. Mindenképpen sikernek könyvelhető el, hogy új, eddig nem használt funkcionalitásokkal gazdagodott az Indri, melyek javíthatnak a lekérdezések eredményességén. Általánosságban még az is elmondható, hogy a modulok helyes használatához, némi szakértelemre és körültekintésre van szükség. Meggondolatlanul alkalmazva őket, jelentősen romolhat a keresőrendszer átlagos relevanciája. 53

54 Köszönetnyilvánítás Szeretném megköszönni Dr. Prószéky Gábornak a munkám során nyújtott támogatását, a kapott hasznos ötleteket, javaslatokat; a MorphoLogic tulajdonát képező nyelvi elemzőt és az országgyűlési naplók adatbázisát. Köszönettel tartozom még Endrédy Istvánnak, aki a nyelvi eszközök használata során látott el hasznos technikai információkkal. Sokat köszönhetek még David Fishernek, aki a Lemur projekt egyik gazdája, és a keresőrendszer használatával kapcsolatos kérdéseimre mindig készségesen válaszolt. Hálával tartozom még családomnak a dolgozat elkészítése során tanúsított türelmükért. 54

55 Függelék Tiltólistás szavak jegyzéke a az abban abból ahhoz ahogy ahol akár aki akik akkor alá alapján alatt által általában amely amelyben amelyek amelyekben amelyeket amelyet amelyik amelynek ami amíg amikor amiről amit amolyan annak arra arról át az azért azok azokat azoknak azon azonban azt aztán azután azzal ban bár be belül ben benne bizony bizonyos biztos csak csupán de e ebben ebből eddig egész egészen egy egyéb egyébként egyértelműen egyes egyet egyetlen egyik egyre 55

56 egyrészt egységes ehhez ekkor el elé elég ellen ellenére elő előbb először előtt előtti első elsősorban emilyen én ennek ennél éppen erre erről és esetén esetleg ez ezek ezeket ezen ezért ezt ezzel fel felé fog fognak gyakorlatilag ha hanem hát helyett hiszem hiszen hogy hogyan hogyha hozzá ide igen így ill illetőleg illetve ilyen ilyenkor inkább is ismét itt jelenlegi jó jobban jól kapcsán kapcsolatban kapcsolatos kell kellene kellett képest keresztül ki kicsit kíván kívül korábban korábbi köszönöm követően között közül különböző le legalább legyen lehet lehetett lehetséges lenne lenni lesz lett maga magát majd már más másik meg még megfelelő mégis mellett mely 56

57 melyek mert mi miatt miért míg mikor miközben milyen mind minden mindenképpen mindenki mindent mindig minél mint mintegy mintha mit mivel módon most nagy nagyobb nagyon ne néha néhány nekem neki nekünk nélkül nem nemcsak nincs nyilván oda olyan ott ő ők őket ön öné önök össze pedig például persze pontosan rá s sajnos se sem semmi senki sok sokat sokkal során sőt szerint szét szinte szintén szükséges talán te tehát tekintettel teljes tényleg természetesen ti tisztelt tovább továbbá további több túl tűnik úgy ugyan ugyanakkor ugyancsak ugyanis új újabb újra után utána utolsó ügy vagy vagyis vagyok vagyunk vajon valaki valamennyi valami valamilyen valamint 57

58 való valóban van vannak végre végül vele viszont vissza volna volt voltak voltam voltunk Konfigurációs fájl A konfigurációs fájl DTD specifikációja a következő: <!-- XML --> <!ELEMENT UDML (separators, units, dates)> <!ELEMENT separators (sep+)> <!ELEMENT sep (#PCDATA)> <!ATTLIST sep isdecimal CDATA #REQUIRED> <!ELEMENT units (unit+)> <!ELEMENT unit (#PCDATA)> <!ATTLIST unit type CDATA #REQUIRED> <!ATTLIST unit multiplier CDATA #REQUIRED> <!ELEMENT dates (date+)> <!ELEMENT date (#PCDATA)> A mezők jelentése: separators elválasztókarakterek, az egyes sep mezők elemei azok a karakterek, melyek elválasztják a mennyiséget jelölő kifejezés részeit. Az isdecimal attribútum true értéke esetén pedig a mező értékére tizedes elválasztó karakterként tekint a feldolgozó program. units felismerendő mennyiségek listája unit egy felismerendő mennyiségi tulajdonság egy mértékegysége, például súlymérték estén kg, g. Attribútumai: type a jelölt mennyiségi tulajdonsághoz létrehozandó field neve. Pl.: weight multiplier a mennyiségi tulajdonság SI mértékegységéhez viszonyított szorzó. Pl.: kg esetén

59 dates a használandó dátumformák listája. Értékei a ban leírt dátumnyelv elemei. A mérések futtatásához használt konfigurációs fájl: <?xml version="1.0"?> <!DOCTYPE UDML SYSTEM "conf.dtd"> <UDML> <separators> <sep isdecimal="true">,</sep> <sep isdecimal="false">\s</sep> </separators> <units> <unit type="weight" multiplier="1000">kg</unit> <unit type="length" multiplier="1000">km</unit> <unit type="deviza" multiplier="1">forint</unit> <unit type="deviza" multiplier="270">euro </unit> <unit type="deviza" multiplier="270">euró</unit> <unit type="deviza" multiplier="180">dollár</unit> </units> <dates> <date>yyyy. month d.</date> <date>yyyy. month dd.</date> <date>yyyy. month d-</date> <date>yyyy. month dd-</date> <date>yyyy. mon. d.</date> <date>yyyy. mon. dd.</date> <date>yyyy. mon. d-</date> <date>yyyy. mon. dd-</date> <date>yyyy. month d.</date> <date>yyyy.mm.dd.</date> <date>yyyy.mm.d.</date> <date>yyyy.mm.dd</date> <date>yyyy.mm.d</date> </dates> </UDML> 59

60 Felhasználói dokumentáció A készített program célja, hogy lehetőséget biztosítson strukturált lekérdezések futtatására, egy tetszőlegesen választott magyar nyelvű dokumentumhalmazon. A felhasználónak az Indri képességein túl lehetősége nyílik: magyar nyelvű szövegben való intelligens szótő szerinti keresésre, magyar nyelvű automatikus szinonima használatra, magyar nyelvterületeken szokásos dátumok használatára a dokumentumhalmazban, ezek felismerésére, keresésére, tetszőleges mennyiségi információk használatára a dokumentumhalmazban olyan módon, hogy az a keresés során elérhető összehasonlító operátorokkal is kereshetővé váljon. A kiegészített keresőrendszer több futtatható alprogramból áll, melyekből a legfontosabbak: dátum és mennyiség jelölő előfeldolgozó program, index készítő alkalmazás, webes felület. Az alábbiakban ezek telepítését és használatát tekintem át. Rendszerkövetelmények A készített alkalmazás futtatásához, az alábbi hardver konfiguráció ajánlott: >1000 MHz processzor, >512 RAM, 300 MB szabad tárhely. A működéshez szükséges szoftverkörnyezet a következő 5 : 32 bites Linux operációs rendszer Boost programkönyvtár Regex komponense (1.38<) Apache Tomcat < Sun Java Runtime Environment 1.6< 5 A készített programhoz mellékeltem a MorphoLogic tulajdonát képező morfológiai elemző modul időkorlátos verzióját, mely december 31.-ig működik. Ha az olvasó az alkalmazást ettől tovább szeretné használni, kérem vegye fel a kapcsolatot a készítő céggel. 60

61 Telepítés Az alábbi lépéseket követően használhatjuk a programot: 1. Az alkalmazás könyvtárstruktúrájában lévő lib mappát tegyük elérhetővé a PATH rendszerváltozóban. 2. Telepítsük a Tomcat webszervert. 3. A web mappában található war kiterjesztésű fájlt adjuk hozzá a Tomcat szerver alkalmazásaihoz. 4. A Tomcat alkalmazás META-INF könyvtárának context.xml fájljában állítsuk be az alábbi paraméterek értékét 6 : index.indri.stemmed szótövezést használó index elérési útja, index.indri.plain eszközöket nélkülöző index elérési útja, index.indri.stemmedstopped szótövezést és tiltólistás szavak szűrését használó index elérési útja, index.indri.stopped csak tiltólistás szavak szűrését használó index elérési útja. 5. Helyezzük a conf.xml, conf.dtd fájlt és a lex könyvtárat a Tomcat futtatási könyvtárába! Előfeldolgozó Az előfeldolgozó programot a bin mappa fieldannotator alkalmazásával indíthatjuk el. Használat a következő: fieldannotator <fromfile> <tofile>, ahol a fromfile a feldolgozandó fájlt jelöli a tofile pedig a létrehozandó új fájlt. A program futtatásához szükséges, hogy korábban említett conf.xml elérhető legyen a futtató környezetéből Ebben a konfigurációs fájlban 7 adhatjuk meg, hogy milyen dátumformákkal és mennyiség típusokkal szeretnénk a keresőrendszert használni. Egy minta fájl található az examples mappában. 6 A program mellékleteként az env könyvtárban megtalálhatóak az általam használt indexek is. 7 Használatához lásd a Konfigurációs fájl alrészt 61

62 Indexelő alkalmazás Indexelő alkalmazásként az Indri BuildIndex alprogramja használandó. Ennek a futtatásához is szükséges a conf.xml fájl elérhetősége, és fontos, hogy az előfeldolgozáskor és az indexeléskor a konfigurációs fájl tartalma megegyezzen. Az indexelés indítása a buildindex <parameterfile> paranccsal történik. A paraméter fájl formátuma az eredeti rendszer leírásának 8 megfelelő. Ahhoz, hogy a magyar nyelvi eszközöket használhassuk, az alábbi sorokkal kell kiegészíteni azt: magyar nyelvű szótövezéshez <stemmer><name>hunstemmer</name></stemmer> dátumfelismeréshez <field> <name>date</name> <numeric>true</numeric> <parsername>hundatefieldannotator</parsername> </field> mennyiségek felismeréshez a lenti kódsorokat annyiszor ahányféle mennyiséget szeretnénk használni. Az M helyére mindig a mennyiséget jelölő conf.xml-ben is megtalálható kulcsszó írandó. Pl.: Weigl, deviza <field> <name>m</name> <numeric>true</numeric> <parsername>unitfieldannotator</parsername> </field> Egy példa paraméter fájl található az examples könyvtárban. Kereső alkalmazás A Tomcat szerver elindítása és az indexek elérési útjának beállítása után, a localhost:8080/indriweb 9 címre navigálva érhetjük el a webes lekérdező felületet. Ennek formája a 6.1 ábrán látható a 8080 a Tomcat által használt alapértelmezett port, de ez persze módosítható, és ezzel együtt a hivatkozás is változik 62

63 6.1. ábra. A keresőrendszer lekérdező felülete. A felhasználói interfész négy részből áll: keresőmező szótövezést választó gomb stopword szűrést választó gomb eredmények A keresőmezőbe begépelve, majd Enter-t ütve indíthatjuk el a keresést. Szinonima használatra a ~ operátorral van lehetőség, mégpedig úgy, hogy ezt a kívánt szó elé írjuk. A lekérdezés a választó gombok által meghatározott indexen fog végrehajtódni. A találati lista első tíz eleme a keresőmező alatt jelenik meg. Fejlesztői dokumentáció A keresőrendszer továbbfejlesztéséhez az alábbi eszközöket használtam fel: GCC fordító SWIG Boost 1.38 programkönyvtár Sun JAVA JDK Eclipse 3.4 (CDT modullal) Iconv programkönyvtár 63

Bináris egység: bit (binary unit) bit ~ b; byte ~ B (Gb Gigabit;GB Gigabyte) Gb;GB;Gib;GiB mind más. Elnevezés Jele Értéke Elnevezés Jele Értéke

Bináris egység: bit (binary unit) bit ~ b; byte ~ B (Gb Gigabit;GB Gigabyte) Gb;GB;Gib;GiB mind más. Elnevezés Jele Értéke Elnevezés Jele Értéke Kódolások Adatok kódolása Bináris egység: bit (binary unit) bit ~ b; byte ~ B (Gb Gigabit;GB Gigabyte) Gb;GB;Gib;GiB mind más. Elnevezés Jele Értéke Elnevezés Jele Értéke Kilo K 1 000 Kibi Ki 1 024 Mega

Részletesebben

BARANGOLÁS AZ E-KÖNYVEK BIRODALMÁBAN Milyen legyen az elektonikus könyv?

BARANGOLÁS AZ E-KÖNYVEK BIRODALMÁBAN Milyen legyen az elektonikus könyv? BARANGOLÁS AZ E-KÖNYVEK BIRODALMÁBAN Milyen legyen az elektonikus könyv? Készítették: Névery Tibor és Széll Ildikó PPKE I. évf. kiadói szerkesztő hallgatók, közösen 1 BEVEZETŐ Az elektronikus könyv valamilyen

Részletesebben

Tudásalapú információ integráció

Tudásalapú információ integráció Tudásalapú információ integráció (A Szemantikus Web megközelítés és a másik irány) Tanszéki értekezlet, 2008. május 14. 1 Miért van szükségünk ilyesmire? WWW: (Alkalmazások) Keresés a weben (pl. összehasonlítás

Részletesebben

KnowledgeTree dokumentumkezelő rendszer

KnowledgeTree dokumentumkezelő rendszer KnowledgeTree dokumentumkezelő rendszer Budapest, 2011. január 11. Tartalomjegyzék Tartalomjegyzék... 2 Dokumentum információ... 3 Változások... 3 Bevezetés... 4 Funkciók... 5 Felhasználói felület... 5

Részletesebben

2. 3. Keresés az Interneten. Navigáció az Interneten: Megoldások. Internetes keresés buktatói. 1. Keresőmotorok. Webes keresési lehetőségek

2. 3. Keresés az Interneten. Navigáció az Interneten: Megoldások. Internetes keresés buktatói. 1. Keresőmotorok. Webes keresési lehetőségek Keresés az Interneten Navigáció az Interneten: Keresőrendszerek, keresési tippek Egyszerű keresőrendszerek Tematikus keresőrendszerek, katalógusok Portálok Adatbázisok, online folyóiratok Elektronikus

Részletesebben

Közoktatási Statisztika Tájékoztató 2012/2013. Használati útmutató

Közoktatási Statisztika Tájékoztató 2012/2013. Használati útmutató Közoktatási Statisztika Tájékoztató 2012/2013 Tartalomjegyzék 1. Technikai információk... 2 2. Publikus felület... 2 2.1 Bejelentkezés... 2 2.2 Összesítés... 3 2.2.1 Statisztikai tábla megtekintése...

Részletesebben

Szövegbányászati rendszer fejlesztése a Magyar Elektronikus Könyvtár számára

Szövegbányászati rendszer fejlesztése a Magyar Elektronikus Könyvtár számára Szövegbányászati rendszer fejlesztése a Magyar Elektronikus Könyvtár számára Vázsonyi Miklós VÁZSONYI Informatikai és Tanácsadó Kft. BME Információ- és Tudásmenedzsment Tanszék 1/23 Tartalom A MEK jelenlegi

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

Részletesebben

Internet programozása. 1. előadás

Internet programozása. 1. előadás Internet programozása 1. előadás Áttekintés 1. Mi a PHP? 2. A PHP fejlődése 3. A PHP 4 újdonságai 4. Miért pont PHP? 5. A programfejlesztés eszközei 1. Mi a PHP? Egy makrókészlet volt, amely személyes

Részletesebben

KERESÉS A NETEN DR. KÓNYA LÁSZLÓ: KERESÉS A NETEN KERESÉS MÓDSZERE, KERESŐPROGRAMOK 2004.04.20

KERESÉS A NETEN DR. KÓNYA LÁSZLÓ: KERESÉS A NETEN KERESÉS MÓDSZERE, KERESŐPROGRAMOK 2004.04.20 INTERNET 1/42 KERESÉS A NETEN DR. KÓNYA LÁSZLÓ: KERESÉS A NETEN KERESÉS MÓDSZERE, KERESŐPROGRAMOK 2004.04.20 FORRÁS: TARR BENCE : KERESÉS AZ INTERNETEN PANEM KIADÓ, 2001 ISBN 963 545 326 4 INTERNET 2/42

Részletesebben

Egyirányban láncolt lista

Egyirányban láncolt lista Egyirányban láncolt lista A tárhely (listaelem) az adatelem értékén kívül egy mutatót tartalmaz, amely a következő listaelem címét tartalmazza. A láncolt lista első elemének címét egy, a láncszerkezeten

Részletesebben

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás Petőfi Irodalmi Múzeum A Digitális Irodalmi Akadémia megújuló rendszere technológiaváltás II. Partnerek, feladatok Petőfi Irodalmi Múzeum Megrendelő, szakmai vezetés, kontroll Konzorcium MTA SZTAKI Internet

Részletesebben

1. tétel. A kommunikáció információelméleti modellje. Analóg és digitális mennyiségek. Az információ fogalma, egységei. Informatika érettségi (diák)

1. tétel. A kommunikáció információelméleti modellje. Analóg és digitális mennyiségek. Az információ fogalma, egységei. Informatika érettségi (diák) 1. tétel A kommunikáció információelméleti modellje. Analóg és digitális mennyiségek. Az információ fogalma, egységei Ismertesse a kommunikáció általános modelljét! Mutassa be egy példán a kommunikációs

Részletesebben

Zimbra levelező rendszer

Zimbra levelező rendszer Zimbra levelező rendszer Budapest, 2011. január 11. Tartalomjegyzék Tartalomjegyzék... 2 Dokumentum információ... 3 Változások... 3 Bevezetés... 4 Funkciók... 5 Email... 5 Társalgás, nézetek, és keresés...

Részletesebben

Az alábbi kód egy JSON objektumot definiál, amiből az adtokat JavaScript segítségével a weboldal tartalmába ágyazzuk.

Az alábbi kód egy JSON objektumot definiál, amiből az adtokat JavaScript segítségével a weboldal tartalmába ágyazzuk. JSON tutorial Készítette: Cyber Zero Web: www.cyberzero.tk E-mail: cyberzero@freemail.hu Msn: cyberzero@mailpont.hu Skype: cyberzero_cz Fb: https://www.facebook.com/cyberzero.cz BEVEZETÉS: A JSON (JavaScript

Részletesebben

Újdonságok az SDL Trados Studio 2009 SP2-ben

Újdonságok az SDL Trados Studio 2009 SP2-ben Újdonságok az SDL Trados Studio 2009 SP2-ben Szekeres Csaba SDL Trados partner szekeres.csaba@m-prospect.hu M-Prospect Kft. New Platform Internal Training Fókuszban Az SDL Trados Studio 2009 SP2 legfőbb

Részletesebben

A KÖZÉPSZINTŰ ÉRETTSÉGI VIZSGA INFORMATIKA TÉMAKÖREI: 1. Információs társadalom

A KÖZÉPSZINTŰ ÉRETTSÉGI VIZSGA INFORMATIKA TÉMAKÖREI: 1. Információs társadalom A KÖZÉPSZINTŰ ÉRETTSÉGI VIZSGA INFORMATIKA TÉMAKÖREI: 1. Információs társadalom 1.1. A kommunikáció 1.1.1. A kommunikáció általános modellje 1.1.2. Információs és kommunikációs technológiák és rendszerek

Részletesebben

KÖVETKEZŐ GENERÁCIÓS NAGYVÁLLALATI TARTALOMKEZELŐ MEGOLDÁSOK Stratis Kft. / Autonomy üzleti reggeli / 2014.10.16. Mezei Ferenc üzletág-igazgató

KÖVETKEZŐ GENERÁCIÓS NAGYVÁLLALATI TARTALOMKEZELŐ MEGOLDÁSOK Stratis Kft. / Autonomy üzleti reggeli / 2014.10.16. Mezei Ferenc üzletág-igazgató KÖVETKEZŐ GENERÁCIÓS NAGYVÁLLALATI TARTALOMKEZELŐ MEGOLDÁSOK Stratis Kft. / Autonomy üzleti reggeli / 2014.10.16. Mezei Ferenc üzletág-igazgató Hasonló, mégis más Ez se rossz amíg ezt ki nem próbáltad!

Részletesebben

C++ programozási nyelv

C++ programozási nyelv C++ programozási nyelv Gyakorlat - 13. hét Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. december A C++ programozási nyelv Soós Sándor 1/10 Tartalomjegyzék Objektumok

Részletesebben

Fejlett kereső és lekérdező eszközök egy elektronikus szakfolyóirathoz (IBVS)

Fejlett kereső és lekérdező eszközök egy elektronikus szakfolyóirathoz (IBVS) Networkshop, 2008 Márc. 17 19., Dunaújváros Holl Erdődi: Fejlett kereső... 1 Fejlett kereső és lekérdező eszközök egy elektronikus szakfolyóirathoz (IBVS) Holl András Erdődi Péter MTA Konkoly Thege Miklós

Részletesebben

KARAKTERFELISMERÉS AZ EVASYS-BEN

KARAKTERFELISMERÉS AZ EVASYS-BEN KARAKTERFELISMERÉS AZ EVASYS-BEN HOL HASZNÁLHATÓ, KI HASZNÁLHATJA A Miskolci Egyetem megvásárolta a kézírásfelismerés (ICR) modult az Evasys legutóbbi licencével együtt. Ezzel lehetőség nyílt a papír alapú

Részletesebben

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

Részletesebben

Internetes keresés. Menedzsment modul. Nyugat-Magyarországi Egyetem Földmérési és Földrendezői Főiskolai Kar SdiLA menedzsment-képzés.

Internetes keresés. Menedzsment modul. Nyugat-Magyarországi Egyetem Földmérési és Földrendezői Főiskolai Kar SdiLA menedzsment-képzés. Nyugat-Magyarországi Egyetem Földmérési és Földrendezői Főiskolai Kar Menedzsment modul Internetes keresés Készítette: Fábián József okl.építőmérnök 2000. április 17. Bevezetés Az Internet egy nemzetközi

Részletesebben

Adatkeresés az interneten. Cicer Norbert 12/K.

Adatkeresés az interneten. Cicer Norbert 12/K. Adatkeresés az interneten Cicer Norbert 12/K. Internetes keresőoldalak Az internet gyakorlatilag végtelen adatmennyiséget tartalmaz A dokumentumokat és egyéb adatokat szolgáltató szerverek száma több millió,

Részletesebben

Adatbázis rendszerek. dr. Siki Zoltán

Adatbázis rendszerek. dr. Siki Zoltán Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti

Részletesebben

Gyakorlati vizsgatevékenység A

Gyakorlati vizsgatevékenység A Gyakorlati vizsgatevékenység A Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

vbar (Vemsoft banki BAR rendszer)

vbar (Vemsoft banki BAR rendszer) vbar (Vemsoft banki BAR rendszer) BAR bemutatása 1994. július 1-jétől kezdte meg működését a Központi Adós- és Hitelinformációs Rendszer, azóta is használt rövidített nevén a BAR, amely kezdetben kizárólag

Részletesebben

Digitális írástudás kompetenciák: IT alpismeretek

Digitális írástudás kompetenciák: IT alpismeretek Digitális írástudás kompetenciák: IT alpismeretek PL-5107 A továbbképzés célja: A program az alapvető számítógépes fogalmakban való jártasságot és a számítógépek alkalmazási területeinek ismeretét nyújtja

Részletesebben

Informatika. 3. Az informatika felhasználási területei és gazdasági hatásai

Informatika. 3. Az informatika felhasználási területei és gazdasági hatásai Informatika 1. Hírek, információk, adatok. Kommunikáció. Definiálja a következő fogalmakat: Információ Hír Adat Kommunikáció Ismertesse a kommunikáció modelljét. 2. A számítástechnika története az ENIAC-ig

Részletesebben

Programozás alapjai Bevezetés

Programozás alapjai Bevezetés Programozás alapjai Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Programozás alapjai Bevezetés SWF1 / 1 Tartalom A gépi kódú programozás és hátrányai A magas szintÿ programozási nyelv fogalma

Részletesebben

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények 1. sz. melléklet MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS A) Műszaki követelmények A körkereső szoftvernek (a továbbiakban Szoftver) az alábbi követelményeknek kell megfelelnie

Részletesebben

FEJLETT INFORMÁCIÓKERESÉSI TECHNOLÓGIA A FELSŐOKTATÁSBAN

FEJLETT INFORMÁCIÓKERESÉSI TECHNOLÓGIA A FELSŐOKTATÁSBAN FEJLETT INFORMÁCIÓKERESÉSI TECHNOLÓGIA A FELSŐOKTATÁSBAN Karácsony Gyöngyi, e-mail cím Debreceni Egyetem Jóföldi Endre, jofoldi.endre@polymeta.hu K-prog Bt. Összefoglaló Milyen problémákkal szembesülünk

Részletesebben

Hozzávalók keresése és csatolása

Hozzávalók keresése és csatolása Hozzávalók keresése és csatolása VUE támogatja digitális tartalmak hozzáadását saját gépről, WEB-ről, távoli rendszerekből, mint az FTP oldalak, digitális forrásokból és Google szerverekről. A tartalmak

Részletesebben

Felhasználói dokumentáció. a TávTagTár programhoz. Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43

Felhasználói dokumentáció. a TávTagTár programhoz. Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43 a TávTagTár programhoz Készítette: Nyíri Gábor, hdd@nc-studio.com GDF Abakusz regisztrációs kód: GDFAba43 Tartalomjegyzék Futási feltételek... 3 Telepítés... 3 Indítás... 3 Főablak... 4 Új személy felvétele...

Részletesebben

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás A Mobil multimédiás kliens fejlesztői eszközkészlet létrehozása című kutatás-fejlesztési projekthez A dokumentum célja A dokumentum

Részletesebben

Microsoft Access alapok

Microsoft Access alapok Microsoft Access alapok Képzési program Cím: 1027 Budapest, Csalogány utca 23. (a) A tanfolyam célja (a képzés során megszerezhető kompetencia) A tanfolyamot azoknak ajánljuk, akik már jártasságát szereztek

Részletesebben

Multimédiás adatbázisok

Multimédiás adatbázisok Multimédiás adatbázisok Multimédiás adatbázis kezelő Olyan adatbázis kezelő, mely támogatja multimédiás adatok (dokumentum, kép, hang, videó) tárolását, módosítását és visszakeresését Minimális elvárás

Részletesebben

Projekt beszámoló. NEWSIT News basedearlywarning System forintradaytrading: Hír alapú Korai Figyelmeztető Rendszer Napon belüli Kereskedéshez

Projekt beszámoló. NEWSIT News basedearlywarning System forintradaytrading: Hír alapú Korai Figyelmeztető Rendszer Napon belüli Kereskedéshez Projekt beszámoló Projekt azonosítója: Projektgazda neve: Projekt címe: DAOP-1.3.1-12-2012-0080 Pénzügyi Innovációs Iroda Kft. NEWSIT News basedearlywarning System forintradaytrading: Hír alapú Korai Figyelmeztető

Részletesebben

E-Kataszteri rendszer ismertető

E-Kataszteri rendszer ismertető E-Kataszteri rendszer ismertető Az E-Szoftverfejlesztő Kft. által fejlesztett KATAwin kataszteri és eszköznyilvántartó rendszert 2,600 db önkormányzat alkalmazza évek óta. Teljeskörű Certop minősítéssel

Részletesebben

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat:

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Karbantartás Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Jelszó módosítása: A felhasználói jelszavunkat módosíthatjuk ebben a menüpontban, a régi jelszavunk megadása után. Általánosan

Részletesebben

KÉPZÉSI PROGRAM. GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02. Szolnok

KÉPZÉSI PROGRAM. GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02. Szolnok KÉPZÉSI PROGRAM GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02 Szolnok 2015 KÉPZÉSI PROGRAM A képzési program Megnevezése Gazdasági informatikus OKJ azonosító 54 481 02 A képzés során megszerezhető kompetenciák

Részletesebben

VBA makrók aláírása Office 2007 esetén

VBA makrók aláírása Office 2007 esetén VBA makrók aláírása Office 2007 esetén Windows tanúsítványtárban és/vagy kriptográfia eszközökön található tanúsítványok esetén Office 2007 alkalmazással 1(10) 1. Tartalomjegyzék 1. Tartalomjegyzék...

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Gépi tanulás a gyakorlatban. Bevezetés

Gépi tanulás a gyakorlatban. Bevezetés Gépi tanulás a gyakorlatban Bevezetés Motiváció Nagyon gyakran találkozunk gépi tanuló alkalmazásokkal Spam detekció Karakter felismerés Fotó címkézés Szociális háló elemzés Piaci szegmentáció analízis

Részletesebben

Gyakorlati vizsgatevékenység B

Gyakorlati vizsgatevékenység B Gyakorlati vizsgatevékenység Szakképesítés azonosító száma, megnevezése: 481 04 0000 00 00 Web-programozó Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1189-06 Web-alkalmazás fejlesztés

Részletesebben

ÉRETTSÉGI TÉTELCÍMEK 2012 Informatika

ÉRETTSÉGI TÉTELCÍMEK 2012 Informatika Budapesti Egyetemi Katolikus Gimnázium és Kollégium ÉRETTSÉGI TÉTELCÍMEK 2012 Informatika Reischlné Rajzó Zsuzsanna Szaktanár Endrédi Józsefné Igazgató Kelt: Budapest, 2012 március 1. tétel A kommunikáció

Részletesebben

KÖNYVTÁRI KATALÓGUS HASZNÁLATI ÚTMUTATÓ

KÖNYVTÁRI KATALÓGUS HASZNÁLATI ÚTMUTATÓ KÖNYVTÁRI KATALÓGUS HASZNÁLATI ÚTMUTATÓ Mi az OPAC? Az OPAC az Online Public Access Catalogue rövidítése. Jelentése olyan számítógépes katalógus, mely nyilvános, bárki számára közvetlenül, általában ingyen

Részletesebben

Az internet az egész világot behálózó számítógép-hálózat.

Az internet az egész világot behálózó számítógép-hálózat. Az internet az egész világot behálózó számítógép-hálózat. A mai internet elődjét a 60-as években az Egyesült Államok hadseregének megbízásából fejlesztették ki, és ARPANet-nek keresztelték. Kifejlesztésének

Részletesebben

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport TANMENET Informatika szakmacsoport Programozási gyakorlatok III. tantárgy 12. évfolyam A osztály 2013/2014 tanév Heti óraszám: Éves óraszám: 3 óra 96 óra Készítette: Szikszai Gusztáv tanár Ellenőrizte:.

Részletesebben

Váci Mihály Kulturális Központ Cím: Telefon: Fax: Web: E-mail: Nyilvántartásba vételi szám:

Váci Mihály Kulturális Központ Cím: Telefon: Fax: Web: E-mail: Nyilvántartásba vételi szám: TÁJÉKOZTATÓ Digitális írástudás fejlesztése /D009 A képzés során megszerezhető kompetenciák A képzésben résztvevő: képessé válik a legfontosabb számítástechnikai kifejezések megnevezésére, megérti a számítógép

Részletesebben

Készítette: Enisz Krisztián, Lugossy Balázs, Speiser Ferenc, Ughy Gergely 2010.11.29. 1

Készítette: Enisz Krisztián, Lugossy Balázs, Speiser Ferenc, Ughy Gergely 2010.11.29. 1 Készítette: Enisz Krisztián, Lugossy Balázs, Speiser Ferenc, Ughy Gergely 2010.11.29. 1 /17 Tartalomjegyzék A térinformatikáról általánosságban Célok Felhasznált eszközök Fejlesztés lépései Adatbázis Grafikus

Részletesebben

Informatika szóbeli vizsga témakörök

Informatika szóbeli vizsga témakörök KECSKEMÉTI MŰSZAKI SZAKKÉPZŐ ISKOLA, SPECIÁLIS SZAKISKOLA ÉS KOLLÉGIUM 6000 Kecskemét, Szolnoki út 31., Telefon: 76/480-744, Fax: 487-928 KANDÓ KÁLMÁN SZAKKÖZÉPISKOLA ÉS SZAKISKOLÁJA 6000 Kecskemét, Bethlen

Részletesebben

Java II. I A Java programozási nyelv alapelemei

Java II. I A Java programozási nyelv alapelemei Java2 / 1 Java II. I A Java programozási nyelv alapelemei Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2009. 02. 09. Java II.: Alapelemek JAVA2 / 1 A Java formalizmusa A C, illetve

Részletesebben

Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás?

Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések. 1. Mi a programozás? Bevezetés Kinek szól a könyv? A könyv témája A könyv felépítése Mire van szükség a könyv használatához? A könyvben használt jelölések Forráskód Hibajegyzék p2p.wrox.com xiii xiii xiv xiv xvi xvii xviii

Részletesebben

PDF DOKUMENTUMOK LÉTREHOZÁSA

PDF DOKUMENTUMOK LÉTREHOZÁSA PDF DOKUMENTUMOK LÉTREHOZÁSA A Portable Document Format (PDF) az Adobe Systems által kifejlesztett bináris fájlformátum. Ebben a formátumban dokumentumok tárolhatók, amelyek különbözı szoftverekkel, hardverekkel

Részletesebben

SDL Trados szervermegoldások. Szekeres Csaba SDL Trados partner szekeres.csaba@m-prospect.hu M-Prospect Kft.

SDL Trados szervermegoldások. Szekeres Csaba SDL Trados partner szekeres.csaba@m-prospect.hu M-Prospect Kft. SDL Trados szervermegoldások Szekeres Csaba SDL Trados partner szekeres.csaba@m-prospect.hu M-Prospect Kft. Fókuszban A fájlalapú fordítási memória korlátai SDL TM Server 2009 A fájlalapú terminológiai

Részletesebben

PHP-MySQL. Adatbázisok gyakorlat

PHP-MySQL. Adatbázisok gyakorlat PHP-MySQL Adatbázisok gyakorlat Weboldalak és adatbázisok Az eddigiek során megismertük, hogyan lehet a PHP segítségével dinamikus weblapokat készíteni. A dinamikus weboldalak az esetek többségében valamilyen

Részletesebben

NYILVÁNOS KÖNYVTÁRI KATALÓGUSOK

NYILVÁNOS KÖNYVTÁRI KATALÓGUSOK NYILVÁNOS KÖNYVTÁRI KATALÓGUSOK A bibliográfiák rendszerező jegyzékek, amelyek a dokumentumokról készült leírásokat, valamilyen nézőpont vagy elv alapján egységben láttatják, értelmezik, visszakereshetővé

Részletesebben

A Clipper evolúciója

A Clipper evolúciója A Clipper evolúciója Ismét itt a nyár, a szabadságolások, és ismét dupla számmal jelentkezünk. Egy könnyedebb nyári tartalom érdekében, ebben a számban összefoglaljuk, mi történik a verzióváltáskor. A

Részletesebben

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat.

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. Súgó Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. A lekérdező rendszer a Hírközlési Szolgáltatások és Interfész bejelentések, valamint az

Részletesebben

MÉRY Android Alkalmazás

MÉRY Android Alkalmazás MÉRY Android Alkalmazás Felhasználói kézikönyv Di-Care Zrt. Utolsó módosítás: 2014.06.12 Oldal: 1 / 7 Tartalomjegyzék 1. Bevezetés 3 1.1. MÉRY Android alkalmazás 3 1.2. A MÉRY Android alkalmazás funkciói

Részletesebben

TERC V.I.P. hardverkulcs regisztráció

TERC V.I.P. hardverkulcs regisztráció TERC V.I.P. hardverkulcs regisztráció 2014. második félévétől kezdődően a TERC V.I.P. költségvetés-készítő program hardverkulcsát regisztrálniuk kell a felhasználóknak azon a számítógépen, melyeken futtatni

Részletesebben

Kezdő lépések Outlook Web Access

Kezdő lépések Outlook Web Access Kezdő lépések Outlook Web Access A Central Europe On-Demand Zrt. által, a Telenor Magyarország Zrt. ügyfelei részére nyújtott szolgáltatások rövid kezelési útmutatója Tartalom Bevezetés... 3 Rendszerkövetelmények...

Részletesebben

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu Számonkérés 2 Papíros (90 perces) zh az utolsó gyakorlaton. Segédanyag nem használható Tematika 1. félév 3 Óra Dátum Gyakorlat 1. 2010.09.28.

Részletesebben

Bár a szoftverleltárt elsősorban magamnak készítettem, de ha már itt van, miért is ne használhatná más is.

Bár a szoftverleltárt elsősorban magamnak készítettem, de ha már itt van, miért is ne használhatná más is. SZOFTVERLELTÁR FREE Amennyiben önnek vállalkozása van, akkor pontosan tudnia kell, hogy milyen programok és alkalmazások vannak telepítve cége, vállalkozása számítógépeire, és ezekhez milyen engedélyeik,

Részletesebben

Vonalkód olvasó rendszer. Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1]

Vonalkód olvasó rendszer. Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1] Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1] T a r t a l o m j e g y z é k 1 Bevezetés... 3 1.1 A rendszer rövid leírása... 3 1.2 A dokumentum célja... 3 1.3 A rendszer komponensei... 3 1.4

Részletesebben

C programozási nyelv Pointerek, tömbök, pointer aritmetika

C programozási nyelv Pointerek, tömbök, pointer aritmetika C programozási nyelv Pointerek, tömbök, pointer aritmetika Dr. Schuster György 2011. június 16. C programozási nyelv Pointerek, tömbök, pointer aritmetika 2011. június 16. 1 / 15 Pointerek (mutatók) Pointerek

Részletesebben

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja 1 / 15 Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja Vajna Miklós 2012. január 24. Tartalomjegyzék 2 / 15 1 Bevezető 2 Motiváció 3

Részletesebben

Enterprise extended Output Management. exom - Greendoc Systems Kft. 1

Enterprise extended Output Management. exom - Greendoc Systems Kft. 1 Enterprise extended Output Management exom - Greendoc Systems Kft. 1 exom - Greendoc Systems Kft. 2 Sokféle bementi adatformátum kezelése Adatok fogadása különböző csatornákon Előfeldolgozás: típus meghatározás,

Részletesebben

Az Orbis adatbáziskezelő

Az Orbis adatbáziskezelő ORBIS ADATBÁZIS WEBRE VITELE KÉSZÍTETTE: SOÓS PÉTER 2001. április 13. Bevezetés Ezen írás a NETWORKSHOP 2001 konferenciára készített előadásom anyagának szerkesztett változata. 1994-95. óta sok jelentős

Részletesebben

Beszédfelismerés alapú megoldások. AITIA International Zrt. Fegyó Tibor

Beszédfelismerés alapú megoldások. AITIA International Zrt. Fegyó Tibor Beszédfelismerés alapú megoldások AITIA International Zrt. Fegyó Tibor fegyo@aitia.hu www.aitia.hu AITIA Magyar tulajdonú vállalkozás Célunk: kutatás-fejlesztési eredményeink integrálása személyre szabott

Részletesebben

Az MS Access adatbázis-kezelő program

Az MS Access adatbázis-kezelő program Az adatbázis-kezelő program A tananyagban az alapfogalmak és a tervezési megoldások megismerése után a gyakorlatban is elkészítünk (számítógépes) adatbázisokat. A számítógépes adatbázisok létrehozásához,

Részletesebben

Image Processor BarCode Service. Felhasználói és üzemeltetői kézikönyv

Image Processor BarCode Service. Felhasználói és üzemeltetői kézikönyv Image Processor BarCode Service Áttekintés CIP-BarCode alkalmazás a Canon Image Processor programcsomag egyik tagja. A program feladata, hogy sokoldalú eszközt biztosítson képállományok dokumentumkezelési

Részletesebben

Területi elemzések. Budapest, 2015. április

Területi elemzések. Budapest, 2015. április TeIR Területi elemzések Felhasználói útmutató Budapest, 2015. április Tartalomjegyzék 1. BEVEZETŐ... 3 2. AZ ELEMZÉSBEN SZEREPLŐ MUTATÓ KIVÁLASZTÁSA... 4 3. AZ ELEMZÉSI FELTÉTELEK DEFINIÁLÁSA... 5 3.1.

Részletesebben

Internet alkamazások Készítette: Methos L. Müller Készült: 2010

Internet alkamazások Készítette: Methos L. Müller Készült: 2010 Internet alkamazások Készítette: Methos L. Müller Készült: 2010 Tartalomjegyzék - Tartalomkezelő rendszerek Miért jó a CMS alapú website? CMS rendszerek - Mi szükséges ezen CMS-ekhez? - Információ építészet

Részletesebben

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat:

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Karbantartás Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Jelszó módosítása: A felhasználói jelszavunkat módosíthatjuk ebben a menüpontban, a régi jelszavunk megadása után. Általánosan

Részletesebben

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata Kutatási beszámoló a Pro Progressio Alapítvány számára Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Mérnök informatika szak Orvosi készülékekben használható modern

Részletesebben

1. Szolgáltatásaink. Adatok feltöltése és elemzése. Digitális feltöltés. Analóg korong feltöltés

1. Szolgáltatásaink. Adatok feltöltése és elemzése. Digitális feltöltés. Analóg korong feltöltés v 1.1 1. Szolgáltatásaink Adatok feltöltése és elemzése A Tacho-X rendszer képes a digitális, valamint analóg tachográfból korongokból származó adatokat beolvasni, és elemezni azokat. Az beolvasott adatokat,

Részletesebben

Adatelemzés az R-ben. 2014. április 25.

Adatelemzés az R-ben. 2014. április 25. Adatelemzés az R-ben 2014. április 25. Kísérleti adatok elemzése Kísérlet célja: valamilyen álĺıtás vagy megfigyelés empirikus és szisztematikus tesztelése. Pl. a nők többet beszélnek, mint a férfiak,

Részletesebben

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0 Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax:

Részletesebben

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció H - 1161 Budapest Rákóczi út 76. Tel./Fax.: +36-1-4010159 http://www.pageos.hu toni@pageos.hu DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció A program használható a TOPOBASE

Részletesebben

Kezdő lépések Microsoft Outlook

Kezdő lépések Microsoft Outlook Kezdő lépések Microsoft Outlook A Central Europe On-Demand Zrt. által, a Telenor Magyarország Zrt. részére nyújtott szolgáltatások rövid kezelési útmutatója 1 Tartalom Áttekintés... 3 MAPI mailbox konfiguráció

Részletesebben

SuliStat felhasználói dokumentáció

SuliStat felhasználói dokumentáció SuliStat felhasználói dokumentáció A jelen dokumentáció által tárgyalt program képes egy iskola tanulmányi adataiból statisztikákat készíteni. Osztály illetve iskola szintű statisztika készítésére van

Részletesebben

Produktív környezetben használt, nyílt forráskódú komplex térinformatikai megoldások dr. Siki Zoltán

Produktív környezetben használt, nyílt forráskódú komplex térinformatikai megoldások dr. Siki Zoltán Produktív környezetben használt, nyílt forráskódú komplex térinformatikai megoldások dr. Siki Zoltán BME Általános és Felsőgeodézia tanszék siki@agt.bme.hu Nyiltforrású koncepció Négy szabadság (Richard

Részletesebben

Java-s Nyomtatványkitöltő Program Súgó

Java-s Nyomtatványkitöltő Program Súgó Java-s Nyomtatványkitöltő Program Súgó Hálózatos telepítés Windows és Linux operációs rendszereken A program nem használja a Registry-t. A program három könyvtárstruktúrát használ, melyek a következők:

Részletesebben

Nyilvántartási Rendszer

Nyilvántartási Rendszer Nyilvántartási Rendszer Veszprém Megyei Levéltár 2011.04.14. Készítette: Juszt Miklós Honnan indultunk? Rövid történeti áttekintés 2003 2007 2008-2011 Access alapú raktári topográfia Adatbázis optimalizálás,

Részletesebben

A Szekszárdi I. Béla Gimnázium Helyi Tanterve

A Szekszárdi I. Béla Gimnázium Helyi Tanterve A Szekszárdi I. Béla Gimnázium Helyi Tanterve Négy évfolyamos gimnázium Informatika Készítette: a gimnázium reál munkaközössége 2015. Tartalomjegyzék Alapvetés...3 Egyéb kötelező direktívák:...6 Informatika

Részletesebben

Rekurzió. Dr. Iványi Péter

Rekurzió. Dr. Iványi Péter Rekurzió Dr. Iványi Péter 1 Függvényhívás void f3(int a3) { printf( %d,a3); } void f2(int a2) { f3(a2); a2 = (a2+1); } void f1() { int a1 = 1; int b1; b1 = f2(a1); } 2 Függvényhívás void f3(int a3) { printf(

Részletesebben

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese

Részletesebben

GalyaTető Grand Hotal nyilvántartási rendszer

GalyaTető Grand Hotal nyilvántartási rendszer GalyaTető Grand Hotal nyilvántartási rendszer Rendszerterv (Kidolgozás) A kivitelezők: Horváth Tamás Projektvezető Balczer Gábor - Adminisztrátor Polgár Tímea - Demonstrátor Hujber János - Kapcsolattartó

Részletesebben

A szavak hálójában: szabadszavas mélyhálókereső

A szavak hálójában: szabadszavas mélyhálókereső A szavak hálójában: szabadszavas mélyhálókereső program Tikk Domonkos, Kardkovács Zsolt, Magyar Gábor Budapesti Műszaki és Gazdaságtudományi Egyetem, Távközlési és Médiainformatikai Tanszék 1117 Budapest,

Részletesebben

Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Fertői Ferenc

Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT. Fertői Ferenc Szegedi Tudományegyetem Informatikai Tanszékcsoport SZAKDOLGOZAT Fertői Ferenc 2010 Szegedi Tudományegyetem Informatikai Tanszékcsoport 3-dimenziós táj generálása útvonalgráf alapján Szakdolgozat Készítette:

Részletesebben

Informatika-érettségi_emelt 11.-12. évfolyam Informatika

Informatika-érettségi_emelt 11.-12. évfolyam Informatika 11. évfolyam A tanév célja a középszintű érettségire való felkészítés, az emelt szintű érettségire való felkészülésnek a megalapozása. A középszintű érettségi elősegíti az eligazodást és a munkába állást

Részletesebben

Szoftver alapfogalmak

Szoftver alapfogalmak Szoftver alapfogalmak Azon a programok algoritmusok, eljárások, és hozzájuk tartozó dokumentációk összessége, melyek a számítógép működéséhez szükségesek. (nem kézzel fogható, szellemi termékek) Algoritmus

Részletesebben

A Hunglish Korpusz és szótár

A Hunglish Korpusz és szótár A Hunglish Korpusz és szótár Halácsy Péter 1, Kornai András 1, Németh László 1, Sass Bálint 2 Varga Dániel 1, Váradi Tamás 1 BME Média Oktató és Kutató Központ 1111 Budapest, Stoczek u. 2 {hp,nemeth,daniel}@mokk.bme.hu

Részletesebben

Kalumet Számlázó. Termék leírás

Kalumet Számlázó. Termék leírás Kalumet Számlázó Termék leírás Rendszerünk potenciális felhasználói Olyan vállalkozások, akiknél fontos cél, szempont, ügyfeleik kiemelt szintű kiszolgálása. Akik szeretnék, hogy a tevékenységeik, ügyfél

Részletesebben

A Békés Megyei Könyvtár Elektronikus Könyvtárának kialakítása

A Békés Megyei Könyvtár Elektronikus Könyvtárának kialakítása A Békés Megyei Könyvtár Elektronikus Könyvtárának kialakítása Előadók: Toldi Klára Vincze Andrea 1 Előzmények 1997-2002 A nemzetközi könyvtári trendek hatására a hazai könyvtárügyben is megjelenik az informatika

Részletesebben

BŐVÍTMÉNYEK TELEPÍTÉSE ÉS SZERKESZTÉSE WORDPRESS-BEN

BŐVÍTMÉNYEK TELEPÍTÉSE ÉS SZERKESZTÉSE WORDPRESS-BEN Mgr. Námesztovszki Zsolt BŐVÍTMÉNYEK TELEPÍTÉSE ÉS SZERKESZTÉSE WORDPRESS-BEN Eötvös Loránd Tudományegyetem, Pedagógiai és Pszichológiai Kar Oktatásinformatikai rendszerek - szöveggyűjtemény Budapest,

Részletesebben

iseries Client Access Express - Mielőtt elkezdi

iseries Client Access Express - Mielőtt elkezdi iseries Client Access Express - Mielőtt elkezdi iseries Client Access Express - Mielőtt elkezdi ii iseries: Client Access Express - Mielőtt elkezdi Tartalom Rész 1. Client Access Express - Mielőtt elkezdi.................

Részletesebben