A MISKOLCI EGYETEM HALLGATÓI TUDÁSTÁRA A KEZDETEKTŐL NAPJAINKIG

Átírás

1 A MISKOLCI EGYETEM HALLGATÓI TUDÁSTÁRA A KEZDETEKTŐL NAPJAINKIG Sztermen Orsolya Lili¹, Vitéz Gáborné², Veréb Norbert³ PhD hallgató, főtanácsos, számítástechnikai munkatárs ME-BTK Irodalomtudományi Doktori Iskola, ME Számítóközpont, ME Számítóközpont CÉLOK, TERVEK A Miskolci Egyetem doktorandusz hallgatójaként nyitott szemmel járok a publikálási lehetőségek világában. Ez idáig már sokszor kellett, hogy felsoroljam publikációimat. Vagy pályázathoz, vagy önéletrajzokhoz kellett összegyűjtenem őket. Amikor a megjelent publikációimat kell összegyűjteni, mindig gondban vagyok, vagyis voltam. Két évvel ezelőtt fogalmazódott meg bennem az igénye annak az adatbázisnak, amely a publikációimnak ad helyet. Annak az adatbázisnak, melyet elkészítettünk a Számítóközpont közbenjárásával. A Miskolci Egyetemen már korábban is létezett egy adattár - Miskolci Egyetemi Publikációs Adatbázis (MEPA) névre hallgat -, mely az oktatók publikációs tevékenységét hivatott tárolni. Egy ilyen adatbázis alapkövetelmény az egyetemeknek, e nélkül szétszóródnának az oktatók publikációi, érdemei. Nem utolsó sorban az adatbázis az adatismertetés hasznára válik mind az oktatóknak, mind az egyetemnek. A Publikációs Adatbázis az egyéni adatfeltöltés elvén működik, de sok esetben nem tartalmazza a szövegeket, csak azok megjelenési helyét, idejét és a szerzőjét, stb. azaz, a metaadatokat. Ezt azért fontos megjegyezni, mert mint hallgató, más igényeket támasztottam a saját elképzelésemmel szemben. Az eltérőség ellenére a Miskolci Egyetem Hallgatói Tudástára (MEHT) a MEPA adatbázisnak a működési elvét követi, egy dologban azonban eltér attól, és ez a tartalom. Én a MEPA-hoz képest egy hasonló rendszert képzeltem tehát el a hallgatók dolgozatainak tárolására, de a tartalom feltöltést, mint lényegi tulajdonságot kihagyhatatlannak tartottam. Fókuszban a hallgató Hosszas keresést követően sem találtam olyan adatbázist a magyar egyetemek honlapján, mely a hallgatók tudományos munkáit gyűjtené össze. Olyat sem találtam, mely a karok diákjainak kutatási tevékenységéről számol be. A kérdés felmerül ilyenkor mindenkiben: miért? Az egyik lehetséges válasz az, hogy nincs értelme a diákok munkáit összegyűjteni, hiszen azok nem minden esetben színvonalasak annyira, hogy az egyetem égisze alatt csokorba szedve jelenjenek meg. Egy másik válasz, hogy nincs értelme a kezdődő tudomány szárnypróbálgatásit gyűjteni, az érték a konferenciák és publikációk megjelenésével kezdődik, így oka vesztetté válik a szárnypróbálgatásra tekinteni. Az tény, hogy az oktatók publikációs tevékenységéhez képest a diákoké nem ugyanazon a színvonalon valósul meg, lévén hogy sem

2 tapasztalat, sem elhivatottság nincs még meg minden diákban, de az akarat igen. S bár nem minden dolgozat sikerül publikálhatóan, az mégis motiváló tényező egy diák számára, ha egyeteme biztatja és munkáját felvállalva azt honlapján is közzé teszi úgy, hogy oktatói néhány mondatos véleményezést is írnak hozzá. Az oktatók munkája ezzel nő, de érdemeik is. Az egyetemeknek, ahogyan azt hirdetik a felvételizni vágyóknak, nem a puszta tananyagleadás, előadás látogatás és zárthelyi javítás a feladata, hanem a tudomány művelése, valamint a diploma megszerzésén túl a diákok tudományra és az életen át tartó tanulásra való felkészítése. Ez egy program, ennek a programnak egyik eszköze lehet a MEHT. Az eszköz mozgatói lehetnek az egyetem felsővezetői, amennyiben meglátják a lehetőséget az adatbázisban, s amennyiben használják azt. Az Oxford University, a Yale University, a Stanford University valamint a University of Texas honlapjain a research menüpontok, valamint kari honlapok menüjében találtam olyan adatbázist, mely publikációkat közöl, vegyesen oktatókét és hallgatókét. A közlési elv talán a publikált munkák megjelenési helyén alapszik. Ezen vizsgálódás után a kiinduló gondolatom az volt, hogy egy blogot, vagy saját üzemeltetésű honlapot készíttetek, amelyet hallgatótársaimnak bemutatva arra használok, hogy tudományos dolgozatokat, publikációkat töltsek fel. A megjelenő publikációkért a doktori szabályzat szerint kredit pont jár (1 p.). Ilyen honlap nem létezett korábban a Miskolci Egyetemen az ún. kolihálón kívül, amely viszont nem tudományos munkákat, hanem a diákok szorgosan feltöltött jegyzeteit tartalmazza. A honlap készítés rövid idő alatt nehézségekbe ütközött, s fennállt annak is a veszélye, hogy az egyetem nem fogja elismerni azt, a diákok nem fogják használni, s nem kerülnek feltöltésre tudományos munkák. Ezért indokolt volt az egyetem felső vezetéséhez fordulnom annak érdekében, hogy az adatbázis az egyetem közbenjárásával valósulhasson meg. Az első lépések Kabdebó Lóránt vezető konzulensem szorgalmazta az ötletemet, melyet egy szeminárium keretében mindenki előtt felvezettem. Tőle bátorítást kaptam. Az egyetem általános- és tudományos rektor helyettesei (Stipta István, Dobróka Mihály, Kovács Viktor egyetem főtitkára) is pozitívan álltak az ötletemhez, és a Számítóközpontot kérték fel arra a feladatra, hogy segítse életre az adatbázist. A Számítóközpont igazgatója, dr. Balla László készségesen támogatta a kérést. Ekkor született meg a neve is, MEHT. A Tudástár már tehát nem csak a PhD hallgató csoporttársaimnak, de az egyetem összes hallgatójának érdekévé vált. Értem ez alatt azt, hogy a feltölthető dolgozatok sem kiterjesztésben, sem témában nincsenek megkötve. Feltölthető szöveg, kép, hanganyag, ábra. Így az összes kar, összes hallgatójának szellemi terméke felkerülhet a világhálóra, s mindez az egyetem honlapjáról elérhetően. A felsővezetői segítséggel, és az egyetemi Számítóközpont együttműködésével tehát új távlatokat kapott az eredeti ötlet.

3 Létrehozni a MEHT-at Az adatbázis egy év alatt, sok munkával és szervezéssel elkészült, számos helyen a MEPA-t véve alapul. Mire elkészült a MEHT mind formailag, mind működésileg, addigra megjelent egy új probléma, ez pedig a tudományos dolgozatok lektorálásának problémája. Korábban is szóba került ez a kérdés. A feltöltések kérdése tehát az, hogy mi kerülhet fel az egyetem honlapjára, ki és hogyan szűri meg a dolgozatokat, és milyen elvet követve lehet a hallgatókhoz eljutni, hogy ők valóban csak egyszer már értékelt dolgozatokat töltsenek fel. Jegyzeteket, tanulási segédleteket és nem értékelt anyagokat ugyanis nem hivatott tárolni a MEHT. A lektorálás kérdése nem tűnt el. Mi szükség van a lektorálásra? Az, hogy teljes bizonyossággal nem tudjuk, hogy a diák milyen adatokat visz fel a rendszerbe. Ezért gondoltuk mi is úgy, hogy a lektorálási folyamatra szükség lehet. A lektorálás úgy működik, hogy a diák először megadja a dolgozat metaadatait, ezek között a lektor nevét is, akit a lektorok listájából választhat ki, majd feltölti magát a dolgozatot. Ezután lesz egy a lektorálási kérést jelentő gomb az űrlapon. Ha erre a gombra kattint, akkor a korábban megadott lektor címére küld egy jóváhagyást kérő levelet a rendszer. A levélben a dolgozat legfontosabb adatait és egy egyedi azonosítóval ellátott hivatkozást talál majd a lektor. A hivatkozásra kattintva már egy weboldal jön be, ahol az oktató az összes kitöltött adatot végig tudja futni és ahol eldöntheti, hogy a dolgozat publikálásra kerüljön vagy elutasításra. A döntésről minden esetben kap automatikus értesítést a dolgozat készítője is. És hogy miért egy sokat vitatott része ez a rendszernek? Mivel a diák azt a tanárát fogja lektornak megjelölni akinél a dolgozatot is írta. Ezzel újabb feladat kerül az oktató vállára (aki már most is túlterhelt). Egyik tanár sem szeretne ezzel foglalkozni, viszont valamilyen ellenőrzésre szükség van. A felsővezetés sajnos nincs segítségünkre ebben a kérdésben. MEGVALÓSÍTÁS, RENDSZERÉPÍTÉS Adatmodell Az első lépések egyike az adatmodell kiválasztása, tervezése volt. Amint a honlapon olvashatjuk: A Dublin Core Metadata Initiative a legrégibb és legismertebb törekvés a számítógépes formában elérhető dokumentumok/források/szolgáltatások leíró adatainak szabványosítására és ezzel a megtalálhatóságuk megkönnyítésére. Nyilvánvaló volt, hogy ezen az úton kellett elindulnunk. Ez volt a kiindulás, azonban a pontosabb elemjellemzőket ez a szabvány nem tartalmazza, ezért rátértünk a Qualified Dublin Core tanulmányozására. Ez már jóval árnyaltabb jellemzést tud megvalósítani. Mi a különbség?

4 A Simple Dublin Core egy olyan Dublin Core metaadat, amely nem használ qualfiereket, csak a Dublin Core 15 elemből álló (Title, Creator,Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights) Metadata Element Set-et terjeszti ki, mint egyszerű attributum párokat anélkül, hogy további részletes információt jelentő minősítést adna a forrásról. A Qualified Dublin Core qualifiereket alkalmaz ahhoz, hogy tovább finomítsa a forrás jelentését. Azok használják az ilyen qualifiereket, akik jelezni akarják, hogy a metaadat érték összetett vagy strukturált érték, sokkal inkább, mint egy egyszerű string. A qualifiereket 2000-ben fogadta el a DCMI (Dublin Core Metadata Initiative). A MEHT adatmodell megalkotásánál leginkább a hazai qdc ajánlásokat vettük alapul. Ezeket az ajánlásokat az NDA (Nemzeti Digitális Adattár) honlapjáról vettük. A title elem a következő minősítőket kaphatja: alternativetitle, seriestitle, paralleltitle, stb. A tervezésnél még arra is törekedtünk, hogy ez a rendszer jól illeszkedjen az egyetemen már működő Publikációs Adatbázishoz (MEPA). Így a későbbiekben közös kereső motort is lehet majd a két rendszerre fejleszteni. Ezeket szem előtt tartva, de a saját igényeinknek megfelelően alakítva készítettük el a Miskolci Egyetemi Hallgatói Tudástár (MEHT) adatmodelljét. A különbségek főleg abban álltak, hogy bizonyos elemeket részletesebben jellemeztünk. A szerzők adatainak tárolásánál arra számítunk, hogy egy-egy szerző neve sokszor fog előfordulni, ezért érdemes külön adatsturktúrát létrehozni, és elég lesz, ha csak a dolgozat szerzőjének kódját rögzítjük a dolgozat adatai között. Így a duplikációt, elírásból származó néveltéréseket könnyebb kezelni. A creator elem MEHT elemtagjai így néznek ki: CId FamilyName GivenName Invert OtherName DateOfCreator Status Institution DepartmentId MailingAddress PostalCode City Country URL A redundancia és egyértelműség, valamint a többszempontú keresések miatt szükségünk volt ezekre a mezőkre. Tehát megfelel a qdc-nek, de jóval több információt hordoz. A szerzők egymás közötti kapcsolatfelvételét is megkönnyítendő, címet, postai címet is tárolunk. A szervezeti egységhez tartozást a keresési feltételek bővítése miatt vettük fel a jellemzők közé. Az objektum (publikáció vagy dolgozat) metaadatolása részben ezekkel az elemekkel történik a mi rendszerünkben: Type Format Language CountryCode FirstYear LastYear Page Edition Location Volume IncludingPubId Látható az IncludingPubId elemtag, amely egy belső azonosítót tartalmaz, a dolgozatot tartalmazó dokumentumra mutat, mely lehet könyv, folyóirat, stb. Itt is a redundanciát elkerülendő, egyszer kell rögzíteni a tartalmazó dokumentum adatait. De azokat is ugyanebben a struktúrában. Sokszor van szükség publikációs lista előállításásra, ezért szerepelnek további adatok (Page Edition Location Volume) a publikáció leírásánál, hogy majdan ezt az igényt is ki tudja elégíteni a rendszer. Részletesebben: itt tároljuk az oldalak számát,

5 kiadásjelzést, a nyomtatott változat lelőhelyét, kötetszám információt, ha van. Ki kell még emelni két eltérést a qdc modelltől. Ilyen a conference tag, és a edocument tag, melyet azért definiáltunk, mert a dolgozatok egy része valószínűleg egy konferencián hangzott el, ez esetben a konferencia adatait is rögzítjük. ConferenceName ConferenceNumber AlternativeName ConferencePlace ConferenceYear Ha pedig a dolgozat megjelenése csak online, akkor az e-dokumentum fontosabb jellemzőit is tárolja a rendszer. etype eformat erequirement VersionNumber esize Itt le lehet írni az online dokumentum jellemzőit, típusát, (szöveg, multimédia, program, adattár) formátumát, ( HTML, PDF, DOC, ) annak a programnak a nevét, verziószámát, amivel olvasható a dolgozat, és végül a file méretét. A további elemek nagyjából megfelelnek a qdc ajánlásnak. RENDSZERFOLYAMATOK A MEHT rendszer két almodulból áll. Az egyik modul a felhasználói felületet szolgálja, a másik az adminisztrációt. Kezdjük az adminisztrációval. Adminisztráció, authentikáció Sokat gondolkodtunk a rendszer egy fontos részén, az authentikáción. Abban már az elején mindnyájan egyetértettünk, hogy nem szeretnénk egy újabb adatbázist létrehozni, ahol a felhasználók hozzáférési adatait tároljuk (felhasználónév és jelszó). Egy már meglévő adatbázis alapján szerettük volna ezt megtenni. Kézenfekvőnek tűnt, hogy ha már a diákoknak úgyis gyakran kell a Neptunt hasznániuk, akkor miért is ne ugyanazokkal az adatokkal lépjenek be a MEHT-be is. Több levélváltást követően az SDA Kft.-vel (Neptun fejlesztői), sajnos arra kellett jutnunk, hogy belátható időn belül ezt nem tudjuk kivitelezni. Ezért próbáltunk egy másik olyan adatbázist keresni, amit szintén sok diák használ. Így döntöttünk az egyetem központi szervere mellett, amit az oktatók, dolgozók és hallgatók is használnak levelezésre. Ezen a gépen az authentikációt egy LDAP szerver végzi, így PHP-ből könnyen tudunk felhasználói azonosítást végezni. Bejelentkezéskor az címét és jelszavát megadva az LDAP szerver a BIND-elést követően visszaigazolja, hogy sikeres volt-e a bejelentkezés. Amennyiben igen, akkor a szerveren tárolt egyéb adatait is le tudjuk kérdezni, mint például a felhasználó teljes nevét. Majd ezek után már az MEHT adatbázisában nézzük meg, hogy ez a felhasználó most jelentkezett be először vagy már korábban is járt itt. Ha most jelentkezett be először, akkor az alkalmazás egy regisztrációs űrlappal fogadja, ahol meg kell adni teljes nevét (amit az LDAP adatai alapján ajánlunk fel neki) és szervezeti egységét valamint a felhasználási feltételek elolvasását és tudomásul vételét is el kell fogadnia. Természetesen ha már jár itt korábban is, akkor ez a lépés kimarad.

6 Bejelentkezéskor azt is ellenőrzi az alkalmazás, hogy milyen szerepkörhöz van jogosultsága az adott felhasználónak. Jelenleg háromféle szerepkörrel rendelkezhet: -azonosított felhasználó, -lektor, -rendszeradminisztrátor. Az azonosított felhasználó tulajdonképpen a diák, aki majd a dolgozatait fogja feltölteni. Mivel nem tudjuk megmondani, hogy ő valós adatokat visz majd fel a rendszerbe vagy csak blöffölni szeretne, ezért van szükségünk egy lektorra is, aki a feltöltött adatokat jóváhagyja. A rendszeradminisztrátornak, ahogy a neve is utal rá, mindenhez jogosultsága van. Adminisztráció, metaadatbevitel Miután az LDAP azonosítónkkal sikeresen regisztráltunk, majd beléptünk a rendszerbe, menüből választhatunk tevékenységet. A felépítés klasszikus. Először a szerző adatait visszük fel a rendszerbe. Ez a szerzők felvitele menüpontból indul. A szerző adatait később módosíthatjuk, vagy ha azonos nevű szerzők esetén nehéz választanunk, a szerzők listázása segíthet ebben. A dolgozatok, publikációk adatait a publikációk, folyóiratok felvitele menüpontban kezdjük. Mivel többféle típusú dolgozatot tud befogadni a rendszer, ezért először típust kell választanunk. Ez a döntés befolyásolja a részletes adatok körét (1. ábra). 1. ábra A publikáció vagy dolgozat adatainak bevitele ezután folytatható a következő űrlap segítségével. Ilyen űrlapból több van a fent ismertetett adatmodellnek megfelelően. Ebből mutatunk meg egyet (2. ábra).

7 2. ábra Nagyon lényeges az az űrlap is, melynek segítségével a dolgozathoz hozzárendelhetjük a szerzőket, melyeket már előzőleg rögzítettünk. Itt történik meg a lektor kiválasztása. Természetesen módosításra, törlésre is van lehetőség. A listázás egy lényeges funkciót (dolgozat lektorálása) is tartalmaz amellett, hogy szép formátumban megtekinthetjük a dolgozat metaadatait, sőt a tartalmazó dokumentum adatait is, ha az rögzítve lett már. Itt indul a lektor értesítése a dolgozat feltöltéséről (3. ábra). 3. ábra Van még egy fontos menüpont, a rendszernek nem elhanyagolható része, a dolgozat feltöltése a szerverre. Ez hozzásegít a dolgozat online olvasgatásához. A

8 Google keresővel teljes szövegű keresést is tudunk indítani ezekre a dolgozatokra, és ami nem elhanyagolható, gondoskodunk a hosszú távú megőrzéséről is. Felhasználói felület A felhasználói felület főbb elemei: keresés, regisztráció, gyakran ismételt kérdések (4. ábra). 4. ábra A keresés funkciót regisztráció nélkül is lehet használni. Jelenleg ezekre a jellemzőkre lehet keresni: Cím, Szerző, Kulcsszó, Téma, Dátum (5. ábra). 5. ábra A keresés eredménye egy lista, amelyből választva a jobb oldali oszlopban azonnal láthatjuk a publikáció metaadatait. További lehetőség, hogy a szerzőkről is megtudhatjuk a fontosabb adatokat a + gombra kattintva. És hogy lehetőség legyen a szerzőkkel, lektorral való kapcsolat felvételére, az

9 címek is kattinthatók. TOVÁBBFEJLESZTÉSI LEHETŐSÉGEK Számos elképzelés született a rendszer jobbítására, továbbfejlesztésére, mielőtt valójában nagyobb számban elkezdték volna használni a hallgatók. Az egyik irány a keresés finomítása. Alapul véve a nemzetközi mintákat is, szeretnénk komolyabb keresési lehetőségeket nyújtani az érdeklődő olvasóknak. Ilyen lenne az összetett keresés megvalósítása, amely a fontosabb mezőkben egyszerre keresne, megengedve a AND és az OR logikai műveleteket is. A másik lehetőség az interaktív elemek erősítése, figyelembe véve a web 2.0 irányokat. Keretet lehetne nyújtani az egyes dolgozatok véleményezéséhez, megvitatásához. Ehhez nagyobb fejlesztésre kell felkészülni. Nem utolsó sorban azt is szeretnénk, hogy ezeket a publikációkat nemzetközi keresők is elérjék. Ehhez olyan szabványos kimenetet, interface-t kell megírni, mely az OAI PMH (Open Archives Initiative - Protocol for Metadata Harvesting) harvesterekkel lekérdezhető. Fontos megjegyezni, hogy az egyetemünk támogatása nélkül nem fog menni a fejlődés. A hallgatók elérésére nem elegendő egy PhD hallgató és egy egyetemi újságban megjelent cikk. Az adatbázist akkor tudjuk feltölteni, ha azt komolyan veszik a hallgatók, és az oktatók is. Szeretnénk, ha a lektorálási rendszer megoldódna, működése megkezdődne, és szellemi támogatást kapnánk a felső vezetéstől. A MEHT tartalmazhatna jegyzeteket, melyeket oktatók készítenek a diákok számára, és tanulási segédanyagok is. A Neptun rendszerben erre nincs lehetőség, az ME nem az ETR rendszert használja, s nincs Coospace (pl. BKF) vagy egyéb névre hallgató tudástára. IRODALOMJEGYZÉK [1] Dublin Core Metadata Initiative, MIT Libraries, [2] The Open Archives Initiative Protocol for Metadata Harvesting, openarchives.org, [3] Powell, A, Johnston, P: Guidelines for implementing Dublin Core in XML Dublin Core Metadata Initiative, [4] Magyar Elektronikus Könyvtár Dublin Core Generátor, [5] NDA Dokumentumtár és Szolgáltatások,