1. fejezet Bevezetés Bevallom, mikor kiválasztottam szakdolgozatom témáját, nem sokat tudtam az Apache Mavenr˝ol, és a Szemantikus web koncepciójáról sem hallottam még. Viszont úgy éreztem, a Java nyelv már közel áll hozzám és abban a félévben épp a konzulensemhez jártam Programozási környezetek gyakorlatra, ahol az els˝o órán nagy vonalakban elmagyarázta, hogy mit is tud a Maven. Így megláttam benne a lehet˝oséget, és úgy gondoltam, hogy belevágok. Kés˝obb, ahogy gyakorlaton eljutottunk ehhez a témához, minél többet tudtam meg róla, annál jobban megtetszett, annál inkább beláttam, milyen nagymértékben segíti egy Java szoftverprojekt életciklusának implementációs és tesztelési fázisát. Ahogy a félév végéhez közeledtem, egyre inkább úgy t˝unt, jó témát választottam szakdolgozatomhoz, f˝oleg mikor megtudtam, az Apache Software Foundation weboldala [2] nagy segítséget nyújt abban, hogyan is kell implementálni egy b˝ovítményt Maven rendszeréhez. Ezen oldal áttanulmányozása után biztosra vettem, nem is lesz olyan nehéz dolgom. Már csak azt kellett kitalálnom, mi legyen pluginom funkcionalitása. Azzal tisztában voltam, nem kell túl bonyolultnak lennie ahhoz, hogy hasznos legyen, elég, hogyha egy kis dologgal egészítem ki a Mavent. Ezután keresni kezdtem, hogy a Programozási környezetek gyakorlaton megtanult pluginokon kívül milyen b˝ovítmények léteznek még ehhez a projektkezel˝o rendszerhez. Mivel annyiféle plugint találtam, amik az általam ismert feladatokhoz hozzá voltak rendelve, és azokat nagyon jól megvalósították, sokáig nem is tudtam, milyen pluszt adhatnék hozzá a Maven-hez. Szerencsére számíthattam konzulensem tanácsára, így mikor problémámmal felkerestem, felvetett egy ötletet: Mi lenne, ha témámat összekapcsolnám a szemantikus világhálóval? Persze f˝uzött hozzá magyarázatot is, de els˝ore elég nagy falatnak t˝unt nekem ez a téma. Elmondta, hogy o˝ tart Szemantikus Web kurzust, úgyhogy jegyzettel, példákkal, és egy nagyon jó könyvvel is segíteni tudja munkámat. 1
Következ˝o alkalommal, mikor felkerestem, már kölcsön is tudta adni a könyvet [13], mely nagyonban hozzájárult ahhoz, hogy megértsem, mit is jelent a szemantikus web fogalma, és miért van rá szükség. Miel˝ott még e fogalom ismertetésére rátérne, bevezetésképpen bemutatja hogyan néz ki manapság a világháló, elmagyarázza, hogyan m˝uködnek a hagyományos keres˝orendszerek és a Google PageRank algoritmusa, és rávezet a web nagy hiányosságára, mégpedig, hogy az információk nagyrészt struktúrálatlan formában találhatók meg rajta. A témával kapcsolatbani tudásom elmélyítése érdekében elolvastam témavezet˝om RDF-r˝ol szóló jegyzetét is, amely weboldaláról letölthet˝o [12]. Edd Dumbill három XML Watch: Describe open source projects with XML cikkének [7] [8] [9] áttanulmányozása után már készen álltam, hogy elkezdjem Apache Maven b˝ovítményem, a zsolczai-doap-maven-plugin fejlesztését. A b˝ovítmény elkészülte után írtam ezt a dokumentumot, melyben összefoglalom a témával kapcsolatban megszerzett tudásomat, majd bemutatom az általam készített plugint.
2
2. fejezet Szemantikus Web A szemantikus világháló alapötlete Tim Berners-Lee-t˝ol származik, akit˝ol a Word Wide Web, és a hozzá kapcsolódó technológiák is (HTTP, HTML, stb). Ezen elgondolás lényege, hogy az világháló forrásaihoz (weboldalak, képek, online megnézhet˝o videók, stb.) metaadatokat1 rendeljünk, pontosabban struktúráltan megjelen˝o metaadatokat. Ez az elgondolás már korábban is megjelent, néhány technológiában már találkozhatunk velük, hiszen az összes fájlrendszer tartalmaz metaadatokat, például az állományok utolsó módosításának dátumát és a hozzáférésre vonatkozó jogokat. Az MP3 fájlok esetén az id3v1 és id3v2 elemek is metainformációk. Weboldalakban is fellelhet˝ok ilyen információk, ezek a META HTML elemek. Itt az oldalhoz tartozó kulcsszavakat adhatunk meg, a keres˝orobotok számára hasznos információkat, amik segítségével könnyebben kategorizálhatják weboldalunkat. Ez az elem azonban nem elég a szemantikus web megvalósításához, mivel nem írhatunk le elég részletes kapcsolatokat vele, azt nem adhatjuk meg vele, hogy egy kulcsszóként feltüntetett fogalom vagy tárgy milyen viszonyban van weboldalunkkal, csak azt, hogy szerepel benne. A szemantikus világháló célja, hogy egy oldal minden egyes objektumáról lehessen információkat közzétenni, például mik, esetleg kik szerepelnek egy oldalon lév˝o fényképen, ki és mikor készítette ezt a képet, stb. A másik ötlet, hogy ezen metainformációk alapján következtetni lehessen. Például, ha egy kép metainformációi közt a kép szerepl˝ojének macska van megadva, akkor azt a képet találatként akkor is jelenítse meg egy keres˝o, ha mi cicát, eml˝ost, vagy esetleg állatot kerestünk. A továbbiakban bemutatom a szemantikus web megvalósításához szükséges technológiákat. 1
adatokról szóló adat
3
2.1.
XML
Az XML2 célja, hogy az adatokat struktúrált formában írjuk le olyan szöveges dokumentumokban, hogy az számítógép által is feldolgozható legyen. Ez biztosítja a gépek közti adatcserét, mivel az XML platformfüggetlen, és mivel szöveges dokumentumokat használ, ezek ember által is olvasható, hiba esetén könnyen javíthatók. Lényegében ez egy leíró nyelv, vagyis dokumentumok leírására szolgál. HTML és az XML dokumentum kísérteties hasonlóságának oka a közös o˝ s, az SGML3 . A HTML valójában ennek a leíró nyelvnek az alkalmazása. Ez a nyelv a weben történ˝o széleskörben használathoz, ezért hozták létre az XML-t az SGML egyszer˝usítéséb˝ol. Az XML egyik hibája a bináris tárolással szembeni karakteres tárolásból adódó nagy fájlméret. Emiatt sokan ellenszenvesnek találják ezt a reprezentációt, a többiek viszont nem foglalkoznak vele, hiszen a tárolókapacitás egyre inkább olyan méreteket ölt, hogy akár egy néhányszáz megabájtos XML állomány is elfogadható. Ráadásul az adatátviteli eszközök sávszélessége is elég nagy ahhoz napjainkban, hogy XML alapokon kommunikáljunk rajtuk keresztül.
2.1.1. Szintaxis Egy XML dokumentum elemekb˝ol és attribútumokból áll, csakúgy, mint egy HTML dokumentum, viszont a HTML szabvány rögzíti, hogy milyen elemeket és attribútumokat használhatunk. Példa egy egyszer˝u XML dokumentumra: Gipsz JakabG1PS2JIK <szak>PTI <evfolyam>2<evfolyam> 06707070707Wincs EszterW1NCS3IK <szak>MI 2 3
eXtensible Markup Language – Kiterjeszthet˝o Jelöl˝onyelv Standard Generalized Markup Language – Szabványos Általánosított Jelöl˝onyelv
4
<evfolyam>1 Az els˝o sor tekinthet˝o a dokumentum fejlécének, ahol megadható a karakterkódolás. Ezen példán láthatjuk, hogyan is lehet struktúrált adatokat megadni XML-ben. A dokumentumban pontosan egy gyökérelem szerepelhet, a többi elem el˝ofordulása attól függ, milyen megszorításokat adunk rá a sémanyelvek segítségével. Mivel telefonszám csak egy hallgatónál van megadva, láthatjuk, hogy ez az elem opcionális, tehát nem kötelez˝o megadni. Ez a hierarchia egy fát határoz meg, aminek gyökere a gyökérelem. Egy elemnek tetsz˝oleges számú attribútuma lehet, de mindegyikb˝ol csak egy. Az, hogy XML dokumentumunkban melyik elemnek adunk attribútumot, hány attribútum van, esetleg egyáltalán nincs attribútum a dokumentumban, lényegtelen, mert attribútumok helyett is használhatunk elemeket. Ilyen szempontból egy dokumentum megtervezése csupán attól függ, hogyan lesz emberi szemmel átláthatóbb és hogyan könnyebb feldolgozni. Viszont azt vegyük figyelembe, hogy attribútum értéke csak szöveg lehet. Az el˝oz˝o példa attribútumokkal: Gipsz JakabIK <szak>PTI <evfolyam>2<evfolyam> 06707070707Wincs EszterIK <szak>MI <evfolyam>1 Ha egy XML dokumentumban egy elem neve egyedi, attól még nem biztos, hogy több XML dokumentum összefésülésekor az a név egyedi lesz, el˝ofordulhatnak névütközések. Ezen névütközések elkerülésére dolgozták ki az XML-névtereket. Ezek a névterek el˝ore definiált elemeket és attribútumokat tartalmaznak, amiket URI-kkal4 jelölünk. Egy URI általában egy szervezethez vagy személyhez tartozik, és szerepelhetnek benne olyan karakterek is, amik nevekben nem 4
Uniform Resource Idenfitier – Egységes Er˝oforrás Leíró
5
megengedettek. Mivel az URI-k általában nagyon hosszúak, és tartalmazhatnak olyan karaktereket, amelyek az XML elemekben nem megengedettek, bevezették az xmlns attribútumot, amivel ilyen formában a dokumentum alapértelmezett névterét lehet deklarálni. Ez azt jelenti, hogy a dokumentumban az el˝otag nélkül megadott elemek az alapértelmezett névtérbe tartoznak. xmlns:prefix formában pedig a prefix el˝otaghoz rendelt névteret lehet deklarálni, ahol a prefix szintén a nevekben megengedett karakterekb˝ol állhat. Példa névterek használatára: Gipsz JakabIK <szak>PTI <evfolyam>2<evfolyam> 06707070707Wincs EszterIK <szak>MI <evfolyam>1
2.1.2. Tartalmi ellen˝orzés Minden dokumentumnak definíció szerint jól formázottnak kell lennie, meg kell felelnie bizonyos jól formázottsági megszorításoknak. Sok ilyen megszorítás van, ezek közül a legfontosabbak: • minden nyitó címkének rendelkeznie kell egy záró címke párral, • minden elemnek megfelel˝oen egymásba skatulyázottnak kell lennie. Néha azonban nem elég ha egy dokumentum jól formázott, mert szerkezetre is eleget kell tennie bizonyos megszorításoknak, amelyeket szintén ellen˝orizni kell. Ezeket a megszorításokat XML sémákkal adhatjuk meg.
6
2.1.3. XML sémák Több XML sémanyelv is létezik, mellyel megszorításokat tehetünk a tartalomra és a szerkezetre. Manapság a két leghasználatosabb XML sémanyelv a W3C XML Schema és a RelaxNG. XML sémák segítségével megadhatjuk, hogy a hozzájuk tartozó XML dokumentumokban milyen elemek és attribútumok lehetnek, azokban milyen értékek megengedettek, az egyes elemeket kötelez˝o-e megadni, stb. XML séma segítségével a feldolgozó alkalmazás könnyedén ellen˝orizheti, hogy az általa feldolgozandó XML dokumentum formátuma helyes-e, a dokumentumban megadott adatok megfelel˝o típusúak-e, így a feldolgozóba nem kell bonyolult ellen˝orz˝o kódot írni elágaztatásokkal és kivételkezeléssel. Egy primitív XML sémanyelvnek tekinthet˝o a DTD is az XML 1.0 részeként. Példa XML sémára: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="hallgatok"> <xs:complexType> <xs:sequence> <xs:element name="hallgato" type="xs:string" minOccurs="1" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="neptun" type="xs:string" use="required"/> <xs:attribute name="nem" type="nemTipus" use="required"/> <xs:sequence> <xs:element name="nev" type="xs:string"> <xs:element name="kar" type="xs:string"> <xs:element name="szak" type="xs:string"> <xs:element name="evfolyam" type="xs:unsignedByte"> <xs:element name="mobilszam" type="telefonszamTipus" minOccurs="0" maxOccurs="1"> 7
<xs:simpleType name="telefonszamTipus"> <xs:restriction base="xsd:string"> <xs:pattern value="\+?[0-9]+([- ][0-9]+)*"/> <xs:simpleType name="nemTipus"> <xs:restriction base="xs:string"> <xs:enumeration value="ferfi"/> <xs:enumeration value="no"/> B˝ovebben a W3C XML Schema típusairól [11] és a séma által nyújtott további lehet˝oségekr˝ol [10] a W3C XML Schema specifikációjában olvashatunk.
2.1.4. XSLT Ezzel a nyelvvel XML dokumentumokat transzformálhatunk más XML dokumentumokká. Az XSLT5 segítségével kifejezett transzformációkat stípuslapoknak (stylesheet) nevezzük. A transzformáció mintaillesztés segítségével történik. A transzformáció során elhagyhatunk elemeket, de akár újakat is létrehozhatunk. A mintákat az XPath nyelv segítségével írhatjuk le. Az XSLT és az XPath egy közös nyelvcsaládba, az XSL6 -be tartoznak. A technológia lényege, hogy különválasszuk az adatokat és a megjelenítést. Az adatokat XML-ben, míg a megjelenítést XSLT-ben írjuk le.
2.1.5. XML összefoglalás Az XML-t nevezhetjük a szemantikus világháló el˝ofutárának. Alkalmazása manapság már elég széleskör˝u, elterjedéséhez elég volt néhány év. Alapvet˝oen adatcsere formátum, de már a Microsoft Office is ebben az alakban menti dokumentumait. A web elterjedése után jött létre, és még így is nagymértékben megváltoztatta a számítógépek közti kommunikációt, mivel ezel˝ott majdnem minden alkalmazás más formátummal dolgozott, így ha egy adatot más alkalmazással szerettünk volna feldolgoztatni, értelmez˝ot kellett írni minden egyes szoftverhez. Azonban 5 6
eXtensive Stylesheet Language Transformation eXtensive Stylesheet Language Family
8
a szemantikus web koncepciójához nem elég, mivel az alkalmazások közti XML alapú kommunikáció megteremtéséhez egyeztetni kell az átvitt információ szemantikáját, hogy egy XML dokumentumban megadott adaton minden szoftver ugyanazt értse. A szemantikus web elterjedéséhez viszont alapvet˝o, hogy az adatok közzétételekor minden fél ugyanazt értse egy adaton. Ennek érdekében jött létre az RDF nyelv.
2.2.
RDF
Az RDF7 lényege, hogy tetsz˝oleges er˝oforrásokat leírhassunk metaadatokkal. Er˝oforrásnak tekinthet˝o bármi, ami URI-val azonosítható. Az URI-kat már említettem az XML névterek kapcsán, most lássunk néhány példát, hogyan is néznek ki: http://www.inf.unideb.hu file:///home/user/pelda.pdf ftp://ftp.pelda.hu/uri Az URI-k legtöbbször interneten elérhet˝o er˝oforrásokat azonosítanak, viszont nem minden esetben. URI-t lehet rendelni a tárgyi világ objektumaihoz is, például egy szobában lév˝o asztalhoz is, a lényeg, hogy az azonosító egyedi legyen. Egy URI rendelkezhet egy úgynevezett er˝oforrásrész-azonosítóval, ami lehet˝ové teszi egy másodlagos er˝oforrás közvetett azonosítását egy els˝odleges er˝oforrásra hivatkozáson keresztül. Ez az azonosító a # jelt˝ol az URI végéig tart. Egy URI lehet abszolút URI, vagy URI hivatkozás. Az abszolút URI nem tartalmaz er˝oforrásrész azonosítót, hogy lehessen bázis URI-ként is használni. Az URI hivatkozás URI, vagy úgynevezett relatív hivatkozás. Egy relatív hivatkozás egy adott környezetben értelmezett, feloldani a már el˝obb említett bázis URI segítségével lehet. Bázis URI-t definiálhatunk egy dokumentumban, ha ezt nem tesszük meg, akkor a bázis a tartalmazó objektum URI-ja lesz, vagy ha ilyen nincs, akkor az az URI lesz, ahol az adott objektum elérhet˝o. Az URI-k a relatív hivatkozástól eltekintve mindig a használat környezetét˝ol függetlenül azonosítanak er˝oforrásokat. Benk˝o Tamás, Szerendi Péter és Lukácsy Gergely A szemantikus világháló elmélete és gyakorlata cím˝u könyvüben[13] a relatív URI kifejezést használják a relatív hivatkozás helyett, de ezt a szabvány nem használja. RDF segítségével úgy közlünk metaadatokat, hogy egy URI-val ellátott er˝oforrásokat tulajdonságok segítségével más er˝oforrásokkal vagy literálokkal kötjük össze. Az RDF adatmodell egy halmazelméleti modell, amely négy halmazt definiál, ezek segítségével írhatunk le metaadatokat: 7
• Er˝oforrások (Resources) halmaza: A halmaz elemeit er˝oforrásoknak hívjuk, minden egyes er˝oforrást URI-k azonosítanak. • Tulajdonságok (Properties) halmaza: Er˝oforrásokhoz kapcsolható jellemz˝ok, amik valójában er˝oforrások, tehát o˝ ket is URI-k azonosítják. A halmaz elemeit tulajdonságoknak nevezzük. • Literálok (Literals) halmaza: Elemei literálok, azaz karaktersorozatok. • Kijelentések (Statements) halmaza: A halmaz elemei kijelentések (hármasok), amik alanyból, állítmányból és tárgyból állnak. Az alany lehet er˝oforrás, az állítmány tulajdonság, a tárgy lehet er˝oforrás, vagy literál. Egy hármas azt jelenti, hogy az alany és a tárgy az állítmány által jelölt viszonyban van egymással, tehát binér relációkat írhatunk le velük.
2.2.1. Szintaxisok Ennek az adatmodellnek a szemantikája az, hogy a kijelentések igazak, viszont a szintaxisról nem mond semmit. A szintaxist három szabványos adatmodell reprezentáció adja meg: • Hármasok halmaza • Címkézett irányított gráf • XML Ezek közül az XML a legelterjedtebb, mert ez biztosítja a hordozhatóságot és a könny˝u gépi feldolgozást. Példa az RDF XML szintaxisára: Gerg˝ oZsolczai 10
A fenti példában lév˝o foaf:Person elem egy úgynevezett köztes er˝oforrás, amit arra szoktunk bevezetni, hogy adatainknak további struktúrát biztostsunk. Emellett binárisnál magasabb fokú relációk binárissá leképezéséhez is használhatjuk a köztes er˝oforrásokat, mivel RDF segítségével csak binér relációkat írhatunk le. Az el˝oz˝o példa gráf reprezentációja talán egy kicsit jobban szemlélteti a köztes er˝oforrás használatát:
2.1. ábra. Egyszer˝u RDF gráf Az er˝oforrásokat ellipszis jelöli, a literálokat téglalap, a tulajdonságokat irányított címkézett élek. A teljesség kedvéért bemutatom példám RDF hármas halmaz reprezentációját is: {[file:///home/zsolczai/],[http://xmlns.com/foaf/0.1/maker], [http://xmlns.com/foaf/0.1/Person]} {[http://xmlns.com/foaf/0.1/Person], [http://xmlns.com/foaf/0.1/givenName],"Gerg˝ o"} {[http://xmlns.com/foaf/0.1/Person], [http://xmlns.com/foaf/0.1/familyName],"Zsolczai"} {[http://xmlns.com/foaf/0.1/Person], [http://xmlns.com/foaf/0.1/mbox], [mailto:[email protected]]} Láthatjuk, hogy a három féle reprezentáció közül ez a legrövidebb, viszont a gráf emberi szemmel átláthatóbb, gépi feldolgozás szempontjából pedig az XML a hatékonyabb. Az RDF XML leírása a szokásos fejléccel kezd˝odik, ami jelzi, hogy adott verziószámú XML szintaktikát használó dokumentumról van szó. Gyökéreleme az rdf:RDF jelzi, hogy itt 11
kezd˝odik az RDF leírás. Az rdf prefixhez rendelt névtér az RDF specifikáció része. A másik deklaráció a FOAF8 névtere, ami egy olyan szabványos szókészlet, ami emberek és kapcsolataik leírására szolgál [1]. Az rdf:Description elem jelzi, hogy az rdf:about attribútum értékeként megadott er˝oforrás leírása következik.
2.2.2. RDF osztályok RDF-ben lehet˝oségünk van osztályok „példányosítására” az objektum-orientált világhoz hasonló módon, azzal a különbséggel, hogy itt nem új példányokat hozunk létre, csupán kijelentjük valamir˝ol, hogy az egy bizonyos osztály példánya. Saját osztály definiálására maga az RDF nem képes, ezt a kés˝obb ismertetett RDF sémákkal tehetjük meg. Ez történik például az el˝oz˝o XML szintaxisú RDF példa leírásban is, ahol kijelentem, hogy Zsolczai Gerg˝o a foaf:Person osztály példánya, ahol a foaf el˝otaghoz hozzárendelem a http://xmlns.com/foaf/0.1/ névteret. Az el˝obb bemutatott példa valójában a példányosítás rövid alakja, teljes alakjához az rdf:type tulajdonságot használjuk: Gerg˝ oZsolczai Egy er˝oforrás több osztály példánya is lehet egyszerre, viszont rövidített alakot csak egyhez használhatunk.
2.2.3. Tárgyiasított kijelentések Mivel RDF kijelentéseket mindenki tehet, mint ahogyan a világhálón is bárki bármilyen információt közzétehet, fontos, hogy a kijelentésekhez hozzárendeljük, kihez tartozik, esetleg mikor történt a kijelentés, hiszen nem feltétlenül igaz minden kijelentés. Az erre szolgáló eszközt az RDF-ben magasabb rend˝u kijelentéseknek, vagyis kijelentésekr˝ol szóló kijelentéseknek nevezzük. Mivel az RDF kijelentés tárgyának er˝oforrásnak kell lennie, ezért kijelentésünket egy speciális er˝oforrással, úgynevezett reifikált (tárgyiasított) kijelentéssel írjuk le, ami valójában az rdf:Statement osztály példánya. Példányosításkor a reifikált kijelentés alanyát, 8
Friend of a Friend
12
állítmányát és tárgyát rendre az rdf:subject, rdf:predicate, rdf:object tulajdonságokkal adhatjuk meg. Ha kész van a reifikált kijelentésünk, már csak annyi van hátra, hogy a hozzá tartozó URI-t hozzárendeljük egy kijelentéshez, mint a kijelentés tárgyát. Ennek a módszernek viszont van egy hiányossága, ez pedig az, hogy a tárgyiasított állítást közvetlenül nem tudjuk összekapcsolni azzal az állítással, amire vonatkozik.
2.2.4. Konténerek Dolgok összességének leírására az RDF konténereket alkalmaz. Konténerek leírására az RDF beépített osztályokat és tulajdonságokat kínál fel. A beépített osztályok a következ˝ok: • Bag (rdf:Bag): er˝oforrások vagy literálok olyan csoportját reprezentálja, amelyben megengedett az ismétl˝odés és lényegtelen a tagok sorrendje. • Sequence (rdf:Seq): er˝oforrások vagy literálok olyan csoportját reprezentálja, amelyben megengedett az ismétl˝odés és lényeges a tagok sorrendje. Tekinthetjük egy rendezett Bagnek is. • Alternative (rdf:Alt) er˝oforrások vagy literálok olyan csoportját reprezentálja, amelyben megengedett az ismétl˝odés és lényegtelen a tagok sorrendje, és a tagok bizonyos szempontból egyenérték˝uek, felcserélhet˝oek egymással. A másik két konténerrel ellentétben ez nem lehet üres, legalább egy elemnek kell benne szerepelnie és ez az elem a konténer alapértelmezett eleme. Mivel RDF-fel csak kijelentéseket tehetünk, az osztályhoz hasonló módon nem hozunk létre új konténert, hanem csak kijelentjük egy er˝oforrásról az rdf:type tulajdonság segítségével, hogy az konténer. Egy konténer bármilyen elemet tartalmazhat és egy konténerr˝ol bármilyen kijelentést tehetünk. Kijelentést úgy tehetünk egy konténerr˝ol, hogy azt olyan tulajdonságelemekkel látjuk el, amik nem a konténer elemeit jelzik. Elemeket az rdf:_n tulajdonsággal adhatunk meg, ahol n természetes szám. Az RDF konténerek kezelése azért hasonlít annyira az osztályok kezeléséhez, mert az RDF-ben a Bag, Sequence és az Alternative valójában osztályok. Példa konténer definiálására: 13
Rövid alakban: Az elemek felsorolásánál az elemek explicit beszámozása helyett használhatjuk az rdf:li jelölést is, az RDF állomány feldolgozásakor a li helyére automatikusan behelyettesít˝odik a megfelel˝o _1, _2, stb.
2.2.5. Kollekciók A konténerekkel ellentétben a kollekciók csak az általunk felsorolt elemeket tartalmazzák. Egy RDF kollekció valójában egy lista, vagyis az rdf:List osztály példánya. A lista els˝o elemét az rdf:first, a többit az rdf:rest tulajdonság jelzi. Az rdf:rest értéke egy újabb rdf:List er˝oforrás lehet, vagy lista vége esetén a http://www.w3.org/1999/02/22-rdf-syntax-ns#nil er˝oforrás. Példa lista használatára: Gipsz JakabWincs Eszter
"www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
2.2.6. Adattípusok Literálok használatánál gyakran felmerülhet igény arra, hogy típussal lássuk el o˝ ket, hogy a feldolgozó alkalmazás egy literált ne csak karaktersorozatként értelmezzen, hanem számként, esetleg dátumként, stb. Literál típusának megadására az RDF az rdf:datatype attribútumot használja, melynek értéke tetsz˝oleges URI lehet. Tetsz˝oleges, mert az RDF nem tör˝odik vele, hogy az az URI mindenkinek ugyanazt a típust jelöli-e, ezzel a feldolgozó alkalmazásnak kell tör˝odnie. Ezen URI-k megadásakor ajánlott a már említett W3C XML Schema által ajánlott típusokat használni az egyértelm˝uség biztosítására. Példa adattípus használatára: 2011-03-30 Az XML séma által támogatott további típusokról a W3X XML Schema specifikációjában olvashatunk [11].
2.2.7. Következtetés Ahogy azt a fejezet elején is leírtam, a szemantikus világháló ötlete a metainformációk közlése mellett az információk alapján történ˝o következtetésre is épül. Ezen következtetéseket viszont az eddig ismertetett módszerekkel nem lehet elvégezni. Ehhez szükség van olyan eszközökre, amelyekkel a tulajdonságok és az osztályok közötti kapcsolatokat tudjuk ismertetni, és ha szükséges, létre is hozhassunk új tulajdonságokat és osztályokat. A fejezet els˝o példájával elmagyarázva, létrehozhatunk egy Macska és egy Eml˝os osztályt, és leírhatjuk a köztük lév˝o tartalmazási viszonyt, hogy a Macska egy speciális Eml˝os osztály, más szóval annak leszármazottja. Emellett arra is szükség van, hogy kijelenthessük, hogy a Macska és a Cica osztály ekvivalens, tehát kezeljük a szinonimákat. Ezeket az eszközöket az RDF sémák biztosítják.
2.2.8. RDF sémák Az RDF sémák ismertetését azzal kezdeném, hogyan is lehet kijelenteni egy er˝oforrásról,
hogy
az
osztály.
Az
RDF 15
m˝uködéséb˝ol
adódóan
ebben
az
eset-
ben sem hozzuk létre az új osztályt. Ezt úgy tehetjük meg, hogy az er˝oforrás
típusának
a
http://www.w3.org/2000/01/rdf-schema#Class
érté-
ket adjuk, vagyis az rdf:type értékeként az rdfs:Class er˝oforrást tüntetjük fel,
kijelentjük, hogy az adott er˝oforrás az rdfs:Class osztály példánya. Az osztály-alosztály viszonyt az rdfs:subClassOf tulajdonsággal írhatjuk le. Az RDF séma a többszörös örökl˝odés elvét vallja, vagyis egy osztálynak tetsz˝oleges számú szül˝oosztálya lehet, emellett tetsz˝oleges számú gyermek osztálya lehet, és az örökl˝odés tranzitív. Példa osztály és tulajdonság definiálására és a kapcsolatok ismertetésére: Eml˝ osök osztályaMacskák osztálya <születésDátuma rdf:datatype= "xs:date">2000-01-01 <Macska rdf:ID="Garfield"> <születésDátuma rdf:datatype= 16
"xs:date">1978-06-19 A fenti példában használom az rdfs:comment tulajdonságot, ami arra szolgál, hogy ember számára érthet˝o rövid szöveges leírást adjunk. Általunk létrehozott osztály példányosítására is láthatunk példát rövid és hosszú alakban is. Láthatjuk, hogy tulajdonságot hasonló módon lehet megadni, mint osztályt, a különbség az, hogy a tulajdonság az rdf:Property osztály példánya. Tulajdonságok esetén is definiálhatunk o˝ s-leszármazott viszonyt, erre a rdfs:subPropertyOf tulajdonság szolgál. Ebben az esetben is tranzitív a viszony. Az rdfs:domain segítségével az adott tulajdonság értelmezési tartományát adhatjuk meg, az rdfs:range tulajdonsággal értékkészletet adhatunk meg. Egy tulajdonság értelmezési tartománya és értékkészlete az rdfs:domain és rdfs:range tulajdonságok értékeként megadott osztályok vagy adattípusok. RDF kijelentés esetén ezen tulajdonságok alanyának és tárgyának az adott osztályok példányait kell megadnunk. A tulajdonságok alapértelmezett értelmezési tartománya és értékkészlete az rdfs:Resource, ez annyit tesz, hogy ha ezekre nincs megadva explicit megszorítás, akkor az adott tulajdonság tetsz˝oleges osztályba tartozó er˝oforrásra alkalmazható. Ha több értelmezési tartományt adunk meg, akkor az értelmezési tartomány a megadott osztályok metszete lesz. Ugyanez érvényes az értékkészletre is. Az RDF séma által kínált további lehet˝oségekr˝ol az RDF séma specifikációjában olvashatunk b˝ovebben [5].
2.2.9. Tulajdonságközpontúság Bár az RDF-nek is van osztály és példány fogalma, az objektum-orientált szemlélettel ellentétben az RDF egy tulajdonságközpontú nyelv. Ez annyit tesz, hogy a tulajdonságokat csak „futási id˝oben” rendeljük hozzá az er˝oforrásokhoz, vagyis az osztály definiálásakor még nem adjuk meg, hogy azok példányai milyen attribútumokkal fognak rendelkezni. Ez nagyobb rugalmasságot biztosít, mert egy létez˝o osztály példányához bárki bármilyen tulajdonságot hozzárendelhet, szemben az objektum-orientált rendszerekkel, ahol a példány csak és kizárólag azokkal a tulajdonságokkal rendelkezhet, amiket már el˝ore definiáltak az osztályában. A tulajdonságközpontúság közel áll az emberi gondolkodáshoz, mert ezzel a módszerrel egy rendszer képes az új ismeretek dinamikus rögzítésére, ezért alkalmasabb a világháló leírására is, mint a statikusabb objektum-orientált szemlélet.
17
2.2.10. RDF összefoglalás A szemantikus világháló megalapozásának második legnagyobb lépése az XML után az RDF megjelenése. Bemutattam az RDF leggyakrabban használt szintaxisait, legf˝oképpen az XML szintaxist, ami megfelel˝o alapja lehet a szemantikus web elterjedésének. Ismertettem, hogyan, milyen szerkezeteket használva lehet felépíteni egy RDF leírást. Kitértem arra is, hogy RDF leírást bárki készíthet, ezért az RDF rendelkezik egy olyan szerkezettel, amivel jelölhetjük, kihez tartoznak az adott kijelentések, viszont ebb˝ol adódik egy jelenleg még megoldaltlan probléma, mégpedig az, hogy semmi sem garantálja, hogy egy állítás igaz. Ez egyébként jellemz˝o a web mai formájára is, bár már vannak sikeresnek mondható eredmények a hamis tartalmak kisz˝urésére, például a Google PageRank algoritmusa kisebb prioritást rendel a rosszabb hír˝u oldalakhoz. A konténerek, kollekciók használatával struktúráltabbá tehetjük közölni kívánt adatainkat, az adattípusok segítségével pedig segíthetjük a feldolgozó alkalmazásokat. Bemutattam, hogyan lehet megvalósítani az RDF sémák segítségével, hogy az RDF által közölt információk alapján a feldolgozók következtetni tudjanak. Az RDF keretrendszer ismertetését a típusközpontúság kifejtésével zártam. Megemlíteném még az OWL webontológia nyelvet, ami az RDF sémáknál komplexebb módon teszi lehet˝ové, hogy következtetéseket vonjunk le a metaadatok alapján. Szakdolgozatomat egy RDF alapú szótár, a DOAP tárgyalásával folytatom. Szemantikus Web fejezetem utolsó szakasza fontos tudnivalókat tartalmaz Apache Maven b˝ovítményem funkcionalitásának megértéséhez, hiszen pluginom segítségével DOAP dokumentumot állíthatunk el˝o.
2.3.
DOAP
A DOAP9 egy XML/RDF alapú szókészlet, melynek segítségével (els˝osorban nyílt forráskódú) szofterprojekteket írhatunk le. A projekt nevét az RDF keretrendszernél már említett FOAF ihlette. A DOAP együttm˝uködést nyújt más népszer˝u web metaadat projektekkel, mint például az RSS, a FOAF és a Dublin Core. Az ily módon elkészített dokumentumban megadhatjuk szoftver projektünk nemzetköziesített leírását, a projekthez kapcsolódó személyeket és a webes er˝oforrásokat is. A DOAP támogatja projektek szoftverkönyvtárakhoz rendelését, a szoftverkönyvtárak közötti adatcserét és tárolók automatikus konfigurációját. 9
Description of a Project
18
2.3.1. Szintaxis Edd Dumbill – a projekt vezet˝oje – elgondolása az volt, hogy amellett, hogy a DOAP leírásokat számítógép által könnyen feldolgozhatóra tervezzék, a szótárak „emberi fogyasztásra” is alkalmasak legyenek. Amint azt már az el˝oz˝o fejezetekben tárgyaltam, ennek megoldására a ma ismert legmegfelel˝obb technológia az XML, vagy méginkább az XML szintaxist használó RDF. A szemantikus web leírónyelveként az RDF már igen elterjedt, néhány ember azonban kerüli ezt a megoldást azzal a magyarázattal, hogy az RDF is XML formátum, és igazi el˝onyét nem tudjuk kihasználni, amíg nem RDF-et támogató feldolgozó eszközt használunk, ezért o˝ k a tisztán XML alapú reprezentáció hívei. Az efféle szerializációnak is megvannak a maga nehézségei. A dokumentum struktúra megválasztásához több sémanyelv is igénybe vehet˝o, amiknek különböz˝o a kifejez˝oereje és az eszköztámogatottsága. A DTD10 annak ellenére, hogy még mindig nagyon elterjedt, elég primitív, szegényes az eszköztámogatottsága. A W3C XML Schema már sokkal rugalmasabb, de szintaxisa és annak használata kissé nehézkes. A RELAX NG-t viszont Edd Dumbill egy ígéretes újoncnak tartja, ami könnyebben megérthet˝o, mint a W3C XML Schema. Rendelkezik XML és nem-XML szintaxissal is, eszközöket nyújt az ezek közti konverzió megvalósítására, továbbá könnyen konvertálható a fentebb említett sémanyelvekre is. A nem-XML szintaxis jóval tömörebb és átláthatóbb, így szerkeszt˝oprogram nélkül is könny˝u megírni. A DOAP tisztán XML alapú reprezentációjához ezért a RELAX NG a legkézenfekv˝obb megoldás, viszont még mindig fennáll egy probléma, ami az XML jellegéb˝ol adódik. Habár a szintaktika jól definiált, az XML nem mond semmit az elemek szemantikájáról. Az RDF séma megengedi, hogy például egy szoftver projekt tulajdonosa a creator Dublin Core tulajdonság altulajdonsága legyen, ezért bármilyen RDF alkalmazás, ami tudja kezelni a Dublin Core-t, a DOAP adatkezelésének legalább az alapjaival tisztában van. Ezzel szemben egy tiszta XML dokumentum nem jelent semmit egy olyan alkalmazásnak, amibe explicit módon nincs belekódolva, hogyan dolgozza fel a DOAP névteret, még ha rendelkezik is a megfelel˝o sémával.
2.3.2. Adatok szerkezete A szoftverkönyvtár weboldalak, mint például a GNOME, OMF, Sourceforge nem feltétlenül ugyanazokat a metaadat elemeket használja. Ezen oldalak közül a legtöbben egy egyszer˝u modellt alkalmaznak, ahol a projekt egy önálló egyed, metaadatai pedig ennek az egyednek egyszer˝u tulajdonságai. Összetett tulajdonságot többféleképpen is meg lehet adni. Egyik példa, ha a tulajdonság tartománya az emberek halmaza. Egy embert ugyebár nem lehet csupán a nevével 10
Document Type Definition
19
azonosítani. A 2.2 ábrán a példámhoz tartozó részleges egyed-kapcsolati diagramot láthatjuk, melynek forrása Edd Dumbill XML Watch: Describe open source projects with XML cikkének második része [8].
2.2. ábra. Egyed-kapcsolati diagram Mivel az összetett tulajdonságokat diagramon könnyen reprezentálhatjuk kapcsolattal, ezért a kihívás nem a modellezésben, hanem inkább abban rejlik, hogy a DOAP-ot úgy tervezzük meg, hogy könnyen el˝oállítható és feldolgozható legyen. Ahhoz, hogy hatékonyan manipuláljuk a szótárunkban leírt adatokat, ki kell jelölnünk legalább egy tulajdonságot projektünk azonosítására. Ez ahhoz hasonló, mint mikor egy adatbázistáblában lév˝o oszlopot kijelölünk els˝odleges kulcsnak, azzal a különbséggel, hogy itt nem elég egy lokálisan egyedi kulcsot választani, ha DOAP-unkat közzé szeretnénk tenni a weben. A DOAP egyik alapelve, hogy decentralizált, vagyis a leírásokat anélkül el lehet készíteni, és meg lehet osztani, hogy egy bizonyos weboldalon regisztrálni kellene. Ahogy azt már az RDF tárgyalásánál említettem, a világhálón egy elem globális azonosítására a legmegfelel˝obb módszer, ha hozzárendelünk egy URI-t. Mivel a nagyobb szoftver projekthez tartozik weboldal, projektünk azonosítására feltüntethetjük weboldalának címét. Ha csak egy nevet használnánk erre a célra, a világhálón könnyen el˝ofordulhatna duplikáció a projektnevekre vonatkozóan. Projekt weboldal URI-kkal ez a probléma nem áll fenn a DNS rendszernek köszönhet˝oen. A webcímek er˝oforrásleíróként használatának viszont hátránya is van, ez pedig a változékonyság. Egy weboldal például már nem lesz elérhet˝o, ha a domain el˝ofizetés lejár, és azt nem hosszabbítják meg. Emellett példa lehet e változékonyság szemléltetésére, ha egy projekt tulajdonosának személye változik és emiatt az er˝oforrások is változnak – például a projektet felvásárolja egy másik cég –, a tulajdonos domain-t vált, és így tovább, ilyenkor DOAP leírásunk 20
érvényét veszti. Ennek a problémának a megoldására a DOAP lehet˝ové teszi, hogy dokumentumunkban feltüntessünk egy, vagy akár több old home page tulajdonságot. Az egyetlen megszorítás, hogy az ilyen tulajdonságokban megadott URI-kat más projektek soha nem használhatják. Ha egy projekt weboldalának címe megváltozik, és a projekt leírására több független DOAP létezik, de csak az egyikben szerepel az új cím home page tulajdonság értékeként, viszont tartalmaz egy old home page tulajdonságot a régi URI-val, a feldolgozók felismerik, hogy ugyanarról a projektr˝ol van szó. Ezt a módszert alkalmazzák egyébként FOAF projektben is. DOAP leírás készítésekor alaposan fontoljuk meg, hogy mely tulajdonságok értékénél használunk literálokat, és melyeknél URI-t. Ott, ahol fontos, hogy egy metaadat plusz információt hordozzon, esetleg számítógép által ellen˝orizhet˝o legyen, használjunk URI-t, például általánosan ismert licenszek feltüntetésekor használjuk azok URI-ját, saját licensz megadásakor webtárhelyünkön hozzunk létre egy külön RDF dokumentumot licenszünk ismertetésére, és rendeljünk hozzá egy URI-t. Ilyenkor persze szintén fennállhat az a probléma, hogy az URI megváltozik, és a régi URI feletti irányítást elveszítjük. Erre Edd Dumbill XML Watch: Describe open source projects with XML cikkének második részében [8] említett megoldása: használjuk a purl.org-ot, vagy ehhez hasonló szolgáltatást, ami garanciát ad az ott regisztrált URI-nk élettartamára. A továbbiakban példákkal illusztrálom, hogyan is néz ki egy RDF sémával reprezentált DOAP. Következ˝o példámat Edd Dumbill XML Watch: Describe open source projects with XML cikkének harmadik részéb˝ol [9] vettem, ami magáról a DOAP projektr˝ol szóló DOAP leírást mutatja be: DOAP2004-05-04 <shortdesc xml:lang="en"> Tools and vocabulary for describing community-based software projects. <description xml:lang="en"> DOAP (Description of a Project) is an RDF vocabulary and associated set of tools for describing communitybased software projects. It is intended to be an interchange vocabulary for software directory sites, and to allow the decentralized expression of involvement in a project. 21
<maintainer> Edd Dumbill Fontos szabályok DOAP írásakor: • Az osztályok nevét nagy kezd˝obet˝uvel írjuk, mint ahogy az látható a Project-nél és a Person-nál, ez egy RDF konvenció. A tulajdonságok nevét csupa kisbet˝uvel írjuk. • Egy DOAP dokumentum legküls˝o eleme a Project. Az RDF szintaxis [6] megengedi az rdf:RDF gyökérelem elhagyását, amennyiben a leírás megadható egy küls˝o elemmel. • A DOAP névterének URI-ja http://usefulinc.com/ns/doap# • Az xml:lang attribútum a tulajdonságok értékeként megjelen˝o szöveg nyelvét jelöli. Egy DOAP leírásban három osztály is felhasználható: • Project: a projekteket reprezentáló er˝oforrás osztálya • Version: a kiadott szoftverek verzióit reprezentáló osztály • Repository: egy verziókezel˝o rendszer tárolóját reprezentáló példány osztálya A Repository-nak vannak alosztályai is, ezeket a Project osztály tárgyalása után mutatom be. A Project osztály A Project a DOAP f˝oosztálya, minden példány egyedien azonosított a saját weboldalának URI-jával. Emellett ajánlott a projekt leírásban felt˝untetni az old home page URI-kat is, hogy a home page változásakor is lehessen azonosítani a projektet. A projekt lehetséges tulajdonságai rövid magyarázattal:
22
Tulajdonság
Leírás
name
A projekt neve.
shortname
A projekt rövid neve, amit gyakran fájlneveknél használnak.
homepage
A projekt weboldalának URI-ja, ami csak ehhez a projekthez van rendelve.
old-homepage
A projekt régi weboldalának URI-ja, ami csak ehhez a projekthez van rendelve.
created
A projekt létrehozásának dátuma YYYY-MM-DD formátumban.
description
A projekt szöveges leírása.
shortdesc
A projekt rövid szöveges leírása (8-9 szó).
category
Egy URI, ami egy a projekthez rendelt kategóriát azonosít.
wiki
A projekthez rendelt Wiki URI-ja.
bug-database
Egy hibakövet˝o rendszer URI-ja, vagy egy e-mail cím, amire a projekttel kapcsolatos hibákat jelenthetjük.
screenshots
Egy a projekt képerny˝oképeit tartalmazó weboldal URI-ja.
mailing-list
A projekthez tartozó levelez˝olista URI-ja.
programming-language A projekt implementálására használt nyelv. os
Az az operációs rendszer, amin a projekt fut (platformfüggetlenség esetén elhagyhatjuk).
license
A projekt licenszének URI-ja.
download-page
Az az URI, amir˝ol a projekt letölthet˝o.
download-mirror
Egy letöltési tükör szerver címe.
repository
Egy doap:Repository példány, ami a projekthez tartozó forráskód tárolót adja meg.
release
Egy doap:Version példány, ami a szoftver projekt aktuális kiadását írja le.
maintainer
Egy foaf:Person példány, ami a projekt tulajdonosát vagy vezet˝ojét adja meg.
developer
Egy foaf:Person példány, ami a projekt fejleszt˝ojét adja meg.
documenter
Egy foaf:Person példány, ami a projekt dokumentáló munkatársát adja meg.
translator
Egy foaf:Person példány, ami a projekt fordító munkatársát adja meg.
helper
Egy foaf:Person példány, ami a projekt olyan munkatársát adja meg, akiket más tulajdonságokkal nem lehet feltüntetni. 23
A Repository osztályok A Repository osztályt, vagyis inkább a négy alosztályát forráskód tárházak leírására használhatjuk. Az alosztályok a következ˝ok: Subversion, BitKeeper, CVS, és GNU Arch, melyek bizonyos ma elterjedten használt verziókezel˝o rendszereknek felelnek meg. Az egyes Repository alosztályokhoz tartozó tulajdonságokat szemléltet˝o táblázat: Tulajdonság Leírás SVNRep. BKRep. anon-root A névtelen módon elérhet˝o tároló elérési útja module A forráskód tárolóban lév˝o modul neve browse A tárolóhoz webböngész˝o in- * * terfészének URL-je location Az arhívum URI-ja * *
CVSRep. ArchRep. * *
*
* *
E rendszerek használatára Edd Dumbill XML Watch: Describe open source projects with XML cikkének harmadik részéb˝ol [9] választottam példákat: Subversion: <SVNRepository>
A Version osztály A verziókövetés nem része a DOAP-nak, így új kiadás esetén az aktuálishoz külön DOAPot kell készítenünk. A Version osztály reprezentálja a szoftver kiadásait. A Version osztály tulajdonságai és azok lehetséges értékei: • A branch tulajdonság értéke egy karakterlánc, ami a verzió ágát jelzi, mint például stable, unstable, gnome24, vagy gnome26. • A name tulajdonság értéke egy kiadásnév, mint például Ubuntu 10.04-nél Lucid Lynx. • A created tulajdonság értéke a kiadás dátuma YYYY-MM-DD formátumban. • A revision tulajdonság értéke A kiadás verziószáma, mint például 1.0. Példa egy Ubuntu kiadás DOAP leírására: stableMaverick Meerkat10.102010-10-10 Minden projektnek lehet több aktuális kiadása, ezért van szükség a branch tulajdonságra. Gyakori az olyan eset is, hogy egy projekt rendelkezik egy stabil ággal, miközben kiadnak hozzá egy instabilt is új funkcionalitások tesztelésére.
2.3.3. DOAP séma A DOAP sémában találhatók a DOAP osztályok és a tulajdonságok formális definíciói. RDF sémaként írták és kölcsönvettek hozzá egy tulajdonságot az OWL ontológia nyelvb˝ol, hogy az azonosító tulajdonságokat jelölje (amiket az OWL nyelvben inverz funkcionális tulajdonságoknak neveznek). A DOAP-ot tiszta XML dokumentumként is fel lehet dolgozni, viszont ha már RDF reprezentációt választottunk DOAP-unkhoz, ajánlott RDF-ként is feldolgozni. Ehhez számos eszköz rendelkezésünkre áll. Viszont el˝onye is van annak, hogy DOAP-unk XML szintaxissal rendelkezik, mégpedig az, hogy ha készíthetünk hozzá egy XSLT stíluslapot, amellyel könnyen olvasható HTML formátumba alakíthatjuk.
25
2.3.4. DOAP összefoglalás Szemantikus Web fejezetemet a DOAP szókészlet ismertetésével zárom, mely segítségével szoftver projektekr˝ol készíthetünk XML/RDF alapú leírásokat, azzal a céllal, hogy közzétehessük azt a szemantikus világhálón. Bemutattam, hogy a DOAP milyen eszközöket biztosít szoftverünk rövid ismertetésére, a hozzá kapcsolódó licenszek leírására, a verziószám jelzésére, és még néhány fontos dologra, mellyel egyértelm˝uen azonosíthatjuk projektünket.
2.4.
Szemantikus Web összefoglalás
Ebben a fejezetben ismertettem, hogy milyen céllal született a szemantikus világháló elgondolás, melynek alapja a weben található er˝oforrásokhoz metaadatok rendelése, és ezen metaadatok segítségével következtetések levonása. Említettem, hogy metaadatokat manapság már több eltér˝o technológia is használ, ám ezek többnyire eltér˝o formátumban jelennek meg. A szemantikus web célja, hogy ezek a metaadatok egy egységes, mindenki számára könnyen feldolgozható formátumban legyenek közzétéve, hiszen a világháló célja, hogy mindenki könnyen információhoz juthasson. Ilyen formátumot igen elterjedt körben használnak már ma is, ez pedig az XML. Ezen formátum ismertetésére az XML fejezetben bemutattam a szintaxisát, és az XML sémákat, melyekkel megszorításokat tehetünk az XML dokumentumok tartalmára és szerkezetére, a feldolgozó alkalmazások közti félreértések elkerülése végett. A következ˝o fejezetben bemutattam az XML szintaxissal is rendelkez˝o RDF keretrendszert, mellyel a metaadatok közzétételét nagyon jól meg lehet valósítani az RDF kijelentései segítségével. Az RDF sémákkal pedig biztosíthatjuk, hogy a feldolgozó szoftverek képesek legyenek következtetéseket levonni az RDF dokumentumok által közölt metaadatok alapján. A fejezetet annak az RDF alapú szókészletnek, a DOAP-nak az ismertetésével zártam, mely formátumú leírás b˝ovítményem által készíthet˝o. A következ˝o fejezetben bemutatom az Apache Maven-t, azt a projektkezel˝o rendszert, melyhez a b˝ovítményemet fejlesztettem.
26
3. fejezet Maven A Maven az Apache Software Foundation (Apache Szoftver Alapítvány) szoftverprojekt kezel˝o eszköze. Eredetileg a Jakarta Turbine projekt build folyamatainak egyszer˝usítése céljából készítette az alapítvány, majd továbbfejlesztve egy könnyebb módszert akartak adni projekt információk közzétételére és JAR1 vagy WAR2 állományok megosztására. Az eredmény a mai Maven, amivel kezelhetünk bármilyen Java alapú projektet egy POM (Project Object Model) által reprezentált információk alapján. Kezelhetjük projektünk fordítását, dokumentálását és jelentéseket generálhatunk segítségével. Mivel a Maven valójában egy keretrendszer, mindezt pluginokon keresztül valósítja meg. Külön plugin kezeli a fordítás folyamatát, a weboldal generálását a forráskódban lév˝o dokumentáció és a POM alapján, és még számos funkciót. Generálhatunk vele webszájtot is, amibe API dokumentációt, kódlefedettségi ellen˝orzés eredményét és egységteszt eredményeket is belegeneráltathatunk, megkönnyítve ezzel a tesztelés fázisát. A kiadások elkészültével egy paranccsal JAR, vagy WAR állományt generálhatunk, amikbe a Maven automatikusan beágyazza a futtatáshoz szükséges függ˝oségeket, értem ezalatt a már korábban esetleg más gyártó által készített komponenseket. A folytatásban kifejtem, hogyan is néz ki a POM.
3.1.
POM
A POM valójában egy XML dokumentum – melynek hagyományosan a pom.xml nevet szokták adni –, amiben értelemszer˝uen XML elemekkel adhatjuk meg projektünk nevét, rövid leírását, esetleg weboldalát, fejleszt˝oi nevét, elérhet˝oségeit, a projektre vonatkozó licenszeket. Emellett a kezeléshez szükséges pluginokat és a (fordításra, tesztelésre vonatkozó, stb.) függ˝o1 2
Java Archive File Web Archive File
27
ségeket is rögzítenünk kell ebben az állományban.
3.1.1. Kötelez˝o POM elemek Bár a POM-nak számos eleme van, amikkel projektünkr˝ol információt szolgáltathatunk, vagy a vezérléséhez szükséges információkat írhatjuk le, kötelez˝oen csupán a következ˝o elemeket kell tartalmaznia: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0 hu.csoport.maven <artifactId>projektem 1.0 • A modelVersion elem a POM verziószámára vonatkozik. A Maven 2 és 3 jelenleg csak a 4.0.0 verziószámú POM-ot támogatja, tehát ha ezen Maven verziók valamelyikével dolgozunk, a modelVersion értékének kötelez˝oen 4.0.0-nak kell lennie. • A groupId egy csoportazonosító, amelynél gakori a fordított domain nevek használata. Az adott projekt azonosítását segíti el˝o, általában egyedi egy szervezetre vagy projektre nézve. • Az artifactId általában a projekt neve, ami egyértelm˝uen azonosítja a projektet, ezért egy szervezeten belül egyedinek kell lennie, hogy egy tárházban az azonos groupId alatt tárolt projektek között is elkerüljük a névütközést. • Mivel egy projekt általában több verzióval is rendelkezik, és ezeket a verziókat nem dobjuk el az újabb megjelenésekor, szükség van a version elemre is, hogy azonosítsuk, a projekt mely verziójáról is van szó.
3.1.2. További POM elemek Csomagolás A packaging elemmel megadhatjuk projektünk csomagolásának módját, vagyis azt, hogy milyen formátumba szeretnénk csomagolni a kimenetként el˝oállt állományokat. Ezen elem lehetséges értékei: pom, jar, maven-plugin, ejb, war, ear, rar, par. A packaging 28
elem alapértelmezett értéke jar, tehát ha nem adjuk meg ezt az elemet, a Maven jar fájlba csomagolja a projektet. Függ˝oségek A POM egyik legfontosabb opcionális eleme a dependencies, mellyel megadhatjuk projektünk függ˝oségi listáját, egy-egy függ˝oséget a dependency elem definiál. A dependencies számos dependency elemet tartalmazhat. Számos projekt függhet egy másiktól, például ha egy olyan szoftvert fejlesztünk, amihez relációs adatbázis szükséges, függ˝oségként megadhatjuk például az Oracle JDBC meghajtóját, vagy más adatbáziskezel˝o modult. Függ˝oségkezelésre szükség van akkor is, ha egy komplex szoftverhez csak egy komponenst fejlesztünk. Elég, ha ezeket a függ˝oségeket felsoroljuk a POM-ban és a Maven automatikusan kezeli o˝ ket helyettünk. Ha a függ˝oség elérhet˝o a Maven központi tárolójában – ami a legtöbb esetben igaz –, le is tölti nekünk, a projekt csomagolása esetén pedig akár be is illeszti a futáshoz szükséges függ˝oségeket (például JAR, WAR, vagy egyéb) állományunkba. Ha azonban az adott függ˝oség tárgya nem érhet˝o el a központi tárolóban – általában nem nyílt forráskódú tartalomnál, vagy saját fejlesztés˝u komponensnél –, azt saját tárolónkba kell telepítenünk, miel˝ott felhasználnánk. A dependency elem gyermekei lehetnek a már ismertetett projektet azonosító alapelemek, a groupId, a arrifactId, és a version. A továbbiakban bemutatok még néhány elemet, melyekkel a dependency gyermekeként további információkat adhatunk meg a függ˝oség tárgyáról: • A type elemmel a csomagolás típusát adhatjuk meg, értékei megegyeznek a packaging elem értékeivel. • A scope elemmel írhatjuk le, projektünk mely életciklusában van szükség az adott függ˝oségre. Alapértelmezett értéke a compile, ami azt jelenti, hogy a függ˝oség tárgyára a fordításnál van szükség. További értékei: – A provided hasonló a compile-hoz, azzal a különbséggel, hogy elvárjuk, hogy futás közben a futtató biztosítsa nekünk az adott függ˝oség tárgyát. – A runtime érték azt jelenti, hogy az adott függ˝oség csak futás közben szükséges, fordításkor nem. – A test érték azt jelöli, hogy az adott függ˝oség csak a tesztelésnél szükséges, az alkalmazás normál futása közben nem.
29
– A system hasonló a provided-hez, azzal a különbséggel, hogy mi biztosítjuk a függ˝oség tárgyát. • A systemPath elemet csak akkor használhatjuk, ha a scope elem értéke system. Ilyenkor egy abszolút elérési utat kell megadnunk ezen elem értékeként. Rendszerspecifikus elérési út esetén ajánlott a tulajdonság használata, mint például a ${java.home}/lib. • Az optional elemre akkor lehet szükség, ha projektünk szintén egy függ˝oség tárgya. Kizárások Kizárásokat akkor használhatunk, ha egy függ˝oségünk tárgyának függ˝oségét nem akarjuk használni projektünknben. A kizárások listáját a dependency elemen belül az exclusions elemmel adhatjuk meg, ezen belül egy kizárást az exclusion elemmel. Egy kizárandó függ˝oséget a groupId és az artifactId elemek értékeként adhatjuk meg. Örökl˝odés Projektünket származtathatjuk más projektb˝ol is, ilyenkor a szül˝o projekt egyes tulajdonságai (mit például a függ˝oségek, fejleszt˝ok, b˝ovítmény beállítások, stb.) örökl˝odnek. B˝ovebben az örökl˝odésr˝ol a [3]-ban olvashatunk. Aggregáció A több modulból álló projektet aggregátor projekteknek is nevezzük. A modulokat a modules elemben kell felsorolni, egy-egy modul nevét a module elem értékeként kell feltüntetni. Példa egy aggregátor projekt POM-jára: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0 hu.csoport.maven <artifactId>projektem 1.0 <packaging>pom <modules> 30
Build folyamat kezelése Projektünk build folyamatát a nyitó és záró build elemek közötti alelemek megadásával konfigurálhatjuk. Erre számos eszköz áll rendelkezésünkre, mint például a defaultGoal elem, mellyel beállíthatjuk, hogy projektünk felépítése után a futtatás helyett például automatikusan tárolónkba települjön, a directory elem, mellyel megadhatjuk, hogy az alapértelmezett target könyvtár helyett milyen könyvtárba építse fel projektünket. Ezen kívül átállíthatjuk a projekt alapértelmezett forráskönyvtárait is, ha a resources elemen belül megadunk egy listát resource elemekkel – viszont a forráskódot és a teszteseteket tartalmazó könyvtárakat a build elemen belül rendre a sourceDirectory és a testSourceDirectory elemekkel állíthatjuk be –, megadhatjuk a build folyamathoz szükséges b˝ovítményeket a plugins elemen belüli plugin elemekkel. További projekt információk Projektünknek a name elemen belül adhatjuk meg egy az artifactId elemen belül megadottnál beszédesebb nevet, a description elem segítségével egy szöveges leírást közölhetünk projektünkr˝ol, az url elemen belül pedig projektünk weboldalának címét ismertethetjük. A projekt licenszeit a licenses elemen belül felsorolt license elemek értékével ismertethetjük. Ha a projekt egy vállalat tulajdonát képezi, a vállalat nevét és weboldalát az organization elemben közölhetjük. Természetesen a fejleszt˝oket is felsorolhatjuk, ezt a developers elem gyermekeivel, a developer elemekkel tehetjük meg. Az ügyfelekkel való kapcsolattartás céljából egy levelez˝olistát is megadhatunk a mailingLists elem segítségével. A projektünkhöz kapcsolódó tárolókat a reporsitories elemen belül sorolhatjuk fel. A POM által nyújtott eszközökr˝ol részletesebben a [3]-ban olvashatunk.
31
3.2.
Maven összefoglalás
Ebben a fejezetben az olvasó betekintést nyerhetett a Maven m˝uködésébe és a Maven projektek lelkébe, a POM felépítésébe. Bemutattam, milyen eszközökkel lehet leírni egy Maven által kezelt Java projektet. Ezen tudásra építve a következ˝o fejezetben ismertetem az Apache Maven b˝ovítményfejlesztés alapjait.
32
4. fejezet Maven plugin A Maven plugin egy vagy több egymással kapcsolatban lév˝o úgynevezett MOJO-ból1 áll. Egy Maven b˝ovítmény projekt tehát nem más, mint Java osztályok és a projektet leíró POM állomány együttese. Hogy kódunk futtatható Maven plugin legyen, a b˝ovítmény f˝o osztályában meg kell adni egy @goal cél Javadoc annotációt, ahol a cél egy tetsz˝oleges Java azonosító. Az ilyen Javadoc annotációval rendelkez˝o osztályokat a plugin konfigurációs állományában is fel kell tüntetni. Példa egyszer˝u MOJO-ra: package simple.plugin; import org.apache.maven.plugin.AbstractMojo; import org.apache.maven.plugin.MojoExecutionException; /** * Kiírja a "Helló világ!" szöveget. * @goal sayhi */ public class SimpleMOJO extends AbstractMojo { public void execute() throws MojoExecutionException { getLog().info("Helló világ!"); } } MOJO-nknak ezen kívül az org.apache.maven.plugin.AbstractMojo absztrakt osztályt is ki kell terjeszteni, amely biztosítja a MOJO implementálásához szükséges infrastruktúrát, kivéve az execute metódust, melynek implementálása a mi dolgunk. A példában látható kötelez˝o Javadoc annotáció melett számos Javadoc annotáció áll rendelkezésünkre, amivel beállíthatjuk, hogyan és mikor fusson MOJO-nk, ezekb˝ol néhányat kés˝obb ismertetek. 1
Maven plain Old Java Object
33
Az execute metódus két kivételt dobhat, hogy informálja az o˝ t futtató Maven-t az esetlegesen bekövetkez˝o hibákról: • org.apache.maven.plugin.MojoExecutionException-t, ha a MOJO nem várt problémába ütközik. E kivétel eldobása esetén a BUILD ERROR üzenetet kapjuk. • org.apache.maven.plugin.MojoFailureException-t, ha várt probléma történik (mint például fordítási hiba). Eldobás esetén szintén BUILD ERROR üzenetet kapunk. Az AbstractMojo-ban definiált getLog metódus egy naplózó objektummal tér vissza, ami lehet˝ové teszi, hogy a plugin debug, info, warn, és error szint˝u üzeneteket küldhessen a felhasználónak. A plugin elkészítéséhez a MOJO megírása után már csak annyi a teend˝o, hogy a projektleíróban – a POM-ban – elvégezzük a megfelel˝o beállításokat. A groupId-t, az artifactIdt és a version-t a már ismertetett módon kell megadni. Emellett be kell állítani a maven-plugin értéket a packaging elemre, és a dependencies elemnek legalább egy függ˝oséget meg kell adni, ami a Maven Plugin Tools API-ra vonatkozik, hogy feloldjuk az AbstractMojo-t és a hozzá kapcsolódó osztályokat. Példa SimpleMOJO osztályom leírójára: <project> <modelVersion>4.0.0 simple.plugin <artifactId>hello-maven-plugin <packaging>maven-plugin 1.0Egyszer˝ u Helló Világ Maven Plugin <dependencies> <dependency> org.apache.maven <artifactId>maven-plugin-api 2.0 Kész Maven b˝ovítményünk használatához a következ˝o parancsokat kell kiadnunk: • mvn compile – lefordítja a plugin Java kódját • mvn test – futtatja a plugin egységtesztjeit 34
• mvn package – felépíti a plugin JAR-t • mvn install – a plugin JAR-t a helyi tárolóba telepíti • mvn deploy – a plugin JAR-t a távoli tárolóba telepíti
4.1.
MOJO futtatása
A futtatás egyik módja, hogy egy projekt POM-jában beállítjuk a következ˝oket: ... simple.plugin <artifactId>hello-maven-plugin 1.0 ... majd a parancssorban megadjuk a plugin nevét és a célt a következ˝o formában: mvn simple.plugin:hello-maven-plugin:1.0:sayhi ahol a sayhi a cél. A verziószám elhagyható, ha a legutolsó verziót szeretnénk futtatni. Ha a név-maven-plugin vagy maven-név-plugin konvenciót alkalmazzuk projektünk elnevezésére, ahol a név tetsz˝oleges, szintén lerövidíthetjük a futtatáshoz szükséges parancsot, a példa parancs a következ˝o lesz: mvn hello:sayhi Megjegyezném, hogy a maven-név-plugin konvenciót azokra a b˝ovítményekre használják, amelyek az Apache Maven projekt részei. Arra is van mód, hogy a konvenció nem betartásakor is rövidüljön a parancs, ilyenkor a $user.home/.m2/settings.xml fájlba a következ˝oket kell hozzáadni: simple.plugin
35
Pluginunkat hozzárendelhetjük egy adott projekt build életciklusának bizonyos fázisához, ha az adott projekt POM-jában megadjuk pluginunk célját például a következ˝o módon: ... simple.plugin <artifactId>hello-maven-plugin 1.0 <executions> <execution> compilesayhi ... Ezen beállítás esetén a plugin cél lefut a Java kód minden egyes fordításakor.
4.2.
Paraméterek
A paraméterek fontos szerepet játszanak a MOJO-k életében, hiszen paraméter segítségével érhetjük el egy adott projekt POM-ját, ezáltal azok elemeit és az elemek értékeit, így a MOJO m˝uveletvégzésére nézve is fontos beállításokat végezhetünk el. Paramétereket úgy definiálhatunk, hogy létrehozunk egy példányváltozót, és hozzáadjuk a megfelel˝o Javadoc annotációt. Példa egy egyszer˝u MOJO paraméterére: /** o üzenet. * Az üdvözl˝ * * @parameter expression="${sayhi.greeting}" default-value="Helló Világ!" * */ private String greeting; A @parameter Javadoc annotáció segítségével nevezhetünk ki egy változót MOJO paraméterré, aminek default-value paraméterével definiálhatjuk a változó alapértelmezett értékét. Ez az érték projektre hivatkozó kifejezéseket is tartalmazhat, mint például 36
$projekt.version. A kifejezés paraméter használatával konfigurálhatjuk MOJO paraméterünket a parancssorból, egy rendszertulajdonságra hivatkozással, amit a felhaszáló a -D kapcsolón keresztül tehet meg. Egy plugin paraméter értékének beállítását Maven 2 és Maven 3 projektben az adott projekt leírójában végezhetjük el a pluginok definiálásának részeként. Egy példa plugin konfigurálására: ... simple.plugin <artifactId>hello-maven-plugin 1.0Szervusz ... A configuration részben a greeting elem a paraméternév, aminek Szervusz tartalma az érték, amit a paraméterhez rendelünk. A továbbiakban bemutatom, milyen típusú paramétereket kezel egy Maven plugin.
4.2.1. Egyszeru˝ paramétertípusok MOJO egyszer˝u típusú paramétereihez használhatjuk a Java által ismert primitív típusokat (mint például int, boolean, char) és azok csomagolóosztályait (Integer, Boolean, Character, stb.), továbbá a Java Date, File, URL, String és StringBuffer osztályait. Példa Integer típusú paraméter értékadására POM-ból: /** * Egy Integer paraméter. * * @parameter */ private Integer anInteger; Konfiguráció: 32 A Date típusú paraméter értékadásakor a POM-ban megadott karakterlánc dátum típusúvá konvertálódik a DateFormat.parse() metódus alkalmazásával. Példa erre: 37
/** opontja. * Ezen példa megalkotásának id˝ * * @parameter */ private Date exampleDate; Konfiguráció: <exampleDate>2011-04-05 5:46:27.3 PM
4.2.2. Összetett paramétertípusok MOJO összetett típusú paraméterének használhatunk tömböt, Java kollekciókat (vagyis minden olyan osztályt, ami implementálja a java.util.Collection interfészt), olyan map osztályt, ami implementálja a java.util.Map interfészt, mint például a HashMap, de nem terjeszti ki a java.util.Properties osztályt, és olyan tulajdonság osztályt, ami kiterjeszti a java.util.Properties-t. Ez is egyfajta map, de ezt a MOJO külön kezeli. Ráadásként olyan egyéb osztályt is adhatunk meg MOJO paraméter típusának, ami nem implementálja a java.util.Map és java.util.Collection interfészt, és nem terjeszti ki a java.util.Dictionary osztályt. Példa tömb használatára: /** * Karaktertömb. * * @parameter */ private String[] stringArray; Értékadás a POM segítségével: <stringArray> <param>Wincs Eszter <param>Gipsz Jakab A listák értékadása analóg módon történik a tömbök értékadásával, Map-eknél a param elem helyett key1, key2, stb. elemeket kell megadni. A paramétertípusok részletesebb leírásáról és MOJO-beli beállító metódusok használatáról a Maven – Guide to Developing Java Plugins [2] honlapján olvashatunk.
38
4.3.
Maven plugin összefoglalás
A fejezetben bemutattam, hogy mik a Maven b˝ovítmények szerkezeti követelményei, hogyan kell felépíteni egy MOJO-t és a b˝ovítmény POM-ját. Röviden ismertettem, hogyan tudunk paramétereket definiálni pluginokhoz és ezek értékeit hogyan állíthatjuk be. Ezzel el is érkeztem szakdolgozatom tárgyához, az általam fejlesztett DOAP generáló b˝ovítményhez, amit a következ˝o fejezetben részletesen leírok.
39
5. fejezet B˝ovítményem Most, hogy a szakdolgozatomhoz felhasznált technológiákat ismertettem, rátérnék az általam fejlesztett Apache Maven b˝ovítményre, a zsolczai-doap-maven-pluginra. Pluginom lényegi része mindössze egy Java osztály és egy XSLT stíluslap, ezen eszközökkel valósítom meg a DOAP generálást egy adott projekt POM-jából.
5.1.
zsolczai.doap.DoapGenerator Java osztály
/** * A Project Object Management fájl felhasználásával egy DOAP ol. * (Description of a Project) leírást készít a projektr˝ * * @goal create */ public class DoapGenerator extends AbstractMojo { ... MOJO osztályom egy cél (@goal) Javadoc annotációval rendelkezik, melynek neve create. A plugin telepítése után parancsként a plugin nevét, és ezt a célt kell megadni, hogy futtathassuk adott Java projektünkön a már ismertetett alakban: mvn zsolczai-doap:create ... /** osegít˝ o stíluslap. * A POM fájl transzformációját el˝ / * private static final String XSL_STYLESHEET = "default.xsl";
40
/** * A DOAP fájl neve. */ private static final String DOAP = "doap.rdf"; /** * A Project Object Manage fájl. * @parameter default-value="pom.xml"; */ private File pom; ... A három MOJO attribútum közül két osztályszint˝uben tárolom rendre az XSLT stíluslap és a generálandó DOAP állomány nevét. A harmadik attribútum egy MOJO paraméter, pluginom ezen keresztül fér hozzá annak a Maven projektnek a POM állományához, amelyhez DOAP leírást szeretnénk készíteni. ... public void execute() throws MojoExecutionException { try { File targetDIR = new File("target"); File siteDIR = new File("target/site"); if (!targetDIR.exists()) { siteDIR.mkdirs(); } else if (!siteDIR.exists()) { siteDIR.mkdir(); } ... MOJO-m a belépési pontjában az execute() metódusban els˝o lépésként ellen˝orzi, hogy a cél Maven projekt rendelkezik-e a szükséges könyvtárszerkezettel a DOAP állomány tárolásához. Ha nem, akkor ez azt jelenti, hogy b˝ovítményem futtatása el˝ott a projekten nem futtattak weboldal (site) generáló plugint, ebben az esetben elkészíti a hiányzó könyvtárakat (a projekt gyökérkönyvtárában a target, azon belül a site mappát). ... getTransformer().transform(new StreamSource(pom), new StreamResult("target/site/" + DOAP)); linkDoapToHtml(); } catch(TransformerException e) { throw new MojoExecutionException( "XML transzformációs Hiba!", e); } catch(IOException e) { 41
} } ... Második lépésként a getTransformer() metódus által átadott transzformációs objektumnak (jelen esetben az XML transzformációs stíluslapnak) átadom forrás csatornaként a cél projekt POM állományát, és cél csatornaként az elkészítend˝o DOAP állományt. A DOAP generálásáért ezután a javax.xml.transform.Transformer példány gondoskodik. Ahhoz, hogy hogyan is kapom meg a kívánt transzformációs objektumot, vagyis a getTransformer() metódus implementációját kés˝obb mutatom be. A linkDoapToHtml() metódus megkísérli a cél projekt index.html oldalához linkelni a DOAP állományt metaadatként, már ha a projekthez rendelkezik a site b˝ovítmény segítségével elkészített API specifikációs weboldallal. A javax.xml.transform.TransformerException kivétel, amit pluginom egy org.apache.maven.plugin.MojoExecutionException
kivételként
dob
to-
vább, abban az esetben következik be, ha az XSLT stíluslap hibás, vagy nem létezik. java.io.IOException kivételt a linkDoapToHtml() metódus dobhat, ezt a kivételt MOJO-m csak elkapja, és nem kezeli, mert ez abban az esetben váltódik ki, ha az index.html állomány nem létezik, és ilyenkor elég, ha egyszer˝uen nem hajtódik végre a DOAP metaadatként való linkelése a weboldalhoz, nem szükséges, hogy a felhasználót informálja az állomány hiányáról. ... private static Transformer getTransformer() throws TransformerException { TransformerFactory factory = TransformerFactory.newInstance(); InputStream in = DoapGenerator.class .getResourceAsStream("/" + XSL_STYLESHEET); if (in != null) { return factory.newTransformer(new StreamSource( in)); } return factory.newTransformer(); } ... Az
el˝obbi
kódrészletben
meghívott
getTransformer()
metódus
objektum
osztály
javax.xml.transform.TransformerFactory gítségével készíti el a transzformációs
objektumot. Ha 42
a
gyár
a se-
MOJO megtalálta a
getResourceAsStream() metódus paramétereként megadott helyen lév˝o XSLT stíluslapot, akkor a transzformációs objektum e stíluslap segítségével készíti el a cél projekt POM állományából a nyert információk alapján a DOAP fájlt, ha nem találta, vagyis az in változónak null referencia adódott át, abban az esetben metódus egy üres transzformációs objektumot ad át hívójának. ... private void linkDoapToHtml() throws IOException { BufferedReader in = new BufferedReader( new FileReader("target/site/index.html")); StringBuilder index = new StringBuilder(); String line = in.readLine(); boolean linked = false; while (line != null) { if (!linked && line.contains("").append("\n"); linked = true; } index.append(line).append("\n"); line = in.readLine(); } in.close(); FileWriter out = new FileWriter("target/site/index.html"); out.write(index.toString()); out.close(); } } linkDoapToHtml() projekt
weboldalához
metódusom
metaadatként
(java.io.BufferedReader)
úgy
valósítja
linkelését,
példány
hogy
segítségével
meg
a
generált
egy
pufferelt
addig
olvassa
DOAP
cél
olvasóegység soronként
az
index.html tartalmát egy java.lang.String példányba, amíg el nem éri a zárócímkét, vagyis, amíg a weboldal fejlécének végéhez nem ér. Közben a ciklusban a sztring tartalma átíródik egy java.lang.StringBuilder példánynak, a metódus így o˝ rzi meg a HTML állomány tartalmát. Amint elér a fejléc végéhez, a zárócímke elé beilleszti a hivatkozást a StringBuilder példányba, majd folytatódik a további sorok bemásolása. A HTML 43
fájl tartalmának kiolvasása után a metódus újra megnyitja az állományt, de ezúttal felülírja azt, annak módosított tartalmával. MOJO osztályom után most következzen az XSLT transzformációs lap.
5.2.
default.xsl XSLT stípuslap
]> ... Stíluslapomhoz entitásokat deklaráltam a készítend˝o DOAP szótár által használt névterek és a leírás nyelvének kiemelésére. ... <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:pom="http://maven.apache.org/POM/4.0.0" version="1.0"> <xsl:output method="xml" encoding="UTF-8" indent="yes"/> ... A stíluslap gyökérelemében deklarálom az xsl és a pom névteret. Az xsl:output elemben megadom a kimenet formátumát, az eredmény dokumentum kódolását, és azt, hogy legyen automatikus szövegtördelés az emberi olvashatóság érdekében. ... <xsl:template match="pom:project"> <xsl:variable name="proj.homepage" select="pom:url"/> <xsl:if test="pom:name"> <xsl:value-of select="pom:name"/> ... 44
Ha a pom:project mintára illeszkedik a forrás POM egy csomópontja, vagyis van benne project elem, akkor az xsl:template gyermek elemeiként megadott szekvenciával folytatódik a program végrehajtása. A proj.homepage változóhoz hozzárendelem a pom:url értékét, ha létezik, erre a mintára való illeszkedést kés˝obb vizsgálom. Létrehozom a Project elemet, ami a DOAP leírás gyökéreleme lesz, és hozzárendelem az rdf, foaf, és doap névtér el˝otagokhoz a megfelel˝o URI-kat. Ha a stíluslap a POM-ban talál name elemet, akkor annak értékét, vagyis a forrás projekt nevét átmásolja a DOAP-ba. ... <xsl:if test="pom:url"> <xsl:if test="pom:description"> <description xml:lang="〈"> <xsl:value-of select="pom:description"/> ... Ez a kódrészlet a pom:url mintára illeszkedést teszteli, vagyis azt, hogy a POM-ban definiált-e az url elem. Ha van, létrehozza a homepage elemet, aminek rdf:resource attribútumának értékeként átadja a $proj.homepage változó értékét. Ezután azt vizsgálja, hogy a POM-ban létezik-e description elem, ha igen ezt az elemet létrehozza a DOAP-ban is, ellátja a lang entitásban tárolt értékkel, és a POM description értékét átadja a DOAP description elemnek. ... <xsl:for-each select="pom:developers/pom:developer"> <developer> <xsl:value-of select="pom:name"/> <xsl:if test="pom:email"> <xsl:variable name="mail" select="pom:email"/> <xsl:if test="pom:url"> <xsl:variable name="homepage" 45
select="pom:url"/> <xsl:if test="pom:organization"> <xsl:variable name="org" select="pom:organization"/> ... A developer elemek vizsgálatára az xsl:for-each ciklust választottam, hogy a forrás projekt minden egyes fejleszt˝oje fel legyen tüntetve a DOAP szótárban. A fejleszt˝oket a FOAF Person osztálya segítségével teszi közzé a generált DOAP, foaf:name (név), foaf:mbox (email cím), foaf:homepage (saját weboldal) és foaf:organization (a személyt foglalkoztató szervezet) elemekkel, feltéve, hogy azok meg vannak adva a POM állományban. ... <xsl:for-each select="pom:licenses/pom:license"> <xsl:variable name="proj.license" select="pom:url"/> Végül XSLT stíluslapom a license elemek létezését vizsgálja, szintén xsl:for-each ciklussal, ha a forrás POM-ban esetleg több licensz is hozzá lenne rendelve a projekthez. Ez esetben minden licenszet átvesz a DOAP leírás.
5.3.
Példa DOAP kimenetre
B˝ovítményem kimenetére bemutatok egy példát is, mely a maven-hello projektet írja le:
46
maven-hello <description xml:lang= "en">A simple hello-world project. <developer> Gergo Zsolczai <developer> En A következ˝o példa a maven-hello projekthez generált HTML oldal fejlécének forrását mutatja be, ahova b˝ovítményem beilleszt egy linket a projekt DOAP leírójáról közvetlen a head elem záró címkéje elé: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> maven-hello - About <style type="text/css" media="all"> @import url("./css/maven-base.css"); 47
@import url("./css/maven-theme.css"); @import url("./css/site.css"); <meta name="Date-Revision-yyyymmdd" content="20110422" /> <meta http-equiv="Content-Language" content="en" /> ... Végezetül bemutatnám a fentebbi maven-hello DOAP leírásomat HTML oldalként megjelenítve. Ezt a megjelenítést az OpenLink Data Explorer nev˝u szoftver segítségével lehet megvalósítani, mely kiegészít˝oként elérhet˝o a Mozilla Firefox, a Google Chrome és az Apple Safari webböngész˝okhöz. Ezen kiegészít˝o lehet˝ové teszi, hogy egy weboldal nyers adatait és a köztük lév˝o rejtett kapcsolatokat böngészhessük. Az OpenLink Data Explorer a szemantikus web egyfajta megvalósításán, a Linked Data-n alapszik. További részleteket arról, hogyan készítsük el weboldalunkat a Linked Data szellemében, Tim Berners-Lee Design Issues: Linked Data cikkében [4] olvashatunk. Ezzel el is értem Apache Maven b˝ovítményem bemutatásának végéhez, ami a felsorolt eszközökkel valósítja meg a DOAP leírás készítését egy projekt POM fájljának felhasználásával.
48
49
6. fejezet Összefoglalás Ezzel el is érkeztünk szakdolgozatom záró fejezetéhez, melyben röviden összefoglalom munkám eredményét. Az els˝o fejezetben ismertettem a Szemantikus világháló jelentését, mi rejlik ezen elgondolás mögött. Megvalósításával lehet˝oség nyílna a webes tartalmak struktúrálására az er˝oforrásokhoz rendelt metainformációk és a köztük lév˝o kapcsolatok jelölésére, és sémák segítségével az adatok alapján következtetések levonására. Ezzel hatékonyabban tudnánk a világhálón keresni, nagyobb valószín˝uséggel találnánk meg a nekünk megfelel˝o weboldalt, képet, és lényegében bármit, amire a web mai formájában oly nehezen bukkanunk rá, ha egyáltalán sikerrel jár keresésünk. Röviden bemutattam az XML nyelvet, mely sikerével bizonyítja, mennyire alkalmas különböz˝o platformmal rendelkez˝o gépek közötti adatcserére, ember általi olvashatósága pedig el˝osegíti a dokumentumban esetlegesen felmerül˝o hibák könny˝u javítását. Kitértem arra is, hogyan lehet biztosítani XML sémákkal, hogy az XML alapú adatcserét bonyolítók között ne legyen félreértés az adatok jelentését illet˝oen. Emellett kitértem a b˝ovítményem által felhasznált egyik technológiára, az XSLT transzformációs stíluslapra is, mellyel XML dokumentumok transzformálását lehet elvégezni más XML dokumetumokká. Ezután ismertettem az RDF keretrendszert, melynek XML szintaxissal rendelkez˝o formája megfelel˝o alapként szolgál a szemantikus világháló megvalósítására, az er˝oforrásokhoz metaadatok rendelésére. Bemutattam, hogy RDF sémák segítségével megvalósíthatjuk a szemantikus web másik alapgondolatát, metaadatok alapján következtetések levonását. Felhívtam a figyelmet arra, hogy amellett, hogy az RDF séma és az objektum-orientált világ között néhány hasonlóság figyelhet˝o meg, a különbség az, ami a webes tartalmak leírására alkalmasabbá teszi az OO nyelvekkel szemben, ez pedig a tulajdonságközpontúság. Ez biztosítja a rugalmasságot, hogy az állandóan változó világhálót hatékonyan tartsuk karban. 50
A DOAP bemutatásával lefedtem azokat a szemantikus webhez kapcsolódó technológiákat, melyeket felhasználtam szakdolgozatomban. Az adott fejezetben leírtam, hogy DOAP segítségével egy RDF-re épül˝o XML szintaxisú szótárat készíthetünk, mellyel – mint ahogy azt neve is mutatja: Description of a Project (egy Projekt Leírása) – szoftver projektek adatait tehetjük közzé. Mivel szakdolgozatom témája az Apache Maven b˝ovítmény fejlesztés, ezért a Maven projekt kezel˝o rendszer ismertetése sem maradhatott ki, ezért a Maven fejezetben röviden bemutattam ezen projekt kezel˝o rendszerben rejl˝o lehet˝oségeket és azokat az eszközöket, amelyeket projektünk implementációs és tesztelési fázisát kezelhetjük. A Maven plugin fejezetben pedig azokat az eszközöket ismertettem, amelyeket a Maven b˝ovítményei fejlesztéséhez biztosít. Ahogy azt már említettem a felkínált eszközökhöz a Maven részletes leírást is ad Maven – Guide to Developing Java Plugins weboldalán[2], így ehhez a fejezethez én is felhasználtam forrásként. A B˝ovítményem cím˝u fejezetben pluginom forráskódrészletei bemutatása után leírtam, hogyan és milyen m˝uveletet hajt végre az adott rész és az XML feldolgozóm milyen parancsokat kap a b˝ovítményemhez készült XSLT stíluslaptól.
51
7. fejezet Köszönetnyilvánítás Köszönetet szeretnék nyilvánítani Jeszenszky Péternek, aki témavezet˝omként segít˝okészségével nagyban hozzájárult szakdolgozatom elkészítéséhez, gyakorlatvezet˝o tanárként pedig tanulmányaim gyakorlati elmélyítéséhez. Továbbá megköszönném a Debreceni Egyetem mindazon oktatójának munkáját, akik kiváló szakmai tudásukkal hozzájárultak egyetemi szint˝u matematikai és informatikai tudásom megszerzésére, kiemelve Dr. Juhász István tanár urat, aki sajátos el˝oadásmódjával talán a legnagyobb ösztönzést adta, hogy szakmai tudásom gyarapítsam a programozás területén. Már több hallgatótársamtól hallottam és én is csak egyet érthetek velük, hogy amit o˝ tanított, arra emlékszem a legjobban, az maradt meg bennem a legrészletesebben.
52
Irodalomjegyzék [1] FOAF Vocabulary Specification. URL http://xmlns.com/foaf/spec/. [2] Maven – Guide to Developing Java Plugins. URL http://maven.apache.org/ guides/plugin/guide-java-plugin-development.html. [3] POM Reference. URL http://maven.apache.org/pom.html. [4] Tim Berners-Lee. Design Issues: Linked Data, 2006. URL http://www.w3.org/ DesignIssues/LinkedData.html. [5] Brian McBride Dan Brickley, R.V. Guha. RDF Vocabulary Description Language 1.0: RDF Schema, 2004. URL http://www.w3.org/TR/rdf-schema/. [6] Brian McBride Dave Beckett. RDF/XML Syntax Specification, 2004. URL http:// www.w3.org/TR/rdf-syntax-grammar/. [7] Edd Dumbill. XML Watch: Describe open source projects with XML, Part 1, 2004. URL http://www.ibm.com/developerworks/xml/library/x-osproj.html. [8] Edd Dumbill. XML Watch: Describe open source projects with XML, Part 2, 2004. URL http://www.ibm.com/developerworks/xml/library/x-osproj2/. [9] Edd Dumbill. XML Watch: Describe open source projects with XML, Part 3, 2004. URL http://www.ibm.com/developerworks/xml/library/x-osproj3/. [10] Murray Maloney Noah Mendelsohn Henry S. Thompson, David Beech. XML Schema Part 1: Structures, 2004. URL http://www.w3.org/TR/xmlschema-1/. [11] Ashok Malhotra Paul V. Biron, Kaiser Permanente. XML Schema Part 2: Datatypes, 2004. URL http://www.w3.org/TR/xmlschema-2/. [12] Jeszenszky Péter.
Resource Description Framework.
URL https://www.inf.
unideb.hu/~jeszy/download/semweb/RDF.pdf. 53
[13] Benk˝o Tamás Szerendi Péter, Lukácsy Gergely. A szemantikus világháló elmélete és gyakorlata. Typotex Elektronikus Kiadó Kft., 2005. ISBN 978-963-9548-48-0.
