Fogalom alapú állománykezelés

Átírás

1 MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR DIPLOMAMUNKA Fogalom alapú állománykezelés Piller Imre Mérnök informatikus MSc Konzulens: Dr. Fegyverneki Sándor egyetemi docens Alkalmazott Matematikai Tanszék Miskolc, 2013

2 Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Matematikai Tanszék Szám: Diplomamunka Feladat Piller Imre (BV62RU) mérnök informatikus jelölt részére. A diplomamunka tárgyköre: állománykezelés A szakdolgozat címe: Fogalom alapú állománykezelés A feladat részletezése: A feladat egy kizárólagosan címkézési módszerre épülő állománykezelő alkalmazás elkészítése. Szükséges ismertetni a címkézés matematikai modelljét, bemutatva az újfajta keresési és módosítási műveleteket. Összehasonlításokat készíteni a hagyományos rendszerek hasonló funkcióival. A megközelítés újszerűsége miatt felhasználói tesztekkel is alá kell támasztani a rendszer használhatóságát. Témavezető: Dr. Fegyverneki Sándor, egyetemi docens A feladat kiadásának ideje: szakfelelős

3 Eredetiségi Nyilatkozat Alulírott Piller Imre; Neptun-kód: BV62RU a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végzős mérnök informatikus szakos hallgatója ezennel büntetőjogi és fegyelmi felelősségem tudatában nyilatkozom és aláírásommal igazolom, hogy Fogalom alapú állománykezelés című diplomamunkám saját, önálló munkám; az abban hivatkozott szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít: szószerinti idézet közlése idézőjel és hivatkozás megjelölése nélkül; tartalmi idézet hivatkozás megjelölése nélkül; más publikált gondolatainak saját gondolatként való feltüntetése. Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül. Miskolc, év hó nap Hallgató

4 1. A szakdolgozat feladat módosítása szükséges (módosítás külön lapon) nem szükséges dátum témavezető(k) 2. A feladat kidolgozását ellenőriztem: témavezető (dátum, aláírás): konzulens (dátum, aláírás): A szakdolgozat beadható: dátum témavezető(k) 4. A szakdolgozat szövegoldalt program protokollt (listát, felhasználói leírást) elektronikus adathordozót (részletezve) egyéb mellékletet (részletezve) tartalmaz dátum témavezető(k) 5. bocsátható A szakdolgozat bírálatra nem bocsátható A bíráló neve: dátum szakfelelős 6. A szakdolgozat osztályzata a témavezető javaslata: a bíráló javaslata: a szakdolgozat végleges eredménye: Miskolc, a Záróvizsga Bizottság Elnöke

5 Tartalomjegyzék 1. Bevezetés 1 2. A címkézés Alkalmazási területek Fájlrendszerek Szemantikus deszktop és indexelő szolgáltatások Címkéző alkalmazások Katalogizálók és referencia nyilvántartók Levelező rendszerek Tartalomkezelő- és megosztó rendszerek Kollaborációs eszközök Szemantikus web és ontológiák A megoldás újszerűsége Fogalom orientált keresési módszer A könyvtárstruktúra Fogalmi hierarchiák Fastruktúra átalakítása kontextusra Objektumok keresése A kontextus bővítése Keresés a bővített kontextusban A kontextus kezelési módjai A kontextushoz tartozó adatok Megvalósítás relációs adatbázissal MongoDB használata Saját tárolási struktúra Egyedi azonosítók Kifejezések és elemek Gyűjtemények Keresés név alapján Adatbázisobjektum Parancssoros kezelőfelület A parancsok felépítése és használata Kapcsolat a befogadó fájlrendszerrel A parancsok értelmezése és végrehajtása

6 6. Grafikus felhasználói felület A felhasználói felület elemei A címkék típusai Példa az egypaneles kialakításra A kétpaneles változat előnyei További funkciók Implementációs lehetőségek Felhasználói tesztek Fogalom alapú fájlrendszer Felhasználókezelés Háttértárak kezelése Programok felépítése Programok telepítése és konfigurációja Folyamatok kezelése Verziókezelés támogatása Összegzés 50 Irodalomjegyzék 52 Adathordozó használati útmutató 54

7 1. fejezet Bevezetés Az elektronikusan tárolt információk mennyisége jelentős mértékben növekszik, és a tendencia azt mutatja, hogy a növekedés a későbbiekben még erőteljesebb lesz. Ez az informatika különböző részterületeire általánosan jellemző. Folyamatosan jelentkezik az igény az új módszerek kifejlesztésére, hogy az adatok továbbítása, feldolgozása, tárolása és a szükséges információk visszanyerése még hatékonyabb lehessen. A hardver, az infrastruktúra és az alkalmazott adatmodellek is igyekeznek megfelelni az újonnan felmerülő elvárásoknak. A felhasználói szokások is komoly változásokon mentek keresztül. Ez főként annak tudható be, hogy az internet a hétköznapok szerves részévé vált. A felhő alapú technológiák megjelenésével a felhasználók elektronikusan tárolt adatainak kezelési módja is szükségszerűen változott. Ennek vannak előnyei és hátrányai is természetesen, de az vitathatatlan hogy a következő években ez a szemlélet lesz uralkodó. A rohamos fejlődés mellett az adatok szervezési módja tulajdonképpen változatlan maradt. Már a mai értelemben vett informatika előtt jelen volt az a hierarchikus rendszerezési elv, amire a modern rendszerek is épülnek. E szerint a rendszerezendő objektumok valamilyen kategorizálás alapján fastruktúrába szervezhetők. Ebben az azonos szinten lévő alkategóriáknak nem lehet közös objektuma, ilyen értelemben tehát szigorú hierarchiáról van szó. (A későbbiekben a hierarchikus kifejezés az ilyen, ténylegesen fastruktúrának megfeleltethető kialakításra vonatkozik.) Nyilvánvalóan ez az elv közel áll az emberi gondolkodásmódhoz, mivel mind a hétköznapi gyakorlatban, mind pedig a tudományterületeken gyakran megjelenik. Van viszont néhány olyan vonatkozása, amely egy általánosabb szervezési mód használatát teheti szükségessé, ahol az lehetséges. A dolgozat az állománykezelés kapcsán jelentkező problémákra ad egy megoldást. A hierarchia egyik fő problémája, hogy a kategóriákba sorolás nem feltétlenül egyértelmű. Azokban az esetekben, amikor több lehetséges kategória van, akkor el kell dönteni, hogy ténylegesen melyikbe is tartozzon az adott objektum. A kategóriák között sincs szükségszerűen alá-fölé rendeltség. Ekkor azt ismét valamilyen további szempont alapján kell meghatározni. Ezek a problémák az állományok kezelésénél számos helyen megjelenhetnek, mint például az elektronikus könyvek, zeneszámok, képek vagy dokumentumok rendszerezésénél. Szépirodalmi könyvek esetében a kategorizálás történhet például korszak, szerző és műfaj szerint is, de más sorrend is elképzelhető. A hierarchikus kialakítás ilyen esetben tehát még akkor sem lesz egyértelmű, ha a kategóriák egyébként jól ismertek. Az említett kötöttségek a keresésnél szintén megjelennek. Amikor több lehetséges kategória is van, akkor nyilvánvalóan az sem lesz egyértelmű, hogy a hierarchiában melyik következő szintre lépjünk tovább. A sorrendi kötöttség szintén nehezíti a keresést, mivel hiába tudjuk, hogy milyen speciális kategóriáról is van szó, mégis először végig 1

8 kell haladni a megelőző szinteken. Az új állomány nyilvántartási módszerek szükségességét többek között az is jelzi, hogy az interneten való keresés a felhasználó szemszögéből gyakran gyorsabb, mint a helyi fájlrendszerben. Ez az erőforrások kihasználása szempontjából jelent elsődlegesen gondot, mivel az adott fájl újboli letöltése szükséges és felesleges redundanciához vezet. A dolgozat elsődlegesen az említett problémákra keres megoldást a fájlkezelő rendszerek kapcsán. A címkézés egy hatékony módszernek bizonyult erre az eddig vizsgálatok alapján. A Címkézett dokumentum-nyilvántartás felhasználóbarát kezelése és alkalmazása című TDK dolgozatomban már adtam egy áttekintő jellegű, az egyes részterületekre általánosságban kitérő leírást a címkézés megvalósításának és alkalmazásának lehetőségeiről. Jelen dolgozat az abban elért eredményekre támaszkodik ugyan, de a megértéséhez nem feltételezi annak ismeretét, attól függetlenül használható. A dolgozat első részében azt részletezem, hogy ebben az esetben pontosan mit is jelent a címkézés. Alkalmazáspéldákon végigkövethető, hogy melyek a hasonlóságok és a lényeges eltérések más rendszerek címkézési megoldásaihoz képest. Ezt a címkézés matematikai modelljének leírása követi. A fogalmak tisztázásának köszönhetően egy egységes megközelítés és formalizmus áll rendelkezésre. A fájlok adatainak kezelési módjához a dolgozat először sorra veszi a rendelkezésre álló kész komponenseket, majd bemutat egy saját adattárolási és keresési megvalósítást is. Ahhoz, hogy valóban állománykezelésről beszélhessünk állománykezelő alkalmazás is szükséges. Ennek a felhasználói felülete parancssoros vagy grafikus szokott lenni. Mind a két típushoz készült egy-egy alkalmazás. Ezek segítségével felmérhető, hogy milyen szemléletmódbeli váltásra van szükség az ilyen típusú rendszerek kezeléséhez. A dolgozat végén különféle tesztek szerepelnek, illetve egy kitekintés hogy operációs rendszerek fájlrendszereként hogyan lehetne használni az új címkézésre épülő megközelítést. A kutató munka a Miskolci Egyetem stratégiai kutatási területén működő Innovációs Gépészeti Tervezés és Technológiák Kiválósági Központ keretében valósult meg. 2

9 2. fejezet A címkézés Címke (tag) alatt alkalmazástól függően különböző dolgokat érthetünk. Hasonló fogalom a felirat (label), és a kulcsszó (keyword), amely bizonyos helyeken a címkézés szinonímájaként szerepel. Címkézni általánosságban csak annyit jelent, hogy bizonyos objektumokat rájuk jellemző címkékkel látunk el. A címke tulajdonképpen egy kifejezés, amely többletinformációval szolgál. Feliratozásnak főként azt a műveletet szokták nevezni, amikor egy, az ember számára nehezen értelmezhető és megjegyezhető formához (például azonosítószámhoz) rendelnek egyértelműen egy könnyebben kezelhető nevet. A kulcsszavas keresés tipikusan abban különbözik a címkézéstől, hogy ott a kulcsszavak már magában a tartalomban is fellelhetők. A módszerek és elnevezések nem válnak élesen külön, emiatt először azt fontos tisztázni, hogy a címkézés itt pontosan mit is jelent. A címke itt tetszőleges szöveges kifejezés lehet. Nem feltétlenül csak egy szó. A hosszára és formátumára ilyen értelemben nincs megkötés. Egy állományhoz tetszőlegesen sok címke és egy címkéhez is tetszőlegesen sok állomány tartozhat. Ez jelentheti akár azt is, hogy lesznek állományok címke nélkül, vagy címkék állomány nélkül. Az állomány tartalma és az állományhoz tartozó címkék között nem feltétlenül kell, hogy legyen bármilyen jelentésbeli kapcsolat. A rendszerezést nyilván segíti ha van, de nem szükségszerű. A címkézést szinte kivétel nélkül csak kiegészítő funkcióként szokták használni. Itt most ez a módszer a rendszerezés alapjául szolgál. Nem arról van szó tehát, hogy egy másik, önmagában is használható struktúra felett még egy absztrakciós réteget képvisel, hanem mint független, önálló réteg jelenik meg. A fájlkezelés sok absztrakciós rétegből áll. Ahhoz, hogy érezhető legyen az előbbiekben vázolt különbség, érdemes megnézni a fájlok adatainak tárolásához és eléréséhez szükséges fő rétegeket. A fizikális réteg tárolja a fájlok adatait ténylegesen. Ez végső soron hardver eszköz kell, hogy legyen. Egy közbülső réteg eredményezi, hogy az adatokhoz hozzá lehessen férni, és a kezelési egység a fájl lehessen. A fájlok rendszerezett eléréséhez egy réteg struktúrába szervezi a fájlokat. Az utolsó réteg az esetek többségében egy jegyzékstruktúrát szolgáltat, amely már elég absztrakt, hogy az emberek számára is értelmezhető és kezelhető legyen. A címkézés tehát most egy alternatív harmadik réteg, nem pedig egy, az előzőekre épülő negyedik. (A későbbi adattárolási megvalósítás kissé ellentmond ennek a felépítésnek. Ez amiatt van, mert a harmadik réteget csak a másodikra építkezve nagyon nehéz, és felesleges is implementálni addig, amíg nem készültek el legalább az alapvető operációs rendszeri 3

10 2.1. Alkalmazási területek szolgáltatások és felhasználói alkalmazások hozzá. A különbség természetesen ettől még jelentős, mivel a fájlok hierarchiában való tárolási módja a címkézéssel nincs közvetlen kapcsolatban.) A címke a rendszerben hasonló feladatot lát el, mint a hierarchikus struktúrákban a jegyzék. Emiatt az automatikus címkézésre már elvi szinten sem lehet szükség. Az elképzelhető persze, hogy mint segédfunkció a későbbiekben megjelenjen, de akkor is csak olyan formában, hogy a rendszer javaslatokat tesz erre vonatkozóan. A jegyzékstruktúrában a navigáció egy szinte kézzel fogható, szemléletes dolog. A címkézésre épülő rendszer esetében inkább keresésről van szó. Elvi szinten lehet itt is navigációról beszélni, viszont a címkék kötetlen megadási sorrendje a kulcsszavas keresők esetében megszokotthoz keresési módhoz hasonlít jobban Alkalmazási területek A címkézés vagy ahhoz hasonló módszer az informatikában számos területen megjelenik. Nehéz annak az eldöntése, hogy pontosan mit tekinthetünk még annak, illetve hogy melyek azok a fő alkalmazástípusok, ahol találkozhatunk ilyen megoldásokkal. A következő alpontokban példák szerepelnek ezekre a típusokra. Mivel a címkézés feladata a dokumentumok felhasználó szemszögéből egyszerűbb keresése, ezért a címkézés mellett az asztali környezetek kereső funkcióit is érdemes sorra venni Fájlrendszerek A fájlrendszerek szintjén is voltak már kísérletek a címkézés megvalósítására. Az egyik jelentős ezek közül a Microsoft cég által 2003 környékén fejlesztett Windows Future Storage 1, vagy röviden WinFS. Ez egy NTFS fájlrendszerre és relációs adatbázisra épülő egységes adattároló és kezelő alrendszernek készült. A tervek szerint a Windows Longhorn majd a Windows Vista operációs rendszerhez készült, de a kiadása meghiúsult. Az elkészült komponenseket többek között a Microsoft SQL Server-be integrálták. A címkék ebben a rendszerben a többi metaadattal együtt kerültek tárolásra, hogy majd azok alapján gyorsabban lehessen keresni. Ez a kezdeményezés abból a szempontból is érdekes, hogy a hagyományos mappa mellett megjelent a virtuális mappa koncepciója is, ami a későbbi Windows kiadásokban is megmaradt. Egy jóval kisebb volumneű fejlesztés a Tagsistant. 2 Ez egy kifejezetten címkézésre készített alkalmazás. A jegyzékek nevét használja mint címkéket. Mivel felhasználói térben futó fájlrendszerként implementálták, ezért nem kell hozzá külön speciális fájlkezelő rendszer. A címkék alapján történő szűrési feltételek magában az útvonalban adhatók meg. Az AND és az OR jegyzékek is szintén az egyszerűbb kezelhetőséget szolgálják, mivel így a logikai műveletek megadása is természetesen adódik. A Tagsistant Manager programmal a címkék közötti tartalmazási kapcsolatok is beállíthatók. A címkézéshez szükséges metaadatok fájlrendszerbe integrálására vannak létező megoldások, mint például a TagFS [SS06]. A hasonló fájlrendszeri megvalósítások általában kísérleti stádiumban vannak, és csak szűk körben terjedtek el Szemantikus deszktop és indexelő szolgáltatások A WinFS fejlesztésével közel egyidőben az Apple is komoly lépéseket tett a hatékonyabb asztali környezetekben való keresés érdekében, méghozzá a SpotLight 3 nevű indexelő 1 [WinFS] 2 [Tagsistant] 3 [SpotLight] 4

11 2.1. Alkalmazási területek szolgáltatás formájában. Technikailag nem egy akkora lépésről volt szó, mint a WinFS esetében, mivel az alapvető tárolási mechanizmusban nem történt változás. Az operációs rendszer indításakor egy Metadata Server indult (mds daemon vagy mdworker néven). A változások folyamatos követése jelentősen nem lassítja a rendszer működését, az indexeknek köszönhetően viszont a keresés eredménye tulajdonképpen azonnal rendelkezésre áll. A címkézésre is ad lehetőséget a kommentek formájában (2.1. ábra) ábra. Címkék hozzáadása a Mac OS X SpotLight nevű keresőrendszerének felületén. Egy átfogó asztali integrációt megcélzó projekt a NEPOMUK 4 (Networked Environment for Personalized, Ontology-based Management of Unified Knowledge). A projekt főként Európai Uniós támogatással valósult meg. A KDE (K Desktop Environment) asztali környezethez készült. A célja nem csupán, hogy egy kereső szolgáltatás legyen, hanem az alkalmazások integritását is igyekszik segíteni. Az adatok konzisztens és kompatibilis tárolására törekszik, hogy majd azokat szemantika alapján rendszerezni tudja. A GNOME (GNU Network Object Model Environment) asztali környezet esetében a Tracker 5 nevű alkalmazás lát el indexelő és kereső funkciókat. Ebben a címkék olyan egy szóból álló feliratok, amelyeket bármelyik fájlhoz hozzárendelhetünk a kategorizálás érdekében. A program címkéket automatikusan is hozzá tud rendelni a fájlokhoz, melyek a felhasználó által megadottal egyenértékűek. 4 [Nepomuk] 5 [Tracker] 5

12 2.1. Alkalmazási területek Címkéző alkalmazások A szemantikus asztali környezetek rendelkeznek saját fájlkezelő alkalmazásokkal, melyekkel a fájlokon lévő címkéket szerkeszteni lehet. Vannak nem az asztali környezet részeként fejlesztett, hasonló funkcionalitással rendelkező alkalmazások is. Az egyik ilyen alkalmazás például az Elyse. 6 Jegyzékek helyett az alkalmazás címke csomópontokat (tag nodes) használ. A csomópontok hierarchiába is szervezhetők. Mindegyik tulajdonképpen egy keresést valósít meg. Egy fájl több csoportba is tartozhat, tehát az egyes kategóriák között lehetnek átfedések. A drag-and-drop módszernek köszönhetően egyszerű a címkézés, és akár több fájlon egyidejűleg is elvégezhető. Támogatja továbbá a jegyzékstruktúra konverzióját és jelzi az ismétlődő példányokat is. A tag2find 7 egy Windows operációs rendszerhez készült címkéző alkalmazás. Ez rendelkezik egy TagBox nevű keresőmezővel, amely a tálcához integrálható. Ebbe elegendő a címkézendő fájlokat belemozgatni, de a kontextus menüből is elérhető a funkció. További hasznos jellemzői, hogy képes figyelni az újonnan megjelenő fájlokat, illetve az új címkék hozzáadására javaslatokat is tesz. A böngészőjében (Tag Browser) van egy címke felhő (Tag Cloud) melyben a gyakoriságuknak megfelelő méretben szerepelnek a címkék. A TaggedFrog 8 egy szintén nagyon jól használható alkalmazás. Szintén lehet dragand-drop módon fájlokat hozzáadni, és a címkék kiválasztásához is azokat egy címke felhőben jeleníti meg. A Windows kontextus menüjébe is integrálható. A címkékkel való keresésen túl még egyéb szűrési feltételek is megadhatók benne. Az alkalmazás felhasználói felülete a 2.2. ábrán látható Katalogizálók és referencia nyilvántartók A Referencer 9 egy GNOME alkalmazás, mely dokumentumok és hivatkozások rendszerezésére szolgál. Nem egy általános fájlkezelő, viszont funkcionalitásában és felépítésében ez is nagyon hasonló a tervezett rendszerhez. Elsődlegesen tudományos anyagok kezelésére készült, így a dokumentumokat is alapvetően tudományos cikkekként kezeli. A hivatkozásokhoz szükséges képes automatikusan kinyerni a PDF fájlokból, és abból BibTeX fájl is generálható vele. DOI vagy arxiv alapján is tud keresni az Interneten. A 2.3. ábrán látható egy kép az alkalmazás felhasználói felületéről. Ennek bal oldali sávjában lehet a keresésben szereplő címkéket kijelölni, akár többet is egyszerre. Ami a címkék kezelésénél nehézséget jelent, hogy csak egy görgethető lista áll rendelkezésre azok keresésére vagy szerkesztésére Levelező rendszerek A levelező rendszerekben is egyre gyakoribb, hogy a jegyzékekbe való csoportosítás mellett a címkézés lehetősége is adott. A Gmail esetében már az is egy címke, hogy a levél beérkezett vagy elküldött. A további címkék hozzáadása kézenfekvő. A levelet megnyitva a tárgyat követően sorban szerepelnek a levélhez rendelt címkék. Újat hozzáadni pedig egy címke ikonra kattintva lehet. Az olyan elterjedt levelezőkliensek, mint például a Thunderbird vagy az Outlook is képesek kezelni a kategóriákat. A módszer elnevezésében vannak különbségek, viszont a felhasználó szempontjából a végeredmény ugyanaz. 6 [Elyse] 7 [Tag2find] 8 [TaggedFrog] 9 [Referencer] 6

13 2.1. Alkalmazási területek 2.2. ábra. Példa képek keresésére TaggedFrog segítségével Tartalomkezelő- és megosztó rendszerek A tartalomkezelő rendszerek esetében a címkézés alapfunkciónak számít. Bizonyos weboldalak, mint például a Delicious 10 kifejezetten erre épülnek. A linkekhez címkéket rendelnek, hogy ezek alapján kategorizálni és keresni is lehessen. A Flickr, 11 mint az egyik legnagyobb fényképmegosztó oldal népszerűségét többek között a címkézésnek köszönheti. Ez volt az egyik első weboldal, amelynél a címkék ábrázolására címke felhőt használtak. A jelentős tartalomkezelő rendszerek (mint például a Drupal, 12 Wordpress, 13 Joomla 14 ) mindegyikében van már lehetőség a címkék kezelésére. Ha az összetett lekérdezéseket nem is támogatják, de annyit biztosan, hogy az adott címkével ellátott tartalmakat listázzák, legyen szó például blogbejegyzésekről, képekről vagy videókról Kollaborációs eszközök A kollaborációs célokra készült alkalmazások nem sokban különböznek az eddigiektől. Ami miatt mégis külön pontba kerültek, hogy a tabbles 15 nevű alkalmazás egy szép példája a használatának ilyen területen. Ebben az esetben is a jegyzékek és a címkézés előnyeinek ötvözése áll a megoldás hátterében. A tabble, amiről az alkalmazás a nevét [Tabbles] 7

14 2.1. Alkalmazási területek 2.3. ábra. A Referencer nevű katalogizáló alkalmazás felhasználói felülete. kapta egy különleges tároló, ami egyaránt használható dokumentumok, mappák illetve könyvjelzők rendszerezésére is. A feltevés az, hogy mappákkal a rendszerezés kényelmesebb, míg a keresésnél inkább címkéket érdemes használni. A címkék helyett tehát itt tabble-nek nevezett virtuális mappák vannak, melyeket kerek ikonok szimbolizálnak. Címkével ellátni egy fájlt úgy lehet, mint ha azt a tabble-be bemásolnánk. Egy fájl több tabble-be is tartozhat. A kereséshez ezek után nem szükséges ismerni a fájl tényleges helyét, elegendő csak a rá jellemző tulajdonságokat felsorolni. A 2.4. ábrán látható egy példa a keresésre, amiben a keresett fájlról tudjuk, hogy az a Business cards és Maurizio tabble-ökben van benne, a kiterjesztése pdf, és nincs benne az Old tabble-ben ábra. A tabbles esetében megvalósított keresési módszerre egy példa. Fontos megemlíteni a tabbles weboldalát. Az ilyen típusú rendszerezési módok még ha bizonyítottan jól használhatók, akkor is igényelnek némi tanulást a felhasználó részéről. A weboldal részletesen bemutatja, hogy milyen problémát és hogyan old meg ez a rendszer. Egyszerű példákon keresztül képekkel és videókkal illusztrálva segíti a megértést. 8

15 2.2. A megoldás újszerűsége Szemantikus web és ontológiák A szemantikus web egy olyan kezdeményezés, amely az Interneten elérhető tartalmakat jelentésüknek, felhasználási területüknek megfelelően igyekszik rendszerezni. Ehhez elsősorban metainformációkat használ, melyeket az eredeti elképzelés szerint a gépek automatikusan állítanak elő. Az ilyen szintű automatizáltság még nem jellemző, viszont a metaadatok egységes megjelenítési formájaként az RDF (Resource Description Framework) használata már általánosnak mondható. (Erre vonatkozóan már a szemantikus web kialakulásakor született javaslat [BL98].) A metaadatok egy másik meghatározó forrása a felhasználói közösség. A különböző weboldalak segítséget nyújtanak az ilyen adatok felviteléhez. A címkézés ennek az egyik elterjedt módja, ahogy az már a tartalomkezelő oldalak kapcsán is felmerült. Ami a szemantikus web esetében a többletet jelenti, hogy vannak törekvések, melyek az addig szeparáltan működő, de hasonló módszerekre épülő szolgáltatásokat integrálni próbálják. A közösségi címkézés az eddig felvázolt címkézési módszernél összetettebb. Az egyszerűbb esetben elegendő az objektumok és címkéik viszonyát vizsgálni. Ezt a közösségi címkézés még kiegészíti azzal, hogy az adott címke milyen forrásból származik, és mennyire megbízható. A címkék jelentése (Moat Of A Tag) sem feltétlenül egyértelmű, így még azt is társítani kell valamilyen módon [PP08]. Új fogalomként megjelent a folkszonómia (folksonomy = folk + taxonomy). Ez egy olyan osztályozási rendszer, amely a felhasználók által megadott fogalmakra építkezik. Alapjául a címke ontológiák szolgálhatnak. Az egyik nehézség ennek kapcsán is az egységes formátum hiánya, melyre megoldást a közösségi címkézés modellje adhat [KB08] A megoldás újszerűsége Az előző pontokban számos címkézést használó alkalmazási területről szó eset. Érdemes röviden összefoglalni, hogy a dolgozatban szereplő megközelítés miben jelent újszerűséget ezekhez képest. Az alkalmazások egy része gyakorlati indíttatású, amelynél csak egy hasznos segédfunkció hozzáadásáról van szó. Ezek nem igényelnek komolyabb elméleti megalapozást. A tapasztalatokhoz, felhasználói visszejelzésekhez igazodik a fejlesztés menete. Ide sorolható például a Tagsistant, tag2find vagy a Referencer. A másik megközelítés a fogalmak elemzéséből, ontológiai vizsgálatokból indul ki. Ezek bizonyíthatóan jó, de általában komplex struktúrákat eredményeznek. Tudományos szempontból ezek a mérvadóak, viszont az így készült alkalmazások a gyakorlatban komolyabb felkészültséget igényelnek a felhasználótól. A dolgozatban bemutatott megoldás a kettő között egy kompromisszumos megoldást ad. Egyszerű, szemléletes matematikai fogalmakra építkezik úgy, hogy közben a gyakorlati szempontok, és a felhasználói elvárások is érvényesülnek. A címkék és a jegyzékek között gyakran vonnak párhuzamot. A tabbles nevű alkalmazás például a kettő funkcionalitásából kapott speciális tárolóról kapta a nevét. Útvonal jellegű kifejezéseket alakít ki, viszont ezek használatára csak példákat hoz fel, nem célja a műveletek formális definiálása. A Tagsistant szintén a jegyzékstruktúra és a címkézés előnyeit ötvözi. Az útvonalak maguk a lekérdezések, a grafikus megvalósítás így már másodlagos, mivel adódik a parancssori kezelési módból. Ez tetszőleges fájlkezelő alkalmazás használatát teszi ugyan lehetővé, viszont azt is jelenti, hogy többletet sem ad a funkcionalitáshoz. 9

16 2.2. A megoldás újszerűsége Az új, fogalom alapú megközelítés a parancssori és a grafikus kezelési módot egymásra építi. Minden grafikus műveletnek megfeleltethető egy parancs, viszont sajátos kezelőfelületet igényel, amely a fogalom alapú állománykezelést segíti. Más fájlrendszerekkel fájlokat cserélni a felvázolt rendszer az importálási és exportálási funkciói segítségével tud. Hasonló megoldást az említett alkalmazások közül az Elyse is támogat. Ami ezt egyedivé teszi, hogy a grafikus felület hierarchikus kezelési módot is biztosít. A megoldás tehát sok hasonlóságot mutat a felsorolt rendszerekkel és módszerekkel. Azok bizonyos jellemzőit át is veszi, egy egységes, letisztított keretbe helyezi el. A célterületre készített alkalmazások kiváltása nem cél. A módszer az állományok kezelésére szorítkozik, viszont ad egy olyan formalizmust, amely bármilyen címkézéssel, kategorizálással megoldható problémára illeszthető. 10

17 3. fejezet Fogalom orientált keresési módszer 3.1. A könyvtárstruktúra A könyvtárstruktúra és a rajta elvégezhető műveletek közismerteknek tekinthetők. A rövid leírására azért van mégis szükség, hogy a későbbiekben összehasonlítható legyen a címkéket használó, fogalmakra épülő megközelítéssel. A hagyományos értelemben vett könyvtárstruktúrának mindig megfeleltethető egy olyan fagráf, melyben a jegyzékeket és a fájlokat egy-egy csomópont jelöli. Fájlok csak a fagráf leveleiben lehetnek. Minden csomópontnak kell hogy legyen neve, amely nem feltétlenül egyedi. Az állományok egyértelmű azonosításához a fa gyökeréből induló és az állományban végződő teljes útvonal megadása szükséges, és elégséges. Ez tehát a jegyzéknevek rendezett listája, melynek végén a fájl neve is szerepel (abszolút útvonal). A fájlok útvonalának célszerűen olyannak kell lennie, hogy valamilyen szinten utaljon a fájl szerepére, tartalmára. Emiatt tekinthetjük a fájlokat általánosan objektumoknak, az útvonalban szereplő jegyzékneveket pedig az objektumok attribútumainak. Egy objektumhoz tehát egy rendezett attribútumlista tartozik, melynek elején tipikusan általánosabb fogalmakra utaló nevek állnak, míg a végére kerülnek a speciális jellemzők. Ez természetesen nem szükségszerű, viszont hierarchikus felépítés ennek a kialakításnak kedvez. A gráfnak mindig van egy kitüntetett csúcspontja amely a hierarchiában elfoglalt helyet jelöli (aktuális jegyzék). A keresés során az élek mentén haladva választhatunk új csomópontot, egészen addig, amíg a keresett állományokat meg nem találjuk. A relatív útvonalakat ilyen lépések sorozatának tekinthetjük, ahol haladhatunk a gyökér felé is. Az abszolút útvonalak esetében a gyökeret tekintjük kiindulópontnak. A jegyzéknevek rendezett listája tehát keresési kifejezésként kezelhető, az eredmény pedig az aktuális jegyzék tartalma lesz. A könyvtárstruktúra műveletei szintén nagyon szemléletesek. A fájlok létrehozása, a másolás, az áthelyezés és a törlés is közvetlenül adódik a kialakításból Fogalmi hierarchiák Az új rendszer modelljének leírásához érdemes először a fogalmak formális leírásával foglalkozó tudományág (formal concept analysis [GW05]) jelöléseit és alapfogalmait röviden összefoglalni. Jelöljön G egy tetszőleges objektumhalmazt, az M pedig egy attribútumhalmazt. (Az objektumok jelen esetben az állományok, az attribútumok pedig a címkék.) A két halmaz közötti kapcsolatok leírásához tekintsük a I G M bináris relációt (incidence relation). Az ezekből kapott (G, M, I) hármast formális kontextusnak nevezzük. 11

18 3.3. Fastruktúra átalakítása kontextusra Tekintsünk egy A G halmazt a kontextusban. Ehhez tartozik egy A = {m M (g,m) I, g A} attribútum halmaz. Analóg módon a B M részhalmazhoz szintén tartozik egy B = {g G (g,m) I, m B} halmaz. Ezen A A illetve B B leképzéseket derivációnak nevezzük. Az olyan (A,B) párt, amelyre fennáll az A = B és B = A összefüggés, fogalmaknak nevezzük. A párhoz tartozó objektum halmazt attribútum-extenziónak (extent), az attribútum halmazt pedig objektum-intenziónak (intent) nevezzük [KA08]. Tekintsük az (A 1,B 1 ) és (A 2,B 2 ) fogalmakat. Amennyiben A 1 A 2 teljesül, akkor az első fogalom a második részfogalma. A második tehát egy általánosabb fogalom. Ez a tartalmazási kapcsolat egy részbenrendezést ad meg, mégpedig (A 1,B 1 ) (A 2,B 2 ) A 1 A 2 B 2 B 1. A kontextushoz tartozó összes fogalom az előbbi részbenrendezéssel adja a fogalomhálót (concept lattice), ami egy teljes háló, vagyis minden részhalmazának van szuprémuma és infimuma. A kontextushoz tartozó összes fogalom többek között az In-Close algoritmussal állítható elő [AS09]. A fogalomhálókat alkalmaznak többek között a csoporttechnológiában is [RS98]. Az állománykezelés egy új területet jelent, és új problémákat vet fel, elsősorban a nagyobb méretű kontextus hatékony kezelése miatt Fastruktúra átalakítása kontextusra Minden fastruktúrához hozzárendelhető olyan kontextus, amely megőrzi a struktúrában lévő hierarchiát. Az ilyen kontextusok fogalomhálóját Hasse-diagram formájában ábrázolva ismét láthatóvá válik a szigorú hierarchia. A kontextus már kiegészíthető olyan többletinformációkkal is, amelyeket a fastruktúra nem tud leírni. A következőkben ezeknek a fő lépéseknek a részletezése szerepel egy példán keresztül szemléltetve azokat. A fastruktúra leképzésének több módja is lehet. Gyakorlati szempontból azt az esetet érdemes vizsgálni, melyben a jegyzékek neveinek feleltetjük meg a kontextusban az attribútumokat. Problémát jelent, hogy a jegyzéknevek nem feltétlenül egyediek, amelyen úgy lehet egyszerűen segíteni, hogy különböző attribútumokat rendelünk a különböző helyeken, de azonos névvel szereplő jegyzékekhez. Például a 3.1 ábrán dolgozatokhoz és programokhoz tartozó állományoknak az elhelyezése szerepel két lehetséges fastruktúrában. Az első esetben a csoportosítás a szerint történik, hogy dolgozatról vagy programról van-e szó, majd ezen belül év szerint szerepelnek az aljegyzékek. A második változatban fordítva, az év szerinti bontás adja a magasabb szintet. A két elrendezés jelentősen nem különbözik. A jegyzékstruktúra esetében dönteni kell, hogy melyiket szempont szerinti csoportosítási módot tekintjük általánosabbnak. Az első változatban a 2010 és 2011 nevek ismétlődnek, így azokhoz például a 2010_dolg, 2010_prog illetve a 2011_dolg, 2011_prog rendelhetők a szülőjegyzéküknek megfelelően. A fájlok nevei különbözőek, tehát azok leképzése közvetlenül adódik. 12

19 3.3. Fastruktúra átalakítása kontextusra 3.1. ábra. Példa dolgozatok és programok állományainak elhelyezésére kétféle struktúrában. A kontextus tehát a objektumhalmazból, az G = {ábra1.png, ábra2.png, dolgozat1.tex, dolgozat1.pdf, képlet.jpg, dolgozat2.doc, prog2.png, dolgozat3.tex, dolgozat3.pdf, prog1.c, prog1.exe, utils.h, prog2.c, prog2.exe} M = {dolgozatok, dolgozat1, dolgozat2, dolgozat3, programok, program1, program2, 2010_dolg, 2010_prog, 2011_dolg, 2011_prog} attribútumhalmazból, illetve a 3.2 táblázattal megadott I bináris relációból áll. Ez a leképzés tetszőleges faszerkezetre elkészíthető, és belőle az eredeti struktúra mindig visszanyerhető. A példában a 2010 és 2011 jegyzéknevek attribútumként is használhatók, ekkor a visszaalakítás már nem lehetséges, viszont ez a megoldás jobban tükrözi a jelentést. Attribútumokként az a sorrendi kötöttség szünne meg, ami a példaként felhozott kétféle struktúra különbségét is jelenti. 13

20 3.4. Objektumok keresése dolgozatok dolgozat1 dolgozat2 dolgozat3 programok program1 program2 2010_dolg 2010_prog 2011_dolg 2011_prog ábra1.png ábra2.png dolgozat1.tex dolgozat1.pdf képlet.jpg dolgozat2.doc prog2.png dolgozat3.tex dolgozat3.pdf prog1.c prog1.exe utils.h prog2.c prog2.exe 3.2. ábra. Az első fastruktúrához tartozó bináris reláció. A prog2.png fájl neve jelzi, hogy a dolgozat3 és a program2 között valamilyen kapcsolat van. Az I relációt a (prog2.png, programok) és (prog2.png, program2) párokkal bővítve ez is megadható. A kontextusban ezen kívül további csoportosítási módok is bevezethetők például a kép, dokumentum, latex és exe attribútumokkal. Az említett módosítások után kapott reláció a 3.3 ábrán szerepel Objektumok keresése A kontextus esetében alkalmazott keresési mód tulajdonképpen a fagráfban való keresés általánosítása. A fagráf helyett itt egy hálóban lehet navigálni. A gyökeret a (G, ) fogalom szimbolizálja. A hálóban lefelé és felfelé is lehet haladni. A jelentős különbség a fagráfhoz képest, hogy itt egy csomópontnak több szülője is lehet. A 3.4 ábrán látható a példában szereplő módosított kontextus fogalmainak hálója. Az ábra a csomópontok megadásánál azt az egyszerűsített jelölésmódot használja, melynél csak az újonnan megjelenő objektumok és attribútumok kerülnek feltüntetésre. A gyökércsomópont a (G, ) lesz. A kiinduló állapot tehát a kontextus összes objektumát tartalmazza. Ehhez a dolgozatok, programok, 2010, illetve 2011 címkék valamelyikét adhatjuk hozzá, hogy egy alsóbb szintre léphessünk. A programok címkét választva a program1, program2 és az exe lehetőségek adódnak. Az exe-re továbblépve tulajdonképpen véget is ért a keresés, mivel bármely további címke hozzáadása már üres objektumhalmazhoz vezetne. Az eredményben itt a prog1.exe és prog2.exe állományok fognak szerepelni. Az ehhez vezető útvonal a programok/exe formában, a kijelölt fogalom pedig a ({programok, exe},{prog1.exe, prog2.exe}) párral adható meg. A navigáció ugyan természetes módon adódik, viszont a kezelési mód a gyakorlatban több problémát is felvet. 14

21 3.4. Objektumok keresése dolgozatok dolgozat1 dolgozat2 dolgozat3 programok program1 program kép dokumentum latex exe ábra1.png ábra2.png dolgozat1.tex dolgozat1.pdf képlet.jpg dolgozat2.doc prog2.png dolgozat3.tex dolgozat3.pdf prog1.c prog1.exe utils.h prog2.c prog2.exe 3.3. ábra. A bővített kontextushoz tartozó bináris reláció. A szintenkénti keresés a hierarchiához nagyon hasonló. Az általános fogalmaktól elindulva fokozatosan juthatunk el a speciálisakhoz. A gond ezzel a megoldással éppen az, hogy így az általánosabb attribútumokat mindig fel kell sorolni, még ha azok egyébként a speciálisakból következnének. Ezzel a hierarchiában lévő sorrendi kötöttség továbbra is megmaradna. Mivel fogalmakról van szó, ezért a hálóban előfordulhatnak név nélküli csomópontok. Ebben az esetben az alsóbb szinteken megjelenő új címkékre is tovább lehet lépni. Például a dolgozatok címke után a dolgozat1, dolgozat2, dolgozat3, kép, dokumentum és latex címke is következhet. Előfordulhat olyan csomópont amelyen több új attribútum jelenik meg. Ez akkor fordulhat elő, ha a kettő már ekvivalensnek tekinthető, ezért bármelyik hozzáadása a többi hozzávételét is jelenti. A megoldás feltételezi, hogy rendelkezésre áll az egész koncepcióháló, amelynek a felépítése és a tárolása nagyon költséges. Fájlrendszer esetében ezért ez nem ajánlott. Ezen okok miatt a fogalomhálóban a keresést inkább lekérdezések sorozatával tanácsos megközelíteni. Ehhez keresési kifejezések szükségesek. A könyvtárszerkezet esetében az útvonal látja el ezt a feladatot. A kontextus esetében ez legyen egy attribútumhalmaz, amelyet jelöljön a Q M (query). A keresés eredménye egy R G (result) objektumhalmaz, amelyet az R = Q derivációval kaphatunk meg. Kezdetben legyen Q =, így R = G. A Q halmazt bővítve az R halmaz számossága vagy csökken vagy nem változik. Minden lekérdezéshez tartozik egy (R,Q ) = (Q,Q ) fogalom. Teljesül, hogy Q Q, vagyis a Q \ Q halmazbeli attribútumok hozzáadásával nem fog csökkenni az R 15

22 3.5. A kontextus bővítése programok 2010 dolgozatok 2011 dokumentum program1 latex dolgozat1 kép program2 exe utils.h, prog2.c dolgozat2 dolgozat3 prog1.c dolgozat1.tex dolgozat1.pdf prog2.exe prog1.exe ábra1.png, ábra2.png dolgozat2.doc képlet.jpg dolgozat3.tex dolgozat3.pdf prog2.png 3.4. ábra. A példaként megadott módosított kontextus fogalmainak Hasse-diagramja. A tömör jelölésmód csak a csomópontban megjelenő új attribútumot vagy objektumot jelöli. számossága, azok az attribútumok már egyébként is a fogalomhoz tartoznak. Ennek megfelelően a keresés szempontjából az M \ Q halmazból érdemes attribútumokat választani. Ezzel fokozatosan lehet szűkíteni a fogalmat anélkül, hogy az utolsó lépést leszámítva üres eredményhalmazt kapnánk. A későbbiekben majd szükség lesz arra is, hogy az eredmény üres legyen, mivel így vihetünk fel az adott helyre új objektumokat, és alakíthatunk ki új fogalmakat A kontextus bővítése A Q halmazban lévő attribútumokat tekinthetjük szűrési feltételeknek is. A deriváció műveletét részletesebben kiírva az R = {g G (g,m 1 ) I (g,m 2 ) I... (g,m k ) I} alakot kapjuk, melyben m i Q és k = Q. Ebben a formában már szembetűnő, hogy a keresés az eddigiek alapján csak a konjunkciós műveletet használja. A teljesség kedvéért a negáció és a diszjunkció műveletének keresésben való alkalmazási lehetőségeit is meg kell vizsgálni. Előfordulhat, hogy a szűrést úgy szeretnénk megfogalmazni, hogy az adott attribútum ne szerepeljen az eredményben lévő objektumokon. Ehhez be kell vezetni az 16

23 3.6. Keresés a bővített kontextusban m 1 m 2 m 3 m 1 m 2 m 3 g 1 g 2 g 3 g ábra. Példa kontextus komplementerrel bővítve. ({g 1,g 2,g 3,g 4 }, ) ({g 1,g 2,g 3,g 4 }, ) ({g 1,g 2,g 4 },{m 2 }) ({g 1,g 3,g 4 },{m 1 }) ({g 2,g 3,g 4 },{m 3 }) ({g 1 },{m 2,m 3 }) ({g 2 },{m 1,m 2 }) ({g 3,g 4 },{m 1,m 3 }) (,{m 1,m 2,m 3 }) ({g 3 },{m 1,m 2,m 3 }) 3.6. ábra. A kontextushoz és a komplementer kontextushoz tartozó fogalomháló. attribútum ellentettjének fogalmát. A kontextust bővíteni kell oly módon, hogy az attribútumok halmazához hozzáveszünk új attribútumokat. Minden ilyen új attribútumra teljesülnie kell, hogy azon objektumokkal van relációban, amellyel a neki megfelelő eredeti attribútum nincs. Egy m M attribútumnak megfelelő ilyen attribútumot nevezzük ellentett attribútumnak, jelölése pedig m. Az ellentett attribútum egy új, a fogalomhálók körében nem használt fogalom. Hasonló összefüggések leírására a komplementer kontextust szokás használni, amely (G,M,I) kontextus esetén a (G,M,G M \ I) kontextus. A kibővített kontextus egyszerűsíti a jelöléseket és egyszerűbb tárgyalásmódot eredményez. Jelölje M a bővített attribútumhalmazt, a bővített incidencia relációt pedig I. A kereséseket az így kapott (G, M, I) kontextusban végezhetjük el. A bővítésnek köszönhetően tetszőleges Q M halmaz az R eredményhalmazzal fogalmat fog alkotni Keresés a bővített kontextusban Tekintsük a G = {g 1,g 2,g 3,g 4 } objektumhalmaz és a hozzá tartozó M = {m 1,m 2,m 3 } attribútumhalmazt. A 3.5. ábra táblázatának első három oszlopában táblázatos formában megadott I bináris relációval ez egy (G, M, I) kontextust alkot. Az attribútumhalmazt az m 1, m 2 és m 3 ellentett attribútumokkal bővítve kapjuk a (G,M,I) relációt. Az eredeti és a komplementer kontextushoz tartozó fogalomhálók Hasse-diagramja a 3.6. ábrán látható, a kibővítetté pedig a 3.7. ábrán. A keresés menetének végigkövetéséhez jelölje Q i Q a keresés megadásához szolgáló halmazt, és R i R pedig az ezekhez tartozó eredményhalmazokat. A C i párok az i-edik lépéshez tartozó koncepciókat jelölik. 17

24 3.6. Keresés a bővített kontextusban ({g 1,g 2,g 3,g 4 }, ) ({g 1,g 2,g 4 },{m 2 }) ({g 1,g 3,g 4 },{m 1 }) ({g 2,g 3,g 4 },{m 3 }) ({g 1,g 4 },{m 2,m 1 }) ({g 2,g 4 },{m 2,m 3 }) ({g 3,g 4 },{m 1,m 3 }) ({g 1 },{m 2,m 3,m 1 }) ({g 2 },{m 1,m 2,m 3 }) ({g 4 },{m 2,m 1,m 3 }) ({g 3 },{m 1,m 2,m 3 }) (,{m 1,m 2,m 3,m 1,m 2,m 3 }) 3.7. ábra. A kibővített relációhoz tartozó koncepcióháló. Kiindulási pontként tekintsük a Q 0 = halmazt. Az ehhez tartozó eredményhalmaz az R 0 = Q 0 = G. A G deriválásával visszakapjuk az üres halmazt, tehát C 0 = ({g 1,g 2,g 3,g 4 }, ). Első lépésben keressük azon objektumokat, melyek az m 2 attribútummal rendelkeznek. Ez azt jelenti, hogy Q 1 = {m 2 }, vagyis R 1 = {g 1,g 2,g 4 }, amelyből C 1 = ({g 1,g 2,g 4 },{m 2 }). Második lépésben zárjuk ki az eredményből azon objektumokat, melyek rendelkeznek az m 3 tulajdonsággal. Ez a Q 2 = {m 2,m 3 }, R 2 = {g 2,g 4 } halmazokat és a C 2 = ({g 2,g 4 },{m 2,m 3 }) fogalmat eredményezi. Tegyük fel, hogy tovább szeretnénk szűkíteni az eredményhalmazt az m 1 attribútum szerint. Ekkor Q 3 = {m 1,m 2,m 3 } adja a keresést, R 3 = {g 2 } halmaz lesz az eredmény, az aktuális fogalom pedig a C 3 = ({g 2 },{m 1,m 2,m 3 }). A keresésben már mind a három attribútumot felhasználtuk, így további szűkítés nem lehetséges úgy, hogy ne üres eredményhalmazt kapjunk. Jól látható, hogy a C 1,C 2,C 3,C 4 koncepciók egy útvonalat jelölnek ki a fogalomhálóban. A kontextus bővítésének köszönhetően a fogalomhálóban a keresés hasonló a fában való kereséssel. A keresésben elvileg diszjunktív művelet is lehet. Az ezekkel kapott R eredményhalmazok mindig felírhatók R = R 1 R 2 alakban. A művelet használata azért nem javasolt, mert így a fogalom nem lenne egyértelmű, és az a lehetőség veszne el, hogy az eredményhez közvetlenül hozzá lehessen adni objektumokat. 18

25 4. fejezet A kontextus kezelési módjai 4.1. A kontextushoz tartozó adatok A dokumentumokhoz, címkékhez és kapcsolataikhoz tartozó adatok kezelési módjának helyes megválasztása kiemelt fontosságú feladat. Alapvetően a kontextus tárolása, módosítása és a keresési műveletei határozzák meg a rendszer fő jellemzőit, mint például a futási időt és a tárigényt. A matematikai felírás alapján a kontextushoz egy objektumhalmaz (G), egy attribútumhalmaz (M), és az ezeken értelmezett bináris reláció (I) tartozik. A megvalósításhoz ez még ebben a formában túlságosan általános, ezért meg kell határozni egy konkrétabb reprezentációt. Az objektumok és az attribútumok egyértelmű azonosításához kulcsértékekre van szükség. A címkék esetében ez lehetne a címke neve is, mivel az biztosan egyedi. Ennek használata a későbbiekben több problémát is okozhat, mivel a nevek elméletileg tetszőleges hosszúságúak lehetnek. Adható egy ésszerű felső korlát, amellyel már rögzített hosszúságúként viszont ez rossz tárkihasználtságot eredményez. A címkkeneveknek módosíthatóaknak kell lenniük. A kulcs értékének megváltoztatása nem tartozik a javasolt művelet közé, mivel sok hivatkozás esetén a végrehajtása költséges, továbbá bizonyos rendszerek nem is teszik lehetővé a szöveg típusú kulcsok használatát, így tehát célszerű egy, a névtől független numerikus azonosítót használni. A címkékhez tartoznia kell még egy, a típusuk leírására szolgáló szöveges adatmezőnek is. Ennek előnyeire a későbbi fejezetek adnak majd magyarázatot. A rendszer objektumai jelen esetben a fájlok. Szerencsés módon a címkék adatainak tárolásához felvázolt séma a fájlokra is alkalmazható. A név értelemszerűen a fájlnév. Erre nem szabad egyediségre vonatkozó feltételt szabni, tehát a külön kulcsérték mindenképpen szükséges. (A két kezelendő halmaz diszjunkt, ezért elegendő csak halmazon belül megkövetelni a kulcsok egyediségét.) Az állományok neve nem feltétlenül utal a fájl típusára a jelenlegi rendszerekben sem. A típus fájlnévtől való elkülönítése egyfajta rugalmasságot jelent, az állományok kezelési módjának meghatározását pedig egyszerűsíti. A fájlok és címkék közötti kapcsolatok tárolásához azok kulcsait kell egymáshoz rendelni. Ennek a megvalósítása adatmodelltől függően jelentősen különbözhet. A (G, M, I) bővített kontextuson értelmezett keresési műveletek hatékony megvalósítására kell törekedni. A következő pontokban három irányvonalról lesz szó. Az első a hagyományos relációs adatmodellre épül. Ezt egy dokumentumorientált módszer követi. A készen elérhető adatbázisok után a saját adattárolási struktúrát mutatom be. 19

26 4.2. Megvalósítás relációs adatbázissal 4.2. Megvalósítás relációs adatbázissal A címke nevének megadásával történő címkézés esetén három relációs adatmodellbeli megvalósítási mód terjedt el. 1 Az első a címkék neveit egy külön oszlopban tárolja el. Ennek előnye, hogy csak egy táblára van hozzá szükség, és a lekérdezések is egyszerűek lesznek. A címkék nevei között ugyanúgy lehet keresni, mint bármilyen más szöveges mező esetében. Hátránya, hogy a címkék együttes hosszúságára a mező típusa adhat egy felső korlátot, illetve sok címke esetében a keresés hatékonyságával gondok lehetnek. Ennél egy rugalmasabb megoldás, ha a címkék egy külön táblába kerülnek, és onnan hivatkoznak a címkézendő elemekre. Ez már közelebb áll a normalizált megoldáshoz, és a címkék száma sem annyira kötött. A fájlok és címkék között több-több kapcsolat van. Ehhez a kézenfekvő megoldást egy kapcsolótábla beiktatása jelenti a fájlok és a címkék adatait tároló táblák közé (4.1. ábra) ábra. Három táblából álló séma a címkézés relációs modellbeli megvalósításához. Az adott címkékkel ellátott fájlok nevének lekérdezése ebben a szerkezetben a következő SQL lekérdezés formájában nézhet ki. SELECT f. name FROM f i l e s f, file_to_tag ft, tags t WHERE f. id = f t. f i l e _ i d AND f t. tag_id = t. id AND ( t. name IN ( tag_1,..., tag_n ) ) GROUP BY f. id HAVING COUNT( f. id ) = N Ebben az N a lekérdezésben szereplő címkék számát jelöli. A szerkezet szimmetrikus, tehát fájlok alapján is lekérdezhetjük a hozzájuk tartozó címkék neveit például a következő módon. SELECT t. name FROM f i l e s f, file_to_tag ft, tags t WHERE f. id = f t. f i l e _ i d AND f t. tag_id = t. id AND ( f. name IN ( f i l e _ 1,..., file_m ) ) GROUP BY t. id HAVING COUNT( t. id ) = M Az M itt az állományok száma. Az ilyen irányú lekérdezés kevésbé elterjedt. Akkor alkalmazható, ha olyan objektumaink vannak, amelyeket ki lehet jelölni, és a hozzájuk rendelt címkéket szeretnénk megkapni. Olyan lekérdezésre is szükség van, amelyikben megadhatjuk azon címkék neveit, melyeket nem szeretnénk, hogy az eredményként kapott fájlokon szerepeljenek. Ez az előzőek mintájára egy alszelekttel fogalmazható meg

27 4.3. MongoDB használata SELECT f. name FROM f i l e s f, file_to_tag ft, tags t WHERE f. id = f t. f i l e _ i d AND f t. tag_id = t. id AND ( t. name IN ( tag_1,..., tag_n ) ) AND ( f. id NOT IN ( SELECT f. id FROM f i l e s f, file_to_tag ft, tags t WHERE f. id = f t. f i l e _ i d AND f t. tag_id = t. id AND t. name IN ( minus_tag_1,..., minus_tag_m ) ) ) GROUP BY f. id HAVING COUNT( f. id ) = N Ezek a lekérdezések röviden leírhatók és egyszerűek ugyan, de a join és halmazműveletek miatt nem hatékonyak MongoDB használata A MongoDB egy nyílt forráskódú dokumentum orientált adatbázis [KC10]. A dokumentumok ebben JSON objektumok, melyek kollekciókba szerveződnek. A fájlok és a címkék dokumentumként kezelhetők. Érdemes őket külön kollekcióban kezelni, bár a dokumentumok rugalmas szerkezete miatt ez akár egyben megoldható lenne. A következőkben egy lehetséges implementáció bemutatására kerül sor. Egy fájl adatainak tárolása a következőképpen történhet. { } " _id " : ObjectId ( " bb6e0656aba " ), " name " : " Minta. pdf ", " type " : " a p p l i c a t i o n /x pdf ", " r e f e r e n c e s " : [ " bd3e0656ab ", " bdbe0656a " ] Az első értékpár a dokumentum egyedi azonosítóját tartalmazza. A name a fájl nevének megadására szolgál, a type-ban pedig itt egy MIME kifejezés van, ami alapján a fájl megnyitásához a program kiválasztható. A references az adott fájlhoz rendelt címkék azonosítóinak listáját tartalmazza. A címkék megadási módja tulajdonképpen megegyezik ezzel, csak a tárolt értékek jelentése lesz más. Címkék alapján keresni az adatbázisban például az alábbi parancs kiadásával lehet. db. f i l e s. f i n d ( { " r e f e r e n c e s " : { " $ a l l " : [ " bd3e0656ab ", " bdbe0656a " ] } } ) 21

28 4.4. Saját tárolási struktúra Ezzel egy olyan dokumentumot keresünk a files kollekcióban, melyre teljesül, hogy a lekérdezésben megadott references listát részeként tartalmazza. Az a lekérdezés, melyben már a mellőzendő címkék is megadásra kerülnek az $and logikai művelettel adható meg, például a következő formában. db. f i l e s. f i n d ( { " r e f e r e n c e s " : { " $and " : [ { " r e f e r e n c e s " : { " $ a l l " : [ " bd3e0656ab ", " bdbe0656a " ] }}, { " r e f e r e n c e s " : { " $nin " : [ " bdbe0656a " ] }} ] } } ) Ebben a kialakításban az állomány és a címke egyenrangúnak tekinthető. A lekérdezések ezért mindkét irányba minimális módosításokkal működni fognak, viszont az adatok felvitelénél és a törlésénél ügyelni kell a hivatkozások beállítására. Elképzelhető olyan megoldás, melyben csak a fájlokhoz tartoznak címkék azonosítóiból álló listák Saját tárolási struktúra Egyedi azonosítók A kulcsértékek formátumának meghatározása a rendszer felépítésére és skálázhatóságára komoly hatással van. Az állományok és a címkék számát nem lehet előre tudni, ezért olyan megoldásokban érdemes gondolkozni, amely használható lesz akkor is, ha a rendszerben tárolt adatok mennyisége nagyságrendekkel növekedne. A választott megoldás változó hosszúságú kulcsértékeket használ. Az alapegysége a bájt, aminek az első bitje jelzi, hogy folytatódik-e még a kulcs. A kulcs általános felépítése látható a 4.2 ábrán ábra. A változó hosszúságú kulcs szerkezete. A bájtok elején lévő bitek kötöttek a láncolás miatt, a többi bit szolgál a kulcs értékének tárolására. A kulcs egy 128-as számrendszerben felírt számhoz hasonló. Ami lényeges különbség, hogy itt a nulla értéket nem lehet lehagyni a számjegy elejéről. Például a 0x00, 0x8000, 0x (hexadecimális alakban felírt) értékek különböző kulcsértékeknek számítanak. A láncoláshoz használt bit nem jelent nagy plusz költséget. Nagyságrendileg például a maximum 4 hosszúságú kulcsokból van, ami egy átlagos asztali környezetben már elegendő lehet az állományok azonosításához. A 0x00 értéket több ok miatt is érdemes speciális jelentéssel felruházni. Az egyik például, hogy így az értékeket közvetlenül egymás után lehet tárolni úgy, hogy a lista végét ez az érték jelzi. A kulcsok kezeléséhez szükséges alapműveleteket egy külön Id nevű osztály látja el. Az osztály felépítése a 4.3. ábrán látható. A size metódus a kulcs hosszát adja vissza. A copy metódus egy másolatot készít a paraméterében megadott kulcsról. A listsize a kulcsértékeket tartalmazó tömbök méretét számítja ki. A kulcsok nagyság szerint sorba rendezhetők. Ennek egyszerűbbé tételére a compare metódus két kulcsértéket össze tud hasonlítani, és 1, 0 vagy 1 értékkel tér vissza, annak megfelelően, hogy az első kulcs kisebb, egyenlő vagy nagyobb mint a második. 22

29 4.4. Saját tárolási struktúra 4.3. ábra. Az Id osztály metódusai. A kulcsérték inkrementálásához az increment metódust célszerű használni. Ez egy új kulcsértéket ad vissza, mely a paraméterben szereplőt követi a rendezés szerint. (Az értéket közvetlenül növelni azért nem lehet, mert előfordulhat, hogy a növelést követően a kulcs hossza is változik.) A read és a tostring metódusokkal a szöveges konverziók végezhetők el. A kulcs szöveges formátuma a keret elhagyásával kapott 7 bites egységes tizes számrendszerbeli alakjából áll / jelekkel összekapcsolva, például 0/32/ Kifejezések és elemek Az állományok és címkék adatait egységesen kifejezésekként, Expression objektumokként kezeli a program. Ennek azonosítója (id), neve (name) és típusa (type) van. A mezők értékének jelentése változhat attól függően, hogy fájlról vagy címkéről van-e szó. A két típus közötti elkülönítés érdekében az Expression-ből származik a File és a Tag osztály (4.4 ábra). Ennek elsősorban a függvények paraméterezésénél lesz jelentősége ábra. Az Expression, és a belőle származtatott osztályok főbb részei. Az adatok tárolása szempontjából a két típus egységesen kezelhető. Erre az Element származtatott osztály szolgál. Ez a references tömbjében megadott kulcsértékekkel hivatkozni tud a más elemekre. Hivatkozásokat hozzáadni és eltávolítani az add- Reference illetve a removereference metódusokkal lehet. A hivatkozásokat a tömbben növekvő sorrendben tárolja, amelynek majd a keresésnél lesz fontos szerepe. Az adatait fájlba menteni a save metódussal, fálból olvasni pedig a load metódussal lehet. 23

30 4.4. Saját tárolási struktúra Gyűjtemények Az elemek gyűjteményekbe rendezéséhez a Collection osztály használható (4.5. ábra). Ez ténylegesen nem tárolja azokat, csak egy hozzáférési réteget biztosít. Egyik fő feladata, hogy nyilvántartja a szabad kulcsértékeket. Ehhez egy vermet készít, amelybe új szabad azonosítót berakni a pushfreeid, kivenni pedig a popfreeid metódussal lehet. Egy új elem létrehozásakor a getfreeid metódusa adja a következő szabad azonosítót. Törléskor a releaseid-t szükséges meghívni az azonosító felszabadításához ábra. A Collection osztály felépítése. A másik fontos feladat az azonosítók útvonalakra való leképzése a getpath metódussal. Az elemek a fájlrendszerben külön fájlként jelennek meg. A gyűjtemény egy speciális jegyzékstruktúra, amelynek a gyökerét a rootdirectory adattag tárolja. Az azonosító utolsó bájtjának 10-es számrendszerbeli alakja adja a fájl nevét. A megelőző bájtokból (ha vannak) a fájlhoz vezető útvonal képezhető. Az első bitek csak a láncolás miatt fontosak, azt elhagyva, a fájlnévhez hasonlóan lehet előállítani a jegyzékneveket. A 4.6 ábrán a jegyzékstruktúra felépítésének a vázlata látható. rootdirectory 0.ext 1.ext ext ext 1.ext ext ext 1.ext ext ábra. Az elemek tárolásához használt jegyzékstruktúra vázlata. A fájlok kiterjesztése kollekciónként kötött. A struktúra gyökerét és a kiterjesztést a konstruktorban lehet megadni. A providedirectory metódus a jegyzékek kezelését egyszerűsíti, ellenőrzi a jegyzék meglétét, és automatikusan létrehozza amennyiben az hiányozna. 24

31 4.4. Saját tárolási struktúra A szabad azonosítók nyilvántartásához a törölt elemek helyén egy olyan elem van, amelyik hivatkozik a következő szabad azonosítóra. Ez olyan fájlt jelent a tárolás szempontjából, amelynek a kiterjesztés helyett csak egy _ utótagja van, és csak egy azonosító értéket tárol. Olvasásukhoz és írásukhoz készült a readid és writeid metódus. A lista első eleme a 0x00 kulcsértékhez tartozó elem. A freeidlistpath adattag tárolja ennek az elérési útvonalát. Adott kulcsértékhez tartozó szabad csomópont elérési útvonalát a getfreenodepath metódus adja meg Keresés név alapján A címkéket a felhasználók szövegesen is megadhatják. Biztosítani kell egy hatékony adatszerkezetet, amely a nevekhez hozzá tudja rendelni az elemek azonosítóit. Ehhez alapvetően egy asszociatív tömb szükséges, ami lehet például prefix fa vagy önszervező kiegyensúlyozott fa is. A prefix fa (trie) egy olyan fastruktúra, amely a benne tárolt szavak közös prefixeit csak egy helyen tárolja. A közös prefixet követően vannak benne elágazások, méghozzá annyi irányba, amennyi lehetséges folytatás van. A tárolt értékek a fa leveleihez rendeltek. A fában a szöveges kifejezéshez tartozó értéket megkeresni úgy lehet, hogy a gyökérből kiindulva minden lépésben a következő karakternek megfelelő irányba kell továbbhaladni. Nem kötelező, de számos előnnyel jár, ha a fa rendezett, vagyis ha a gyerekelemek egy rendezési relációnak megfelelően követik egymást. A 4.7. ábrán egy olyan prefix fa látható, mely az eper, erdei, erdő, est, jeges, jegyzet, jel, jelentés, kép, könyv, kör és körút szavakat tárolja. A pont termináló karakterre azért van szükség, hogy az olyan szavakat is el lehessen helyezni a struktúrában, amely egy másik szó prefixe. A példában ilyen többek között a jel és a jelentés szó. e j k p r s e é ö e d t g l p n r r e ő. e y. e. y.. i. s z n v.. e t. t é. s ábra. Példa egy 12 kifejezést tartalmazó prefix fára. A prefix fa konkrét megvalósításának több, egymástól jelentősen eltérő módja van. A karakterkészlet véges számú karakterből áll, ami egyben azt is megadja, hogy egy 25

32 4.4. Saját tárolási struktúra csomópontnak maximum mennyi gyerekeleme lehet. A legegyszerűbb megoldás minden csomópontban egy tömböt tárol, amelynek az indexeléséhez a karaktereket használja. A tömbben a gyerekelemek mutatói lesznek. A keresés így nagyon gyors lesz, és az algoritmusok is egyszerűen leírhatók, viszont a tárigény szempontjából nem szerencsés a megoldás. Ha a fában aránylag kevés elágazás van, akkor a tömb feleslegesen foglalja a területet. A fát azonos típusú elemek láncolt listáiból is fel lehet építeni. Minden listaelemnek rendelkeznie kell egy gyerek és egy jobbtestvér mutatóval, illetve tárolnia kell az adott karakter értékét. A szülő és a bal oldali testvér mutatóinak tárolása egyszerűsít az algoritmusokon ugyan, viszont a tárigényt közel duplázza. Sajnos már a két pointeres változatnál is problémák merülnek fel. A tárolandó karakter általában 1 bájton elfér. Egy 64 bites rendszer tekintve egy mutató 8 bájtot foglal, amivel tehát egy csomópont mérete 17 bájt lenne. Tovább rontja a helyzetet, hogy ez a hardver oldaláról nem egy kényelmes kezelési egység, így a fordító a méretet 4 vagy 8 többszörösére egészíti ki, ami miatt a csomópont mérete 24 bájt is lehet. A csomópontokban dinamikus tömböket használva a tárigény csökkenthető. Ez a műveleti idők növekedését vonja maga után, mivel a beszúrásnál és a törlésnél is újra kell allokálni a tömböket és az elemeik nagy részét is másolni kell. A gyerekmutatók keresésnél a lineáris keresés szintjén rontja a hatékonyságot. Az alkalmazásba az előbbi, dinamikus tömböket használó prefix fa került. A Trie osztály szöveges értékekhez tetszőleges (void* típusú) mutatókat rendel. Az osztálydiagramja a 4.8. ábrán látható ábra. A Trie, és a belőle származtatott IdTrie osztályok. A TrieNode struktúrában két, azonosan size elemszámú tömbre mutató pointer van. A values a csomópontban választható további karaktereket tárolja, a children pedig ennek megfelelően a gyerekelemek mutatóit. A prefixfa gyökerének címe a Trie osztály root adattagjában van. Elemeket a fába beszúrni az insert, belőle törölni pedig a remove metódusokkal lehet. Az ősosztály tetszőleges típus kezelésére képes. Az elemeket item néven kezeli, azokat a fában megkeresni a find metódussal lehet. Az osztály implementációjában iteratív algoritmusok szerepelnek. Mivel a szülőmutatókat a fa nem tárolja, ezért ahol szükség lenne rá (például mélységi keresésnél) ott 26

33 4.4. Saját tárolási struktúra egy vermet épít neki átmenetileg. A verem tetejére a parentstack mutat. Új csomópontot, mint szülőt beletenni a pushparent-tel lehet, a verem tetejéről levenni pedig a popparent-tel. Annak, hogy a fa kulcsokat tárol a fájlba mentésnél (save), illetve a fájlból olvasásnál (load) lesz jelentősége. A IdTrie az adatokat szöveges formában menti le. A fájlformátum úgy épül fel, hogy egy sorban van a kifejezés, és mögötte szóközzel elválasztva a kulcsérték. A kulcs értéke a gyűjteménynél bemutatott útvonal formájában jelenik meg. Az állomány egyes sorai tehát például a következőképpen nézhetnek ki. j e g e s 1/78/107 j e g y z e t 7/62/65 j e l 9/10/125 A kifejezésben természetesen szóközök is lehetnek, mivel a végét az egész sorban lévő utolsó szóköz határozza meg. A szöveges formátum nem hatékony, viszont néhány százezer név és kulcsérték párnál még elfogadható időn belül elvégezhető a mentés és a betöltés. A helyes működés és a műveleti idők tesztelésére készült a test/unit_test.cpp állományban definiált TrieTest osztály (4.9. ábra) ábra. A prefixfa tesztelésére szolgáló osztály. A teszteléshez nagy mennyiségű szöveges kifejezésre volt szükség, amelyik címke neveként előfordulhat. Ilyeneket találhatunk például szótárfájlokban, vagy valamilyen kifejezésgyűjteményben. A teszteléshez a gyűjtemény választásánál szempontként szerepelt, hogy ékezetes betűket, speciális karaktereket is tartalmazzon. Ezekkel gyakran probléma szokott lenni, így már a tesztelés kezdeti szakaszában jobb felkészülni ezekre. A kifejezések változatos hosszúságúak legyenek. A hosszú címkenevek a rendszerezés szempontjából később biztosan nem lesznek szerencsések, viszont a Trie osztály tetszőleges hosszúságú szöveges értékekhez készült. Tartalmazzon ismétlődő kifejezéseket is. Erre azért érdemes külön figyelmet fordítani, mert a szógyűjteményekre ez nem jellemző, viszont az algoritmusokat az ismétlődésekre is fel kell készíteni. A választott gyűjtemény (tag_samples.txt) magyar nyelvű, de nem feltétlenül értelmes kifejezést tartalmaz. A gyűjteményben különböző kifejezés van. A TrieTest osztály a load metódusában a samples vektorba tölti fel az egyes sorokban lévő kifejezéseket. Az inserttest a vektor elemein végighalad, és mindegyiket megpróbálja beszúrni a fába. A következő lépésben mindegyiket ellenőrzi, hogy valóban 27

34 4.4. Saját tárolási struktúra benne vannak-e a fában. A removetest sorban törli a fából az elemeket, és minden törlésnél vizsgálja, hogy az valóban eltávolításra került-e. A saveandloadtest a fájlba mentésre és a betöltésre vonatkozik. Ez a fát feltölti elemekkel, és elmenti a test.trie fájlba, majd innen visszaolvasás után ellenőrzi, hogy mindegyiket meg tudja-e találni. A kifejezésekhez tartozó kulcsok a 0/0/1-gyel kezdődnek, és sorban egyesével növekednek. A metódusok akkor térnek vissza igaz értékkel, ha sikeres volt a teszt. Az asszociatív tömb egy másik, szintén gyakori megvalósítási módja a piros-fekete fa. A C++ szabványos sablonok között a map is ezt a struktúrát használja. A szükséges műveletekkel a map is rendelkezik, így össze lehet hasonlítani, hogy a két struktúra közül melyiket, és milyen okok miatt lenne célszerű használni. A tesztosztály rbtreetimes és trietimes metódusa a beszúrás és keresés sebességét méri. A tesztek mérik a beszúrás és a keresés idejét is. Ezek eredményei grafikus formában a 4.10 és a ábrán láthatóak. A mérési pontok beszúrásonként, illetve keresésenként következtek egymás után, az időegység pedig másodperc volt. A teszt is igazolta, hogy mindkét művelet konstans idejű mindkét adatstruktúra esetében. A prefix fa eredményei rosszabbak ugyan, viszont lényegesen nem marad el a piros-fekete fa mögött. A grafikonok görbéin vannak nagyobb törések. Ezeket a memóriafoglalás időigénye, illetve a szavak hosszával arányos műveleti idők okozzák ábra. A prefix és piros-fekete fába való beszúrás időigénye (10000 elemenként, másodpercben megadva). A prefix fák alkalmazásának a későbbiekre nézve vannak további előnyei is. Ilyen például, hogy csak egy prefix alapján is lehet keresni benne. Ezzel megoldható a kifejezések automatikus kiegészítése. A fa csomópontjaihoz gyakoriságokat vagy valószínűségeket is rendelhetünk. Ennek segítségével az adott prefixel kezdődő szavakat a szerint lehet rendezni, hogy melyik a leginkább várható. A hatékonyság javításához számos lehetőség adott. A beszúrás gyorsításához előre le lehet foglalni nagyobb méretű tömböket a csomópontokban. Ez a gyökérnél jelentheti akár az összes lehetséges karakternek megfelelő méretet (256 elemet), míg a levelek felé közeledve egyre kevesebbet. A kereséshez a csomópontban lévő lineáris keresést ki lehet cserélni binárisra is, mivel rendezett a fa. Az adatszerkezet nagy memóriaigényét csökkenteni a hosszú, elágazás nélküli szakaszok összevonásával lehet. Ez egy bevett gyakorlat. Az ilyen struktúrát kompakt prefix fának (compact prefix tree), radix fának (radix trie) vagy patricia trienek (Practical Algorithm to Retrieve Information Coded 28

35 4.4. Saját tárolási struktúra ábra. A prefix és piros-fekete fában való keresés időigénye (10000 keresésenként, másodpercben megadva). in Alphanumeric) nevezzük [DM68] Adatbázisobjektum Az eddig bemutatott osztályok az adatok tárolásának és visszakeresésének részfeladatait külön oldották meg. A Database osztály ezeket összehangolja, és egy felületet biztosít a kezelésükhöz (4.12. ábra). Az adatbázis három gyűjteményt kezel. A filecollection az állományok adatait, a tagcollection a címkék adatait a storagecollection pedig magukat az állományokat tárolja. A címkék neveinek tárolására és keresésére szolgál a tagnames trie. Az adatbázis objektummal az adatokat cserélni File és Tag típusú objektumok formájában lehet. A lekérdezések során ezeket Element típusokra képzi le, de ez az objektum használata során nem látszik. Új fájlt beszúrni a insertfile, aktualizálni az updatefile, törölni pedig a removefile metódusokkal lehet. A címkék esetében ugyanilyen feladatokat lát el az inserttag, updatetag és a removetag metódus. A fájlok és a címkék közötti kapcsolatok hozzáadásához az insertrelation metódust használjuk. Ennek kétféle paraméterezése is van a szimmetria miatt. Bizonyos esetekben érdemes a társítást vagy a fájl, vagy a címke szempontjából megközelíteni. A kapcsolat törlésére megegyező paraméterezéssel a removerelation-t lehet használni. Egy címkét név alapján lekérdezni az adatbázisból a findtagbyname metódussal lehet. Ez az adatbázis objektum prefix fájában keresi meg a nevet, majd ebből készít egy új Tag objektumot. Egyidejűleg több címke is lekérdezhető a findtagsbyprefix metódussal. Ez első paraméterként a keresett címkék prefixét várja, ami lehet üres is. A limit paraméterrel a visszaadott címkék maximális száma határozható meg. Az állományok címkék alapján történő keresésére a findfiles metódus szolgál. Ennek paramétere a címkék és az ellentett címkék listája. Az eredmény File objektumok listája lesz. A keresés a következő nagyobb lépésekből áll. A kereséshez használt két címkelistából Element típusokat tároló lista készül. Az átadott Tag objektumoknak érvényes azonosítókkal kell rendelkezniük. A lekérdezést a query metódus valósítja meg. Ez már az azonosítók listáit várja, illetve azt a kollekciót (domain), amelyikben keresnie kell. 29

36 4.4. Saját tárolási struktúra ábra. Az adatbázis osztály adattagjai és metódusai. A megadott azonosítók alapján beolvassa az Element objektumokat a kollekcióból. Kiválaszt egy hivatkozási tömböt (célszerűen a legrövidebbet), és abból készít egy láncolt listát. A többi hivatkozási tömbbel az intersect és a subtract metódusokkal szűri az elemeket a listából. Az intersect azokat az elemeket törli a listából, melyek nem szerepelnek a szűrési feltételként megadott tömbben, a subtract pedig éppen azokat amelyek egyeznek. A query egy azonosító listával tér vissza. Ehhez még az adatbázis visszakeresi az elemeket, azokból kifejezéseket készít, és az így kapott eredménylistával tér vissza. A lekérdezési mód feltételezi, hogy a lekérdezésben mindig szerepel egy nem ellentett címke. A későbbiekben majd látható lesz, hogy ez egyáltalán nem jelent gondot, mivel legalább egy, vagy a felhasználóra vagy az adattárolóra vonatkozó címke mindig érvényben van a keresésben. Az adatbázis objektum a fájlok behozatalát és kimentését is biztosítja az import- File és exportfile metódusokkal. A fájlok megnyitásához a createlink metódussal link készíthető a paraméterben megadott helyre. Az adatbázis objektum tehát már képes ellátni a kontextus kezelésével járó feladatokat. A megvalósítás erősen kötődik a UNIX rendszerekhez az elemeknek és a címkék neveinek a tárolási és a linkek kezelési módja miatt. 30

37 5. fejezet Parancssoros kezelőfelület A fájlok kezelésének egyik első, és a mai napig használatban lévő eszköze a parancssor. Ez a felhasználótól az utasításokat szöveges formában várja, azt értelmezi, majd szintén szöveges formában válaszol. Tipikusan a kiadott parancs a parancs nevéből és a paraméterezéséből áll. A következőkben szereplő parancsok is ezt a formát követik. Fájlkezelés kapcsán a fájlok neveinek listázására, a másolási, mozgatási és törlési műveletekre kell külön kitérni. Ezek bemutatása a feldolgozási folyamat szintjeinek megfelelően következik A parancsok felépítése és használata A parancssornak a parancs szintaktikáját és szemantikáját is ellenőrzi. Az ellenőrzéshez azt először tokenekre bontja. A tokenek adatainak tárolására egy struktúra jellegű Token osztály szolgál (5.1. ábra) ábra. A struktúra jellegű token osztály adattagjai. A tokenhez tartozó szöveges értéket a value mező tárolja. A TokenType mező értéke ID, PLAIN, PLUS, MINUS, NEGATED vagy BRACKET lehet. A tokeneket szóköz, vagy egyéb nem használt karakter választja el ott, ahol az elválasztás nem egyértelmű. A nem definiált karaktereket az értelmező egyszerűen kihagyja, azokra hibát nem jelez. Az ID a szöveges formában megadott kulcsérték. Ennek a szintaxis diagramja az 5.2. ábrán látható. A Number ebben egy [0; 127] intervallumon értelmezett egész számot jelöl ábra. A kulcs (Id) szöveges leírási módjának, és a kifejezés (Expression) szintaxis diagramja. A PLAIN típusba a hagyományos, idézőjelek között megadott karakterlánc tartozik. A parancsokban fájlokat vagy címkéket kell egyértelműen azonosítani. A felhasználó 31

38 5.1. A parancsok felépítése és használata szemszögéből a névvel való azonosítás az egyszerűbb. Erre a címkék esetében mindig van lehetőség, mivel azoknak egyedieknek kell lenniük, viszont a fájlokra ez nem feltétlenül érvényes. A keresési módszerből adódik, hogy ha megkövetelnénk a név egyediségét a fogalmakban, akkor az egész rendszerben nem lehetne két azonos nevű fájl sem. Ez nyilvánvalóan nem megfelelő megoldás, ezért az olyan esetekben, ahol a fájl azonosítása nem egyértelmű az egyedi azonosítóját kell használni. (Azonosító mindig szerepelhet a név helyett.) A későbbi szintaxis leírást egyszerűsítésének érdekében itt is bevezethetjük a kifejezést (Expression), amely az Id vagy Plain valamelyikét jelöli. A PLUS, MINUS és NEGATED olyan kifejezések, melyeket +, - vagy! karakter előz meg (5.3. ábra) ábra. A Plus, Minus és Negated tokenek szintaxis diagramja. A BRACKET a [ vagy ] karakterek valamelyikét jelöli. Az eddigi elemek segítségével már az abszolút- és relatív útvonalak is definiálhatók (5.4. ábra). A címkékkel kapcsolatos műveletekhez a tag parancs használható. Ezt paraméter nélkül kiadva a kontextushoz tartozó címkék neveinek listáját kapjuk meg. A paraméterben abszolút vagy relatív útvonalat megadva az adott fogalomhoz lehet eljutni (5.5). Ezek a parancsok a jegyzékstruktúrában a cd (change directory) parancsnak felelnek meg ábra. Az abszolút- (AbsolutePath) és relatív útvonal (RelativePath) szintaxisa ábra. Címkék listázásának, és a fogalom váltásának parancsai abszolút- és relatív útvonallal. Parancssorok esetében segíti a tájékozódást, ha az aktuális pozíció is feltüntetésre kerül. A prompt ezért az abszolút útvonalat is tartalmazza, amit egy kettőspont követ. Az eddig bevezetett parancssori elemek bemutatására a következő példát mutatjuk. [ ] : tag [ " kö r ", " kép " ] [ " kö r ", " kép " ] : tag +" e r d e i " [ " kö r ", " kép ", " e r d e i " ] : tag! " e r d e i " [ " kö r ", " kép ",! " e r d e i " ] : tag "kö r " " e r d e i "! " t é l " [ " kép ",! " t é l " ] : 32

39 5.1. A parancsok felépítése és használata Az első parancs egy abszolút útvonalat állít be, az utána következő három pedig relatívakat. Minden címke csak egyszer szerepelhet az útvonalban. A felkiáltójellel kezdődő megadás vagy egy új ellentett címkét ad hozzá az addigi útvonalhoz, vagy a már benne szereplőt negálja. Amennyiben az már negálva van, akkor az újabb negálásra nem fordul meg. Tulajdonképpen úgy kell tekinteni, mint ha felülírásra kerülne. A szemléletesebb példák érdekében érdemes itt megadni a fogalomhoz tartozó fájlok listázásának módját. Ez egyszerűen az ls vagy list paranccsal végezhető el. [ " kép ",! " t é l " ] : l s 1/34 ő sz. png 1/36 tavasz. png 1/37 nyá r. png Az első oszlopban az egyedi azonosítók vannak, a másodikban pedig a fájlok nevei. A címkenevek listázási formátuma nagyon hasonló. [ " kép ",! " t é l " ] : tag 120 e r d e i 11 kép 14 kö r 0/80 nyá r 0/81 ő sz 0/82 tavasz 0/83 t é l A relatív útvonalban is szerepelhet azonosító, például a következő módon. [ " kép ",! " t é l " ] : tag +0/80 [ " kép ",! " t é l ", " nyá r " ] : l s 1/37 nyá r. png A fájlok közös címkéinek lekérdezéséhez a fájlneveket a tag után kell megadni (5.6. ábra). A listában az aktuális fogalomhoz tartozó fájlokra lehet hivatkozni névvel, ha azok egyediek. Amennyiben a fogalom több azonos néven szereplő állományt tartalmazna, akkor az azonosítót kell használni ábra. A felsorolt állományokhoz tartozó közös címkék lekérdezése. A fájlok közös címkéinek lekérdezésére példa az alábbi parancs. [ " kép ",! " t é l " ] : tag " tavasz. png " " nyá r. png " 11 kép 33

40 5.1. A parancsok felépítése és használata A fájlok mozgatásához használt parancsok tulajdonképpen már következnek az eddigiekből. A fogalom váltásához használt parancsokat kell kiegészíteni a fájlok listájával (5.7. ábra) ábra. A megadott fájlok mozgatása abszolút- vagy relatív útvonallal. A mozgatás itt mindössze átcímkézést jelent. Például a nyár.png fájlt a fénykép címkével alkotott szűkebb fogalomba áthelyezni az alábbi módon lehet. [ " kép ", " nyá r " ] : l s 1/37 nyá r. png [ " kép ", " nyá r " ] : tag " nyá r. png " +" f énykép " [ " kép ", " nyá r " ] : tag " nyá r. png " 11 kép 0/80 nyá r 1/46 f énykép A szintaxis megengedi, hogy negált címkék is legyenek az útvonalakban áthelyezéskor. Ez itt furcsának tünhet, mivel negált címkét a fájlhoz hozzárendelni nem lehet. Erre egyrészt az egységesség miatt szükség van, másrészt pedig ha az adott áthelyezendő fájl rendelkezik egy olyan címkével amelyik negálva benne van a célként megadott fogalomban, akkor azt a címkét el kell távolítani a fájlról az áthelyezés során. Ennek a bemutatására a következő példa szolgál. [ " kép ", " nyá r " ] : tag " nyá r. png "! " t é l "! " f énykép " [ " kép ", " nyá r " ] : tag " nyá r. png " 11 kép 0/80 nyá r A relatív útvonallal megadott áthelyezés csak módosítja az érintett címkéket, míg az abszolút útvonal esetében a címkelista cseréjéről van szó, például [ " kép ", " nyá r " ] : tag " nyá r. png " [ " f o n t o s ", " t á jk ép " ] [ " kép ", " nyá r " ] : tag " nyá r. png " 58 f o n t o s 0/165 t á jk ép 34

41 5.2. Kapcsolat a befogadó fájlrendszerrel A tag parancs szintaktikája viszonylag összetett, mivel az összes címkelistával kapcsolatos lekérdező és módosító műveletet ezzel lehet megvalósítani. A másolás és törlés már jóval egyszerűbb. Fájlokat másolni a cp vagy a copy paranccsal lehet. A paraméterezése megegyezik az áthelyezésével. A működésük annyiban tér el, hogy a másolást követően mindkét helyen meg lesz egy példányban az állomány, és függetlenül kezelhetőek a továbbiakban. Duplikátumok útvonal megadása nélkül készíthetők vele. Ez a sablonok használatánál lehet például hasznos, mint ahogy az alábbi rövid példa is mutatja. [ " sablon ", "LaTeX " ] : l s 0/76 j e g y z e t. tex 0/90 prez. tex [ " sablon ", "LaTeX " ] : cp " prez. tex " [ " sablon ", "LaTeX " ] : l s 0/76 j e g y z e t. tex 0/90 prez. tex 1/51 prez. tex [ " sablon ", "LaTeX " ] : tag 1/51 [ " e l őadá s ", " e l s ő vá l t o z a t " ] A törléshez az rm vagy a remove parancsot lehet használni. Ezzel az aktuális fogalomhoz tartozó fájlokat lehet törölni a fájlok neveinek vagy azonosítóinak megadásával. Az összes fájl törléséhez a fájllista helyett paraméterként a * karaktert is meg lehet adni. Az átnevezés ebben a kialakításban nem oldható meg úgy, mint a jegyzékek esetében az mv utasítással. Ehhez itt külön be kell vezetni egy rename parancsot, ami első paraméterként az átnevezendő fájl elérését, másodikként pedig az új nevet várja. Ez a következőképpen nézhet ki. [ " sablon ", "LaTeX " ] : rename " prez. tex " " prezent á c i ó. tex " Átnevezésre a címkék esetében is szükség lehet. Ez a rename tag utasítással végezhető el, például [ " sablon ", "LaTeX " ] : rename tag "LaTeX" " l a t e x " [ " sablon ", " l a t e x " ] : 5.2. Kapcsolat a befogadó fájlrendszerrel A címkézést használó rendszernek valamilyen módon fájlokat kell tudni cserélnie a hagyományos rendszerekkel. A fájlok importálásához az import parancs használható. Ennek első paramétere az útvonal, a második a fájl neve a harmadik pedig a típusa. Az így létrejött fájl az aktuális fogalomba kerül. Az import parancs használatát a következő példa mutatja be. [ " sablon ", " l a t e x " ] : import "/ Docs/sym. tex " " sym. tex " " tex " 35

42 5.3. A parancsok értelmezése és végrehajtása [ " sablon ", " l a t e x " ] : l s 0/76 j e g y z e t. tex 0/90 prezent á c i ó. tex 1/83 sym. tex A fájlok kimentése hasonlóképpen történik az export paranccsal. Az exportálásához a kontextusban a fájl elérhetőségét és az új útvonalat kell megadni, például [ " sablon ", " l a t e x " ] : export " j e g y z e t. tex " "/ Docs/ j e g y z e t. tex " Az importálás és az exportálás is másolással jár. Amennyiben az adott fájl megnyitására lenne szükség egy link készítése hatékonyabb megoldás. Ehhez a link parancsot kell kiadni, aminek a paraméterezése teljesen megegyezik az exportáláséval. Az előbbi példa linkeléssel a következőképpen néz ki. [ " sablon ", " l a t e x " ] : l i n k " j e g y z e t. tex " "/ Docs/ j e g y z e t. tex " Ez egy hard linket készít a megadott helyre, ami csak akkor hozható létre, ha azonos fájlrendszerben van, mint maga a címkézéses adatbázis A parancsok értelmezése és végrehajtása A szövegként érkező parancsok értelmezéséért a Command osztály a felelős (5.8. ábra) ábra. A parancsok értelmezéséért felelős osztály felépítése. A parse metódusában kell megadni a feldolgozandó parancsot. A feldolgozás sikerességét a visszatérési érték jelzi. Igaz értékkel tér vissza, ha rendben végre tudta hajtani. A parancs neve a commandname attribútumba kerül. A beolvasott fájlnevek a files, míg az útvonalhoz tartozó elemek a path listába kerülnek. Az absolute logikai érték jelzi, hogy a beolvasott parancsban abszolút vagy relatív útvonal szerepelt-e. Az aktuális fogalom nyilvántartásával és műveleteivel kapcsolatos adminisztrációt a Scope osztály végzi (5.9. ábra). Az aktuális lekérdezést QueryItem-ek listájában tárolja. Ebben benne vannak a címkék, illetve az isnegated logikai érték jelzi, hogy ellentett címkéről van-e szó. Ez az osztály tartja a kapcsolatot magával az adatbázissal a database adattagon keresztül. Itt már megjelenik az aktuális felhasználó jelzésére szolgáló címke is. Ezt a setuser metódussal lehet beállítani. A fájlok importálása, exportálása és linkelése az importfile, exportfile és link- File metódusokkal hajtható végre. Az abszolút és relatív útvonal beállításához az absolutepath és relativepath metódusokat kell használni. Az aktuális fogalomra 36

43 5.3. A parancsok értelmezése és végrehajtása 5.9. ábra. Az aktuális fogalmat kezelő osztály. jellemző abszolút útvonalat a getpath adja, a fogalomhoz tartozó fájlok listája pedig a getfiles metódussal kérdezhető le. A címkék neveihez a gettaglist illetve getcommontags-t lehet használni. A többi metódus is tulajdonképpen közvetlenül megfeleltethető a már bemutatott műveleteknek. A parancssori felületet a Shell nevű osztály hozza létre (5.10. ábra) ábra. A parancssort kezelő osztály vázlatos felépítése. A parancssort elindítani a run metódusával lehet. Ezt követően az objektum csak minimális előfeldolgozás végez az interpret metódusában. A feladata mindössze a beolvasott parancs továbbítása a scope objektumnak. Ez olyan kivételes esetekben nem szükséges, mint például az exit parancsnál, amellyel ki lehet lépni a parancssorból. 37

44 6. fejezet Grafikus felhasználói felület Az állományok kezeléséhez a felhasználók manapság már grafikus felületeket használnak. Alkalmazásonként ugyan vannak különbségek közöttük, de ennek ellenére a fő jellegzetességeik, és típusaik jól elkülöníthetőek. A legnépszerűbb az a változat, amelyik a fájlokat és jegyzékeket ikonokkal reprezentálja. Opcióként megjelenik a listás vagy fa struktúrájú megjelenítés is. Egy külön csoportot képeznek a kétpaneles (ortodox) fájlkezelők. Ennek jeles képviselői a Norton, a Volkov, a Midnight és a Total Commander. Az első három ugyan még karakteres felületet használ, viszont a fájlműveleteket bennük már kijelöléssel és közvetlen grafikus visszacsatolással lehet végrehajtani A felhasználói felület elemei A grafikus fájlkezelő felület megtervezésénél az eddig más rendszerekben már bevált módszerek és az újszerű, fogalmakra épülő elvi modell ötvözése volt a cél. Ennek eredménye az a 6.1. ábrán látható. a e b d c 6.1. ábra. A fogalom alapú grafikus állománykezelő rendszer vázlatos felépítése a. az aktuális fogalom címkelistája b. új címke felviteléhez beviteli mező, c. címke javaslati lista, d. az eredményben szereplő állományok, e. ikon az állomány reprezentálására. A bal-felső részben (a) a kereséshez használt címkék listája szerepel. Ez tulajdonképpen a parancssornál bemutatott prompt-nak feleltethető meg, vagy a jegyzékstruktúra esetében felső sávon elhelyezett útvonalnak. Ez alatt (b) van az új címkék megadásához a beviteli mező. Ez az új címkék felvitelénél fokozatosan lejjebb kerül. A bal oldali sáv alsó részén (c) azon címkék listáját jeleníti meg a program, amelyre a következő 38

45 6.3. Példa az egypaneles kialakításra lépésben szükség lehet. Az ebben szereplő címkék meghatározásához több stratégiát egyidejűleg kell figyelembe venni. Ezek például a következők lehetnek. Vélhetően arra a címkére lesz nagyobb szükség, amelyik több állományon szerepel. A nemrégiben használt címkékre nagyobb valószínűséggel lesz szükség, mint a régebbiekre. A fogalomhálóban a fogalmak közötti reláció szerinti rákövetkező fogalmakban megjelenő új címkék specializálják az aktuális fogalmat, ezért azokat érdemes előre venni. A címke nevének gépelése közben a lehetséges címkék száma jelentősen csökkenthető akár a prefix akár a jellemző karakterkapcsolatok alapján. Ezek mellett a felhasználónak is célszerű lehetőséget biztosítani a lista összeállítási módjának befolyásolására. Ilyen lehet például, hogy bizonyos címkéket könyvjelzőszerűen rögzíthessen, vagy a ritkábban használt, de egyébként gyakori címkéket el tudja rejteni. A címkék listájának előállításában a kontextus vizsgálata is sokat segít. Ennek egyik módja a címkék hálóba szervezése lehet [KL07]. A felület nagyobbik részére (d) kerülnek a fogalomhoz tartozó állományok. Ezek megjeleníthetők a szokásos módon ikonokkal (e) A címkék típusai A grafikus megjelenítés a parancssori megvalósításban bemutatott funkciók kényelmesebb, természetesebb elérési módját teszi lehetővé. A címkék típusait és használati módjukat, ezért itt pontosítani kell. Egy címke azon túl, hogy a címke nevének megjelenítésére szolgál, két fő részből áll, melynek feladata típusonként változhat (6.2. ábra). f g 6.2. ábra. A címke sematikus rajza f. gomb a ritkábban használt funkciókhoz, g. a címke neve, és gomb a gyakrabban használt funkciókhoz. A címke alapvető típusa az, amely az aktuális fogalom részét képezi. Ez lehet akár ellentett attribútumhoz tartozó is. A két gomb feladata itt nem válik külön. Bármelyik részére kattintva a címkét ki lehet venni a kereséshez használt címkék közül. Ezek alatt van az a címke, amely új címke felvitelére szolgál. A címke nevének begépelését követően vagy az enter billentyűt kell megnyomni vagy pedig a címkén látható plusz jelre kell kattintatni, hogy a megadott név az aktuális abszolút útvonalba belekerülhessen. A javaslatcímkékre kattintva a teljes név begépelése nélkül is kiválaszthatók a címkék. Ennek a bal szélére kattintva a negált címke kerül be a keresési kifejezésbe. Az eredményben szereplő ikonokat kijelölve a bal oldali sávon a címkék működése is változik. Az útvonal kiegészül az aktuálisan kijelölt fájlok abszolút útvonalban nem szereplő címkéivel. Az útvonalban szereplő címkék bal széle ekkor a címkék fájlokról való törlésére használható, a jobb oldali fele pedig úgy veszi ki a címkét a keresésből, hogy a fájlok kijelölése még érvényben maradjon. A címke hozzáadása ekkor már a kijelölt állományokra vonatkozik, a javaslatlistából választva is a címke már az állományra kerül. Ez azt is jelenti, hogy negált címkét nem lehet ekkor már megadni. Ennek a kezelési módnak megvan a szerencsés tulajdonsága, hogy a kijelölésben lévő fájlokat együtt lehet mozgatni a fogalmak között akár több lépésen keresztül is. 39

46 6.5. További funkciók 6.3. Példa az egypaneles kialakításra A 6.3. ábrán egy példa látható a felhasználói felületre. Itt az útvonalban a project, python és converter címkék vannak megadva. A keresés eredménye itt 10 fájl. Ezek mindegyikén biztosan szerepel az előbbi három címke ábra. Példa az egypaneles felhasználói felületre. Az állományokon lévő, útvonalhoz nem tartozó címkéket kijelöléssel nézhetjük meg. A converter.py nevű fájlt kijelölve a 6.4. ábrán látható eredményt kapjuk. Az állományon öt címke van. A címkék és a kijelölés színe is utal arra, hogy mely címkék tartoznak a kereséshez, és melyek a fájlhoz. A beviteli mező és a javaslatok színe is változik. Ez szintén nem csak az egységes szinezet miatt van, hanem mert ez is jelzi a megváltozott működést A kétpaneles változat előnyei A másolási és áthelyezési műveletek szempontjából előnyös, ha egyszerre látható a forrás és a cél. Jegyzékek, jelen esetben pedig fogalmak összehasonlításakor is kedvező. A 6.5. ábrán egymás mellett látható két fogalom a hozzá tartozó címkékkel és állományokkal. A bal oldalon egy Python projekthez tartozó állományok vannak, a jobb oldalon pedig Python szkriptek. Láthatóan a converter.py és a test.py nem tartozik a szkriptek közé, mivel csak a python címke van hozzájuk rendelve. A keresési egyszerű módjának köszönhetően be lehet másolni az állományokat oda, ahol legközelebb keresni fogjuk. A jegyzékstruktúra böngészésére is alkalmassá tehető a bal oldali sáv. Az analógiának megfelelően a címkék helyén az aktuális jegyzékhez vezető útvonalon lévő jegyzékneveknek kell szerepelni, a javaslati listában pedig az aljegyzékeknek. Két panel esetén az importálás és az exportálás is lényegesen egyszerűbb ebben a formában. 40

47 6.7. Felhasználói tesztek 6.4. ábra. A kijelölés hatására a címkék funkciója megváltozik További funkciók A grafikus felület számos további funkcióval bővíthető. A fogalmak maguk halmazpárok, így az eddigiekben az eredményhalmaz rendezettségével nem kellett külön foglalkozni. A fájlokhoz érdemes még további adatokat hozzárendelni, mint például a létrehozási, elérési és módosítási dátumok, a fájlméret, vagy a használati gyakoriság. Bizonyos esetekben ezek segítségével hatékonyabban lehet keresni. Könyvjelzők alkalmazhatók akár címke akár fogalmak szintjén is. A címkék alapján történő keresés egyik előnye éppen az, hogy a fájlokhoz vezető útvonal lerövödíthető, ha tudjuk, hogy mit keresünk. Megfelelően karbantartott könyvjelzőkkel ez még tovább javítható. Integrált asztali környezet esetében egy lomtárba kerülnek az állományok mielőtt véglegesen törölnénk azokat. Mivel a törlési műveletre itt is szükség van, ezért a lomtárról is érdemes gondoskodni. Ez megoldható az asztali környezetbe való integrációval. Címkézés esetén célszerűbb egy lomtár címkét alkalmazni. A fájlokat törléskor ezzel a címkével kell ellátni, így a lomtárban lévő fájlok egyben lekérdezhetők és törölhetők. Az általános lekérdezésekben, amelyek nem kifejezetten a lomtárra vonatkoznak a lomtár címke ellentettjének kell szerepelnie Implementációs lehetőségek A fájlkezelő alkalmazás grafikus implementációjához először a megfelelő, felhasználói felületek készítéséhez alkalmas függvénykönyvtár (widget toolkit) kiválasztása szükség. Célszerű platformfüggetlen megoldásokban gondolkodni, így például a Qt, a GTK, a wxwidget vagy az FLTK jöhetnek számításba. 41

48 6.7. Felhasználói tesztek 6.5. ábra. Példa a kétpaneles felhasználói felületre Felhasználói tesztek Egyelőre csak ad-hoc jellegű felhasználói tesztekre került sor. Ezek a grafikus felhasználói felület tesztelésére koncentráltak. A fő kérdés az volt, hogy mennyire érthető a felület felépítése és működése egy átlagos felhasználó számára. Készült egy egyszerűbb webalkalmazás prototípus, melyről egy kép a 6.6. ábrán látható. A kontextus tárolását PHP szkriptek és MongoDB segítségével oldja meg [SF12]. Egy panelt és egy fájl kijelölését támogatja a jelenlegi változat ábra. Az alkalmazás prototípusának felhasználói felülete. A visszajelzések alapján a felhasználói felület újszerűsége és az alkalmazott matematikai modell együtt azt sejteti, hogy a használati mód elsajátítása komoly erőfeszítéseket igényel. A fogalomhálónak és a műveleteinek megértése feltételez némi matematikai jártasságot, viszont az állományok kezeléséhez ezek ismerete nem szükséges. 42