Budapesti Műszaki- és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar
BIBLIOGRÁFIAI ADATOK HITELESÍTÉSE A MAGYAR TUDOMÁNYOS MŰVEK TÁRÁBAN DIPLOMATERV
Témavezető:
Készítette:
Dr. Kollár István
Csurcsia Péter Zoltán
egyetemi tanár
Budapest 2010.
HALLGATÓI NYILATKOZAT
Alulírott Csurcsia Péter Zoltán, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, amelyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Tudomásul veszem, hogy az elkészült diplomatervben található eredményeket a Budapesti Műszaki és Gazdaságtudományi Egyetem, a feladatot kiíró egyetemi intézmény saját céljaira felhasználhatja.
Budapest, 2010. május 14.
__________________________ Csurcsia Péter Zoltán hallgató
Tartalomjegyzék
TARTALOMJEGYZÉK Tartalomjegyzék ............................................................................................ vi I. Köszönetnyilvánítás ................................................................................ ix II. Összefoglalás .......................................................................................... x III. Abstract .................................................................................................. xi 1. Bevezetés ................................................................................................ 1 2. A probléma leírása, megoldás szükségessége ....................................... 3 3. Bibliográfiai formátumok .......................................................................... 5 3.1. Hagyományos formátum ................................................................... 5 3.1.1. A bibliográfiai leírással kapcsolatos alapfogalmak ...................... 5 3.1.2. A katalogizálás jelentősége és szerepe a könyvtárban ............... 7 3.1.3. Nemzetközi egységesítési törekvések ........................................ 7 3.1.4. A katalogizálás hagyományos munkafolyamata .......................... 8 3.1.5. Online Public Access Catalogue ................................................. 9 3.2. Elektronikus formátumok ................................................................. 10 3.2.1. BibTeX ...................................................................................... 10 3.2.2. RIS ............................................................................................ 12 3.2.3. Összegzés ................................................................................ 13 4. Internetes formátumok ........................................................................... 14 4.1. HTML .............................................................................................. 14 4.2. JSON .............................................................................................. 16 4.3. XML ................................................................................................. 17 4.3.1. Jól formázott XML dokumentum ................................................ 17 4.3.2. Érvényes XML dokumentumok.................................................. 18 4.3.3. XML kiterjesztések .................................................................... 19 4.3.4. XML előnyei és hátrányai .......................................................... 20 4.4. XHTML ............................................................................................ 21 5. Document Object Identifier .................................................................... 22 5.1. Felépítés ......................................................................................... 22 6. Programozási paradigmák és technikák ................................................ 23 6.1. Imperatív paradigma ....................................................................... 24 6.2. Procedurális és strukturált paradigma ............................................. 24 6.3. Objektum orientált paradigma ......................................................... 25 7. Releváns technológiák........................................................................... 27 7.1. Statikus weboldalak ........................................................................ 27 7.2. Dinamikus weboldalak .................................................................... 27 7.3. Kliens oldali programozás ............................................................... 28 7.4. Szerver oldali programozás............................................................. 28 7.4.1. JSP............................................................................................ 28 7.4.2. ASP.NET ................................................................................... 29 7.4.3. PHP ........................................................................................... 30
vi
Tartalomjegyzék 8.
Kereső algoritmusok .............................................................................. 32 8.1. Teljes egyezés módszere................................................................ 32 8.2. Hangzás alapján való keresés ........................................................ 33 8.3. Levenshtein algoritmus ................................................................... 34 8.4. Similar text ...................................................................................... 35 9. Esettanulmányok ................................................................................... 37 9.1. EISZ ................................................................................................ 37 9.2. IEEE ................................................................................................ 38 9.3. Web Of Science .............................................................................. 42 9.4. Scopus ............................................................................................ 44 9.5. MedLine .......................................................................................... 46 10. A BME Publikációs Adattára és a rendszer általános felépítése ........... 48 10.1. A BME Publikációs Adattár és az MTA Köztestületi Publikációs Adattár ........................................................................................................ 48 10.2. Az adatbázis használatának előnyei ............................................... 49 10.3. Technikai rendszer és az Adatbázis szerkezet ............................... 49 10.3.1. Általános adatok ...................................................................... 49 10.3.2. Adatbázis háttér ...................................................................... 50 10.3.3. Felhasználók ........................................................................... 50 10.3.4. Fejlesztés ................................................................................ 50 11. Követelmény menedzsment .................................................................. 51 11.1. Felhasználói követelmények ........................................................... 52 11.2. Rendszerkövetelmények ................................................................. 52 11.1. UML Use Case diagram .................................................................. 55 11.2. Fejlesztőkörnyezet és a verzió menedzsment................................. 55 12. Rendszertervezés .................................................................................. 57 12.1. Rendszer generikus felépítése ........................................................ 57 12.2. Rendszerszintű komponensek és modulok ..................................... 59 12.3. UML Class diagram ......................................................................... 61 13. A kereső és pontozó algoritmus............................................................. 63 13.1. A keresés nehézségei ..................................................................... 63 13.2. A keresési metódus ......................................................................... 64 13.2.1. Szöveg és szám keresése ...................................................... 66 13.2.2. Szerző keresés........................................................................ 67 13.3. Pontozási metódus.......................................................................... 68 13.4. Validáció.......................................................................................... 69 13.5. Példa a validációra .......................................................................... 70 13.5.1. „A” eset .................................................................................... 70 13.5.2. „B” eset .................................................................................... 71 13.5.3. „C” eset ................................................................................... 71 14. A konfigurációs formátum táblázat......................................................... 72
vii
Tartalomjegyzék 15. Az Információ csere és az XML formátum ............................................. 75 15.1. Adatexportálás ................................................................................ 76 15.1.1. Az exportáló PHP kód felépítése ............................................. 77 15.1.2. Az exportálás tesztelése ......................................................... 78 15.1.3. Egy minta XML ........................................................................ 79 15.2. Az adatimport .................................................................................. 81 15.3. Az XML dokumentum ...................................................................... 82 15.3.1. Az root gyökérelem ................................................................. 82 15.3.2. Az descriptions ág ................................................................... 83 15.3.3. Az authors ág .......................................................................... 84 15.3.4. A publication ág ....................................................................... 86 15.3.5. A citations ág ........................................................................... 89 16. A Tesztelés ............................................................................................ 90 16.1. A tesztelés....................................................................................... 90 16.2. A rendszer tesztelhetősége ............................................................. 90 17. Értékelés és kitekintés ........................................................................... 92 V. Irodalomjegyzék ....................................................................................... xii VI. Ábrák jegyzéke ....................................................................................... xvi VII. Táblázatok jegyzéke..............................................................................xvii IV. Listák jegyzéke .................................................................................... xviii
viii
I.Köszönetnyilvánítás
I.
KÖSZÖNETNYILVÁNÍTÁS Ezúton
szeretnék
köszönetet
mondani
egyetemi
témavezetőmnek
dr. Kollár István egyetemi tanárnak, aki hasznos tanácsaival, ötleteivel, szakmai és erkölcsi támogatásával hozzájárult diplomatervezésem sikeres elkészítéséhez. Egyben szeretném azok segítségét is megköszönni, akik hozzájárultak dolgozatom sikeres megírásához a szükséges informatikai háttér megteremtésével (mint pl. távoli hozzáférés a tanszéki szerverhez, a BME OMIKK-hoz). Külön köszönet illeti meg Marton Józsefet, aki nagyon barátságosan időrőlidőre segítséget nyújtott BME PA kapcsán felmerülő kérdéseim megválaszolásával.
ix
II.Összefoglalás
II.
ÖSSZEFOGLALÁS A diplomaterv célja a BME Publikációs Adattárából származó bibliográfiai re-
kordok megbízható, interaktív és hibatűrő módon való verifikálása (ellenőrzése) illetve validálása (hitelesítése) PHP 5.0 futtatókörnyezet felhasználásával, ami a terveink szerint pilot projekt jelleggel a BME Publikációs Adattárban illetve a Magyar Tudományos Művek Tárában kerül majd felhasználásra. A feladat megoldásához nem csak a „hagyományos” imperatív, procedurális programozási paradigmákat, hanem a PHP rendszerben kicsit „szokatlan” objektum orientált paradigmákat és viselkedésvezérelt modelleket is felhasználtam. A kommunikációs csatornán egy saját készítésű XML formátumban áramlanak az adatok, amely a Publikációs Adattár és a Magyar Tudományos Művek Tára egy lehetséges kimeneti formátuma is lesz reményeink szerint hamarosan. Az így megszerzett adatokban található, internetes weboldal visszavezetésére alkalmas azonosító alapján (pl. IEEE esetében a DOI vagy az azonosító, PubMed esetében cikkazonosító) a hivatkozott weboldal pontos helyének meghatározása következik. A feloldott címre mutató oldal beolvasása után a rendszertől független feldolgozás következik, és az innen nyert adatoknak az XML tartalommal való azonosítása, összehasonlítása, majd a rekordok validációja következik. A XML-ben található mezőkhöz különböző, publikáció típusonként és website-onként eltérő úgynevezett súlyszámot (pontszámot) lehet rendelni. Egy rekordnak a hitelesítésre átnyújtott összes mezői alapján elérhető teljes pontszám adott hányadát kell elérnie ahhoz, hogy valid (megerősített, létező) publikációnak fogadjuk el, minden más esetben kézi ellenőrzéssel lehet hitelesíteni a rekordot. „Tetszőleges” új oldalak felismerése és rendszerbe integrálása kis idő és energia kérdése, egy formátumleíró CSV táblázat kitöltésének segítségével.
x
III. Abstract
III.
ABSTRACT The aim of the master's thesis is to verify and validate bibliographical records
from the Publication Data Base of the Budapest University of Technology and Economics (BME-PA) in a reliable, fault-tolerant, interactive way, using the PHP 5.0 environment. This is a pilot project for the Publication Data Base of Hungarian Science (Magyar Tudományos Művek Tára, MTMT). To solve the task, I used „conventional” imperative, procedural programming paradigms, as well as „unusual” object-oriented paradigms and behaviour-driven models in the PHP system. In the communication channel, the data flow in a self-created XML format, which is meant as a future output format of the Repositories. These data contain identifiers that allow back-tracking of records to web pages in international data bases or catalogs (e.g. identifier or DOI in case of IEEE or article identifier in case of PubMed). Based on this data, the exact location of the referred page is identified. Once the location has been decoded, the page is processed, independently of the its source. Information contained in XML is identified and compared, the records are validated. To the fields contained in the XML, different weights (points) can be assigned, based on publication and website type. For a record to be accepted as valid (existing and verified), it has to reach a certain amount of pointsIn other cases, the record can be validated only manually. Various kinds of further webpages can be identified and integrated within short time and energy, by only filling out a format descriptor CSV chart.
xi
1.Bevezetés
1.
BEVEZETÉS Jelen diplomaterv a Budapesti Műszaki és Gazdaságtudományi Egyetem Vil-
lamosmérnöki és Informatikai Kar beágyazott információs rendszerek illetve alkalmazott informatika szakirányú villamosmérnöki mesterszak követelményeinek kielégítésére készült. A diplomaterv célja egy olyan intelligens, megbízható, hibatűrő, PHP alapú rendszer megtervezése és implementálása, amely képes a tudományos művek bibliográfiai adatait tartalmazó publikációs weboldalakban rejlő információkat automatikusan a Magyar Tudományos Művek Tárából, illetve a Budapesti Műszaki és Gazdaságtudományi Egyetem Publikációs Adattárából származó bejegyzésekkel összehasonlítani, majd ítéletet mondani a rekordok megegyezésére, azaz a publikáció hitelességére. A diplomaterv időszerűségét és szükségszerűségét az is mutatja, hogy a jelenleg kapható programok között nem található olyan, amely kifejezetten bibliográfiai adatok bejegyzésének ellenőrzésére és hitelesítésére szolgál. A rendelkezésre álló idő és erőforrások hiánya miatt a projektnek természetesen nem célja és nem is feladata a kereskedelmi forgalomban kapható szoftverek minőségének megközelítése. A következőben leírom a probléma pontos megfogalmazását, a diplomaterv felépítését, és a tervezés gondolatmenetét. Az első fejezetekben a diplomatervezésemben felmerülő és megoldandó problémát ismertetem, ezzel párhuzamosan meghatározom a megtervezendő és megoldandó feladatot is. A feladat általános ismertetése után bemutatom a hagyományos bibliográfiai adatokat, azok megadásának módjait, melyet közvetlenül a legismertebb elektronikus bibliográfiai formátumok ismertetése követ, különös tekintettel azok előnyeire és hátrányaira.
1
1.Bevezetés A gondolatmenet befejezéseképpen az Internetes, felhasználó által megjeleníthető és elérhető népszerűbb formátumokat is összefoglalom, hiszen a számunkra releváns információk leggyakrabban ezekben a dokumentumokban, beágyazva találhatóak meg. A rendszertervezés során azonban nem csak arra a kérdésre kell válaszolnunk, hogy honnan férhetünk hozzá az adatokhoz, hanem arra is, hogy milyen módszerekkel és technikákkal tehetjük meg azt. Ennek megfelelően veszem sorra a számunkra számításba vehető programozási paradigmákat és szoftver architektúrákat (futtatókörnyezetek). A lehetőségek felvázolása után röviden elemzem a Budapesti Műszaki és Gazdaságtudományi Egyetem Publikációs Adattára illetve Magyar Tudományos Művek Tára fizikai és logikai rendszerét. Ennek alapján, részenként kerülnek kiválasztásra a rendszer egyes fizikai és logikai alkotó elemei. Mindezeket követi majd a rendszer részletes specifikációjának meghatározása, illetve a rendszer megtervezése, és implementálása. Külön szeretném leszögezni, hogy a fejezetekben tárgyalt konkrét megállapítások, tények és adatok – informatikai rendszerről lévén szó – kifejezetten a fejezet, illetve diplomatervezés megírásának időpontjában voltak érvényesek.
2
2.A probléma leírása, megoldás
2. A PROBLÉMA LEÍRÁSA, MEGOLDÁS SZÜKSÉGESSÉGE Napjaink tudományos életében elengedhetetlen követelménynek tűnik tudományos művek adatainak elektronikus módon ellenőrzött (verifikált) és hitelesített (validált) tárolása. Továbbá szintén triviális (és megoldott) feladatnak tűnik e bibliográfiai bejegyzéseknek az elektronikus hozzáférése illetve automatizált információcseréje a tudományos repozitóriumok között. A fenti követelményeknek eleget tevő rendszerek létezését sokszor magától értetődőnek feltételezzük, hiszen az információs szupersztrádánkon, az Interneten található (majdnem) minden információ kapcsán azzal a feltételezéssel élünk, hogy azok helyesek és pontosak. Azonban a bibliográfiai (publikációs) adatok felvitele kezdve a szerzők adataitól a konkrét publikáció adatain keresztül az idézettségi listán át tipikusan kézzel vagy kézzel vezérelt feltöltéssel történik amelyek – könnyen belátható módon- sajnos emberi hibákkal terheltek [15]. A Magyar Tudományos Művek Tára a diplomaterv írásának pillanatában is kialakítás alatt áll. Célja a magyar tudósok tudományos művei hiteles bibliográfiai adatbázisának létrehozása. A rendszerben már most is több százezer hitelesítésre váró bejegyzés szerepel. Amennyiben azzal a feltételezéssel élünk, hogy egy könyvtáros átlagosan 15 perc alatt hitelesít egy rekordot, azaz nem csak közlemények létét és adatait ellenőrzi, hanem hivatkozóknál azt is, hogy ténylegesen hivatkoznak-e az adott közleményre, a szokásos munkaidőt feltételezve több tíz évre lenne szüksége csak az eddigi bejegyzések hitelesítésére, nem is beszélve a rendszerbe kerülő új rekordokról [15].
3
2.A probléma leírása, megoldás A fenti egyszerű példából látható, hogy a kézzel való tömeges hitelesítés sem anyagi erőforrások sem belátható idő tekintetében nem lehetséges. További (jelenleg megoldatlan) probléma – különösen adatmigrációnál – az adatállományok, bejegyzések cseréjének módja. Sajnálatos módon a Magyar Tudományos Művek Tárába migrálni kívánt rendszerek nem rendelkeznek teljesen azonos ki- és bemeneti formátummal, azaz nem beszélnek azonos nyelvet, és ezek a formátumok sem biztosítják a teljes adatleírást (sem a publikációk, sem a hozzájuk rendelt idézetek esetében). Az egyes szabványosnak vélt formátumokban sokszor olyan fontos adatok hiányoznak, mint a publikáció helye, vagy a szerzői adatok. A problémákat tetézi a duplumok egyelőre még nem megfelelő felismerése és kezelése, ami a hiányos, sérült adatok miatt sokszor szintén nem lehet reális elvárás egy könyvtárostól. A diplomatervezés fő célja tehát az, hogy mentesítsük a könyvtárosokat a tömeges adatfeldolgozástól, hibatűrő és megbízható módon összevessük a hitelesíteni kívánt adatokat a megbízható, interneten elérhető adatbázisokkal és döntsünk a hitelességről. A programom univerzalitásának egyik feltétele az, hogy az információ cserére lehetőleg egy univerzális, közös interfészen keresztül kerüljön sor, mely interfésznek köszönhetően lehetőség nyílik a könyvtárközi (adatbázisközi) szabványos információ cserére is egy saját készítésű XML leíró formátummal.
2-1. ábra: a megoldandó feladat illusztrálása
4
3. Bibliográfiai formátumok
3.
BIBLIOGRÁFIAI FORMÁTUMOK A következő fejezetben röviden ismertetem a néhány főbb, számunkra rele-
váns bibliográfiai alapadatot illetve az őket hordozó formátumok közül néhány elterjedtet. A hagyományos formátum fejezet a tipikusan nyomtatott formában is tárolt alapadatokról szól, melyben különös hangsúlyt kapnak az egyes bejegyzések helyes megadásának módjai. Az elektronikus formátumok fejezetben pedig az egyik két legismertebb fájlformátumot mutatom be esettanulmány szerűen, különösképpen kiemelve azok előnyeit és hátrányait. Az egyes formátumok használatát mintaképpen egy nemzetközi konferencia kiadványban szereplő publikációm bibliográfiai bejegyzéseivel illusztrálom.
3.1. 3.1.1.
HAGYOMÁNYOS FORMÁTUM A BIBLIOGRÁFIAI LEÍRÁSSAL KAPCSOLATOS ALAPFOGALMAK
A bibliográfiai adatfeldolgozás, mint tudományterület terminológiája igen kötött. A következőekben felsorolok néhány, számunkra releváns, a szabványokból átemelt alapfogalmat, melyet
későbbi tárgyalás
során
ismertnek feltételezek
[3][8][17][20][31][32][40]. • bibliográfiai adat: a bibliográfiai tétel meghatározott helyén található besorolási adatok és a bibliográfiai leírás együttese • bibliográfiai leírás: meghatározott szabályok szerinti egységes szerkezetben, formában és sorrendben rögzített adatok összessége • katalogizálás: az a folyamat, amelyben rögzítjük a dokumentumok bibliográfiai adatait 5
3. Bibliográfiai formátumok • bibliográfiai/katalógus tétel: a leírt dokumentumok bibliográfiai és ezekhez járuló egyéb adatainak egységként kezelt együttese • adatcsoport: a bibliográfiai leírás összetartozó adatelemekből álló egysége • adatelem: a dokumentumról meghatározott információt közlő szó, kifejezés vagy jelcsoport • alcím: a könyv (dokumentum) címoldalán, (más dokumentumnál a címoldalhelyettesítőn) közölt – a főcímhez illetve a párhuzamos címhez képest alárendelt jelentőségű – cím • ISBN: International Standard Book Number - Könyvek Nemzetközi Azonosító Száma • ISSN: International Standard Serial Number - Időszaki Kiadványok Nemzetközi Azonosító Száma • megjelenés adatai (impresszum): a kiadóra illetve a terjesztőre, valamint a nyomdára, ezek székhelyére, valamint a megjelenés évére vonatkozó adatok összessége • megjelenés helye: az a város vagy egyéb település, amelyet a könyv valamely előzéke vagy kolofonja a megjelenés helyeként nevez meg • párhuzamos cím: a címoldalon a főcím megismétlése más nyelven illetve más írásrendszerben • sorozatcím: a sorozat keretében megjelent mű címoldalán vagy valamely más előzékén – a sorozat egészére vonatkozóan közölt – tipográfiailag egyértelműen kiemelt vagy ilyen megkülönböztetés hiányában az első cím • kiadó: a dokumentumot megjelentető illetve terjesztő természetes vagy jogi személy • kötelező jel: a bibliográfiai leírásban használandó jelek, melyek az adatcsoportok elkülönítésére, az adatelemek típusának felismerésére és róluk kiegészítő információ közlésére, valamint az adatforrások jelölésére szolgálnak • kötet: a könyv olyan - általában fizikailag önálló - egysége, amelynek a könyv egészére vonatkozó bibliográfiai adatain kívül, saját megkülönböztető biblio6
3. Bibliográfiai formátumok gráfiai adatai is vannak: mindenképp van kötetjelzése, illetve kötetcíme, valamint impresszuma és kolofonja • kötetcím: a kötet főcíme, vagyis a kötet megkülönböztető címei közül a kötet valamely előzékén tipográfiailag egyértelműen kiemelt vagy - ilyen megkülönböztetés hiányában - az elsőként közölt cím • szerző: az a természetes vagy jogi személy, aki/amely a dokumentum vagy a dokumentum főrésze szellemi tartalmának alkotója, mely e tartalomért elsősorban felelős • szerzőségi közlés: a leírásban közölt szerzőségi adatok összessége • szerzőségi adat: a dokumentummal kapcsolatos azonos szerzői funkciót betöltő természetes vagy jogi személyekre vonatkozó adat
3.1.2.
A KATALOGIZÁLÁS JELENTŐSÉGE ÉS SZEREPE A KÖNYVTÁRBAN
A dokumentumok összegyűjtése, közvetítése, és hozzáférhetővé tétele elsősorban a könyvtárak feladata. A dokumentumokról való tájékoztatás előfeltétele, hogy azokat „feldolgozzuk”, azaz legfontosabb jegyeiket lejegyezzük [3][31][32][38]. A formai feltárás (katalogizálás) során a dokumentumokról első lépésben bibliográfiai leírást készítünk, amely lehetővé teszi a dokumentum azonosítását (pl. cím(ek), szerző(k), közreműködő(k), impresszumra vonatkozó adatok stb.). Második lépésben kiegészítjük az így kapott tételeket besorolási adatokkal, szakjelzetekkel, tárgyszavakkal és valamilyen formában közzétesszük azokat.
3.1.3.
NEMZETKÖZI EGYSÉGESÍTÉSI TÖREKVÉSEK
A nemzetközi egységesítések kérdésével 1929-ben foglalkoztak először a könyvtári és bibliográfiai világkongresszuson, ahol meghatározták a katalóguscédula egységes nemzetközi formátumát, amelyet ma is használunk [3][38]. A második világháború után a nemzetközi egységesítés szükségessége újból fokozottan előtérbe került. Támogatója és irányítója a Könyvtáros Egyesületek és Intézetek Nemzetközi Szövetsége (IFLA) volt.
7
3. Bibliográfiai formátumok A következő fontos történeti állomás a Nemzetközi Szabványos Bibliográfiai leírás (International Standard Bibliographic Description, ISBD) program volt, melynek főbb jellemzői: •
alapfunkciójuk a dokumentumok azonosíthatóságának és számbavételének biztosítása
•
visszakereshetőség érdekében kiegészülnek besorolási adatokkal
•
alkalmazásuk lehetővé teszi a leírások nemzetközi cseréjét
•
a leírás formálisan értelmezhető
•
használata megkönnyíti a számítógépes feldolgozás bevezetését
•
meghatározzák a bibliográfiai leírás adatelemeinek körét
•
az adatelemeket adatcsoportokba rendezik, megszabják a csoportok sorrendjét
•
szabályozzák a forrásokat, amelyekből a dokumentum adatai megállapíthatók
•
szabályozzák az adatok közlésmódját (dokumentumhoz való hűség)
•
meghatározzák az egyezményes jeleket Az ISBD-k megjelenése kedvezően hatott az egyes nemzetek katalogizálási
szabályzatának revíziójára [3].
3.1.4.
A KATALOGIZÁLÁS HAGYOMÁNYOS MUNKAFOLYAMATA
Maga a bibliográfiai leírás hét adatcsoportot tartalmaz. Sorrendjük, katalógustételen történő elrendezésük a következő listán található meg [31][32][38]. 3-1. lista: Hagyományos katalógus cédula elrendezése [38]
1. Cím- és szerzőségi közlés. – 2. Kiadás-jelzés. – 3. Megjelenés. – 4. Terjedelem. – 5. (Sorozat adatai) 6. Megjegyzés 7. Terjesztési adatok
8
3. Bibliográfiai formátumok A következő minta listában egy tényleges katalógus címként tekinthetünk meg, melyben a műnek három szakjelzete is van [38]. Az első az építészetet (72), a második a természetvédelmi területet (502.4), a harmadik a művelődéstörténetet (930.85) jelenti. A (100) az egyetemes földrajzi vonatkozást jelenti. A mű több szerző műve, ezért a cím határozza meg a jelzet második sorát. A könyv tehát egy helyen, az olvasóteremben, a 720-as polcon, azon belül a V betűnél a 87-es számúak között. A katalógusban mindhárom szakjelzetnél, cím és sorozati címnél, valamint a szerzők, és közreműködők nevénél is megtalálja az olvasó. 3-2. lista: Minta katalógus cédula [38] OLVASÓTEREM 720 V 87 A világ természeti csodái és kultúrkincsei. – [Pécs] : Alexandra, [1997]- . – 30 cm. – (Az UNESCO világöröksége) 4., Nyugat-Európa / szerzők: Jörg Holzwarth, Jürgen Lotz, Thomas Veser ; ford. Fejesné Arany Katalin. – 1998. - 304 p. : ill. ISBN 963-367-366-6 : 4980.-Ft. *Nyugat-Európa Mt.: Holzwarth, Jörg – Lotz, Jürgen –Veser, Thomas – Fejesné Arany Katalin (ford.) 72(100) 502.4(100) 930.85(100) Európa – Nyugat-Európa-Útleírások UNESCO világörökség Világörökség
3.1.5.
ONLINE PUBLIC ACCESS CATALOGUE
Az OPAC (Online Public Access Catalogue) a számítógépes hálózaton, bárki számára közvetlenül elérhető katalógus [28]. Általában telnet program segítségével tudjuk elérni, de egyre gyakoribb a web felületen elérhető katalógus is [28]. A hazai könyvtárak honlap és katalógus listáját egyéb könyvtári szolgáltatások listájával és címével együtt a HUNOPAC nevű weblapon érhetjük el.
9
3. Bibliográfiai formátumok 3.2. 3.2.1.
ELEKTRONIKUS FORMÁTUMOK BIBTEX
A BibTeX olyan elektronikus stílus fájl formátum, melyet kifejezetten bibliográfiai adatok, mint például cikkek, könyvek, szakdolgozatok platform független reprezentálására készítettek 1985-ben [1]. Az ilyen fájlok kiterjesztése általában .bib, de sokszor neten is elérhetőek HTML dokumentumba ágyazva (mint egyszerű dokumentum szöveg). A BibTeX fájlból azok, akik a LaTeX dokumentum szerkesztőt használják, a publikációkból könnyen (félautomata módon) készíthetnek bibliográfiai bejegyzést. BibTeX-hel az alábbi bibliográfiai típusokat lehet definiálni: •
article (folyóiratcikk)
•
book (könyv)
•
inbook (egy könyv része)
•
booklet (Nyomtatott munka, kiadó nélkül)
•
incollection (saját címmel rendelkező mezők könyvrész.)
•
proceedings (konferencia közlemény)
•
inproceedings (konferencia közleményben megjelent cikk)
•
manual (technikai dokumentáció)
•
mastersthesis (diplomamunka, szakdolgozat)
•
phdthesis (doktori értekezés)
•
techreport (esettanulmány)
•
misc (nem besorolható)
Az egyes típusokban szerepelnek kötelező és opcionális elemek is. A BibTeX formátum alkalmazásának hátrányai például a következők: •
A formátum sokszor nehezen olvasható és értelmezhető
•
olyan leíró nyelvet használ, amit nem mindig egyszerű megérteni, illetve alkalmazni, feldolgozáshoz parser-re (értelmező programra) van szükség
10
3. Bibliográfiai formátumok •
nagyon sok változata létezik és az egyes formátumok illetve bejegyzés típusok nagyon lazán kezelendőek
•
nem számítanak a szóközök
•
ékezetes karakterek rendszerfüggőek, helyette biztosan alkalmazhatóak repülő ékezetek, ami viszont az emberi feldolgozást nehezíti pl.: \”{u}\’o ami pontosan megfelel \”u\’{o}-nek
3-3. lista:Minta BibTeX állomány [11] @INPROCEEDINGS{5286576, author={Csurcsia, P.Z. and Banovics, A. and Kollar, I.}, journal={Intelligent Signal Processing, 2009. WISP 2009. IEEE International Symposium on}, title={Digital oscilloscope displays results together with confidence bounds}, year={2009}, month={aug.}, volume={}, number={}, pages={81 -86}, abstract={We have designed and implemented a platform independent computerbased digital oscilloscope using a high performance 32-bit RISC microcontroller. The oscilloscope program makes use of very low software and hardware cost, and uses recursive formulas (e.g. recursive averaging, variance) in a platform independent object oriented environment with stable and deterministic computing time. This means that, if evaluated on-line, confidence limits can also be displayed. It can be seen from the measurements that the recursive formulas accomplish the required sample number independent output.}, keywords={RISC microcontroller;confidence bounds;digital oscilloscope displays;platform independent computer-based digital oscilloscope;digital storage oscilloscopes;display instrumentation;microcontrollers;reduced instruction set computing;}, doi={10.1109/WISP.2009.5286576}, ISSN={}, }
11
3. Bibliográfiai formátumok
3.2.2.
RIS
A RIS egy széleskörűen elterjedt és alkalmazott bibliográfiai szabványosított tag formátum, melyet a Research Information Systems Incorporated fejlesztett ki a bibliográfiai adatok programok és adatbázisok közötti cserélésére [33]. A formátum tipikusan .ris formátumvégződést visel. A BibTeX-hez hasonlóan általában szintén megtalálható HTML dokumentumokba beágyazva. A RIS formátum felépítése igen egyszerű és könnyen szerkeszthető. Attribútum képzése két betűt két szóköz követ, amit egy gondolatjel zár. Ez után kell megadni az attribútum értéket (pl. szerző neve). A sorokat kötelezően ASCII kocsi vissza (return) és soremelés (line feed) karakter kell, hogy zárja (ez annak idején az operációs rendszerek közti kompatibilitási problémák miatt volt fontos)[33]. Itt is hasonló problémákkal kell szembe néznünk, mint a BibTeX esetében, ilyen például: •
pontatlan, lazán, sokszor szabadon értelmezhető formázottság
•
szerző neveinek írásmódja, karakterkódolások
•
kevés támogatott attribútum (pl. nem található benne DOI, ID, irodalomjegyzék), melyeket megjegyzésként kell beszúrni, amire szintén nincs szabványos módszer
•
a konferenciacikkekhez még szabványos tartalmak is hiányoznak (város, ország) Kétségtelen előnye, hogy könnyebben olvasható és értelmezhető, könnyen
szerkeszthető. 3-4. lista: RIS mintafájl [11] TY - CONF JO - Intelligent Signal Processing, 2009. WISP 2009. IEEE International Symposium on TI - Digital oscilloscope displays results together with confidence bounds T2 - Intelligent Signal Processing, 2009. WISP 2009. IEEE International Symposium on IS SN VO -
12
3. Bibliográfiai formátumok SP - 81 EP - 86 AU - Csurcsia, P.Z. AU - Banovics, A. AU - Kollar, I. PY - 2009 KW - digital storage oscilloscopes KW - display instrumentation KW - microcontrollers KW - reduced instruction set computing KW - RISC microcontroller KW - confidence bounds KW - digital oscilloscope displays KW - platform independent computer-based digital oscilloscope VL JA - Intelligent Signal Processing, 2009. WISP 2009. IEEE International Symposium on AB - We have designed and implemented a platform independent computerbased digital oscilloscope using a high performance 32-bit RISC microcontroller. The oscilloscope program makes use of very low software and hardware cost, and uses recursive formulas (e.g. recursive averaging, variance) in a platform independent object oriented environment with stable and deterministic computing time. This means that, if evaluated on-line, confidence limits can also be displayed. It can be seen from the measurements that the recursive formulas accomplish the required sample number independent output. ER -
3.2.3.
ÖSSZEGZÉS
A fenti formátumokon kívül természetesen számtalan más formátum is rendelkezésre áll, nagyon közkedvelt és gyakran használt például a Web of Science RIS-szerű formátuma, vagy az EndNote bibliográfiai és hivatkozás kezelő rendszer Fontosnak érzem továbbá megemlíteni, hogy létezik úgynevezett „szabványos” MARC illetve annak magyarosítása is a HUNMARC [28]. A HUNMARC az Országos Széchényi Könyvtár által alkalmazott és kezelt, a bibliográfiai rekordok adatcsere formátuma, a bibliográfiai adatok géppel olvasható formájú ábrázolására, a bibliográfiai adatok gépi adathordozón való csereformátumának meghatározására. A HUNMARC formátum, illetve egyes elemei az adatcsere mellett a bibliográfiai adatok beviteli és a bibliográfiai tételek megjelenítési formátumaként is alkalmazható. Ennél a formátumnál is, a fentiekhez hasonlóakkal kell szembe néznünk. Az összes eddigi megoldás legfőbb problémája az, hogy egyik sem teljes és elég gazdag, nem bővíthető szabadon mezőkkel, ezért szükségesnek éreztük egy saját, univerzális célú formátum létrehozását.
13
4.Internetes formátumok
4.
INTERNETES FORMÁTUMOK Ebben a fejezetben az Interneten, átlagos felhasználó által megjeleníthető és
elérhető népszerűbb (webes) formátumokat bemutatom be, külön hangsúlyt fektetve az XML-re, hiszen az a későbbiekben ismertetett információ átvitel közegeként fog közreműködni. Az eddigi tárgyalásmódhoz megszokottan itt is kitérek az egyes formátumok előnyeire illetve azok hátrányaira, az egyes formátumok használatát egyszerűbb mintakóddal szemléltetem.
4.1.
HTML
A HTML (HyperText Markup Language) egy olyan SGML alapú, világszerte ismert leíró nyelv, amelyet elsősorban weboldalak megjelenítéséhez fejlesztettek ki, s mára az Internet egyik legmeghatározóbb W3C (World Wide Web Consortium) által ajánlott szabványnak tekinthető [4][5][36][43][44]. Egy tetszőleges HTML dokumentum alapvetően három sorrendtartó szerkezeti részre osztható föl [4][36]: 1. DTD (Document Type Definition, dokumentum típus definíció), ami az állomány első sorában található, meghatározza a dokumentum típusát (pl. HTML 4.01 verziót szeretnék alkalmazni) 2. head (fejléc), ami tartalmazhatja a technológiai paramétereket (pl. kódkészlet), a böngésző által (általában fejlécben) megjelenített címet (title), illetve egyéb meta adatokat. Ezek –a fejléc kivételével – általában a felhasználók számára implicit nem láthatóak. Ide szokás általában elhelyezni a főbb java scripteket is. 3. body (törzs), ami a ténylegesen megjelenítendő információkat tartalmazza
14
4.Internetes formátumok A HTML szabvány tipikus építőelemei [5][44]: •
úgy nevezett tag-ek, melyek tipikusan
nyitó és záró párosból állnak, illetve felhasználhatóak önzáró tag-gel is
formában, amennyiben nincs a két tag között semmilyen információ
•
a tag-ekhez rendelhetőek attribútumok is
formában (természetesen önzáró tag-hez is rendelhetőek attribútumok)
•
tag-ekkel megvalósíthatóak strukturális formázások (pl. táblázatok), szövegformázások (pl. félkövér, dőlt formázások), hiperszövegek (hivatkozás valamilyen dokumentumra vagy a dokumentum pontjára), illetve tartalmazhat eszköz elemeket is (mint pl. gombok, beviteli mezők, listák stb.)
•
szerkezeti elemek, amelyek leírják az adott szöveg "célját" például
Téma 1
mint első szintű címsor (alcím). Amennyiben valamilyen oknál fogva valamelyik szerkezeti vagy építő elem
hiányzik, vagy helytelenül lett megnyitva illetve lezárva, a feldolgozás (tipikusan) nem áll meg, a böngésző programok megpróbálják értelmezni az oldalt [36][44]. Ez a „paradigma” egyben a HTML dokumentumok nagy előnyekét is szolgál: nagyon nagyfokú hibatűrő képességgel rendelkeznek. Ez az átlagos felhasználó számára a böngésző általi megjelenítésnél nagyon dicsérendő, azonban a mi esetünkben preferált szövegfeldolgozásnál ez a fajta „lezserség” problémákat okozhat (lásd később). A HTML tehát elsősorban vizuális (képernyőn történő), egységes megjelenítésre lett tervezve, azonban köszönhetően az úgynevezett „böngésző háborúnak” megjelentek böngésző specifikus illetve böngésző függő elemek is, ami gátolja az egységes megjelenítést és vele a gépi információ feldolgozást is [5][44]. További gyakori probléma, hogy a HTML dokumentumok alapértelmezésképpen ISO-8859-1 karakterkódolást alkalmaznak (ez az úgynevezett charset paraméter), melyet a weblapkészítők nagyon gyakran elfelejtenek helyesen beállítani, így a magyar nyelvű honlapok esetén gyakran más karakterek kerülnek megjelenítésre pl. (ű helyett û), rosszabb esetekben akár egyszerűen olvashatatlanná válik a dokumentum [5].
15
4.Internetes formátumok 4-1. lista: HTML mintafájl <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
Csurcsia Péter Zoltán honlapja Csurcsia Péter Zoltán weblapja
4.2.
JSON
A JSON (JavaScript Object Notation) egy platform független szövegformátum, elsősorban a C szerű nyelvekben járatos programozók számára ideális nagymennyiségű adatcseréhez [13]. Nagy előnye, hogy külön parser (értelmező program) nélkül is ember számára olvasható formátumot kínál fel. Fő alkalmazási területének elsősorban az AJAX alapú webes alkalmazások tekinthetőek, hiszen tömörebb a leírás módja, mint a konkurens XML-nek (XML szintaktikailag összetettebb és nagyobb a fájl mérete, mint JSON-nak). A JSON előnyéből következik a hátránya is, azaz nem célszerű vele összetettebb, bonyolultabb (ön)leírásokat létrehozni vele, nem találhatók és nem is támogatottak benne olyan speciális kiterjesztések (szolgáltatások) mint az XML-ben. A JSON-nak kéttípusú felépítése lehetséges: •
név-érték párok halmaza
•
értékek rendezett halmaza (pl. tömb, vektor)
Egy lehetséges mintát a következő lista mutat. 4-2. lista:JSON mintafájl { "firstName": "John", "lastName": "Smith", "age": 25, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY",
16
4.Internetes formátumok "postalCode": "10021" }, "phoneNumber": [ { "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646 555-4567" } ], "newSubscription": false, "companyName": null }
4.3.
XML
Míg a HTML elsősorban vizuális megjelenítésre alkalmas, addig az XML az adatok tárolására és átvitelére lett kifejlesztve [4][43][44]. Az XML (eXtensible Markup Language) különböző, általunk definiálható adattípusok és értékek leírására alkalmas, mely elsősorban Interneten keresztüli jól strukturált, hardver és szoftver független információ megosztására és tárolására alkalmas formátum. Az XML gyakorlatilag a HTML kiterjesztése, az SGML egy részhalmaza, melyet a W3C (World Wide Web Consortium) által ajánlott szabványnak tekinthetünk [44]. Egy XML dokumentum akkor és csak is akkor érvényes (helyes) ha eleget tesz a következő követelményeknek [43][44]: •
Jól formázottság (well formated): egy helyesen formázott XML dokumentum megfelel minden XML szintaxis szabálynak
•
Érvényesség (valid document). egy érvényes dokumentum olyan adatot tárol, ami megfelel a felhasználó által definiált tartalmi megadási szabálynak Az a dokumentum, ami nem helyesen formázott, nem tekinthető feldolgozha-
tó XML-nek, azaz az elemzőnek meg kell tagadnia a feldolgozását [44].
4.3.1.
JÓL FORMÁZOTT XML DOKUMENTUM
Az XML dokumentum alapértelmezésben Unicode szöveget tartalmazhat, UTF-8 ill. UTF-16 kódolást támogatva, valamint továbbá egy helyesen formázott XML dokumentumnak többek között a következő szabályoknak is meg kell felelnie [43][44]: 17
4.Internetes formátumok •
a dokumentumban csak egyetlen egy gyökér elem szerepelhet, amit csak megjegyzések, deklarációk és utasítások előzhetnek meg (pl. a karakterkódolásra vonatkozó információk)
•
csak az üres elem (tag) lehet önlezáró, minden más esetben kötelező a nyitó és záró tag használata (természetesen üres elem is lehet nyitó-záró tag-gel ellátott)
•
az egyes tag-ek egymásba ágyazhatóak tetszőleges mélységi szintig, azonban ezek nem lehetnek egymást átfedőek, azaz minden nem gyökér elemet egy másiknak kell megában foglalnia
•
minden tagbeli attribútum kötelezően ’ vagy ” (idéző) jellel kezdődik és ugyan ilyen jellel záródik
•
az XML alapértelmezésképpen Unicode karakterkészletet alkalmaz, melyet opcionálisan definiálni lehet az XML deklarációban vagy esetleg a szállító protokollban, de az ettől való eltérést kötelező definiálni
•
az összes XML részre igaz, hogy case sensitive, tehát megkülönböztetjük a kis és nagybetűket (karaktereket)
4.3.2.
ÉRVÉNYES XML DOKUMENTUMOK
Az XML dokumentum validációjának szükséges, de nem elégséges feltétele, hogy helyesen formázott legyen. A dokumentum helyes formázásán felül kötelezően meg kell felelnie egy típus definíciónak is [44]. Az egyik lehetőség az SGML alapú DTD (Document Type Definition) használata, mellyel a megengedhető építőelemeket lehet deklarálni XML 1.0 szabvány alapján. A szabványnak kétségtelenül nagy előnye, hogy mindenhol egyformán támogatott, azonban nem támogatja az újabb XML képességeket illetve további probléma, hogy SGML alapúsága miatt nem használ XML szintakszist a deklarációhoz [43][44]. Egy másik tipikus lehetőség problémánk megoldására egy XML Schema alkalmazása (XML Schema Definition, XSD), amit a DTD utódaként lehet tekinteni [44]. Az XML alapú schema lényegesen több lehetőséget rejt magában, mint elődje, segítségével pontosabban és jobban deklarálhatóak a felhasználni kívánt adatstruktúrák. Az XSD hátránya azonban kétségtelenül az XML alapúságában rejlik: bőbeszédű, terjengős deklarációk gyakran alig vagy egyáltalán nem olvashatóak. 18
4.Internetes formátumok Az XML dokumentumokra vonatkozó szigorú előírások lehetővé teszik, hogy a dokumentumok (tartalmi és formai) ellenőrzéssel az előírásoknak megfelelően automatikusan dolgozzuk fel, azonban megjegyzem, hogy ez által nem csak tömeges adatfeldolgozásra van lehetőség, hanem XML alapú alkalmazások is készíthetőek vele, mint például a .NET alapú XAML (eXtensible Application Markup Language), mellyel weblapon keresztül alkalmazásokat tudunk megosztani és futtatni (bizonyos technológiai megkötésekkel természetesen). Az XML-nek jelenleg két verziója létezik: az XML 1.0 illetve az XML 1.1 (az egyes verziószámokban azonban inkonzisztensen több változat is létezik) [43]. Lényeges különbség a megengedett attribútum, vezérlő karakterek kódolásában rejlik, illetve az XML 1.1 néhány újabb speciális tulajdonságot is tartalmaz, de elterjedtsége miatt továbbiakban csak az XML 1.0-val foglalkozok.
4.3.3.
XML KITERJESZTÉSEK
Az alábbiakban megtekinthetjük az XML lehetséges kiterjesztéseit, mint további alkalmazási és felhasználási lehetőséget [43][44]: •
Xquery: adatbázis lekérdezések alkalmazhatók vele (hasonlóképpen, mint a relációs adatbázisokban az SQL)
•
XML namespaces (névterek): segítségével egy dokumentumon belül több definíciós leírásból XML elemeket és attribútumokat alkalmazhatunk névütközések nélkül
•
XML signature (aláírás): digitális aláírások létrehozását támogató szabályokat definiál
•
XML encryption (titkosítás): titkosítására szolgáló szabályokat definiál
•
XSL és XSLT: megjelenítési stílust definiálnak (tipikusan képernyőn illetve nyomtatón történő feldolgozáshoz)
•
Xpath: XML-en belüli hivatkozást definiált
19
4.Internetes formátumok
4.3.4.
XML ELŐNYEI ÉS HÁTRÁNYAI
Az XML-nek számos olyan tulajdonsága van, amelyek alkalmassá teszik adattovábbításra [44]: •
Unicode karakterkészlet támogatás (így speciális karakterek gond nélkül megjeleníthetők és továbbíthatók vele)
•
mind az ember, mind a gép számára olvasható formátum
•
összetett típusok ábrázolására és kezelésére is alkalmas (fák, listák)
•
Önleíró formátum, amely struktúra- és mezőneveket ír le speciális értékekkel együtt
•
szigorú szintaktikus és elemzési követelményeket támaszt, ami biztosítja, hogy a szükséges elemzési algoritmus egyszerű, hatékony és ellentmondásmentes maradjon
•
teljesen platform független, így elvileg bármilyen környezetben használható
•
letisztult és jól átgondolt szerkezet, mely annak köszönhető, hogy Internetes szabványokon alapul, így a tapasztalatok sokat segítettek a kialakításában
•
ingyenes és teljesen szabadon használható formátum
•
sok fejlesztő eszköz áll rendelkezésre, melyek közül sok ingyenes is
•
a hierarchikus struktúrája megfelel a legtöbb dokumentum típusnak
Bizonyos alkalmazások szempontjából a következő hátrányokkal rendelkezik [44]: •
szintaxisa elég bőbeszédű és részben redundáns
•
(nagyon) összetett dokumentumok olvashatósága már nehézkes
•
nagytömegű adatátvitel esetén már számottevő forgalomra kell számítani
•
nincs lehetőség a dokumentum egyes részeinek közvetlen elérésére és frissítésére, erre csak a teljes fa bejárásával van lehetőség
•
a nem hierarchikus adatstruktúrák modellezése külön erőfeszítést igényel.
•
az XML relációs és objektum orientált paradigmához kötése néha sok erőfeszítést kíván a programozóktól
20
4.Internetes formátumok A következő lista egy lehetséges XML kódot szemléltet. 4-3. lista: XML mintafájl
1. szerző neve keresztnevek vezetéknév <suffix>AO.U.Prof.Dr.DI.Mag.(FH) szerzőazonosító a filesource-ban 12345 ide személyhez rendelt adatbázis komment jön <share>0,5 szerző intézetének a neve intézet azonosító pl. 42
4.4.
XHTML
Az XHTML a gyakorlatilag HTML dokumentumok kiterjesztése XML felett, lényes eltérés csak a formai követelmények szigorúságában rejlik, mint például [5][36]: •
a DOCTYPE kivételével mindent tag-et csak kis betűvel szabad írni
•
minden tag-et kötelező lezárni, az üres tag-et azaz < jel, tag_név, szóköz, / jel és > jel-el kell bezárni.
•
az attribútumoknak kötelező értéket adni
21
5.Document Object Identifier
5.
DOCUMENT OBJECT IDENTIFIER A DOI (Digital Object Identifier, digitális objektum azonosító) tetszőleges, az
Interneten megtalálható elektronikus dokumentumok azonosítását teszi lehetővé, állandó, úgynevezett DOI cím alkalmazásával. A Nemzetközi DOI Alapítvány (International DOI Foundation, IDF) által létrehozott azonosító (címzési) rendszer kétségtelen előnye abban rejlik, hogy a címfeloldás nem attól függ, hogy hol található meg a dokumentum (mint pl. URL címek esetében) [6]. Egy dokumentum (általában) egész élettartama alatt egyetlen egy DOI címet kap, így elvileg, ha változik egy weblap címe attól még a DOI cím jó eséllyel a megfelelő helyre fog mutatni.
5.1.
FELÉPÍTÉS
A DOI cím egyedi alfanumerikus karaktersorozatból áll elő, amely két fő részre az első és az utótagra oszlik [6]. 10.1234/NP5678 ahol:
•
10.1234
az előtag, ezen belül
o 10: directory code (jelenleg a 10. egyetlen használatban lévő) o 1234: publisher ID, kiadó kódja, melyet az alapítvány ad a felhasználóknak •
NP5678: item ID, egyedi dokumentum kódja, melyet a regisztráló maga hoz
létre 5-1. lista: Egy példa DOI azonosító, és a DOI címből feloldott link
DOI cím: 10.1109/WISP.2009.5286576 URL: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5286576 22
6.Programozási paradigmák és technikák
6. PROGRAMOZÁSI TECHNIKÁK
PARADIGMÁK
ÉS
A szoftverfejlesztés során a legfontosabb célnak tekinthető, hogy az elkészítendő szoftverünk megfeleljen a rá előírt funkcionális és minőségi követelményeknek [2][35][37]. A szoftverfejlesztést mindenféleképpen egy tervezői munka kell, hogy megelőzze annak érdekében, hogy a követelmények valóban kielégítésre kerüljenek. Ennek folyamán nagyon fontos a rendszerfejlesztők, programozók számára, hogy a szoftverfejlesztés a lehető legoptimálisabb legyen, azaz a szoftverfejlesztési módszertanokat és modelleket jól válasszuk meg, mivel ez az egész fejlesztés módját és menetét determinálja [35]. A programozási paradigma alatt számítógépes programok tervezésének és implementálásának adott szemléletmódú módszertanait kell érteni, mely egyben a programozás absztrakciós szintjeit is meghatározza [35]. Minden egyes paradigma középpontjában illetve célkeresztjében más és más szemléletmód áll, melyeknek az a célja, hogy minél egyszerűbben és hatékonyabban legyünk képesek programokat, programrendszereket megtervezni és létrehozni az adott környezetben. Nyilvánvaló, hogy minden egyes programozási paradigmának meg van a maga előnye és hátránya, továbbá nyilvánvaló az is, hogy némelyek rendszerfüggőek (pl. egy kisteljesítményű mikrovezérlőre nem célszerű objektum orientált programokat tervezni magas szintű programozási nyelvvel), némelyek pedig csak egy adott szűk probléma körben alkalmazhatóak (pl. logikai programozási paradigma alkalmazása elsősorban adatbázis közeli környezetekben hasznos). A programozási paradigmák fejlődése nagyon gyakran az absztrakciós szint növekedését is magával vonja, mely új utakat nyithat a fejlesztésben: azt gyorsíthatja és egyszerűsítheti. 23
6.Programozási paradigmák és technikák A paradigma gyakran szoros összefüggésbe kerül némely szoftver-felépítési és szoftvertechnológiai ágazatokkal, vagy sokszor össze is kapcsolják őket bizonyos népszerű programnyelvekkel. Általában van rá mód, hogy az egyes paradigmákat vegyesen is használjuk és sokszor átfedések is találhatók közöttük. A következőkben csak a legfontosabb, csak az általunk választott PHP futtatókörnyezetben is számításba vehető paradigmákat mutatom be röviden [29][30].
6.1.
IMPERATÍV PARADIGMA
Az imperatív programozási paradigma az egyik legrégebbi időkre visszavezethető, erősen kötődik a Neumann-féle architektúrához [35]. A középpontban a parancs és az állapot áll. A programunk itt utasítások sorozata, amelyek hatnak a programunkra, azaz meghatározott parancsokkal változtatjuk meg a program állapotát. Így a programunk az állapotok mentén írható le, ami a feladat megvalósításának lépéseit írja le. A program állapotát a leggyakoribb paranccsal, az értékadással - azaz a változók frissítésével - változtathatjuk meg. Három programkonstrukciót használ a program összeállításához: szekvencia, elágazás, ciklus, amelyek tetszőlegesen egymásba ágyazhatóak. A megoldás megtervezéséhez specifikációt használ. Nagyon nagy hátrányának tekinthető, hogy nincs kód újrahasznosítás. Ezt a programozási paradigmát egyszerűbb weblapok esetében ajánlatos használni.
6.2.
PROCEDURÁLIS ÉS STRUKTURÁLT PARADIGMA
A procedurális programozási illetve strukturált paradigma a programokat particiónálja, azaz felbontja függvények és eljárások illetve csomagok halmazára[35]. Minden ilyen partíció egy adott részfeladatot, vagy valamely részfeladat részfeladatát lát el. A strukturált programozási paradigma esetében a tervezéskor felülről lefelé megközelítéssel élünk, azaz a fő problémát felbontjuk, majd azt további részekre és így tovább.
24
6.Programozási paradigmák és technikák A vezérlést alapvetően a főprogram szolgáltatja, azonban az egyes függvények és eljárások tetszőleges mértékben hívhatják egymás, adatokat cserélhetnek. A szemlélet módból határozottan az absztrakciós szint növekedése következik, ami lehetőséget kínál a kód újrahasznosításra, a program szerkezet szabadabb megválasztására valamint ezek révén a forráskód(ok) áttekinthetősége is jelentős mértékben javul. Az állapot befolyásolása természetesen itt is a programkód által valósul meg, itt azonban a középpontban a „hogyan” kérdésre kell válaszolnunk.
6.3.
OBJEKTUM ORIENTÁLT PARADIGMA
Az objektum orientált programozási paradigma esetében a középpontban az adat áll illetve az adatokat képviselő objektumok, melyeken végezhetünk különböző műveleteket[29][35]. A problémák megoldásában az alulról felfelé megközelítést alkalmazza. A programegységet egymással kommunikáló objektumok összessége adja, amelyek valamilyen relációban állnak egymással. Az egyes objektumok tulajdonságait, viselkedését az osztályok írják le. Kifejezetten nagy előnye, hogy az absztrakciós szint nagymértékben növelhető. Az öröklés és a többalakúság révén el lehet érni, hogy azonos függvényhívásokkal más és más fusson le, más kontextusban másképpen működjenek a rendszerek. Ez lehetőséget ad nekünk egy viselkedés vezérelt rendszer kialakítására, anélkül, hogy a nagyon bonyolult procedurális, strukturális programkódok százait használnánk fel átláthatatlanul. A láthatóságok révén el tudjuk érni azt is, hogy a strukturális programoknál megszokott több száz függvényből csak a mások számára közvetlenül fontos interfészeket mutassuk be, amivel megfelelő absztrakciós szintet tudunk biztosítani. Ugyan ezzel a technikával bevezethetjük a biztonsági kérdések körét is. Míg az előző paradigmák esetében a program modellezésére elegendő általában egy struktrogramm vagy egy folyamatábra, így ebben az esetben a képességekre és az összetettségre tekintettel ezek nem elegendőek. Az objektum orientált
25
6.Programozási paradigmák és technikák programok modellezésére elsősorban UML (Unifield Modelling Language) diagramokat alkalmaznak, amelynek részletes ismertetése túlmutat a diplomaterven. Ez a programozási technika már nem közvetlenül csak a SISD (Single Instruction Single Data Stream) architektúrákat tartalmazza, hanem a több szálas, több processzoros technikákat is (pontosabban lehetőséget biztosít rá). A fentiekből egyértelműen következik, hogy ez a paradigma a számunkra legkedvezőbb és a legkívánatosabb is. Egyedüli, ám jelentős hátránya, hogy az így elkészült programok habár jóval gyorsabban elkészíthetőek, futtatásuk lassabb, mint az egyszerű procedurális programoké, ez az idő azonban az alkalmazási körünket tekintve nem számottevő, hiszen egy weboldal letöltéséhez viszonyítva a futtatási idő elhanyagolható. Tapasztalataim szerint a PHP oldalak csak igen kevés hányadában alkalmaznak objektum orientált paradigmákat, azonban véleményem szerint ez elsősorban nem sebesség és a támogatottság kérdése. Sokkal inkább arról van szó, hogy a web fejlesztők többsége – akik nem ASP.NET vagy hasonló objektum orientált keretrendszer alatt – programoznak, nem ismerik a technikát.
26
7.Releváns technológiák
7.
RELEVÁNS TECHNOLÓGIÁK 7.1.
STATIKUS WEBOLDALAK
Statikusak nevezzük azokat a weboldalakat, melyeknek tartalma nem változik a szerkesztés után, azaz a web szerverre feltöltött dokumentum létrehozása (és szerkesztése) után az összes lekérdezés esetében ugyan azt a választ fogjuk kapni [4][5][36][44]. Az ilyen weboldalak legnagyobb hátránya, hogy nélkülözik az interaktivitás minden formáját (pl. nem lehet hozzászólni a fórumokhoz), emellett szerkesztésük nagyobb portálok rendszeres karbantartása esetében igen időigényes lenne [5]. Előnye azonban a rengeteg, akár már interneten is szerkeszthető fejlesztőeszköz, melyekkel akár szakmai tudás nélkül is tudunk weboldalakat létrehozni [4][36].
7.2.
DINAMIKUS WEBOLDALAK
A statikus weboldalakkal szemben a dinamikus oldalak tartalma nem fixen rögzített, a felhasználók futtatási időben befolyásolhatják a megtalálható és megjeleníthető tartalmat, azokat módosíthatják is, és különféle módon kérhetik le [4][36]. Az ilyen rendszerek képesek felhasználói csoportokat, felhasználókat saját jogosultságuk és beállításuk szerint kezelni, azaz ezzel a módszerrel bevezethetőek jogosultsági kérdések is. A dinamikus weboldalak hátránya ebből is következik: ennek megfelelően jóval több törődést, folyamatos adminisztrációt kíván (hiszen pl. egy adatbázist nem elég csak létrehozni, hanem menedzselni is kell).
27
7.Releváns technológiák 7.3.
KLIENS OLDALI PROGRAMOZÁS
Kliens oldali programozás esetén a kódok és a kezdeti adatok letöltődnek a szerverről a kliens oldali programba (böngészőbe). Ezek után (tipikusan) minden a kliens oldalon fut, azaz ezzel tehermentesítjük a szerverszámítógépet a számításoktól, illetve bizonyos adatfeldolgozások alól [4][5][36].. A kódok alatt (általában) szkripteket kell érteni (pl. JavaScript), amihez külön fordító nem szükséges, azokat a böngésző program értelmezi futtatási időben. Az adatok bizonyos szintű és minőségi feldolgozásához nem szükséges feltétlen élő Internet kapcsolat, mint például az e-mail cím vagy telefonszám megfelelő formában való beírásának ellenőrzéséhez [4].
7.4.
SZERVER OLDALI PROGRAMOZÁS
A szerver oldali programozás esetében az adatfeldolgozás, számítási művelet a (web) szerver oldalon történik [4][24]. Erre egy tipikus példa az lehet, hogy a weblapon beállítunk egy nekünk megfelelő lekérdezést (pl. a szerzők nevére keresünk), az elküldés (submit) gombra kattintva az adatok elérnek a web szerverhez (ezt nevezzük HTTP kérésnek), ahol feldolgozásra kerülnek és az eredményeket weboldal formájában HTML kódként kapjuk vissza (HTTP válasz)[24].
7.4.1.
JSP
A JSP (JavaServer Pages) egy Java alapú dinamikus weboldal készítési technológia, melynek segítségével dinamikusan tudunk generálni HTML, XML vagy egyéb dokumentumokat megfelelő HTTP kérésekre válaszolva [12]. A technológia nagy előnye az erős támogatottság, a C szerű szintakszis, ami könnyen lehetővé teszi az oldalkészítést. A CGI-vel ellentétben a szervlet osztály (JSP) példányai nem jönnek létre illetve szűnnek meg minden egyes kliens hívás alkalmával, ami egyben a fejlettebb menetkezelést is jelenti [12][44].
28
7.Releváns technológiák Java szemléletű megközelítésből következően az így készült kódok objektum orientált paradigmákhoz nagyon jól illeszthetőek (hiszen maga a Java is tiszta, objektum orientált nyelv). Egy JSP oldalban alapvetően a következő nyelvi elemek lehetnek [12]: •
szkript elemek és változók (pl. HTML kódba ágyazva is)
•
statikus adat: például HTML kódok
•
direktívák: JSP konténerek aktiválására szóló utasítások, ilyenek például a header fájlok inkludálása
•
akciók: azaz a megfelelő események kezelésére vonatkozó utasítások és paraméterek
7.4.2.
ASP.NET
1996-ban megjelent az ASP (Active Server Pages) a Microsoft által kifejlesztett dinamikus, eseményeken alapuló weboldalak generálására alkalmas szerveroldali keretrendszere [24]. Az egyszerű ASP oldalak Visual Basic „alapúak”, az oldalak kimenete általában HTML, amelyekben azonban sokszor találhatunk Visual Basic Scipteket is (VBS). 2002-ben az ASP-t felváltva az ASP.NET jelent meg (NET keretrendszer megjelenésével párhuzamosan). A teljesen objektum orientált .NET keretrendszer előnyeit kihasználva (főképpen az adatbáziskötések, adatelérési modellek) legfőképpen Internetes adatbázis elérésre használják. Egy ilyen gyakorlati példa lehet a BME-n is alkalmazott ASP.NET alapú NEPTUN Egységes Felsőoktatási Tanulmányi Rendszer vagy a BME hivatalos weboldala. Természetesen ezen kívül rengeteg célra lehet alkalmazni a nyelvet. Míg az ASP-ben a szerver oldali programozásnál az elsődleges programozási nyelv a Visual Basic volt addig az ASP.NET-ben akár „egymás mellett” használha-
29
7.Releváns technológiák tunk Basic, C#, J#, C++ stb. nyelveket. A kliens oldalon (mindkét technológiában) script nyelveket lehet használni (pl. JavaScript, VBS). További jellemzője úgyszintén a .NET technológiának köszönhetően a nagyon gazdag, előre elkészített szerver és kliensoldali komponensek és vezérlő elemek, könnyű szerkeszthetőség, gyorsaság rugalmasság. Mivel az ASP.NET véleményem szerint az egyik legjobban használható, rugalmas, tiszta objektum orientált környezetet, melyet szinte bármilyen célra elő szeretettel tudok ajánlani, kiváló lenne a feladatom megoldásához. Azonban sajnos technológiai és egyéb tényezők miatt a PHP keretrendszert kell alkalmaznom, melyet a következő fejezetben ismertetek.
7.4.3.
PHP
A PHP (több, redundáns névfeloldással: Personal Home Page, PHP: Hypertext Preprocessor) nyílt forráskódú, weboldalak dinamikus leírására is alkalmas szkript nyelv [9][29][30]. A PHP-t jórészt szerver oldalon használják, bár elvileg léteznek, olyan fordítok, amik gépi kódot képesek generálni a PHP kódokból [9]. A PHP kétségtelen előnye, hogy a legtöbb web szerverre, operációs rendszerre és platformra ingyenesen telepíthető, az Apache web szerver egyik legnépszerűbb modulja. Ennek köszönhetően az egyik legelterjedtebb technológia [29]. A PHP kódok tipikusan .php végződési állományokban találhatóak, amelyek vegyesen tartalmazhatnak HTML, PHP és PHP-ba ágyazott dinamikus HTML kódokat. Számos beépített szolgáltatást tartalmaz és rengeteg fórum található ahol szkript gyűjteményre bukkanhatunk, ilyenek például: fórum rendszerek, e-mail küldés, adatbázis hozzáférések, fájlkezelések, listakészítés, login eszközök[30]. További előnye, hogy a nyelv C szerű, könnyű megérthető és kezelhető programnyelv. A változókat (tipikusan) nem kell külön deklarálni, definiálás közben (illetve némely esetben futtatási időben) a fordító automatikusan eldönti a változó típusát [30].
30
7.Releváns technológiák Az előnyök mellett azonban sok hátrányos tulajdonság is megmutatkozik. Ilyen például az egész és lebegőpontos számok platformfüggő tárolása is, melyet a Standard PHP Library (SPL) igyekszik kiküszöbölni [9]. A nyelv első verziója 1994-re datálódik, a használatos PHP implementációkat a PHP Group tartja karban és fejleszti [9][29]. A PHP kezdetekben CGI programok gyűjteménye volt, melyet az űrlap értelmező megalkotása követett (CGI alkalmazások kombinálásával) ezt neveztük PHP/FI (Form Interpreter)-nek, ami már jóval szélesebb funkcionalitással bírt. A PHP első nyilvános változata 1995-ben látott napvilágot, ami lehetővé tette a gyorsabb fejlődést, a hibakeresést és az elterjedést. A PHP2 verzióban a mai PHP alapvető tulajdonságai megtalálhatóak voltak: a Perl-éhez hasonló változók, az űrlapok kezelése és a HTML-kód beszúrásának lehetősége. A PHP szintaktikája is hasonló volt a Perl-éhez, de annál jóval korlátoltabb, egyszerűbb és kevésbé volt egységes. Jelenleg két verzió használatos: a PHP 4.x illetve a PHP 5.x. A PHP 4 2000-ben jelent meg, fejlesztése 2007 végén zárult le 4.4.8 verziószámmal [29]. A PHP 5 2004-ben jelenleg meg, ami jelenleg a nyelv egyetlen aktívan fejlesztett verziója, mely sok újítást tartalmazott: objektumorientált programozási lehetőségeket (amik személyes tapasztalataim szerint igen csekélyek), teljesítmény nővelő eljárásokat, fejlettebb adatbázis-absztrakciós kiterjesztéseket stb. [29] A PHP 6 verzió, bár már egy 2009. decemberi konferencián bemutatásra került, de a diplomatervírás idején még nem jelent meg a „forgalomban”, annyit azonban lehet tudni, hogy több PHP 4.x-es támogatás megszűnik, illetve a Unicode szövegek kezeléssével problémák adódnak (lassú kezelés, nem megfelelő támogatás). Nagyon sok rendszer sajnos még mindig a 4.x-es verziót használja. Az átállást nehezíti, hogy nagyon sok utasítás és környezeti paraméter nem portolható át könnyen [30]. A Magyar Tudományos Művek Tára alapvetően a PHP 5-ös verziót használja. A Budapesti Műszaki Egyetem Publikációs Adattárja 2010. januárban tért át az PHP 5-re .
31
8.Kereső algoritmusok
8.
KERESŐ ALGORITMUSOK A következő fejezetben elsősorban a PHP futtatókörnyezetben is alkalmaz-
ható szöveg- illetve tartalomkeresés főbb módszereit mutatom be, különös tekintettel arra, hogy az egyes módszerek milyen alkalmazási területtel, előnyökkel és hátrányokkal járnak. Az itt ismertetett algoritmusokat és módszereket építő elemekként használom fel, így a későbbiekben ezekre hivatkozni fogok. Rövid, de elgondolkodtató bevezetésképpen hadd előlegezzek meg néhány felmerülő és megoldandó problémát. Triviális és igen egyszerű megoldásnak tűnhet, hogy a mezőket egy az egyben egyesével végig keresem, ha mindegyik mező megtalálható egy az egyben akkor a siker biztos, egyezés van. Azonban a dolog nem ilyen egyszerű, hiszen gyakran előfordulnak elgépelések mindkét oldalról, egyes formátumhoz kötött adatokra (pl. ISBN) nem lehet egyszerűen rákeresni stb. A kereső algoritmusok alkalmazásakor el kell gondolkodnunk, hogy egyes mezőtípusoknál mennyire kell toleránsnak lennünk. Például egészen másképp kell értékelni az eltérést egy ISBN azonosító, egy szerzői név illetve egy rezümé esetében. Ezeknek a problémáknak részletesebb körülírását valamint az alkalmazott megoldásokat a Rendszertervezés fejezetben részletezem.
8.1.
TELJES EGYEZÉS MÓDSZERE
A teljes egyezéses keresés során arra akarunk választ adni, hogy egy vizsgálandó szöveg megtalálható-e egy másik dokumentumban betűről betűre [19][30].
32
8.Kereső algoritmusok Ez ideális megoldás lehet például egy biztosan hibátlanul feltöltött konferencia cikk címe esetében, amennyiben a vizsgálati oldalon (pl. weblapon) is ezzel a feltételezéssel élünk. Ezzel a módszerrel a legegyszerűbb esetben a vizsgálandó szöveget megpróbáljuk ráilleszteni a legelső karaktertől kezdődően, amennyiben a két minta stimmel, egyezés van, a vizsgálat pozitív eredménnyel zárult le. Amennyiben nincs találat, valamilyen lépésközzel (például betűnként, szavanként) végignézzük az összehasonlítandó állományban, egészen a dokumentum végéig illetve egyezésig (ez a rész azonban már opcionális). A keresés hatékonyságát a speciális karakterek lecserélésével is növelhetjük (pl. a HTML fejezetben tárgyalt, rossz kódkészlet beállítása miatt előfordulhat, hogy bár a tartalom tényleg azonos, azonban a kódkészlet miatt nem lesz találat). Ennek a keresési módszernek (algoritmusnak) kétségtelen előnye, hogy az egyik leggyorsabb, azonban nélkülözi a hibatűrést, ami esetünkben nem elfogadható.
8.2.
HANGZÁS ALAPJÁN VALÓ KERESÉS
A PHP-ben lehetőség van hangzás alapján való keresésre (pontosabban hangzás vizsgálatra), amivel két szöveg illetve szövegrész hangzását tudjuk összehasonlítani [30][37]. Ez elsősorban az angol nyelvű, kézi bevitelű repozitóriumokban alkalmazható kiválóan. Két releváns függvényt lehet megemlíteni az egyik a soundex, ami generikusan vizsgálja két szó hasonlóságát, valamint a metaphone függvény, ami figyelembe veszi az angol kiejtést is [30]. Nézzünk egy konkrét példát: 8-1. lista:Minta metaphone függvény használatára
33
8.Kereső algoritmusok A szkript a fenti példában ugyanazzal az értékkel tér vissza (SN), így a két szó hangzás alapján hasonlít egymásra (pontosabban ugyan azon hangzással rendelkeznek).
8.3.
LEVENSHTEIN ALGORITMUS
A Levenshtein algoritmussal (1965) lehetőség van két sztring úgynevezett Levenshtein-távolságát kiszámolni [19] [30] [37]. Ez számunkra a gyakorlatban leegyszerűsítve azt jelenti, hogy meg lehet határozni, hogy hány karaktert kell hozzáadni, törölni, vagy lecserélni ahhoz, hogy a két sztring azonos legyen, így a Levenshtein-távolság gyakorlatilag a Hamming távolság általánosítása úgy, hogy nem csak egyforma hosszakra, illetve nem csak betűcserére értelmezzük az összehasonlítást [19]. Nyilvánvalóan két szó akkor egyezik legjobban, ha e távolságuk minimális értéket vesz fel (ideális esetben nullát). Ezen algoritmus széles körben alkalmazott, például helyesírás ellenőrző rendszerekben, optikai karakterfelismerő rendszerekben stb.. Nézzünk is egy példát: 8-2. lista: Minta egyszerű paraméterezésű Levenshtein függvény használatára
Ebben az esetben a nevemet hasonlítottam össze. String_a esetében a hivatalosan használt alakot vettem, míg string_b esetében a rövid (tipikusan konferencia kitűzőkön, bankkártyákon) alkalmazott alakot. A szkript futtatás után 7-es eredménynyel tér vissza, azaz a két sztring közötti Levenhstein-távolság hét (ebben az esetben hét karaktert kell hozzáadni string_b-hez, hogy string_a legyen.
34
8.Kereső algoritmusok Nézzünk ugyan ezekkel a sztringekkel egy másik példát a paraméterezett összehasonlító függvényre: 8-3. lista:Minta összetett paraméterezésű Levenshtein függvény használatára
Ebben az esetben további paramétereket, úgynevezett költség paramétereket is meg lehet adni, melyek a példában illusztrált módon a következőket jelenti [20] •
első helyen a beszúrás költsége áll, mely a példában 2
•
második helyen a betűcserélés költsége áll, mely 1
•
a harmadik helyen a betűelhagyás költsége áll, amely 0 A futtatás után a függvény 0 eredménnyel tér vissza, hiszen string_a-ból hét-
szeres karakterelhagyással hétszer nullát ad hozzá a Levenshtein-távolsághoz. Tehát ezzel a módszerrel a gyakran előforduló gépelési hibákat különböző súllyal vehetjük figyelembe.
8.4.
SIMILAR TEXT
Az Oliver (1993) által készített algoritmus működése hasonló, mint a Levenshtein algoritmusa [30][37]. A lényeges különbséget az algoritmus futási idejében találhatjuk. Jelöljük rendre a két összehasonlítandó string hosszát m illetve n betűvel, ekkor [28] •
Levenshtein algoritmus futása ideje O(m*n)
•
Similar text algoritmus futása ideje O(max(n,m)*3) Ebből következik, hogy a hosszú összehasonlítandó szövegek esetében
kedvező a Similar text, azonban esetünkben egyfelől a tipikus összehasonlítandó szöveg mérete miatt, másfelől az ismertsége és egyszerűsége miatt a Levenshtein algoritmust veszem alapul, melyet a feladatoknak megfelelően módosítok. 35
8.Kereső algoritmusok Nézzünk egy példát a függvény alkalmazására: 8-4. lista:Minta similar_text függvény használatára
A függvény három értéket vár. Az első, az a szövegrész melyben keresni szeretnénk, a második az a sztring, amit keresni szeretnénk, és a harmadik érték egy opcionális érték, ami a százalékos egyezést írja ki. Ebben a konkrét példában az egyezés mértékét 80%-nak számította a program.
36
9. Esettanulmányok
9.
ESETTANULMÁNYOK Ebben a fejezetben röviden összefoglalom esettanulmány szerűen az első-
sorban a villamosmérnöki és (műszaki) informatikai szempontból fontos publikációs weboldalak közül az IEEE, a Web of Science (WOS), Scopus oldalait illetve az orvosi, biológiai vonatkozású PubMed MedLine weboldalát, kitekintve főbb jellemzőikre illetve azokon elérhető formátumokat.
9.1.
EISZ
Az EISZ (Elektronikus Információszolgáltatás) nemzeti program célja, hogy a felsőoktatás és a tudományos kutatás számára nélkülözhetetlen elektronikus információforrásokat központilag, nemzeti licenc alapján vásárolja meg, melynek eredményeként az eddigieknél lényegesen több információt tud biztosítani [7]. A felhasználókat csak az intézményük által igényelt és támogatott adatbázisokhoz férhetnek hozzá, mivel az EISZ keretein belül elérhető adatbázisok előfizetési díjához a tagintézményeknek önrésszel kell hozzájárulniuk]. Az Elektronikus Információszolgáltatás rendszeréből például elérhetőek a következő elektronikus szolgáltatások, adatbázisok [7]: • Web of Science • Science Direct • Science Magazine • ACM Digital Library • MathSciNet • stb. A szolgáltatások, mely több mint 50 millió rekordot tartalmaznak, biztosítják a legszélesebb körű hozzáférést különböző típusú elektronikus forrásokhoz. Lehetővé 37
9. Esettanulmányok teszi a bibliográfiák keresést, valamint együttesen oldja meg az adatbázis és a fulltext hozzáférést is.
9.2.
IEEE
Az IEEE (Institute of Electrical and Electronics Engineers) a világ egyik vezető műszaki szervezete, nevéhez számos villamos és informatikai szabvány, folyóirat cikk, konferencia előadás stb. kapcsolódik, például a hálózati technológiák, adatátvitel és Internet témakörökből [11][27]. A fentiek alapján jogos és triviális elvárás azt feltételezni, hogy az IEEE portáljánál minden a „nagykönyv” szerint van megtervezve, azonban későbbiekben ismertetett példákban eléggé meghökkentő tényeket tapasztalhatunk. Az IEEE oldalain keresztül külön regisztráció nélkül megtekinthetjük egyes publikációk általános, HTML dokumentumba ágyazott tartalmát, amennyiben ismerjük a cikk (publikáció) DOI vagy HTML címét. Külön regisztrációhoz (és természetesen vele együtt járóan díjhoz) kötötten lehetőség nyílik a publikációk adatait letölteni RIS, BibTeX illetve „egyszerű” szöveges ASCII formátumban. Ugyancsak regisztrációhoz kötötten lehetőség van a tudományos mű lenyomatának letöltésére is PDF formátumban. A fentiek igen kecsegtetően hangzanak, főként, hogy a BME (OMIKK) rendelkezik hozzáféréssel (pontosabban intézményi regisztrációval), így minden problémánk megoldottnak tűnik, hiszen egy kattintásra elérhetünk minden fontos formátumot. Azonban jobban megvizsgálva az oldalt az előzőkben említetthez csatlakozva, megdöbbenve tapasztalhatjuk, hogy: • egy cikket DOI címmel lekérdve (empirikus tapasztalataim alapján) tíz esetből átlagosan hétszer hibához jutunk (lásd 9-1. ábra). A probléma kapcsán az IEEE-vel kapcsolatba léptünk, azonban ők azt a semmitmondó tájékoztatást adták, hogy a saját rendszerükből meghívva a szolgáltatást nem tapasztalnak rendellenességet. 38
9. Esettanulmányok Ugyancsak empirikus megfigyelések révén arra a következtetésre jutottam, hogy a legvalószínűbb módon az IEEE session kezelésével van a probléma, hiszen a DOI alapítványnál szereplő bejegyzések helyesek és a DOI névfeloldás után kapott linket a böngészőbe beírva ugyan csak hibára jutunk, azonban a bekövetkezett hiba aránya függőt az internetelérés földrajzi helyétől és a sebességtől is. Hosszas vizsgálódások és kísérletek után sikerült olyan speciális módszert találnom, amelyben tíz esetből tízszer helyes eredményre jutunk. Az általam adott lehetséges magyarázat, empirikus megfigyeléseim alapján a hibás web session kezelésből (menetkezelés) adódik: böngésző emuláció nélkül a get paraméterrel átadott oldal lehívása az adatbázisból nem mindig jár sikerrel, azonban amikor egyértelműen azonosítható böngészővel (emulációval) próbálkozunk, akkor a lekérdezés közel 100% eredménnyel jár. Tehát vélhetőleg nem tudja az IEEE szerver (pontosabban a kiszolgáló szoftver) beazonosítani, hogy honnan származott a lekérdezés.
9-1. ábra: Egy IEEE példa publikáció sikertelen DOI resolving eredménye
•
Egyes bibliográfiai adatokat hordozó formátumokban – mint pl. HTML,
RIS, BibTeX – más és más adatok szerepelnek, azonban szerencsére ezek nem egymásnak nem ellentmondóak, csak hiányosak. Egy példát említve az egyik formátumból az absztrakt, másikból az ISBN, a harmadikból pedig a tanszék (intézmény) hiányzik. A fentiekre egy egyszerű példát illusztrál a 9-2. ábra, ahol egy DOI oldalból sikeresen feloldott weboldalról elérhető újabb oldalon további plusz információkat érhetünk el (lásd a képen aláhúzott szövegek).
39
9. Esettanulmányok
9-2. ábra:Egy IEEE példa publikáció sikeres DOI resolving eredménye, valamint a feloldott oldalon keresztül elérhető újabb oldal
• A dolgozatírás kezdetekor az azonos cikkhez tartozólag is háromfajta, látszólag ugyan olyan megjelenésű, de belső szerkezetét tekintve eltérő oldal tartozik. Természetesen itt is sikerült jó eredményeket elérni egy link sablon felhasználásának segítségével, amivel, nagy eséllyel ugyan azt az oldalt sikerül elérni. Egy másik lehetséges –egyben általam is alkalmazott– megoldás egy univerzális HTML tag feldolgozó alkalmazása. A fenti probléma illusztrálásával tekintsük meg a 9-3. ábra illetve 9-4. ábra által mutatott ugyan azon webcímhez tartozó web böngésző által megjelenítet képet illetve ugyan azon rész HTML kódjának részletét. A főbb eltéréseket piros színnel jelöltem.
40
9. Esettanulmányok
9-3. ábra: "A" lekérdezés eredménye a böngészőben illetve részlet az oldal HTML kódjából
9-4. ábra: "B" lekérdezés eredménye a böngészőben illetve részlet az oldal HTML kódjából
41
9. Esettanulmányok • Az egyes IEEE oldalak számos HTML szintaktikai hibát tartalmaznak, egy példát említve, csak a nyitó oldalon több mint 900 a W3C HTML validátorjával felismertethető hiba található meg.
9-5. ábra: IEEE kezdő oldal HTML validációja [42]
WEB OF SCIENCE
9.3.
A Web of Science (WoS) az ISI (Institute for Scientific Information) interdiszciplináris elektronikus bibliográfiai adatbázisa [7][41]. Tudományos szempontok szerint rendszerez, valamint sokoldalú keresést biztosít. A
WoS
szolgáltatása
a
citációs
index,
amely
lehetővé
teszi
a
tudománymetriai elemzéseket, mivel a cikkek bibliográfiai adatain kívül a szerzői hivatkozásokat is feltárja. Hasonló szolgáltatások természetesen elérhetőek többek között a Scopus, Google Schoolar illetve részben az IEEE oldalain is. A Web of Science három adatbázisa három fő tudományterületre osztva rendszerez [41]: • Arts & Humanities Citation Index: bölcsészettudományi és művészeti index, mely 25 kategóriában tartalmazza, több mint ezer teljes folyóirat anyagát, valamint a vonatkozó cikkeket több mint hétezer társadalomtudományi és tudományos folyóiratból
42
9. Esettanulmányok • Science Citation Index Expanded & SciSearch: természet- és műszaki tudományos index, amely 160 tudományterületet ölel fel • Social Sciences Citation Index & Social SciSearch: társadalomtudományi index, mely 55 kategóriában tartalmazza 1700 folyóirat teljes anyagát, valamint 5700 vonatkozó cikket a vezető tudományos és műszaki folyóiratokból. A
WoS-ban
a
figyelt
folyóiratok
kiválasztása
erősen
alapkutatás-centrikus
[16][18][42]: • konferenciákat egyáltalán nem figyelnek • a WoS-ban nem figyelt folyóiratokban megjelent cikkekre való hivatkozást csak akkor rendelik az összes szerzőkhöz, ha ezek az irodalomjegyzékben fel is vannak sorolva (az "et al" jelentését nem tudja feloldani az adatbázis) • az ISI döntésétől, és nem a szakterület közvéleményétől függ az egyes folyóiratok figyelése/negligálása • a hivatkozások száma nagyon függ a szakterület (és a folyóirat) szokásaitól: a társ-szerzők tipikus száma, a hivatkozások mennyisége, cikkek hossza, cikkek megjelentési sebessége, stb. • a megjelenített oldal a WoS-ban általános célú, az egyetemen illetve a műszaki területen kívánatos szempontokat nem lehet beállítani.
43
9. Esettanulmányok
9.4.
SCOPUS
A Scopus az egyik legnagyobb, több nyelvet is támogató tudományos, műszaki, orvosi és társadalomtudományi absztrakt és citációs adatbázis, mely számos szolgáltatást nyújt [34]. Adatbázisa több mint 40 millió rekordot tartalmaz, melyből kb. 20 millió bejegyzés 1823 és 1996 között datálódik (hivatkozás kezelése nélkül). A Scopus közel 18 000 elektronikus címen, több mint 5 000 nemzetközi kiadó adatbázisaira támaszkodik. Rendelkezik ezen kívül széleskörű konferencia lefedettséggel (majd négymillió konferencia előadás adatait tartalmazza), valamint szabadalmi bejegyzésekkel is. Scopus többek között az alábbi szolgáltatásokat nyújtja [34]: • Citation Tracker mellyel egyszerűen meg lehet találni, ellenőrizni és nyomon követni citációs adatokat • Journal Analyzer ami gyors betekintést folyóiratok volumenébe • PatentCites, amellyel nyomon lehet követheti, hogy az egyes szabadalom státuszát, illetve hol alkalmazzák őket • WebCites ami nyomon követni internetes irodalmakat, citációkat A weboldal az alábbi kimeneti formátumokat tartalmazza • szöveges (ASCII) formátumba • RIS formátumba vagy annak segítségével ProCite-ba illetve EndNote-ba • RefWorks-be való exportálás • pontos vesszővel tagolt CSV fájl A következő ábrákban egy publikáció weboldalát és a HTML validátor eredményét tekinthetünk meg.
44
9. Esettanulmányok
9-6. ábra: Scopus minta oldal
9-7. ábra:Scopus kezdő oldal HTML validációja [42]
45
9. Esettanulmányok
9.5.
MEDLINE
A MedLine az U.S. National Library of Medicine által üzemeltetett legnagyobb és legismertebb orvosi illetve orvosi vonatkozású biológiai és kémiai bibliográfiai adatbázis [39]. A MedLine adatbázis évente körülbelül 400 000 tétellel bővül, melyek 85 százaléka angol nyelvű, a tételek közel 70 százaléka tartalmaz kivonatot, vagy hivatkozást a teljes cikkre. A repozitórium többféle elérési módja közül (pl. Ovid, Ebsco) a legnépszerűbb az ingyenes hozzáférésű PubMed néven ismert, webes adatbázis. A 9-8. ábra a keresési és megjelenítési lehetőségekre mutat egy példát. A megjelenített publikáció szokásos alapadatain felül találhatunk hivatkozásokat is, melyek a teljes illetve eredeti cikkre mutatnak. Az oldal támogatja a fájlként való letöltést, vágólapra másolást, e-mail-ben való elküldést egyszerű szöveges, RIS szerű formátumban illetve XML-ként. A későbbiekben ismertetett XML átviteli formátumunk kialakítása során nagyon sok hasznos ötletet merítettem a MedLine XML formátumból. Megjegyzem, hogy bár az oldal nem kínálja fel, de lehetőség van egy link sablon és cikkazonosító alkalmazásával a fenti formátumokat direktben elérni (saját kísérletek nyomán).
46
9. Esettanulmányok
9-9. ábra: PubMed minta oldal
9-8. ábra:PubMed MedLine kezdő oldal HTML validációja [42]
47
10.A BME Publikációs Adattára és a rendszer általános felépítése
10. A BME PUBLIKÁCIÓS ADATTÁRA ÉS A RENDSZER ÁLTALÁNOS FELÉPÍTÉSE 10.1.
A BME PUBLIKÁCIÓS ADATTÁR ÉS AZ MTA
KÖZTESTÜLETI PUBLIKÁCIÓS ADATTÁR Amíg BME Publikációs Adattár (BME-PA, PA) elsősorban a Budapesti Műszaki és Gazdaságtudományi Egyetem oktatói, hallgatói és alkalmazottai számára üzemeltetett adattár, a vele szoros kapcsolatban lévő MTA Köztestületi Publikációs Adattár (MTA KPA, KPA) a Magyar Tudományos Akadémia köztestületi tagjai számára fenntartott repozitórium. Ennek alapján jött létre a Magyar Tudományos Művek Tára (MTMT). A BME-PA és az MTMT (pontosabban a mycite kód alapú) adatbázisok egymással együttműködni képesek, illetve nagyban hasonlítanak egymásra. Hosszú távon várhatóan egységesen fognak működni [16][18]. Egyetemünkön az alkalmazottak, doktoranduszok számára Publikációs Adattár használata általában (erősen) ajánlott, de természetesen ez alól is van kivétel: pl. a Villamosmérnöki és Informatikai Karon a doktori értekezés beadásakor kötelező használata, míg habilitációkor, akadémiai doktori értekezés beadásakor illetve akadémikusi ajánláskor ennek vagy az ezzel lényegében ekvivalens KPA-nak a használata kötelező. A duplikációt és az inkonzisztenciát elkerülendő a két “testvér” repozitórium keresői egymás adataira is rámutat(hat)nak, így nem szükséges (nem is kívánatos) dupla lista készítése. Az összekapcsolás (rámutatás) teljesül amennyiben [18]: •
a szerző mindkét adattárban létre van hozva
•
a szerző rendelkezik köztestületi azonosítóval, ami mind a két oldalon regisztrálva van
•
megfelelő adminisztrációs beállítások után az átirányítás létrejön
48
10.A BME Publikációs Adattára és a rendszer általános felépítése Ettől fogva mindkét adattár keresője ismerni fogja a szerzőt és keresőjük ugyanazt a listát fogja mutatni.
10.2.
AZ ADATBÁZIS HASZNÁLATÁNAK ELŐNYEI
A következőkben vázlatosan összefoglaljuk a BME-PA (MTMT) alkalmazásának az előnyeit [18]: •
az adatbázisba való bevitel segíti a publikációk pontos megadást, figyelmeztet a hiányzó adatokra, jelzi a duplumokat és önhivatkozásokat
•
többé nem kell külön publikációs listát kezelni
•
automatikusan megadja az impakt faktorokat és központi forrásból meg fogja tudni adni a folyóiratok jellemzőit (pl. lektorált vagy nem lektorált, külföldi vagy magyarországi kiadású)
•
kisebb átalakítások után könnyen egyesíthetők a különböző adatbázisokban (pl. Web of Science, IEEE eXplore, Scopus, Google scholar) megtalálható hivatkozási adatok
•
a honlapunkra beköthető egy URL (webcím), melyen az összes publikációnk és hivatkozásunk megtalálható
•
a publikációk és hivatkozások jól kereshetők, sokféle formában elmenthetők
•
segítségével a VIK PhD és az MTA Műszaki Tudományok Osztálya pontozás automatikusan megtekinthető és kinyomtatható
10.3.
TECHNIKAI RENDSZER ÉS AZ ADATBÁZIS SZER-
KEZET 10.3.1.
ÁLTALÁNOS ADATOK
A BME-PA adatbázisát hivatalosan a http://mycite.omikk.bme.hu cím alatt lehet elérni . A szerveren úgynevezett mycite kód fut PHP 5.2.6. alapon. A rendszer több mint 70 ezer kódsorból épül fel, modul jelleggel. az aktív modulok kb. 50.000 PHP sort tartalmaznak, és a fejlesztő saját megjelenítési-sablon kezelőjét használják. 49
10.A BME Publikációs Adattára és a rendszer általános felépítése
10.3.2.
ADATBÁZIS HÁTTÉR
Az adatbázis, melyben több mint 160 adatbázis tábla található, MySQL 5.0.32 alapú, UTF-8 alapú kódolással. A teljes adatbázis tárigénye 6,7 GB feletti, amiből jelentős rész a keresési index. A táblák gazdagon tűzdeltek foreign key (idegen kulcs), primary key (kulcs) constraintekkel (megkötésekkel) és indexekkel. A PA adatait naponta mentik. Ez azt jelenti, hogy véletlen törlés, vagy még rendszerösszeomlás esetén is helyreállítható a legfeljebb 24 órával előbbi állapot.
10.3.3. •
FELHASZNÁLÓK
kereső: az adatbázisban tárolt publikációk és időző közlemények között kereső felhasználó, amely lehet autentikált vagy anonim
•
szerző: karbantartja a saját publikációs listáját. Ezt megteheti szerkesztőfelületen vagy különböző importokkal. Kereshet (ekkor autentikált keresőként viselkedik), és azon szervezeti egységes statisztikai adatait éri el, amiknek tagja
•
könyvtáros: szerzők egy csoportjára proxy user, azaz karbantartja az ő publikációs listájukat. A csoportok képzésének alapja a szerzők intézményi hozzárendelése
•
adminisztrátor: törzsadatokat kezel. Folyóiratok, impakt faktorok, intézményi hierarchia és hozzárendelés. Felhasználókat kezel és statisztikákhoz fér hozzá
Az MTMT-ben a jogosultsági rendszer ennél bonyolultabb, de a fő funkciók megyegyeznek.
10.3.4.
FEJLESZTÉS
Tapasztalataim és a rendelkezésre álló dokumentációk alapján a fejlesztés sokszor ad hoc jellegű. A verziókezelés egyelőre nem megoldott. Az elkészített kódok igen ritkán kommentezettek és csak kisebb részben állnak rendelkezésre adatbázis, fejlesztői, üzemeltetői dokumentációk.
50
11.Követelmény menedzsment
11.
KÖVETELMÉNY MENEDZSMENT A következő fejezetben a megtervezendő rendszer követelmény menedzs-
mentjét tárgyalom. Egy olyan feltételt, melynek a rendszer meg kell, hogy feleljen, vagy egy olyan képességet, melyet a rendszernek nyújtania kell, a rendszerrel szemben támasztott követelménynek nevezünk [35]. A követelmények tehát azok a célok, amelyeket a szoftverfejlesztési munkánk során realizálnunk kell. A követelménytervezés (specifikáció) a szoftverfejlesztés első és egyben igen fontos lépése, amelynek célja, hogy meghatározzuk milyen szolgáltatásokat követelünk meg a rendszertől, és hogy a rendszer fejlesztésének és működtetésének milyen megszorításait alkalmazzuk [35]. Nagyszámú követelménnyel csak akkor boldogulhatunk, ha külön energiát fektetünk azok kezelésére, ezt a tevékenységet a követelmény menedzsmentnek nevezzük. A diplomatervezésemben egy egyszerűsített követelmény és verzió menedzsment szisztémát alkalmazok. Következőkben a BME Publikációs Adattárával egyeztetett felhasználói és rendszer követelmények kerülnek röviden, felsorolás jelleggel ismertetésre. 11.1. táblázat: Követelmény menedzsmentben alkalmazott jelölések
Jelölések a követelmény menedzsmentben: Megvalósított funkciók és követelmények
félkövér
Tesztelés alatti funkciók és követelmények
félkövér
Nem megvalósított funkció és követelmények
51
11.Követelmény menedzsment 11.1.
FELHASZNÁLÓI KÖVETELMÉNYEK
A felhasználói menedzsmentben többnyire természetes nyelvű kijelentések találhatóak arról, hogy mely szolgáltatásokat várunk el a rendszertől, és arról, hogy annak mely megszorítások mellett kell helyesen működnie [35]. A következő táblázat segítségével áttekinthetjük a felhasználó által támasztott főbb követelményeket. 11.2. táblázat: Felhasználói követelmények listája Felhasználói Követelmények
követelmény száma
1 az elkészítendő program (szkript) legyen képes bibliográfiai rekordok internetes verifikációjára és validációjára 2 működjön együtt az MTA (KPA) szervereivel, rendszereivel és alrendszereivel 3 kezelése és használata legyen érthető 4 legyen hibatűrő, hibás és rosszindulatú inputtal ne lehessen a program végrehajtását felfüggeszteni 5 legyen univerzális működésű, azaz lehetőség szerint más platformokra könnyen lehessen átportolni, új támogatott weboldalat könnyen lehessen integrálni
11.2.
RENDSZERKÖVETELMÉNYEK
A rendszerkövetelmények (funkcionális specifikáció) a rendszerszolgáltatásokat és megszorításokat jelöli részletesen. A következőkben ez kerül definiálásra. 11.3. táblázat: Rendszerkövetelmények listája Rendszer Felhasználói követelkövetelmény száma mény száma 1 1,2,5
Követelmények
működjön együtt a BME PA szervereivel, rendszereivel és alrendszereivel: alkalmazzon Apache alapú PHP 5.0-ás kompatibilis szkripteket, SQL
52
11.Követelmény menedzsment 2 2,3
kezelése és használata legyen érthető: a forráskód dokumentációja legyen megfelelő mennyiségű és minőségű, interfészek egyértelmű definiálása
3 1,5
legyen hibatűrő, hibás és rosszindulatú inputtal ne lehessen a program végrehajtását felfüggeszteni, a program ne okozzon védelmi hibát a rendszerben
4 4
legyen hibatűrő, hibás és rosszindulatú (vírust, férget stb. tartalmazó) weboldalakkal szemben legyen immunis
5 4
legyen képes a szkript önellenőrző, hibadetektálásra
6 4
amennyiben valamilyen oknál fogva a rendszerben a program futtatása kivételkezelés nélkül valamilyen hiba (pl. védelmi hiba) miatt megáll, a rendszer ismételt hívásra legyen képes visszaállni eredeti állapotába, legyen kész ismét adatok és parancsok fogadására
7 1,2,5
támogassa a DOI-val megadott oldalakat
8 1,2,5
támogassa a linkkel adott oldalakat
9 1,2,5
támogassa a publikáló szervezet nevével és az azonosítóval feloldható oldalakat
10 1,5
eltérő viselkedést alkalmazzon különböző rekord típusonként
11 1,5
eltérő viselkedést alkalmazzon különböző mező típusonként
12 1,5
eltérő viselkedési modellt is képes legyen alkalmazni különböző weboldalakra
13 1,5
legyen képes böngészőprogram emulálásra ezzel elkerülvén az esetleg felmerülő jogosultsági problémákat
14 1,5
legyen képes felismerni, hogy az adott weboldalon milyen gyakran van lehetőség folyamatos lekérdezésre, ezzel elkerülve az esetleges kitiltásokat
15 1
rekord egyezés eredményét egy a mezők összes egyezési valószínűségét figyelembe vevő kumulált egyezési hányados figyelembe vételével határozza meg
16 1
a mezők értékének egyezését az egyezés valószínűségével kvázi lineárisan csökkentve határozza meg, nem pedig indikátor változókkal
53
11.Követelmény menedzsment 17 1,2,4
a mezők, mint az MTA, mint a weboldalak részéről legyen toleráns az egyszeri elgépelésekkel szemben
18 1,2,4,5
a mezők általában, de különösképpen a publikáció címét tartalmazó mezőkben a gyakori szöveghosszúsági eltérések miatt a szövegek összehasonlítása kevésbé legyen érzékeny a kimaradt vagy lerövidített szavakra, de a szavak egymás utáni sorrendjére legyen kritikus
19 1,2,4,5
a mezők a weboldalról és az adatbázisból interfészen keresztül kapott értékében szereplő felesleges karaktereket elemzés során ne vegye figyelembe
20 1,2,4,5
amennyiben lehetőség van rá az egyes egyoldali vagy kétoldali hiányzó mezőket (pl. ISSN azonosító) más lehetséges adatokból is legyen lehetőség azonosítani (pl. Kiadvány neve, kötetet, megjelenés ideje stb.)
21 1,2,4
a rekord csak akkor lehet elfogadott, ha a szerzők neveinek száma megegyezik az MTA KPA-ban tároltakkal és a publikációs honlappal
22 1,2
meghatározott esetekben a rekord csak akkor lehet elfogadott, ha szerzők sorrendje megegyezik, mint az MTA KPA-ban tárolt, mint a publikációs honlapról értelmezhető adatokkal
23 1,2,4
rendszer legyen képes felismerni az eltérő nyelvből és jelölésből adódóan a megjelenés, publikálás helyét, különös tekintettel a városokra és az országokra
24 1,2,4
25 1,2,4,5
a rendszer legyen képes az idézők számát verifikálni és validálni
rendszer legyen képes helyi adatbázisban, illetve eltérő adatbázisokban található rekordok kapcsán duplum vizsgálatra
26 1,2,4,5
a rendszer legyen képes a publikáció verifikációhoz hasonló módon szabadalmi bejegyzésen, lajtromon is verifikációt, validációt végre hajtani
54
11.Követelmény menedzsment
11.1.
UML USE CASE DIAGRAM
A következő ábrában a rendszer egyszerűsített használati eset diagramját mutatom be, a specifikációnak megfelelően. Az egyes szerepeket a „A BME Publikációs Adattára és a rendszer általános felépítése” fejezetben mutatom be.
11-1. ábra: A rendszer egyszerűsített USE CASE diagramja
11.2.
FEJLESZTŐKÖRNYEZET ÉS A VERZIÓ MENEDZS-
MENT A fejlesztés és a tesztelés során a következő szoftverek kerültek felhasználásra, az újbóli sikeres fejlesztés és a tesztelés csak az alábbi szoftverekkel együtt működve garantáltak:
55
11.Követelmény menedzsment 11.4. táblázat: Fejlesztés és tervezés során felhasznált szoftverek kivonatos listája
Név
Rövid leírás
phpDesigner 6.2.5.2
A phpDesigner egy a PHP fejlesztést elősegítő szoftver, amely számos beépített funkciója segíti a fejlesztését, ilyen például az integrált debugger (ami igen ritka PHP fejlesztőknél)
XAMPP Lite 1.7.2 által
Az XAMPP könnyen telepíthető Apache terjesztés,
vezérelt virtualizációs környezet
több fajta operációs rendszeren elérhető. Segítségével könnyen elérhetőek az Apache szerveren futó szolgáltatások hosszan tartó és bonyolult konfigurációk nélkül
Apache
Webserver
2.0,
PHP 5.3 támogatással MySQL
XAMPP által vezérelhető Apache Webszerver PHP 5.3 futtatókörnyezettel egybe integrálva Egy MySQL adatbázis kliens, SSH Tunelen keresztül elérhető vele a BME PA bibliográfiai adatbázisa
Tortoise SVN 1.6.6.17493 64 bites verzió
A TortoiseSVN egy ingyenes kliens program Windows operációs rendszerek alá az SVN szerverek és repozitóriumok eléréséhez
VisualSVN
Server
Standad Edition 2.0.8 Stylus Studio 2010 XML Professional Suite 10.0.1
A VisualSVN egy operációs rendszerbe beépülő, könnyen karbantartható ingyenes SVN szerver A Studio XML egy professzionális célú XML tervező, szerkesztő és validáló program. Segítségével állítottam elő az XSD fájlt, illetve teszteltem az exportálás funkciót
A verzió menedzsment – habár egyfejlesztős rendszerről beszélünk – az SVN szoftverrel valósult meg copy-modify-merge megközelítésben (természetesen ebben az esetben a merge-nek nincs jelentősége). A fejlesztés során számos, különböző számítógépet használtam fel, és mivel platform független technikáról beszélünk, ezért nem tartom szükségét a fejlesztés során alkalmazott hardverek leírásának .
56
12. Rendszertervezés
12.
RENDSZERTERVEZÉS
12.1.
RENDSZER GENERIKUS FELÉPÍTÉSE
A következőkben a rendszer általános – strukturális – felépítését tekinthetjük át, melyhez a következő, absztrakciós rétegeket tartalmazó ábra nyújt segítséget.
12-1. ábra: A rendszer elméleti felépítése
A felhasználók internetes webes interfészen (böngésző programon) keresztülérhetik el a BME PA szolgáltatásait, mint például a szerzők publikációnak keresését. Regisztrált (jogosultsággal) rendelkező felhasználóknak lehetőségük van többek között publikációs bejegyzéseket létrehozni és átadatni őket hitelesítésre. Ezt az elérési szintet nevezem böngésző (webes) absztrakciós, illetve felhasználói szintnek.
57
12. Rendszertervezés Szintén ugyan ezen a szinten található a programom által közvetlenül, a hitelesítés céljából elérni kívánt weboldal letöltési funkció. A publikációs weboldalak számára (pl. IEEE eXplore) a programom, mint egy böngésző látható, mely mögött vélhetően egy felhasználó ül, nem pedig egy automata keresőprogram (motor). Ez a tény szintén fontos szerepet játszik, hiszen vannak olyan weboldalak ahol a motor által vezérelt letöltés, keresés nem megengedett. Ezt természetesen – nem transzparens programok miatt – közvetlenül nem lehet megítélni, hogy a lekérdezéseket egy klienst vagy pedig egy motor végzi el. A web szolgáltatást üzemeltetők általában ezt egy lekérési időhöz szokták kötni, azaz például ha túl sűrűn vannak lekérdezések az adott oldalon, akkor vélhetőleg nem egy egyszerű felhasználóval van dolgunk, hanem egy motorral, melynek IP-jét illetve loginját ebben az esetben ki kell tiltani. Az én megoldásomban lehetőség van beállítani, hogy milyen időközönként lehet az egyes lekérdezéseket futtatni egy adott oldalon, ezzel el lehet kerülni a „motorság” látszatát. A következő absztrakciós szinten található a programom elérhetőségi szintje, ahol az egyes hitelesítéshez illetve önteszthez szükséges függvényeket meg lehet hívni. Ez az átlagos felhasználó számára már transzparens réteg. Ugyan csak ezen a rétegen találhatóak az XML dokumentum előállítására szolgáló függvények, mely a tervek szerint hamarosan a BME PA és a MTA KPA webes felületén keresztül is elérhetőek lesznek. A forráskód szinten találhatóak a programom működéséhez szükséges php állományok, statikus paraméter táblázatok (pl. publikációs weboldal beállítások), melyek csak a programom által hívhatóak meg, mivel önmagukban a függvények egymással együttműködnek, valamint több állományban szétszórva találhatóak meg, így a „kézzel való” meghívás nem szükségszerű és nem is kívánatos. A legalsó szinten pedig az adatbázis hozzáférési absztrakciós szint található meg, melyet az XML exportáló programom használ fel (a hitelesítés minden esetben az XML állományon keresztül történik).
58
12. Rendszertervezés
12.2.
RENDSZERSZINTŰ KOMPONENSEK ÉS MODULOK
Míg az előző fejezetben az általános működést és szerkezetet fejtettem ki, a következőkben a fizikai rendszer főbb alkotóelemeit tekinthetem át. A szoftverrendszer alapvetően több, fájl szinten különálló (de logikailag sokszor összetartozó, elválaszthatatlan) részekből áll, mivel ezeket egyszerű viselkedési modelleken (pl. UML diagramok) nem lehet illusztrálni szükséges egy komponens szintű leírás is. A következő táblázat egy rövid leírást mutat, melyekben a modulok fájlbeli, rövid funkcionális leírása található. A részletesebb – és egyben naprakészebb – leírást a mellékelt forráskódból előállított (myphpDocument által készített) html alapú dokumentáció tartalmaz. 12.1. táblázat: A fejlesztés során létrehozott főbb állományok listája
Fájl név
Funkció
Leírás
parser.php
inicializálás
szükséges böngésző emulációk betöltése, futtatókörnyezetbeli paraméterek beállítása
weboldal nyitása
paraméterként megadott weboldal biztonságos megnyitása, valamint az oldal tartalmának elmentése egy változóba
link elemzés
weboldal linkjének feloldása a DOI-val ill. cikk azonosítóval és weblap nevével
beallitasok-
környezeti
betoltese.php
zók
válto- a rendszer környezeti változóinak, inicializáláskor szükséges változók és konstansok tárolása
objektum tartalmi objektum inicializálási eljárások meghívása, tartafeltöltése osztaly.php
objektum zálás
lomkeresés és összehasonlítás végrehajtása iniciali- alapvető viselkedési modell futtatásidejű realizálása a link elemzésben kapott adatok szerinti eltérő példányosítás révén
csv fájlok
oldal paraméterek oldal specifikus (IEEE, MedLine, Scopus stb.) bebetöltése
állításait tartalmazó táblázat
59
12. Rendszertervezés kereso-
statikus
fuggvenyek.php
függvények
kereső- generikus keresőfüggvények, melyek segítségével tag-ek, kulcsszavak, szakaszok között tudunk keresni
namecomp.php
név összehasonlí- külső készítésű függvény, amely a név összeható függvény
sonlítás kapcsán felmerülő függvényeket tartalmazza
verification.php
meghívandó indí- a verifikálás és validálás során felhasználók szátó php kód
mára meghívható komplex függvényeket tartalmaz
önteszt elvégzése
öntesztelésre szolgáló meghívható függvényeket tartalmaz, mellyel a publikációs weboldalak kapcsán beállítottak aktualitását tudjuk ellenőrzi
xml_export.php
XML export
az XML export kapcsán fellépő feladatok ellátására szolgáló meghívható függvényeket tartalmazza
index.php
bemutató oldal
dinamikus demonstrációs oldal, amellyel működés közben bemutatja a rendszer képességeit vizuális felület segítségével
schema.xsd
séma fájl
az éppen aktuálisan érvényben lévő XML schema adatait tartalmazó fájl
link_sablon.csv
link sablonok
a CSV fájl tartalmazza a különböző publikációs oldalak publikációs azonosítóval való betöltésére utaló linket (pl. egy cikk azonosítóból, hogy lehet előállítani a cikkre mutató linket)
60
12. Rendszertervezés
12.3.
UML CLASS DIAGRAM
A következőkben egy rövid és tömör áttekintést nyerhetünk a működés alapjairól, a részletes leírást a phpMyDocument által készített forráskód dokumentációban találhatjuk meg. A rendszer objektum orientált egyszerűsített felépítését [2] a következő Visual Studio-val készített UML osztály diagram ábra illusztrálja. A rendszer logikai alapját az általános Field osztály képzi, melynek funkciója a hitelesítésre átadott mezők adatainak tárolása és vizsgálata. Az inicializálás során – melyet a Beallitasok osztály és parser php állomány végez a konstruktor meghívás segítségével – a Field tulajdonságai (ábrában Fields) feltöltődnek a megfelelő weblap típusnak megfelelően (pl. MedLine PubMed keresési paraméterek). A Field osztály továbbiakban tartalmaz egy Tartalomkereses nevű metódust is, melynek feladata az adott, inicializáció után feltöltött tartalom megkeresése (pl. oldalszámok, publikálás helye). Ez a metódus – futtatási időben eldöntve – az adott publikációs weblapon alkalmazott formátumnak, típusnak (pl. HTML, fix tag-ek közé zárt attribútum) megfelelően, kombinálva, sorrendhelyesen meghívja a (statikus osztállyal reprezentált) keresőfüggvényeket. A Field osztály tartalmaz még egy Osszehasonlitas() nevű operációt is, melynek feladata a weblapon megtalált mező összehasonlítása az adatbázisunkból származó
mezővel.
Az
egyezés
(nem
feltétlenül
lineáris)
eredményét
az
osszpontszam mezőben tároljuk el. Mivel a Field Tartalomkereses() és Osszehasonlitas() metódusa általános vonatkozása ezért – a túlzott komplexitás elkerülése és az objektum orientáltság figyelembe vételével – szükség van ennek az osztálynak a specializációjára is. Egy ilyen megvalósítást mutat be az Author osztály is, melynek feladata a szerző nevekre való összehasonlítás speciális szabályainak megvalósítása, az Oszehasonlitas() metódus felülírása révén. Az itt alkalmazott metódus a BME PA rendszeréből származik, illusztrálva ezzel a rendszer szabadon univerzalitását is.
61
12. Rendszertervezés Hasonló specializációt láthatunk az ISBN_ISSN osztályban, azonban itt a keresési módszerek különböznek az előzőekhez képest. A Beallitasok osztály tartalmazza az inicializálás főbb részeit, azaz a weboldalfüggő beállítások betöltését, és az egyes nyelvi sajátosságok miatt a karakterek kicserélésére szolgáló függvényt is.
12-2. ábra: A rendszer egyszerűsített, általános UML Class diagramja
62
13.A kereső és pontozó algoritmus
13. A KERESŐ ÉS PONTOZÓ ALGORITMUS 13.1.
A KERESÉS NEHÉZSÉGEI
Mint ahogyan már korábban említettem igen egyszerű és magától értetődő megoldásnak tűnhet, hogy a számunkra releváns mezőket egy az egyben egyesével végig keresem a publikációs weboldalon, ha mindegyik mező megtalálható egy az egyben akkor a siker biztos, egyezés van, az adatbázis bejegyzés validálható. A fenti elképzelés gyakorlatban nem valósítható meg, mert például: •
gyakran előfordulnak elgépelések mindkét oldalról, így az egy az egyben való keresés nem megoldható. Egy nagyon jó példa lehet, hogy a cikk absztraktja tipikusan több mint száz karaktert tartalmaz, azonban ha csak az utolsó pont is hiányozna, a felismerés a triviális módszer használatával hibát mutatna
•
számokra (pl. oldalszám, ISBN) nem lehet egyszerűen rákeresni, mert például az oldalszám lehet a telefonszám, ISBN része is. Tipikus hiba továbbá egyes formátumhoz kötött adatok nem a megfelelő megadási formátumban vannak letárolva, ilyennel sokszor találkozhatunk pl. az ISBN mezők esetében is
•
szövegre sem lehet rákeresni, mert lehet, hogy egy szöveg (pl. Abstract) előfordul többször (pl. szerző nevében, címben, az oldal témájában stb.), ekkor nem tudjuk eldönteni, hogy melyik a helyes megoldás
•
a szerző(k) neve sem egyértelmű, hiszen például tegyük fel a kérdést, hogy a Csurcsia Péter Zoltán személye megegyezik-e a P.Z. Csurcsia illetve Péter Z. Cs. megadással?
•
továbbá bár nem fő feladata a projektnek, de arra is választ kell adnunk, hogy hogyan lehet egyes csalásokat kivédeni. Bár az alapfeltételezünk természetesen az, hogy csak elgépelési hibák adódhatnak, de a rendszert a csalások elhárításá63
13.A kereső és pontozó algoritmus ra is fel kell készítenünk, egy egyszerű példa lehetne, hogy a cikk elérhetőségnek megadom az általam szerkesztett honlapot és azt állítom, hogy az egy IEEE cikk A kereső algoritmusok alkalmazásakor el kell gondolkodnunk tehát, hogy egyes mezőtípusoknál hogy kell az adatokat feldolgozni, illetve, hogy mennyire kell toleránsnak lennünk a feldolgozás során. Például egészen másképp kell értékelni az eltérést egy ISBN azonosító, egy szerzői név illetve egy rezümé hiánya esetében.
13.2.
A KERESÉSI METÓDUS
A következő részben feltételezzük, hogy nem túl gyakran (tipikusan évenként, kétévenként) illetve nem túl drasztikus mértékben változtatják, a publikációs weboldalak kimenti html/xml/xaml stb. elemeinek szerkezetét. Amennyiben a fenti feltételezésünk helytálló, lehetőség nyílik az adott oldalra jellemző paraméterek feljegyzése egy táblázatban (esetünkben Microsoft Excel kompatibilis CSV fájl), melyekben az adatok lokalizációjához szükséges konfigurációs beállítások (pl. szerző név-html tag páros) egy statikus táblázatból olvassuk ki, majd az alapján dolgozzuk fel az oldalt, mezőnként egyesével. A keresés a vizsgálandó publikáció XML fájljának átadásával és feldolgozásával indul. A továbbiakban nem teszek különbséget a publikációs alapadatokban és az idézettségi listában történő keresés illetve vizsgálat során, hiszen azoknál azonosan kell eljárni. Első lépésben megállapításra kerül, hogy az adott publikáció milyen típusú és milyen médiumban került publikálásra, milyen weboldalon lehet azt elérni (elsősorban preferált a DOI, másodsorban pedig a direkt URL cím). Ezután következik a megfelelő konfigurációs beállítások betöltése a publikáló médiumnak (pl. IEEE eXplore) megfelelő CSV fájl betöltése, valamint a megfelelő Field osztály példányok létrehozása. A tag- és szövegkeresés a rá utaló jellemzők pl. tag-nevek, szöveg címkét a weboldalbeli kezdeti szöveg pozíciójának és a vélhető hosszának meghatározásával kezdődik. A hossz pontosabban az adott mezőzáró karakter pozíciója egyfelől a megfelelő zárótag-ig tarthat, illetve amennyiben be van állítva egy fix hossz akkor a nyitótagtól számított hosszig tart, ezt az iterációt minden esetben a dokumentum vé64
13.A kereső és pontozó algoritmus géig ismételjük, melynek segítségével például a több szerzős, több intézményes egyezési eseteket kutathatjuk fel. Amennyiben egy mezőhöz több feloldást is tartalmaz a weblap, úgy megtalált mező értékeket egy tömbben helyezi el sorrend folytonosan. Természetesen lehetőség van annak is megadására, hogy egy HMTL tag pároson belül több fajta mezőt is megadjunk, például elválasztó karakterek segítségével vagy az egységen belüli sor számának megadásának segítségével. Ilyen esetre mutat példát az IEEE oldala, ahol egy HTML tag pároson belül találhatjuk meg a mű címét az első sorban, a következő sorban a szerzők nevét dupla nem törhető szóközzel illetve vesszővel elválasztva, a harmadik sorban pedig az intézet nevét. Hosszú szövegek esetén (tehát nem név, és oldalszám esetén) Levenshtein és similar text algoritmust is használok, a kedvezőbb eredményét figyelembe véve. A keresést két mező (saját adatbázisunk és a honlapról feldolgozott adatok) között a következőkben foglalható össze 1. a mezőket Levenshtein algoritmussal összehasonlítjuk, majd elosztjuk az így kapott eredményt a hosszabb mező hosszával (normalizálásként), ha az ebből származtatott egyezés mértéke legalább 80%-os (vagy külön, a CSV konfigurációs táblázatban beállított érték szerinti) a mezők között, akkor a mező egyezés értékét elfogadjuk 2. ha az 1. pontban foglaltak szerint nincs egyezés, akkor az adatbázis és a honlap szövegét szavakra felbontjuk és a rövidebb tartalmú szöveget megpróbáljuk sorrendhelyesen ráilleszteni (mappelni) a hosszabb tartalmú szövegre, ebben az esetben rövidebb szöveg szavankénti az 1. pontban megállapított algoritmus szerinti egyezési találatok átlaga adja a mező egyezés pontszámát 3. amennyiben a kettes szerinti egyezési találat is a konfidencia szint alatt marad, úgy a tipikus elképelési hibák (szomszédos betűk és számok felcserélése) után végig futtatjuk az 1. illetve 2. pontot (amennyiben nem volt csak a maximális egyezés elfogadott beállítva)
65
13.A kereső és pontozó algoritmus
Tagkeresés(szöveg,kereső struktúra)
i=0
Van „hasonló” i. nyitótag?
Igen
Kezdőpozició nyitótagtól
Van „hasonló” zárótag?
Végpozició soremelésig
igen
Végpozició zárótagik
Eredmény[i] megfelelő sorokból
Végpozició ==szöveg vége?
i++
Vissza eredmény tömb
13-1. ábra: Tag kereső egyszerűsített algoritmusa
13.2.1.
SZÖVEG ÉS SZÁM KERESÉSE
A szöveges keresés lényegében az előbb elmondottak kiegészítése a feldolgozó függvény bemenetire vonatkozóan. A HTML (XML) tag-ek közé zárt szöveges információt kívánjuk összehasonlítani az XML alapú fájlban megkapott tudományos repozitóriumunkból származó adatokkal. A fenti adatokat a feldolgozás során először egy „irreverzibilis” szöveg átalakításnak vetem alá, azaz: •
ékezet mentesítem a mezőket, pontosabban lecserélem az ékezetes karaktereket ékezet nélküli karakterekre
66
13.A kereső és pontozó algoritmus •
speciális írásjeleket eltüntetem
•
a weboldalról származó szövegben eltüntetem a felesleges (dupla, tripla) szóközöket és írásjeleket
•
mindkét oldali mezők tartalmából eltüntetem az esetleges véletlenül megmaradt HTML formázásokat (ez empirikus megfigyeléseim szerint sajnos mind a két oldalon előfordulhatnak)
•
tipikusan számadatok esetén (pl. oldalszámok) illetve ISBN, ISSN esetén a bennük foglalt írásjeleket törlöm (pl. 1234-567x ISBN mezőből 1234567x lesz) A fenti eljárás minden típus esetében végzet viszem (függetlenül annak tartalmára). További, speciális kiterjesztési lehetőség lehetne:
•
ország és város neveinek feldolgozása: egy olyan adatbázist (táblát) létrehozni, ahol az adott ország illetve város összes lehetséges előfordulása meg van adva, majd mind a két oldalról jövő mezőket lecserélni egy egységesre, tartalomra
•
speciális matematikai, fizikai jelöléseket lecserélni egy „szabványos” ASCII karakterekből álló jelekre
•
(számunkra) speciális karaktereket tartalmazó nevek lecserélési ASCII karakterekre
•
stb. Mint fentebb láthatjuk, rengeteg kivétel van, melyek meglehetősen komple-
xek. Ennélfogva az ezekre nyújtható megoldás nem képezi a diplomamunkám részét, de iránymutatást ad a későbbi lehetséges továbbfejlesztéshez.
13.2.2.
SZERZŐ KERESÉS
A szerzői nevek keresése további feladatokat von maga után. Egyrészt fontos lehet az, hogy a vezetéknevet, keresztnevet (illetve előtagot) milyen sorrendben írjuk le a cikkben, hogyan kerül tárolásra a repozitóriumunkban illetve a weboldalra.
67
13.A kereső és pontozó algoritmus Másrészt fontos lehet az is, hogy a fenti esetekben a nevek hogyan követik egymást (tipikusan az első szerző domináns szerepet játszik egy publikációban). A szerzői nevek összehasonlításra a BME PA (MTMT) kérésének megfelelően az általuk készített összehasonlító programot használtam fel (lásd az UML Class ábrát). A név összehasonlító szkript szintén egy speciális ékezet mentesítéssel kezdődik, majd egy Levenshtein algoritmus segítségével ítéletet mond a két név különbségére, amely függvény az eltérés fokával tér vissza. Az algoritmus nagy hátránya, hogy megengedő a vezetéknév és keresztnév felcserélésével illetve a rövidítésekkel szemben, pl. a Csurcsia Péter, és a Csermely Péter rövidítései megegyeznek (Cs. Péter). Természetesen ez a probléma mindaddig fenn fog állni, míg nem állnak rendelkezésre teljes nevek.
13.3.
PONTOZÁSI METÓDUS
A pontozás során minden egyes repozitóriumából származó mezőhöz, publikáció típusonként és weboldalanként pontszámot lehet rendelni, mely pontszámok együttes összege alapján állapítható meg a publikációk egyezése. E rendszer felhasználása segítségével lehetőség van a fontosabb információ tartalmú mezőkre (pl. név, cím) nagyobb pontszámot adni, míg a kevésbé fontos súlyú mezőkre kevesebb pontot adni. A pontozó algoritmus működésének lényege a következőkben foglalható öszsze: 1. ha van legalább 80%-os (vagy beállított érték szerinti) egyezési találat a mezők között akkor pontszám az egyezési érték és a mezőre adható pontszám szorzata, máskülönben 2. a hosszabb tartalmú szövegre rámappeljük a rövidebb szöveget, ebben az esetben rövidebb szöveg szavankénti egyezési találatok átlaga adja a pontszámot
68
13.A kereső és pontozó algoritmus 3. amennyiben egy mezőtípushoz (pl. szerző) több ellem is tartozik, akkor a mezőnként megszerezhető pontszám osztódik az adott típusú mező darabszámával 4. amennyiben egy a repozitóriumából származó mező nem lett megtalálva, úgy arra a mező egyezési értékére nulla pont számítódik fel
13.4.
VALIDÁCIÓ
A verifikációs (ellenőrzési) eljárás végén következik a validációs eljárás, azaz ítélet „hirdetés” a két rekord egyezésére. A fentieket kiegészítve az összehasonlítás néhány speciális körülményeit a következő, a CSV konfigurációban beállítható lehetőséggel tudjuk kibővíteni: •
be lehet állítani, hogy a forrás mezőkben szereplő adatok számossága egyezzen meg az internetes weboldalon felismerhető mezők számosságával (pl. szerző nevek száma egyezzék meg), amennyiben az egyezés nem helytálló úgy el kell utasítani az rekord hitelesítését
•
be lehet állítani, hogy a forrás mezőkben szereplő adatok sorrendisége egyezzen meg az webes sorrenddel, amennyiben a sorrend nem helytálló úgy nem elfogadható a rekord
Egy rekord akkor és csak akkor validálható, ha 1. nem áll fenn önmagában kizáró egyezési probléma, lásd fenti két lehetőség 2. a rekord típusra jellemző, de az összes mezőre vonatkoztatott pontszámok közül legalább a beállított minimális elfogadási küszöbszintet elérte (alapértelmezettként 80%) Amennyiben a verifikációs illetve validációs eljárás sikeretlen volt, úgy a rekord kézzel való hitelesítése, vizsgálata szükséges, ami tipikusan a könyvtárosi munkakörébe tartozik. Megjegyzem továbbá, hogy a duplum keresés is hasonlóképpen zajlik, de viszont ebben az esetben kívánatos, hogy a konfidencia szintet úgy változtassuk, hogy kisebb értékű megegyezést is detektálni tudjon a rendszer.
69
13.A kereső és pontozó algoritmus
13.5. 13.5.1.
PÉLDA A VALIDÁCIÓRA „A” ESET
Ebben az esetben egy valós BME PA bejegyzést teszteltem le, melyhez segítségségül hívtam egy grafikus web felület. A bejegyzés egy IEEE konferencia cikkre mutat, melyet DOI segítségével oldottam fel. Az összehasonlítás során a zöld színű mezők jelzik a száz százalékos egyezést, a sárga mezők pedig a konfidencia intervallumon belülit, a piros a konfidencia intervallumon kívüli egyezést. A pontszámok a „Pontozási metódus”-ban taglaltaknak megfelelően lettek kialakítva. Látható, hogy habár egyik mező nem felelt meg a kritériumoknak, összességében azonban az megszerzett összes pontszám az előírt pontszámon felül volt, így a publikáció validálható. Ebben a tesztelési szekvenciában nem lett beállítva, hogy a szerzők nevének pontosan kell egyeznie (lásd kritérium mező). A feldolgozás grafikus eredményét a következő ábra mutatja be.
13-2. ábra: “A” példa rekord verifikáció eredményének megjelenítése grafikus felületen
70
13.A kereső és pontozó algoritmus
13.5.2.
„B” ESET
Ebben az esetben is ugyan arról a publikáció típusról van szó, azonban itt egy kis csalást követtem el, a professzorom nevét kihagytam az adatbázisba való beíráskor, és elküldtem a bejegyzést a programom számára hitelesítés céljából. Mivel az alapértelmezett IEEE statikus formátum táblázatban az lett beállítva, hogy a kötelező a szerzők darab számának egyezése, ezért ennek megfelelően a feldolgozás el lett utasítva.
13-3. ábra: “B” példa rekord verifikáció eredményének megjelenítése grafikus felületen
13.5.3.
„C” ESET
Ebben az esetben a DOI cím az adatbázisban rosszul szerepel, és mivel kritérium mező ezért a validációs eljárás automatikusan sikertelen.
13-4. ábra:”C” példa rekord verifikáció eredményének megjelenítése grafikus felületen
71
14.A konfigurációs formátum táblázat
14. A KONFIGURÁCIÓS FORMÁTUM TÁBLÁZAT Mint ahogyan már többször is említettem, a megfelelő konfigurációs beállítások betöltése a publikáló médiumnak megfelelő CSV fájl betöltésével kezdődik (miután rendelkezésre áll ez az adat). A CSV fájl megfelelő paraméterei betöltődése után a paraméterek feldolgozásra kerülnek, melye a megfelelő Field osztály példányok meghívásra követ. A következőkben a főbb táblázati paramétereket mutatom be, lássuk a mezőket sorrend helyesen, első három sorban: •
Lekérdezési időköz: meghatározható segítségével milliszekundumban, hogy mennyi időt kell várni az adott weboldal esetén a két lekérdezés között. Alapértelmezett érték nulla, ami azt jelenti, hogy nem kell várni a két idő között, maximális érték pedig 50 000 ms (jelenleg).
•
Eltérő böngésző emuláció: igaz (1)/hamis(0) típusú mező, mely segítségével azt lehet beállítani, hogy egyes lekérdezések esetén véletlenszerűen válassza ki az emulálni kívánt böngésző típusát. Tapasztalataim szerint ez nagyban segít a feldolgozásban egyes „jól védett” oldalak esetén (mint pl. IEEE)
•
Önteszt publikáció webes címe, XML referencia, Pontszám: opcionálisan megadható, hogy önteszt esetén mely (stabil tartalmú) internetes weboldalon található publikációt hasonlítsuk össze a repozitóriumunkból származó (szerveren fájlként letárolt) XML-el, valamint a sikeres feldolgozás hány pontot szerzett a validációs eljárás során. A negyedik sortól kezdve a táblázat oszlopokra oszlik, melyek jelentése a
következő (sorrend helyesen): •
név: a feldolgozandó XML elem pontos neve, mint pl. authors.name vagy authors.institutes.intitute.name 72
14.A konfigurációs formátum táblázat •
kezdőtípus: felsorolás típus, amely megadja, hogy az első, mezőhöz tartozó karakter milyen típusú kell, hogy legyen. felsorolás értékei lehetnek: betű, szám, vegyes
•
végtípus: felsorolás típus, amely megadja, hogy az utolsó, mezőhöz tartozó karakter milyen típusú kell, hogy legyen. A felsorolás értékei megegyeznek a kezdőtípuséval
•
min elvárt hossz: megadja, hogy az adott mezőhöz tartozólag mekkora a minimálisan megengedhető hossz (üresen hagyott mező tetszőleges méretet jelent), ha ez alatti a megtalált mező mérete, akkor nem kerül feldolgozásra
•
max elvárt hossz: megadja, hogy az adott mezőhöz tartozólag mekkora a maximálisan megengedhető hossz (üresen hagyott mező tetszőleges méretet jelent), ha e fölötti a megtalált mező mérete, akkor maximum csak a beírt számú (amenynyiben az nem üres) hosszig tart a feldolgozott mező tartalma
•
több soros: igaz(1) / hamis (0) típusú mező, amennyiben 1 (igaz) van beállítva akkor a tag keresési algoritmust több sorra módosítom, a függvény visszatérési értéke egy vektorhalmaz lesz (lásd következő elem)
•
hányadik sor: amennyiben több soros a feldolgozás, meg lehet adni, hogy a keresendő mezőt az adott tag-en/szövegen belül hányadik sorban lehet megtalálni
•
több szavas: igaz (1) / hamis (0) típusú mező, amennyiben 1 (igaz) van beállítva akkor a megtalált mezőt a következő sorban ismertetett érték szerint bontja fel, ebben az esetben a függvény visszatérési értéke úgyszintén vektor halmaz
•
elválasztó karakterek: amennyiben több szavas keresés hajtunk végre szükséges megadni az elválasztó karaktereket (lásd minta táblázat)
•
súly faktor: egész vagy tizedes szám, amely megadja, hogy a feldolgozás során a mezőnek mennyi maximális pontszáma (száz százalékos egyezés esetén). A mezők pontszámítását részletesebben a „Pontozási metódus” alfejezetben ismertettem.
•
kritérium mező: igaz (1) / hamis (0) típusú mező, amely megadja, hogy az adott mezőnek feltétlenül meg kell egyeznie, amennyiben igaz értékre lett beállítva és nem egyezik meg a két (vagy több mező tartalma) száz százalékosan akkor a validáció sikertelen
•
darab szám egyezés: igaz (1) / hamis (0) típusú mező, amely megadja, hogy az adott típusú mezőből, mint a repozitóriumi, mint a weboldalon egyforma darab73
14.A konfigurációs formátum táblázat számnak kell lennie (pl. szerző számok), amennyiben ez az opció be lett állítva és nem egyezik a darabszám úgy a validáció sikertelen •
sorrend helyesség: igaz (1) / hamis (0) típusú mező, amely megadja, hogy az adott típusú mezőből a feldolgozás során, mind a két oldalon ugyan olyan sorrendben kell, hogy kövesség egymást (pl. szerző nevek megadása), amennyiben ez az opció be lett állítva, de a sorrendek nem stimmelnek úgy a validáció sikertelen
•
nyitó tag: meg lehet adni, hogy az adott mezőt melyik nyitó tag utána lehet megtalálni, amennyiben beágyazott tag-ról van szó, akkor lehetőség van megadni több tag szintet is, az egyes tag-eket dupla fel kiállító jellel egymás után elválasztva. A záró tag illetve záró pozíció megállapítása a fent beállított paraméterek segítségével történik (automatikusan)
•
kereső szavak: meg lehet adni, hogy az adott mezőt melyik szó, szavak után kell keresni (szavakat egymás követő cellákba kell leírni). A záró pozíció megállapítása a fent beállított paraméterek segítségével automatikusan történik Fontos megjegyzések a táblázat használata során:
•
a keresési paramétereket az ötödik sortól, folytonosan kell feltölteni
•
a táblázatban alkalmazott szöveges mezők (pl. „lekérdezési időköz”) tetszőlegesen átírható, azonban a sor és oszlopszám kötött (azaz a táblázat e részei nem kerülnek feldolgozásra)
•
amennyiben egy szöveges típusú oszlop nem tartalmaz értéket „nincs” szöveggel vagy mínuszjellel kell jelezni
14-1. ábra: Minta egy Excel-el segített IEEE formátum táblázat kitöltésére
74
15.Az Információ csere és az XML formátum
15. AZ INFORMÁCIÓ CSERE ÉS AZ XML FORMÁTUM Az előzőekben tárgyalt lehetséges formátumok folytatásaképpen a következő fejezetben a saját tervezésű, lehetséges információ cserélési formátumot fogom bemutatni. Az információ csere alatt elsősorban az adatbázisok közötti információ cserét, illetve a hitelesítő programom és az adatbázis közötti interfészt kell érteni. A fentiek szerint tehát azt kell megtervezni, hogyan célszerű sztenderdizált módon az adatbázisban rejlő effektív információ tartalmat leképezni egy univerzális interfészre, úgy, hogy lehetőleg az adatintegritás és információ tartalom ne sérüljön meg. A fentiek szerint nagyon fontos kérdés, hogy az adatokat milyen formátumban visszük át a rendszerek között. Erre számos lehetőség adódik pl. a hagyományos elektronikus bibliográfiai formátumoktól (pl. RIS) a JSON-on keresztül az XMLig bezárólag, több tucat szóba jöhető formátum létezik. Természetesen, mint ahogyan már ismertettem, az adatcserét egy XML formátummal támogatott rendszerrel képzeljük el, mivel többek között: •
attribútumok illetve tag-ek száma nem korlátozott
•
az egyes attribútumok jelentését mi magunk határozhatjuk meg
•
schema fájl segítségével alapvető megkötéseket tehetünk az egyes attribútumokra (pl. oldalszám típusú mezőben csak számok szerepelhetnek)
•
könnyen olvasható, értelmezhető és feldolgozható formátum Ezen érvek miatt biztos megoldásnak ígérkezik az XML, de ugyan akkor fon-
tos azt is megjegyezni, hogy jelentős hátrányba a terjengőség, de alkalmazási területünkből adódóan ez nem számottevő probléma (pl. egy rekord hitelesítés idejének csupán egy-két százalékát adja a formátum átvitelére szánt futtatási idő (empirikus megfigyeléseim alapján)).
75
15.Az Információ csere és az XML formátum Az így megtervezendő és implementálandó projekt alapvetően négy részből áll: •
megtervezni az XML sablont, azaz konkretizálni, hogy milyen mezőket szeretnénk átvinni
•
az egyes XML mezőkre helyesírási és formázási szabályokat definiálni, azaz az XSD séma fájl illesztése az XML sablonhoz
•
adatbázisból való exportálás megtervezése
•
adatbázisba történő importálás megtervezése A következőkben bemutatom az adatexportálást valamint az általunk elkép-
zelt XML adat traszport formátumot, XML áganként egy minta XML fájl segítségével. Megjegyzem, hogy a teljesen korrekt tárgyalási mód részletesen, például az XSD sémafájl párhuzamos bemutatásával képzelhető el, azonban terjedelmi okok miatt ez nem kivitelezhető.
15.1.
ADATEXPORTÁLÁS
Az adatbázishoz való illesztés igen sok problémát vont maga után, ami a nem megfelelő minőségű AD-HOC tervezéséből adódik. Ennek köszönhetően az univerzális adatbázis illesztés meghiúsul, hiszen hiányzik belőle a gondos tervezés, a jól strukturáltság és az önleírás. A fejlesztés és az illesztés során tipikus problémák voltak például: •
az egyes tábla elnevezések sokszor nem beszédesek, az elnevezési konvenciók is problematikusak (pl. tbldoc_author és tbldocauthor tábla nevek hasonlósága)
•
az egyes attribútumok megnevezése sem triviális, pl. hozzávetőlegesen azonos arányban szerepelnek az egyes mezők MezőNévID, MezőnévID, MezőNévId formátumban, ami további problémákat vet fel (valóban igaz, hogy az SQL alapvetően case insensitive, de a PHP kód illetve a benne tárolt adatok elérése viszont már case sensitive)
•
hasonló típusú probléma a mezőnevek elnevezése, pl. sok esetben találkozhatunk az ISBN mezővel, de van ugyan olyan jelentésű ISBNNumber mező is (típusonként eltérő táblából kerülnek feldolgozásra az adatok) 76
15.Az Információ csere és az XML formátum •
egyes esetekben, az adatbázisban felesleges redundanciák fordulnak elő, az adatbázis normál foka sem mindig megfelelő és az ismert adatbázis anomáliák is előfordultak, ilyen például a szerző intézetének elérése, a tbldoc_author táblában csak bizonyos esetekben található a szerzőnév mellett az intézet azonosítója (mellyel az intézet adatait képezhetjük el), azonban a tbldocauthor táblában ennél sokkal nagyobb számban fordulnak elő az intézetre vonatkozó bejegyzések
•
az egyes mezőkben sokszor nem azok a bejegyzések szerepelnek és nem is abban a formátumban, amiben elvárt lenne pl. Comment mezőben sokszor találkoztam URL illetve DOI címekkel, előfordult olyan eset is, amikor ISBN bejegyzés is szerepelt ugyan itt
•
egy másik tipikus példa, hogy az MTA köztestületi azonosítót tartalmazó mezőben (kozid) nálam is szerepelt bejegyzés (BME-CWA0FQ tartalommal), ami ugyan részemről nagyon hízelgő, de ez az állítás valótlan. Legjobb tudomásom szerint ezt a mezőt kiegészítésként arra is használják, hogy aki nem „rendesen regisztrált” szerző, azonosítsák vele. Azonban véleményem szerint ez a mező alkalmatlan erre (adatexportálásnál anomáliákat okozhat)
15.1.1.
AZ EXPORTÁLÓ PHP KÓD FELÉPÍTÉSE
Az adatexportálásért felelős PHP kód alapvetően három részre bontható fel (sorrendhelyesen): •
Adatbázis hozzáférésre (rendszerfüggő)
•
Rendszerfüggő adatok átvitele rendszer független adatokká
•
Rendszer független adatok XML-be való írása A PHP szkript tehát rendszerfüggő adatbázis hozzáférési kódokkal kezdődik.
Itt lekérdezésre kerülnek a publikáció típusától független alapinformációk, mint pl. a mű címe, megjelenés éve, nyelve, típusa, besorolása stb. Ezek után kezdődik a típusonkénti lekérdezés, ahol az adatbázis inkonzisztenciákkal már számolni kell. A tervezés során igyekeztem úgy megírni a lekérdezéseket, hogy a lehető legtöbb, minden típusban előforduló azonos nevű elemeket vegyem alapul, ezek egy meghatározott tömb változóban kerülnek tárolásra (pl. $publikacio_alapadatok, 77
15.Az Információ csere és az XML formátum $journal_alapadatok). A további lekérdezések a konkrét publikáció típustól függnek (pl. más a lekérdezések fajtákat kell lefutatni journal paper és bookchapter esetében). A kód középső logikai részében az egyes, többnyire azonos nevű, de eltérő lekérdezés módú változókból a releváns adatokat áttöltöm az XML fát leíró PHP (tömb) változókba. A hozzávetőleges 15 ismert durva inkonzisztenciát egyesével kezelem le ebben a fázisban, ilyenek például az ISBN és az ISBNNummer mezőnevek. A kód utolsó részében pedig a konkrét XML fa kerül kiírásra. Az olyan elemek, melyek nem tartalmaznak értéket, természetesen nem kerülnek kiírásra (nincsenek üres értéket tartalmazó tag-ek). A szkriptem csak a lehető legegyszerűbb adatbázis helyes formátumra történő átalakítási esetekkel foglalkozik (pl. ISSN szám 1234-789x formára történő átalakítás). Az inkonzisztens mezőhasználatból származó hibák megoldása nem a diplomaterv feladata, azok az adatbázis adminisztrátorok feladatait képezik. Az így felépített és kellőképpen kikommentezett PHP szkript előnye, hogy gyorsan új adatbázishoz illeszthető, hiszen a három rész közül csak az első részt kell átírni. Egy a programom által készített a BME PA-ból származó példák mutat a következő lista.
15.1.2.
AZ EXPORTÁLÁS TESZTELÉSE
Az adatexportálás sikerességének tesztelése fontos, hiszen az csak így biztosítható az adatintegritás és az információ tartalom megőrzése. A tesztelésre a következő főbb módszerek lehetségesek: 1. adatexportálás kimenetének ellenőrzése XML sémafájl (XSD) segítségével 2. többfajta módszerrel történő exportálás végeredmények összehasonlítása 3. adatexportálás kimenetelének visszacsatolása az XML alapú adatimportálásra, majd a különbségek megvizsgálása 4. kimeneti XML formátum kézi módszerrel történő összehasonlítása az adatbázisban tárolt adatokkal 78
15.Az Információ csere és az XML formátum A fenti módszerek közül a leghatásosabb a harmadikként ismertetett adatexportálás visszacsatolása a bemenetre. Eredeti terveink szerint ezzel a módszerrel került volna tesztelésre a rendszer, azonban rajtam kívül álló okok miatt ez nem valósulhatott meg. Az ellenőrzést az első és negyedik módszerrel kombináltan végeztem, azaz a kimeneti állományokat először egy jól formázottság és tartalmi vizsgálatnak vetettem alá az Stylus Studio XML Designer segítségével, majd ezt követően kézzel öszszehasonlítottam az adatbázissal.
15.1.3.
EGY MINTA XML
A következőben bemutatok egy a BME PA-ból „véletlenszerűen” kiválasztott publikációs bejegyzés programom által elkészített XML fájlját illetve az XSD validáció eredményét.
15-1. ábra: Egy BME PA-ból származó XML formátumú rekord XSD validálása
79
15.Az Információ csere és az XML formátum 15-1. lista: Minta egy BME PA-ból származó XML formátumú rekordra
<descriptions> BME PA 3076 <source> 3076 <edited> 2009.01.10. 16:21 kollar-teszt Steele GL <share>0.333333333 Porpiglia PJ <share>0.333333333 Chandler JM <share>0.333333333 Efficacy of Kih-485 on Texas Panicum (panicum Texanum) And Selected Broadleaf Weeds in Corn 19 4 0890-037x yes 2005 <entry> <page_start>866 <page_end>869 angol 80
15.Az Információ csere és az XML formátum folyóiratcikk <subtype>szakcikk tudományos WEED TECHNOLOGY <shorttitle>WEED TECHNOL Texas A&M Univ, Dept Soil & Crop Sci, College Stn, TX 77843 USA. KI Chem USA Inc, Res & Dev, White Plains, NY 10606 USA. Texas A&M Univ, Dept Soil & Crop Sci, College Stn, TX 77843 USA. ATRAZINE ZEA-MAYS S-METOLACHLOR
15.2.
AZ ADATIMPORT
A fejezet bevezetőjében ismertetett XML formátummal támogatott adatcserélés teszteléséhez az importálás és tesztelés funkciót kell megvalósítani, melyet eredeti terveink szerint közös témavezetőnkkel együtt működve, diplomatervező társam Szluka Péter János végezte volna el, azonban rajtunk kívül álló okok miatt ez nem valósulhatott meg. Az import fejlesztése az MTMT-ben készül, elkészülési határidejét nem ismerem. Addig az export is csak „elkészült” állapotban van, hiszen az alapos és megbízhatóbb teszteléshez szükség van mind a két funkció egyidejű elérhetőségére.
81
15.Az Információ csere és az XML formátum
15.3. 15.3.1.
AZ XML DOKUMENTUM AZ ROOT GYÖKÉRELEM
Az XML (és az XSD) gyökérelemben megtalálhatóak az éppen aktuálisan használt verzió illetve karakterkódolási információk. Az XML dokumentumok esetében a használni kívánt névterek és a saját készítésű séma fájl (schema.xsd). Minden egyes lekérdezéshez tartozó dokumentum kötelezően ezzel kell, hogy kezdődjön. 15-2. lista:részlet az XSD fájlból
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> 15-3. lista:részlet egy XML fájlból
A record néven jelölt gyökérelemben szereplő tag-ek sorrendje kötött, míg a benne szereplő altag-ek sorrendje tetszőlegesen módosítható. A gyökérelem kivételével a jól formázottság szabályait figyelembe véve tetszőleges elem hagyható el. A gyökérelem sorrendje azért kötött, mert az XSD a kötetlen elemszámú felsorolás mellé (pl. egy publikációnak több szerzője is lehet) kötelező sorrendet ír elő (xs:sequence), így az ágon belüli mezők sorrendje is kötött [43][44]. Azonban az ez alatti szinteken némi gyakorlati megfontolással és praktikákkal elérhető, hogy az elemek sorrendje kötetlen legyen (xs:all), azonban ennek a módszernek a hátránya az, hogy legfeljebb egyetlen egy mező lehet típusonként.
82
15.Az Információ csere és az XML formátum
15-2. ábra: XSD sémafájl gyökérszerkezete
A fabeli elemek angol tag-ekkel lettek reprezentálva, bízva abban, hogy a projektbe esetleg külföldi partnerek is becsatlakoznak. Az egyes szinteken az azonos típushoz tartozó gyerek nevek megegyeznek (pl. identifier). Az egyes ágakban lévő mezők általában azonos tartalommal illetve jelentéssel bírnak, ezért nem kerülnek ismertetésre minden ágban a közös elemek. Az egyes, összetett, ismétlődő és rövidített elemeket (ágakat) félkövér, dőlt betűtípussal jelölöm a listákban.
15.3.2.
AZ DESCRIPTIONS ÁG
A descriptions ágban az adatbázis egyes publikációhoz rendelt meta adatait érhetjük el, mint például melyik adatbázisból származik a rekord (filesource) és az ottani adatbázisban elfoglalt azonosító (identifier). Fontos lehet továbbá, hogy ki a cikk tulajdonosa (owner), ki kezeli, mikor és ki módosította (edited, time_stamp tag-ek), illetve a hitelesítésre vonatkozó információkat is megtalálhatunk benne (authenticable, authenticated). Természetesen sem az ág, sem az itt lévő mezők kitöltése nem kötelező, hiszen pl. erre az ágra a hitelesítésre „beküldött” publikáció verifikációs eljárása során nincs is szükség. Az itt szereplő nyelvi mezőkben (language) a többnyelvű verziókban is rendelkezésre álló bejegyzések nyelvi megadására van lehetőség, pl. ha egy konferencia cikk adatai angol és magyar nyelven is rendelkezésre állnak, célszerű mindkét nyelven leképezni az adatokat. Nézzünk is egy az XSD sémának is megfelelő mintát, melynek segítségével a megfelelő elemek tartalmi értelmezése triviálissá válik. 83
15.Az Információ csere és az XML formátum 15-4. lista: Minta az XML fájl description ágára
<descriptions> adatforrás kanonikus neve publikáció azonosítója a forrásnál adatbázis output aktuális nyelve <suffix>Előtag pl. Dr. Tulajdonos Neve Keresztneve(k) Vezetéknév 12345 login név 2345532123 <source> Eredeti adatforrás neve Eredeti adatforrás azonosítója URL az eredeti forrásban 2009.12.30. 12:30 <edited> 2009.12.30. 12:30 létrehozó login név yes Adatbázis neve Azonosító az adatbázisban 2010.01.22.
15.3.3.
AZ AUTHORS ÁG
Az authors ágban a szerzők (author) sorrendhelyes felsorolása található meg. Célszerű, hogy külön kezeljük a szerző publikációjában használt nevét (name), valamint az azonosítója (identifier) segítségével az adatbázisból előhívható neveit (suffix, name_first, name_last). 84
15.Az Információ csere és az XML formátum Amennyiben az egyes szerzők rendelkeznek az MTA köztestületi azonosítójával (kozid) akkor természetesen ennek a megadására is van lehetőség (mivel ez egy magyar sajátosság, így a későbbi esetleges nemzetközi kooperációra is tekintettel, ez a mező nem került lefordításra). Az egyes szerzőkhöz természetesen az intézetük, tanszékük, cégük stb. is hozzárendelhetők (institute), egy személyhez természetesen több is tartozhat. Célszerű ezt úgy felhasználni, hogy amennyiben rendelkezésre áll információ, a publikáció megírásakor érvényes állapot legyen feltüntetve, nem pedig az éppen aktuális tanszék. A szerző megadási lehetőségekre a következő példa adott. 15-5. lista: Minta az XML fájl authors ágára
1. szerző neve keresztneve(k) vezetéknév <suffix>Előtag pl. Dr. szerzőazonosító a filesource-ban 12345 ide személyhez rendelt adatbázis komment jön <share>0,5 1. szerző intézetének a neve intézet azonosító pl. 42 1. szerző intézetének a neve intézet azonosító pl. 42 2. szerző neve szerzőazonosító a filesource-ban <share>0,5 2. szerző intézetének a neve intézet azonosító pl. 42
85
15.Az Információ csere és az XML formátum 15.3.4.
A PUBLICATION ÁG
Ebben az ágban a tudományos művünk konkrét adatait van lehetőségünk rögzíteni, mint például megjelenésére és értékelésére vonatkozó információkat. Ilyen adatok tipikusan például a mű címe(i) (title, subtitle), a fejezet (volume) és füzet száma (issue), a mű egyéni azonosítója (identifier), a terjedelmi adatok (lenght), a mű nyelve (language), rezümé (abtract), elérhetőségek (url, url_public, doi), kulcsszavak (keywords), egy folyóirat, konferencia cikk címe (title, shorttitle), megjelenés helye (location_city, location_country), ideje (date, date_to, date_from), megjelenítő
szervezet
neve
(publisher),
tudományos
mű
lektoráltsága
(peerreviewed), az egyes ISBN és ISSN azonosítók (isbn, issn). Itt fontos kiemelni, hogy sokszor az ISSN számok eltérhetnek kiadásonként, típusonként (issn, issn_printed, issn_electronic), szerzőnként (author). Amennyiben rendelkezésre állnak ezek az információk, célszerű értelemszerűen kitölteni a mezőket (azonban mint a többi esetben, itt sem kötelező). Az egyes ISSN és ISBN azonosítók megadásának módja csak [25][26] szerint érvényes. Végezetül megtalálhatóak az ágban az egyes típus és besorolási adatok (classifications), impakt faktor (impactfactor) is. A besorolási adatokkal azonban elővigyázatosnak kell lennünk, hiszen egy tudományos – impakt fakorral rendelkező – folyóiratban szerepelhet ismeretterjesztő cikk is, ami már nem számít tudományosnak. A fenti probléma elkerülésére lehetőség van megadni a benn foglaló mű adatait is (container ág, lásd külön listában). Ez természetesen például könyv, szabadalom esetén nem értelmezhető. A lehetséges, megengedhető típusokat (type) altípusokat (subtype) illetve besorolásokat (character) az MTMT dokumentációjában diplomaterv írásának időpontjában találhatóak szerint lettek megállapítva [22], bekódolva az XSD 1.0.-ás XML sablon fájlba. Lehetőség van továbbá megadni a mű hivatkozásait is (reference), illetve rendelkezik szabadon felhasználható mezőkkel is (free_field) A használatot a következő kód illusztrálja, külön kiemelve az egyes besorolási, terjedelem megadási módszereket. 86
15.Az Információ csere és az XML formátum 15-6. lista: Minta az XML fájl publication ágára Ez a cikk címe <subtitle>Ez a cikk alcíme 11 1 cikkazonosító (folyóirat, konferencia) 1-23-456789-0 1234-561x 1234-5679 1234-5699 Budapest Magyarország kiadó 2010.01.12. 2010.01.12. 2010.01.13. true 1.234 1908 Hungarian Rezümé a teljes cikk URL-je yes A teljes cikk URL-je a kiadónál <doi>doi-string Megjegyzések irodalom a irodalom b irodalom c kulcsszavak kulcsszavak első szabad mező második szabad mező n-edik szabad mező
87
15.Az Információ csere és az XML formátum 15-7 lista:Minta az XML fájl classifications ágára
book <subtype>book scientific
15-8. lista:Minta az XML fájl container ágára
A mű teljes neve <shorttitle>A mű rövid neve a journal webcíme <editors> <editor>A szerkesztő <editor>B szerkesztő book <subtype>book scientific
15-9. lista:Minta az XML fájl length ágára
<entry> <page_start>12 <page_end>15 <page_number>4 1.1 <entry> <page_start>22 <page_end>24 <page_number>3 1.3
88
15.Az Információ csere és az XML formátum 15.3.5.
A CITATIONS ÁG
A citations részben az egyes idézettségek (citation) adatait tudjuk megjeleníteni, mint például a cikk neve(i) (title, subtitle), a szerzőkre vonatkozó információkat (authors), besorolások (classsifications), hivatkozás faját (independent). Továbbá lehetőség van itt is természetesen a referencia lista (references) illetve a kereszthivatkozások (crosslinks) megadására is. Használatának elsajátítását a következő példa szemléltetni. 15-10. lista: Minta az XML fájl citations ágára
cikkazonosító Ez a cikk címe <subtitle>Ez az cikk alcíme Kollár szerzőazonosító 12345 Hungarian Rezümé a teljescikk URL-je <doi>doi-string Megjegyzések cited work 2009 yes yes yes
89
16.A Tesztelés
16.
A TESZTELÉS
16.1.
A TESZTELÉS
Ahogy a mondás is tartja, nincs tökéletes, hibátlan program, csak rosszul tesztelt. A megtervezett és implementált rendszer sikerességének tesztelése nagyon fontos, hiszen az csak így biztosítható a megfelelő, megbízható működés, az adatintegritás és az információ tartalom megőrzése. Egy szoftver rendszer tesztelésénél alapvetően két fő célt, tesztet említhetünk meg [35]: •
validációs tesztelés: a szoftverfejlesztés végső, a fejlesztők és megrendelő számára tartott tesztelés annak demonstrálása, hogy a szoftver maradéktalanul teljesíti a követelményeket és hibátlanul fut. Sajnos ez az estünkben még igen meszsze áll, hiszen maga az MTMT rendszere is fejlesztés alatt áll
•
hibatesztelés: a rendszerben lévő hibák keresése, ami vagy hibás viselkedésben vagy specifikáció nem teljesítésben nyilvánul meg.
16.2.
A RENDSZER TESZTELHETŐSÉGE
Az evolúciós fejlesztés, integráció és használat esetén (mint a diplomatervem is) a rendszert már a fejlesztési fázisban is tesztelni kell. Az eddig elkészült programrészeket ugyan a virtuális szerver környezetemben sikeresen leteszteltem, de elkerülhetetlen a BME PA-ba majd ezt követően a MTMT-be való integráció és tesztelés is. Az elkészült rendszert mindenképpen lépcsőzetesen ajánlott bevezetni, esetleg párhuzamos jelleggel, majd a tapasztalatok levonása, a hibák kijavítása után az integrációt növelni (ez a fejlesztési és tesztelési modell működik jelenleg is PA illetve MTMT rendszereknél). 90
16.A Tesztelés A sikeres teszt a rendszert hibás működésre kényszeríti, így a rendszer hibájára mutat rá. Természetesen csak kimerítő, mindenre kiterjedő teszteléssel deríthető ki, hogy a program valóban hibamentes, azonban az ilyen típusú tesztelés lehetetlen (pontosabban mondva nem kivitelezhető egy dinamikusan fejlődő, összetett rendszerben). Azonban a következő tesztelési vezérelvek segítenek, segíthetnek a tesztek kiválasztásának módjában [35]: • menükön keresztül elérhető valamennyi funkciót le kell tesztelni • az azonos menün keresztül elérhető funkciók kombinációit tesztelni kell • ahol felhasználói bevitel van, minden funkciót ellenőrizni kell helyes és helytelen adatokkal • ahol internetes adatátvitel, illetve internetes információ feldolgozás van, minden esetben (napi rendszerességgel) ellenőrizni (öntesztelni kell) a megfelelő adatfeldolgozást egy etalon vektor (teszt minta) segítségével Az egyes tesztek megvalósulhatnak: • kézi, ismételten futtatható tesztelés révén: a rendszer egyes részeinek tesztelésére kiválóan alkalmas módszer, ha bizonyos lehetőségekre a fejlesztők, adminisztrátorok rátesztelhetnek • automatikusan futó/automatikusan generált tesztelés révén: ilyen például a naponta egyszeri illetve többszöri öntesztelés elvégzése • ötletszerű/gyakori eseteket lefedő/kimerítő tesztelés révén: egyes fejlesztési ciklusokban ad-hoc jelleggel komplex tesztet lehet elvégezni (hiszen gyakran a hiba nem is ott jelentkezik, ahol azt feltételeznénk)
91
17.Értékelés és kitekintés
17.
ÉRTÉKELÉS ÉS KITEKINTÉS A dolgozat beadásakor örömmel mondhatom el, hogy a félév elején kitűzött
célok közül szinte majdnem mindent sikerült gyakorlatban is megvalósítanom. A diplomatervezésem pilot projekt jellegű volt, nagyon sokat konzultáltam témavezető professzorommal, aki szoros kapcsolatban áll a BME PA, MTA KPA és MTMT vezetésével. A feladat mélységét, komolyságát és az interakciókat például az is mutatja, hogy egyes rendszerszintű koncepciókat többször is átgondoltunk, újra szabtunk. Erre egy jó példa az XML formátumunk, mely a dolgozatírás és tervezés alatt több mint tíz – kisebb-nagyobb – változtatást élt meg. Kissé csalódottságként élem meg, hogy a MTMT-be való integrálás sajnos nem látszik belátható időn belül reálisnak. Az általam megírt XML export a BME-PA-n azonban fut. Elégedett vagyok a megvalósított funkciókkal is, a programomat sikerült adaptálnom többek között az IEEE Xplore, PubMed/MedLine, Scopus, Periodica Politechnica rendszerekhez. Programom, rendszerem kifejezetten erre a célra készült programok közül egyedülállónak tekinthető, nem ismerek olyan kereskedelmi forgalomban szoftvert, ami erre a célra készült. A fejlesztés következő lépéseiben a legfontosabbnak érzem az XML import funkció megvalósítását a BME-PA-ban (MTMT-ben), valamint az ezzel való tesztelést. Az általam elképzelt duplumkezelés gyakorlatban még nem megvalósított, szintén elengedhetetlennek érzem ennek elkészítését, hiszen az „egységes” MTMT adatbázisban a tagintézmények feltöltéseivel nagyon sok duplum keletkezhet, ennek elkerülése jelentős cél. 92
17.Értékelés és kitekintés Továbbá nélkülözhetetlennek érzem a projektem kapcsán megtervezett illetve elkészült programok, szkriptek továbbfejlesztését a teszteredmények figyelembe vételével. Távlati célnak képzelem el egy intézményi repozitóriumi rendszer elkészítését. Jelenleg is kísérletek folynak arra, hogyan tudunk összekapcsolni más architektúrájú tudományos repozitóriumokat (pl. harvester protokollok). Véleményem szerint az általam elkészített és megtervezett XML formátum, a megfelelő, gyakorlati tesztelés után alkalmas lesz nem csak a hazai adatbázisok közötti információ cserére, hanem akár nemzetközi vonatkozásban is. A fentiekre az is enged következtetni, hogy diplomaterv félévemet ösztöndíjjal Ausztriában sikerült töltenem, ahol nagyon sok példát láthattam egyes egyetemeken, főiskolákon (pl. Technische Universität Wien, Universität Wien, Fachhochschule Technikum Wien) az alkalmazott tudományos adatbázisok alkalmazásáról, céljairól és fontosságáról. A félév megkezdésekor azzal a szent meggyőződéssel jöttem ki, hogy nagyon sok új, hasznos elméleti és gyakorlati tudást és tapasztalatot fogok tudni megszerezni a témám kapcsán. Azonban a valóság mást igazolt. Dolgozatomban többször is körvonalaztam, hogy az általam tapasztaltak szerint a BME-PA, MTMT rendszerei hagynak kívánni valót maguk után, azonban sajnálatos módon meg kell állapítanunk, hogy mindennek ellenére egyfelől a felmerülő igény terén, másfelől a koordináltság terén mi megelőzzük testvér országunkat. A dolgozat terjedelmi keretei sajnos nem engedik meg, hogy tapasztalatimat, meglátásaimat részletezzem.
93
V. Irodalomjegyzék
V. IRODALOMJEGYZÉK [1] Alexander Feder BibTeX oldala, 2010. 02. 25. 10:00, http://www.bibtex.org/ [2] Bruce Powel Douglass. Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition), Addison-Wesley, 2004. [3] Csűry István. Párizsi alapelvek, ISBD, AAC: a bibliográfiai leírás nemzetközi szabványosításának történeti és ideológiai hátteréhez, KLTE, Debrecen, 1979 [4] D. Goodman. Dynamic HTML – The Defensive Reference, O’Reilly, 1998, ISBN 1-56592-494-0 [5] DeBolt, Virginia. HTML és CSS: webszerkesztés stílusosan, Kiskapu Kft, 2005, ISBN 963-9301-96-5 [6] Document
Object
Identifier
Alapítvány
hivatalos
honlapja,
2010. 03. 9. 10:00, http://www.doi.org/ [7] Elektronikus Információszolgáltatás hivatalos weboldala, 2010. 04. 11. 12:00, http://www.eisz.hu/ [8] Gazdag Tiborné. Az időszaki kiadványok számbavétele és feltárása – nemzetközi tendenciák és hazai környezet: az ISSN számadás hazai gyakorlata és nemzetközi összefüggései In: Könyvtári figyelő. 48. évfolyam, 4. szám (2002.) [9] George Schlossnagle. PHP fejlesztés felsőfokon, Kiskapu, 2004, ISBN 963-9301-80- 9 [10]
Google Scholar hivatalos honlapja,
2010. 04. 20. 10:00, http://scholar.google.com/ [11]
Institute
of
Electrical
and
Electronics
2010. 04. 29. 13:00, http://ieee.org/index.html
xii
Engineers
hivatalos
honlapja.
V. Irodalomjegyzék [12]
Java Sun JSP hivatalos honlapja,
2010. 04. 23. 13:00, http://java.sun.com/products/jsp/ [13]
JavaScript Object Notation szakmai oldal,
2010. 03. 12. 12:00, http://www.json.org/ [14]
John L. Viescas, Michael J. Hernandez. SQL-lekérdezések földi halandóknak,
Kiskapú kiadó, 2009, ISBN 963-9637-52-8 [15]
Kollár István. Álom vagy valóság? Egy (fél)automatikusan működő bibliográfiai
adatbázis felé. Kézirat, Budapest, 2009 [16]
Kollár István. Tudományos publikálás hatékonyan, BME Méréstechnika és
Információs Rendszerek Tanszék 2010. 03.11. 10:00, http://www.mit.bme.hu/services/pubinfo/szakirod-kezeles.pdf [17]
Kovács Ilona. A könyvek bibliográfiai leírása: útmutató az MSZ 3424/1 – 78
tanulmányozásához, Budapest, OSZK KMK , 1980 [18]
BME
Publikációs
Adattár:
Gyakran
ismételt
kérdések
2010. 04. 9. 10:00, http://www.mit.bme.hu/services/pubinfo/gyik.pdf [19]
Levensthein algoritmus, hivatalos szakmai oldal,
2010. 03. 17. 14:00, http://www.levenshtein.net/ [20]
Magyar Szabvány: MSZ 3493-82 bibliográfiai tételek besorolási szabályai
[21]
Magyar Szabvány: MSZ ISO 2709 Információ és dokumentáció csere szabá-
lyai [22]
Magyar Tudományos Művek Tára, könyvtárosbizottság: MTMT: Jellegek és
besorolások – javaslat, munkahelyi dokumentum, 2009. december [23]
Martin Fowler. Analysis Patterns: Reusable Object Models, Addison-Wesley,
1996, ISBN 0201895420 [24]
Microsoft ASP. NET hivatalos honlapja,
2010. 03. 20. 13:00, http://www.asp.net/ [25]
Nemzetközi ISBN Szövetség hivatalos weboldala,
2010. 03. 20. 10:00, http://www.isbn.org/standards/home/index.asp
xiii
V. Irodalomjegyzék [26]
Nemzetközi ISSN Szövetség hivatalos weboldala,
2010. 03. 20. 19:00, http://www.issn.org/ [27]
Országos Műszaki Információs Központ és Könyvtár hivatalos oldala,
2010. 03. 19. 10:00, http://www.omikk.bme.hu [28]
Országos Széchenyi Könyvtár hivatalos oldala,
2010. 04. 11. 12:00, http://www.oszk.hu/ [29]
Peter Moulding, PHP Haladóknak Fekete könyv, Perfact,
ISBN: 9630-0955-80-2 [30]
PHP Net közösségi professzionális weboldal,
2010. 03.19. 12:00, http://php.net/ [31]
Rácz Ágnes. A kiadványok bibliográfiai számbavétele. - In: Könyvtárosok ké-
zikönyve. 2., Budapest, Osiris, 2001. [32]
Rácz Ágnes. Bibliográfiai leírás, katalogizálás, Budapest, Nemzeti Tankönyv-
kiadó, 1995. [33]
Reference Magager – RIS formátum hivatalos oldala,
2010. 03. 21. 15:00, http://www.refman.com/support/risformat_intro.asp [34]
Scopus tudományos adatbázis hivatalos oldala,
2010. 04. 2. 11:00, http://www.scopus.com/home.url [35]
Simon Gyula (Pannónia Egyetem) Szoftvertechnológia oldala,
2010. 02. 27. 15:00, http://www.dcs.vein.hu/~simon/oktatas/ST/ [36]
Szeredi, Lukácsy, Benkő. A szemantikus világháló elmélete és gyakorlata.
Typotex Kiadó, 2005, ISBN 963-9548-48-0 [37]
Thomas H. Cormen. Introduction to Algorithms (Third Edition), The MIT Press,
September 2009, ISBN 978-02620-33-84-8 [38]
Tóvári Judit. Bibliográfiai adatfeldolgozás : felsőoktatási tankönyv. – Nyíregy-
háza, Dialógus, 2002. [39]
U.S. National Library of Medicine National Institutes of Health hivatalos oldala,
2010. 03. 19. 10:00, http://www.ncbi.nlm.nih.gov/pubmed/
xiv
V. Irodalomjegyzék [40]
Vajda Erik. Megújul a könyvtári szabványosítás : a szabályzat – némi beveze-
téssel – a szakmai közvélemény tájékoztatására. - In: Könyv, könyvtár, könyvtáros, 1997. [41]
Web of Science hivatalos honlapja,
2010. 04. 25. 12:00, http://isiknowledge.com [42]
Word Web Web Consortitum validációs oldala,
http://validator.w3.org/ [43]
Word Wide Web Consortium hivatalos oldala,
2010. 03. 29. 10:00, http://www.w3.org/ [44]
Word Wide Web Consortium Schooling hivatalos oldala,
2010. 03. 29. 8:00, http://www.w3schools.com/
xv
VII. Ábrák jegyzéke
VI. ÁBRÁK JEGYZÉKE 2-1. ÁBRA: A MEGOLDANDÓ FELADAT ILLUSZTRÁLÁSA .......................................................................................... 4 9-1. ÁBRA: EGY IEEE PÉLDA PUBLIKÁCIÓ SIKERTELEN DOI RESOLVING EREDMÉNYE ........................................... 39 9-2. ÁBRA:EGY IEEE PÉLDA PUBLIKÁCIÓ SIKERES DOI RESOLVING EREDMÉNYE, VALAMINT A FELOLDOTT OLDALON KERESZTÜL ELÉRHETŐ ÚJABB OLDAL .......................................................................................... 40 9-3. ÁBRA: "A" LEKÉRDEZÉS EREDMÉNYE A BÖNGÉSZŐBEN ILLETVE RÉSZLET AZ OLDAL HTML KÓDJÁBÓL ........ 41 9-4. ÁBRA: "B" LEKÉRDEZÉS EREDMÉNYE A BÖNGÉSZŐBEN ILLETVE RÉSZLET AZ OLDAL HTML KÓDJÁBÓL ........ 41 9-5. ÁBRA: IEEE KEZDŐ OLDAL HTML VALIDÁCIÓJA [42] ....................................................................................... 42 9-6. ÁBRA: SCOPUS MINTA OLDAL ........................................................................................................................ 45 9-7. ÁBRA:SCOPUS KEZDŐ OLDAL HTML VALIDÁCIÓJA [42] ................................................................................. 45 9-8. ÁBRA:PUBMED MEDLINE KEZDŐ OLDAL HTML VALIDÁCIÓJA [42] ................................................................ 47 9-9. ÁBRA: PUBMED MINTA OLDAL....................................................................................................................... 47 11-1. ÁBRA: A RENDSZER EGYSZERŰSÍTETT USE CASE DIAGRAMJA ...................................................................... 55 12-1. ÁBRA: A RENDSZER ELMÉLETI FELÉPÍTÉSE ................................................................................................... 57 12-2. ÁBRA: A RENDSZER EGYSZERŰSÍTETT, ÁLTALÁNOS UML CLASS DIAGRAMJA .............................................. 62 13-1. ÁBRA: TAG KERESŐ EGYSZERŰSÍTETT ALGORITMUSA ................................................................................. 66 13-2. ÁBRA: “A” PÉLDA REKORD VERIFIKÁCIÓ EREDMÉNYÉNEK MEGJELENÍTÉSE GRAFIKUS FELÜLETEN ............ 70 13-3. ÁBRA: “B” PÉLDA REKORD VERIFIKÁCIÓ EREDMÉNYÉNEK MEGJELENÍTÉSE GRAFIKUS FELÜLETEN ............ 71 13-4. ÁBRA:”C” PÉLDA REKORD VERIFIKÁCIÓ EREDMÉNYÉNEK MEGJELENÍTÉSE GRAFIKUS FELÜLETEN ............. 71 14-1. ÁBRA: MINTA EGY EXCEL-EL SEGÍTETT IEEE FORMÁTUM TÁBLÁZAT KITÖLTÉSÉRE ..................................... 74 15-1. ÁBRA: EGY BME PA-BÓL SZÁRMAZÓ XML FORMÁTUMÚ REKORD XSD VALIDÁLÁSA .................................. 79 15-2. ÁBRA: XSD SÉMAFÁJL GYÖKÉRSZERKEZETE ................................................................................................. 83
xvi
VII. Táblázatok jegyzéke
VII. TÁBLÁZATOK JEGYZÉKE 11.1. TÁBLÁZAT: KÖVETELMÉNY MENEDZSMENTBEN ALKALMAZOTT JELÖLÉSEK ............................................... 51 11.2. TÁBLÁZAT: FELHASZNÁLÓI KÖVETELMÉNYEK LISTÁJA ................................................................................. 52 11.3. TÁBLÁZAT: RENDSZERKÖVETELMÉNYEK LISTÁJA ......................................................................................... 52 11.4. TÁBLÁZAT: FEJLESZTÉS ÉS TERVEZÉS SORÁN FELHASZNÁLT SZOFTVEREK KIVONATOS LISTÁJA .................. 56 12.1. TÁBLÁZAT: A FEJLESZTÉS SORÁN LÉTREHOZOTT FŐBB ÁLLOMÁNYOK LISTÁJA ........................................... 59
xvii
VIII. Listák jegyzéke
IV.
LISTÁK JEGYZÉKE
3-1. LISTA: HAGYOMÁNYOS KATALÓGUS CÉDULA ELRENDEZÉSE [38] ................................................................... 8 3-2. LISTA: MINTA KATALÓGUS CÉDULA [38] .......................................................................................................... 9 3-3. LISTA:MINTA BIBTEX ÁLLOMÁNY [11] ............................................................................................................ 11 3-4. LISTA: RIS MINTAFÁJL [11] ............................................................................................................................. 12 4-1. LISTA: HTML MINTAFÁJL ................................................................................................................................ 16 4-2. LISTA:JSON MINTAFÁJL .................................................................................................................................. 16 4-3. LISTA: XML MINTAFÁJL ................................................................................................................................... 21 5-1. LISTA: EGY PÉLDA DOI AZONOSÍTÓ, ÉS A DOI CÍMBŐL FELOLDOTT LINK ...................................................... 22 8-1. LISTA:MINTA METAPHONE FÜGGVÉNY HASZNÁLATÁRA ............................................................................... 33 8-2. LISTA: MINTA EGYSZERŰ PARAMÉTEREZÉSŰ LEVENSHTEIN FÜGGVÉNY HASZNÁLATÁRA ............................ 34 8-3. LISTA:MINTA ÖSSZETETT PARAMÉTEREZÉSŰ LEVENSHTEIN FÜGGVÉNY HASZNÁLATÁRA ............................ 35 8-4. LISTA:MINTA SIMILAR_TEXT FÜGGVÉNY HASZNÁLATÁRA ............................................................................. 36 15-1. LISTA: MINTA EGY BME PA-BÓL SZÁRMAZÓ XML FORMÁTUMÚ REKORDRA.............................................. 80 15-2. LISTA:RÉSZLET AZ XSD FÁJLBÓL .................................................................................................................... 82 15-3. LISTA:RÉSZLET EGY XML FÁJLBÓL ................................................................................................................. 82 15-4. LISTA: MINTA AZ XML FÁJL DESCRIPTION ÁGÁRA ........................................................................................ 84 15-5. LISTA: MINTA AZ XML FÁJL AUTHORS ÁGÁRA.............................................................................................. 85 15-6. LISTA: MINTA AZ XML FÁJL PUBLICATION ÁGÁRA ....................................................................................... 87 15-7 LISTA:MINTA AZ XML FÁJL CLASSIFICATIONS ÁGÁRA ................................................................................... 88 15-8. LISTA:MINTA AZ XML FÁJL CONTAINER ÁGÁRA ........................................................................................... 88 15-9. LISTA:MINTA AZ XML FÁJL LENGTH ÁGÁRA ................................................................................................. 88 15-10. LISTA: MINTA AZ XML FÁJL CITATIONS ÁGÁRA .......................................................................................... 89
xviii
