A Semantic Web az Internet egy lehetséges jövője, mely a jelenlegi Web-et olyan extra információkkal egészíti ki, hogy a leírtakat ne csak egy személy, de a számítógép is megérthesse. Egy egységes leíró nyelv segítségével az alkalmazások emberi beavatkozás nélkül képesek kommunikálni, információt megosztani. Teljesen automatikusan működő programok nyújtanak segítséget vagy szolgáltatást. A weboldalak tematikus leírását kihasználó keresők pedig sokkal hatékonyabban működhetnek.
Káosz jellemzi leginkább a jelenkor internetes világát. Igaz, hogy még nem telt el túl sok év azóta, hogy létrehozták az Internetet, de az óta a világ - vagy legalábbis az informatikai világ - sokat változott. Akkor még nem sok számítógép volt a hálózatra kötve, most pedig már majdnem minden háztartásban van legalább egy számítógép, ami sok esetben rá is van kapcsolva erre a világméretű rendszerre. A fejlett országokban szinte alapnak számít a Net, de Magyarországon is egymást érik az internetes szolgáltatók, akik egyre olcsóbban kínálják a hozzáférést, telefonon, széles sávon vagy akár televízió-kábelen. Nincs is olyan, hogy valaki ne érhetné el a nagy rendszert. Vagy a munkahelyén, vagy ahol tanul, vagy a mobiltelefonján vagy egy kis falusi netes kávézóban. A legtöbben ugyan csak lefelé töltenek róla, de egyre-másra alakulnak a cégek, melyek immár nem engedhetik meg maguknak, hogy ne legyenek ott, vagy elég csak a magánszemélyeket néznünk: sokan vágynak arra, hogy saját honlapjuk legyen, melyen bárki megtekintheti az önéletrajzukat vagy a fényképeiket a kutyájukról-macskájukról. Mindenki "fenn" akar lenni, részt követel magának ebből az óriási hálóból. Nem csoda hát, hogy annyi blog oldal születik az utóbbi időben (a blog vagy weblog internetes naplót jelent), annyi helyen van fórum, ahol bárki hozzászólhat bármihez, és oly sok a chat és levelezési lista. Serkentővel beszórt gombák módjára szaporodnak a honlapok és mivel még mindig nő az emberi lelkek száma és még mindig van, aki egyelőre nem jutott számítógép-közelbe, nem is valószínű, hogy a gyarapodás egyhamar abbamarad. Egy ekkora rendszerben magától senki sem boldogulhat, így nagy szükség volt a keresők megjelenésére.
A gigászi méretű információtömeggel a keresőgépek sem nagyon tudnak már megbirkózni, de a felhasználók is tanácstalanul bámulnak, ha beírnak egy szót és cserébe felajánlanak nekik több százezer oldalt. A keresőket persze fejlesztik, hogy minél inkább "kitalálják", mit is keres az illető, a lapokat pedig rangsorolják, hogy azok kerüljenek előbbre, melyek tényleg a kívánt témával foglalkoznak, és nem csak véletlenül szerepel rajtuk ez a szó. A rutinosabb szörfölők is hamar beletanulnak, hogy hogyan érdemes megadni a kérdésüket, hogy megfelelő címeket kapjanak vissza. De ők is, ha túl sok mindent adnak meg, akkor gyakran azt kapják vissza, hogy nincs ilyen dokumentum. Ilyenkor pedig elcsodálkozik: "Hogy lehet az, hogy többmilliárd oldal van, és pont az nincs fenn, amit én keresek?" Pedig lehet, hogy mégiscsak létezik az, amit ő keres, csak éppen rossz szavakkal próbálkozott. Az is lehet, hogy a keresőgép még nem találta meg az oldalt, nem dolgozta fel és ezért nincs is benne az adatbázisában.
A keresők alapvető működési elve meglehetősen egyszerű. Ún. kereső robotokat alkalmaznak. Ezek a robotok elindulnak valamilyen címről, lehetőleg olyanról, melyen sok hivatkozás található és a linkeket követik. Vagyis ha valahol van egy hivatkozás, akkor letöltik azt az oldalt, amelyre mutat, és azon is ugyanígy végighaladnak, keresve a linkeket, miközben az oldalak teljes szöveges tartalmát letöltik és később feldolgozzák. Talán ebből világos, hogy nem sikerülhet nekik minden lapot megtalálni. Ugyanis csak a megadott címekről indulnak el, és azokra a honlapokra, melyeknek ehhez semmi köze, lehet, hogy sohasem jutnak el. Vagy ha valaki magánszemély összerak magának egy honlapot és felteszi például egy ingyenes tárhely-szolgáltató szerverére, az sem válik ismertté. Mivel senki sem hivatkozik az ő honlapjára, nem is jut el hozzá keresőrobot sem. De még a fellelt honlapokon sem biztos, hogy minden linket észrevesznek! Lehet, hogy JavaScript kód állítja elő őket, illetve egy PHP vagy Flash program vezérli az egész honlapot és speciális módszerekkel lehet előhozni a hivatkozásokat.
A megtalált lapokat mindenesetre indexeli és teljes szöveges tartalmát letárolja. Erre sok-sok összekapcsolt számítógépet használ, melyekben gyors elérésű nagy kapacitású háttértárak vannak. Az oldalakat rangsorolni szokták: annál "népszerűbb" egy oldal, minél több helyről hivatkoznak rá, sőt, az is számít, hogy a hivatkozó oldalak mennyire népszerűek.
A keresés úgy kezdődik, hogy a felhasználó beír egy vagy több szót, esetleg kifejezést, például olyat, hogy szerepeljen a lapon ez és ez a szó, de ne szerepeljen a harmadik. A keresőgép ezt megkapja és végignézi az összes honlapot, hogy hol szerepelnek a megadott szavak. A lapokat megfelelő sorrendbe rendezi és a címeiket visszaküldi a felhasználónak. Mivel azok kerülnek előre, melyek nagyobb rangúak és sokszor szerepel rajtuk a keresett szó, valószínű, hogy az első tíz-húsz találat között ott lesz az is, amelyiket kereste az illető. A Google-t (www.google.com) tartják a legeredményesebb keresőnek, mert itt találjuk meg leghamarabb (általában) azt, amit tényleg keresünk, de sokszor még ennél is időigényes, mire a linkek közül kihalásszuk a megfelelőt.
Egy elavult keresési módszer a kulcsszó szerinti keresés. A HTML fájlok fejlécében ugyanis meg lehet adni egy kulcsszó listát, hogy miről van szó a dokumentumban. Ez viszont egyáltalán nem megbízható. A legtöbb fájlból ugyanis ez hiányzik, míg más fájlok szerzői azzal akarják felhívni a figyelmet az oldalukra, hogy olyan kulcsszavakat írnak be, melyeknek ugyan semmi köze a témához, de gyakran keresett szavak.
Sokan - főleg a kezdő felhasználók - nem is szeretik a keresőrendszereket, hanem inkább portálokat és linkgyűjteményeket keresnek fel. Itt emberek, és nem gépek által összegyűjtött hivatkozások várják őket és talán jobban megfelelnek az igényeiknek, mintha nekik kellene a sok-sok visszaadott link közül válogatni.
A képkeresők úgy működnek, hogy a képekhez rendelt címkéket olvassák és aszerint keresnek találatot. De a címke sokszor hiányzik, vagy csak egy számsorozatot tartalmaz, amiről nem lehet megmondani, hogy egy krokodilt ábrázol vagy egy diagrammot.
Léteznek tematikus keresők is: ezek a visszaadandó lapokat témakörök szerint csoportosítják és a felhasználó kiválaszthatja a neki tetszőt. A témakörök 1-2 szint mélységig vannak kidolgozva, azon belül pedig a szokásos módon sorolják fel a címeket. A legjobb ilyen módszert talán az ausztrál Mooter Search valósítja meg.
Akármelyiket használjuk, a keresés mindig szó alapján történik. Ha a keresett szó nem szerepel a honlapon, akkor az a találati listába biztosan nem kerül be; pedig lehet, hogy mégiscsak arról szól, csak éppen mindig a szó egy szinonimáját használta a szerző.
Ha még az embernek is nehéz megtalálni azt, amit keres, akkor hogyan találjon meg valamit egy program? Hacsak nincs emberhez hasonló mesterséges intelligenciája - és jó pár évig ilyen nem is lesz még -, akkor hogyan boldogulhat el egy egyszerű kis alkalmazás egy ilyen összetett és kicsit zavaros világban?
Mióta az ember lemászott a fáról - illetve kiűzetett a Paradicsomból, ha valaki abban hisz -, azon fáradozik, hogy tárgyakkal megkönnyítse életét. Kezdve az élesre csiszolt kövektől és a keréktől a gőzmozdonyon át a vonalkódig vagy az elektromos fogkeféig. De a szórakozással is így van: először csak festéket gyártott, hogy kedvenc mamutjait a falra pingálhassa, most pedig fejlődésre képes robotkutyát, hogy a panelházban lakó japán gyerekeknek is legyen háziállata. Az Internet, mely egyszerre az élet több területét lefedi (munka, tanulás, szórakozás, stb.) sem kerülheti el sorsát: azon fáradoznak, hogy az átlagemberek számára minél egyszerűbbnek tűnjön és minél könnyebben alkalmazkodjon hozzájuk. Az utóbbi időben az ember mindent gépesíteni akar. Az egyre csak növő internetes információhalmazt is jó lenne programok által kezelni és abban keresni; úgy, hogy a megtalált adat ne csak a felhasználó, hanem az alkalmazás számára is információvá váljon - tudja, hogy mit talált, ebből tudjon következtetéseket levonni és ezek alapján tovább dolgozni. Mindezt úgy, hogy ne kelljen gépi agyat létrehozni, komoly mesterséges intelligenciával bíró eszközöket felhasználni, tekintve, hogy azok drágák lennének ahhoz, hogy mindenhol használják, másrészt a "gondolkodáshoz" idő kell, az Interneten pedig fontos a minél gyorsabb eredmény. Egy olyan rendszerre lenne szükség, mely egyszerű állításokat képes megérteni és ezeket megfelelően összekapcsolva a feltett kérdésre válaszolni.
Kutatók szerint három-öt év kell ahhoz, hogy az Internet egy következő szintre emelkedjék. A fentebb már tárgyalt összevisszaság miatt erre szükség is van; de hogy melyik lesz ez a szint, az még nem teljesen biztos.
Az viszont már biztos, hogy a pusztán szavak szerinti keresésnek már nincs nagy jövője. A szövegkörnyezet nagyon fontos, mivel a szónak aszerint van jelentése, hogy hol használjuk (gondoljunk pl. a vár szóra, mely egyszerre főnév és ige, és teljesen mást jelent). Na de hogyan tudnánk definiálni a szövegkörnyezetet? És a felhasználó hogyan adhatná meg, hogy ő a szónak melyik jelentésére gondolt? Ez a módszer szerintem sosem valósul meg. A keresők kétfelé fejlődhetnek: vagy speciálisak lesznek - mást használunk, ha képet keresünk és mást, ha szöveget vagy zenét -, vagy mindent magukba foglalók. Ez utóbbi természetesen sokkal jobban hangzik. Viszont az kellene hozzá, hogy a keresőgépek megértsék, hogy mik vannak az egyes honlapokon. Az Amerikai Mesterséges Intelligencia Társaság (AAAI) a szövegfeldolgozásban (text-mining és web-mining) elért némi sikert. Egyelőre ugyan csak neveket ért meg a szoftverük - a szövegben jó valószínűséggel felismeri a személyneveket és helyszíneket, továbbá a dátumokat -, de remélik, hogy másokra is képes lesz nemsokára. A program megfigyelheti, hogy mely nevek köré milyen szavak csoportosulnak, mely címek kötődnek hozzájuk és szerencsés esetben ebből következtetni is tud egy-két dologra. Ez az egyik járható irány: az intelligens keresőprogram, ami pusztán a szöveg alapján - akárcsak az ember - megérti a lap tartalmát. Az út járható, de nagyon rögös. A másik lehetőség, hogy a lapok úgy vannak felépítve, hogy a szöveg mellett annak logikai tartalma (a szemantikája) is le van tárolva, egyszerű kijelentések halmazaként. A keresőnek ekkor már nem kell szuperintelligenciával rendelkezni, hogy képet alkosson a tartalomról. Ez az út mindjárt kellemesebben járható, de extra befektetést kíván meg a honlapok alkotóitól. A Semantic Web mindenesetre ezt az irányt választotta.
Ha elvetjük a szavak szerinti keresés elvét, akkor a felhasználónak sem szavakat kell beírni a kereső ablakába. Inkább (egyelőre csak egyszerű) kérdéseket tehetnek fel, mint például "Ki az Egyesült Államok elnöke?". A kérdés átalakítható arra, hogy egy nevet keresünk, méghozzá olyan esetben, ahol az "elnök" és az "Egyesült Államok" egymással birtokviszonyban áll. A kereső a kérdést kielemzi és nekilát kutatni a weben; aztán vagy csak visszadob egy nevet, vagy felkínál címeket, melyek például az USA vagy a Fehér Ház hivatalos honlapjára mutatnak.
Láttuk, hogy a kulcsszavas keresés már nem nagyon alkalmazható, mert az embernek is elég kiszűrni, hogy melyik a fontos vagy keresett információ. Ha pedig a keresést a számítógépre szeretnénk bízni, akkor át kellene műttetnünk bele az agyunkat, hogy képes legyen megérteni a világhálón lévő adatok információtartalmát. Ha a tartalom viszont egyfajta "gépi nyelven" is le van írva, akkor már egyszerűbben fel tudja fogni. A klasszikus HTML egyértelműen az ember számára készült: a nyers szövegen kívül szinte csak a formázásra vonatkozó parancsokat tartalmaz. A Semantic Web viszont sokkal inkább a gépnek íródott: az erőforrásokhoz olyan kifejezéseket társít, melyet a programok könnyedén képesek elemezni és különösebb nehézség nélkül felhasználni újabb állításokhoz.
Erőforrás bármi lehet, aminek csak egy kis köze is van a világhálóhoz. Lehet egy elektronikus könyv, egy személy egy adatbázisban, vagy akár egy televízió, mely a ház központi számítógépén át kapcsolódik a rendszerbe; de akár a macskánk is lehet az, ha az adatait felvisszük a számítógépünkre (és nem szükséges magát az állatot bekötni a hálózati csatlakozóba). Akármilyen erőforrásról tehetünk különféle állításokat, melyeket ha közzé teszünk az Interneten, azokat mások, illetve mások által írt alkalmazások megszerezhetnek és értelmezhetnek. Így ne csodálkozzunk, ha egyszer csak e-mailt kapunk a Macskabarátok Klubjától és azt írják, hogy a keresőprogramjuk ránktalált, mint közelben lakó cicatulajdonosra és nem-e akarunk belépni a klubjukba.
Amikor arról írtam, hogy a programok "gondolkodnak", akkor biztosan mindenkinek eszébe jutott, hogy ez nem egy világszenzáció. Hiszen milyen régi találmány már a sakkozó automata vagy bizonyára vannak régebbi "okos" gépek is! A tudásreprezentáció, a következtető gépek fogalma már nagy múltra tekint vissza. Kár is lenne tagadni, hogy a Semantic Webnek semmi köze hozzájuk. Nem is lenne értelme figyelmen kívül hagyni őket, hiszen nagyon hosszú ideje, nagy matematikusok dolgoznak a témán. A tudásreprezentációs rendszerek általános problémája az, hogy két vagy több különböző tudásbázist nem igazán tudnak összekapcsolni. Mindegyiknek megvan a saját nyelvezete, a saját elképzelése a modell tárolásáról. Ezért csak egy-egy adott feladat(csoport)ra specializálódnak és nem alkalmasak egy világméretű, mindent magába foglaló rendszer leírására. A Semantic Web tervezői tehát hasznosították az ezekből szerzett tapasztalatot, de nem estek abba a hibába, hogy kicsiben gondolkodjanak.
Ha már szóba kerültek a tervezők, ideje lenne elárulni, kik is azok. Mint annyi egyéb szabvány, ez is a World Wide Web Consortiumtól (röviden W3C, www.w3.org) származik. Ők felelősek a HTML, az XML, a Scalable Vector Graphics (SVG) és még számos ismert és hasznos szabvány megalkotásáért. A Semantic Web alapjául szolgáló eszközöket néhány éve készítették el. A szokásos bevezetés (terv, vázlat, előzetes, stb.) után most, 2004. február 10-én végre ajánlássá vált. Ezután talán még több fejlesztő veszi a bátorságot, hogy használja, akik eddig bizonytalankodtak, nem tudván, hogy lesznek-e nagy változtatások még vagy lesz-e egyáltalán belőle valami.
A W3C a Semantic Webet így definiálja: "A Web egy lehetséges jövője, ahol az információt egyértelmű jelentéssel adjuk meg, ezáltal egyszerűbbé téve a gépek számára az automatikus feldolgozást és az információ integrálást."[1] A Semantic Web felépítéséhez három réteg, három nyelv szükséges.
A legalsó réteg az XML, azaz az Extensible Markup Language. Magyarul kiterjeszthető leíró nyelvet jelent és nem véletlenül kapta ezt a nevet: szókészletét tetszőlegesen bővíthetjük. Alapvetően ez egy szintaxis strukturált elektronikus dokumentumok leírására. A HTML-lel nem csak abban hasonlítanak, hogy mindkettő leíró nyelv (markup language) és ugyanaz a társaság fejlesztette ki. A szerkezetet leíró jelölések, a tag-ek megadása ugyanaz: < és > jel közé zárva adjuk meg az elem nevét. Ez jelöli az elem kezdetét, a végén pedig ugyanez áll, de a név elé egy perjelet is kiírunk. Az XML és a HTML sokban hasonlít, a kis különbség az, hogy a HTML-t inkább emberi fogyasztásra tervezték. A parancsok azt szolgálják, hogy a multimédia tartalom (szöveg, képek, hang, stb.) úgy jelenjen meg, hogy a felhasználó számára kényelmet és esztétikus látványt nyújtson. Az XML sokkal inkább egy adattárként szolgál. Leírhatók benne hierarchikus adatszerkezetek, melyekre ha az ember ránéz, nem feltétlenül látja azonnal a felépítést, de a számítógép számára könnyen olvasható. Ettől függetlenül az XML-ben is lehet HTML tartalmat leírni, sőt, egy közbülső fájl - egy stíluslap (XSL és XSLT) - segítségével az XML HTML formátumúra alakítható. Ezen kívül létezik még az XHTML fájlformátum is. Ez a HTML XML-formátumba átírt változata. (Mivel az XML-ben tetszőleges nevekkel láthatjuk el az elemeket, megtehetjük, hogy a HTML-ben elfogadott neveket alkalmazzuk. Vagyis azt is mondhatjuk, hogy egy HTML dokumentum egy speciális XML dokumentum.) Az XML és a HTML tulajdonképpen testvérek, hiszen mindkettőnek közös gyökere van: a Standard Általánosított Leíró Nyelv (SGML, Standard Generalized Markup Language) leszármazottai, ami pedig az IBM még '73-ban indított projektjéből bontakozott ki.
Addig ugyanis sokat vitáztak azon, hogy az adatokat hogyan kellene megosztani. Sokat használták a CSV-t (comma separated values), vagyis hogy a változókat vesszővel elválasztva sorolták fel. De olyan strukturált adatokat, mint például egy adatbázist vagy egy komolyabb dokumentumot nem tudtak vele továbbítani. Ráadásul a CSV nem is volt szabvány, többféle változata létezett. Azonkívül több száz szoftverkészítő, nem törődve a CSV-vel saját egyedi fájlformátumot használt.
Ellenben az XML a tag-ek segítségével elválasztja és megfelelően strukturálja az adatokat. A nyitó és záró tag közötti elemben lévő további tag-ek a hozzájuk tartozó elemekkel a hierarchiában ezalatt helyezkednek el. A nyitó tag-ben ráadásul jellemző paramétereket is megadhatunk. A tag-eknek hosszú, értelmes neveket adhatunk, hogy már ránézésre tudjuk, mit jelentenek.
Az XML általános célokra felhasználható és nem bonyolult az elkészítése vagy feldolgozása, történjen ez akár szoftveres, akár hardveres módon.
Mindenre persze nem képes. Peter Moulding (online körökben elismert programozó és író) szerint "az XML nem készít jó cappuccinót, nem hozza el a világbékét és nem segít az adatelemzésben sem." Ebből nekünk az utolsó tagmondat a fontos: az adatelemzést nekünk kell elvégezni és ugyancsak az XML-szerkezet kifejlesztését is.
A szerkezetre vonatkozóan az XML fájl tartalmazhat megszorításokat egy sémában, például DTD-t (dokumentum típus definíció), s így a számítógép automatikusan végezhet az új adatokon ellenőrzést, mielőtt a fájlba illesztené azokat. A DTD egy elég primitív sémanyelv, használhatunk komplexebbeket is. A W3C XML Schema (rövidebben XML Schema) például adattípusokat is tartalmaz, így megszabhatjuk az egyes adatokra, hogy milyen típusúak kell legyenek. Ezen felül természetesen további lehetőségeket is biztosít a szerkezeti megszorításokra.
Röviden összefoglalva tehát az XML egy olyan platformfüggetlen nyelv, amelyben könnyedén megadható valamilyen strukturált adathalmaz, feldolgozása és bejárása nem nehézkes és már számos segédprogramot írtak, amellyel létre tudunk hozni vagy be tudunk olvasni egy XML dokumentumot.
Ezen jó tulajdonságai miatt a W3C által kifejlesztett magasabb szintű nyelvek mind az XML-re építkeznek; megtartják a szintaktikát és az egész koncepciót.
A középső réteget az RDF jelenti. Az RDF a Resource Description Framework rövidítése és erőforrások leírására használható. Túl sok mindent most nem érdemes róla elmondani, majd a második fejezetben kicsit jobban foglalkozom vele. Egyelőre elég annyit tudnunk, hogy ez épül rá az XML-re. Abban ugyanis azonfelül, hogy megadtuk az egyes tag-eket és kitöltöttük őket, nem tudtuk, hogy mit jelentenek az egyes tag-ek. Az RDF és az RDFS (RDF Schema) adnak nekik jelentést; az RDF-ben adjuk meg magát az adatmodellt, az RDFS-ben pedig a modell elemeinek a jelentését definiáljuk. Ezért lehetséges erőforrásokat leírni vele, mert azokhoz nem csak hozzárendelünk 1-2 adatot, hanem tudjuk is, hogy ezek miféle adatok. Szebben mondva információt reprezentálhatunk a weben. Használható arra, ami a HTML fájlok fejlécében is elő szokott fordulni: a dokumentumok metaadatainak megadására. Az ott lévő <META> tag-eket helyettesítve ebben is megadhatjuk például egy dokumentum címét, szerzőjét, létrehozásának dátumát, a megfelelő copyright információkat és így tovább. De persze ennél sokkal többre is képes: mindenről megadhatunk információkat, ami csak azonosítható a weben, még akkor is, ha közvetlenül nem is érhető el. A megadott tulajdonságok jobbára gépi fogyasztásra valók, de egyeseket meg is lehet jeleníteni, ha van értelme.
Szó volt róla, hogy az XML-ben mindenki olyan nevet ad a tag-eknek, ami neki tetszik. Így nehezen érti meg egy másik program, hogy ez a tag vajon mit jelenthet. Az RDF-ben viszont alapvető követelmény, hogy ugyanazt jelentse valami egy másik alkalmazás számára is, mint annak a számára, amelyikhez készült; azaz úgy kicserélni az adatokat, hogy közben ne veszítse el az értelmét.
Ehhez az kell, hogy megegyezzenek abban, mi mit jelent. Az RDF ezért mindent URI-kkal azonosít. Ha két URI megegyezik, akkor az ugyanarra a valamire vonatkozik. Felvetődik a kérdés: mi van akkor, ha két helyen is definiálunk valamit, különböző URI-kkal, de a két dolog ugyanaz. Erre a problémára is látunk majd megoldást.
Az RDF-ben mindent hármasokkal (angolul triplet) írunk le. Ez két erőforrást és a köztük lévő kapcsolatot reprezentálja. Például az Ádám erőforráshoz a vanFeleségetulajdonsággal hozzá van kapcsolva az Éva erőforrás. Mind a három URI-val van azonosítva. Az erőforrás URI-ja ugyebár egyértelmű. De miért kell a tulajdonsághoz is URI-t rendelnünk? Egyszerű: így már nem pusztán egy szó, de egy egyedi definícióhoz is hozzá van kötve, amit bárki megtalálhat a neten. Ha pedig ott rákeres, talán azt is megtalálja, hogy a vanFelesége egyenértékű azzal, hogy férje (mármint Ádám Évának). Az objektumoknak (az RDF-ben osztályok), de még a tulajdonságoknak is lehet hierarchiája, ami szintén leírható az RDF-ben. (Például a vanFelesége altulajdonsága annak, hogy vanHázastársa.) A hierarchiával természetesen az is együtt jár, hogy az alacsonyabb szinten lévő objektumok öröklik a szülők jellemzőit. A kapcsolatok miatt azonban az objektumok egymáshoz való viszonya meglehetősen bonyolult is lehet: az RDF dokumentum így nem írható már le fa szerkezetben, hanem egy irányított gráfként. Ennek ellenére egyszerűen reprezentálható XML fájlban, mert nem az egész egybefüggő gráfot adjuk meg egy blokkban, hanem egy-egy ágat.
A hármasok bonyolult halmazával sok minden leírható. Például a jövő keresőgépének feltehetjük a kérdést: "Miket írt Kovács István eddig?" Akkor ő szépen megkeresi azokat a hármasokat, ahol a jobboldali erőforrás "Kovács István", a kapcsolat pedig "szerzője". A baloldali erőforrásokat összegyűjti és máris megkaptuk az összes olyan dokumentumot, aminek ő a szerzője.
A legfelső réteg egy ontológia nyelv. A világ túl bonyolult ehhez képest. Az ontológia nyelvek formálisan leírhatják az osztályok és a tulajdonságok szemantikáját. Ha a gépek következtetéseket akarnak levonni ezen dokumentumokra vonatkozóan, akkor összetettebb nyelvre van szükség, mint az RDFS, ami csak alapvető szemantikát képes biztosítani.
Az ontológiákban definiált pontos kifejezések (termek) segítségével tudunk egy tudásterületet reprezentálni és jellemezni. A Semantic Web pedig az ontológiák halmazaként definiálható. Tulajdonképpen az RDFS is egy egyszerű ontológia nyelvnek tekinthető és bár egyszerűbb következtetésekre így is juthatunk a feldolgozásukkal, továbbra is megmaradunk az egyszerűségnél. Ha intelligens programokat akarunk, akkor bizony gazdagabb nyelvekre van szükség. Nem lehet benne ugyanis olyanokat definiálni, mint hogy két osztály diszjunkt vagy valaminek a számosságát.
Korábban a DAML+OIL nyelvvel próbálkoztak, amit a DARPA fejlesztett ki. Ezt tovább alakítgatta a W3C, és olyan sokat változtattak, hogy már új nevet kapott: OWL, azaz Web Ontology Language. Természetesen ez is az XML-re és az RDF/RDFS-re épül. Utóbbiból nagyon sokat átemel, így az OWL-es tag-ekre csak ott van szükség a fájlban, ahol valami olyan bonyolult dolgot akarunk leírni, amit az RDF szókészlete már nem támogat. Az OWL-ben nagyon sokféle módon kapcsolhatjuk össze az osztályokat és sokféle megszorítást tehetünk.
Az OWL (főleg az OWL Full, az OWL legösszetettebb alnyelve) már több mint elég komplex ahhoz, hogy leírhassuk vele az erőforrásokat. Ezekből a jellemzésekből állnak össze az ontológiák, melyeket felhasználhatnak emberek, adatbázisok és alkalmazások az információ megosztására valamely területen. A terület akármi lehet, például autószervizelés, gyógyszerkeresés, szerszámok beszerzése... Nem folytatom, mert minden ide tartozik, ami csak fellelhető az Interneten és keresést igényel. Az első példánál maradva: alkatrészt keresünk az autónkhoz. Ekkor fel kell keresnünk minden honlapot, ahol ezzel foglalkoznak, mindenhol megnyitni a katalógust, abban megkeresni a megfelelő alkatrészt, megnézni az árát, összehasonlítani a többi honlapon találtakkal. Nem árt a távolságot sem figyelni, hogy átmehetünk-e érte gyalog vagy külföldről kellene importálni drága postaköltségen, stb-stb. Időrabló, fárasztó és nem is túl érdekes feladat; vagyis a jelenkor ideges és időhiánnyal küszködő emberének cseppet sem hiányzó tortúra. Ám milyen jó lenne mindezt rábízni a számítógépre, mi pedig csak egy rövidke listát kapnánk vissza a lehetséges szervizekről és a költségekről, sőt, még ki is lenne emelve a leginkább ajánlott! (Mivel némi idő elteltével a személyi keresőprogramunk már kiismer minket, egyre jobban el tudja találni ízlésünket...) Álom? Nem hiszem, hogy nagyon sokat kell még aludnunk ahhoz, hogy elérjük ezt a szintet.
A keresés egyébként csak egy lehetséges felhasználása a Semantic Webnek. A W3C szerint a következőkben mindben segíthet: szoftver ágensek, döntéstámogatás, beszéd és természetes nyelvek értése, tudásmenedzsment, intelligens adatbázisok, elektronikus kereskedelem és még jó néhány kisebb-nagyobb feladat.
Lévén Internetről szó, a Semantic Webnek is decentralizáltnak kell lennie, hogy hatékonyan és napra készen működhessen. Ebből viszont ugyanaz a hátrány is előjön: nem minden lesz elérhető. Mint ahogy gyakori, hogy egy linket követve nem létező oldalra jutunk, itt is az, hogy nem létező fájlra, adatra, ontológiára találunk hivatkozást. A teljes konzisztencia tehát nem biztosítható. A gépeknek alighanem elég sok problémát okoz majd, hogy mit kezdjenek azokkal az adatokkal, amiket nem találnak, vagy azokkal, amik több helyen is előfordulnak, de más tartalommal. El kell fogadnunk, hogy feltehetnek olyan kérdéseket, amikre nem lehet válaszolni, vagy hogy a következtetések során paradoxonokhoz juthatunk. A decentralizáltság további hátránya, hogy - akárcsak a mai webnél - sohasem lehetünk biztosak abban, hogy mindent megtaláltunk. Mivel nincs összegyűjtve sehol az összes dokumentum, könnyen lehet, hogy kimarad a kereséskor 1-2 fontos fájl és így nem is kaphatunk teljesen pontos képet a valóságról.
Ha már sikerült olyan programokat alkotnunk, melyek úgymond "felfogják" az Interneten olvasott dokumentumokat, miért ne használnánk ki ezt a lehetőséget másra is? Attól lesz valóban ereje a Semantic Web-nek, hogy olyan programokat írhatunk, melyek a Net különböző vidékeiről szedik össze a tudásukat, és miután feldolgozták ezeket, az eredményeiket megoszthatják más programokkal is.
Azt, hogy mi a szoftver ágens vagy szoftver ügynök, nehéz pontosan megfogalmazni. Mondjuk, hogy olyan eszközök, melyek adatokat tudnak fogadni, feldolgozni, továbbítani. Lehet a számítógépen futó böngészőprogram vagy például egy szerveren futó, szolgáltatásnyújtó segédprogram.
Utóbbi ugyebár teljesen automatikusan működik, mindenféle emberi beavatkozás nélkül. Ha a Semantic Web-nek köszönhetően az ágensek közös nyelvet beszélnek, világos az egyik számára, hogy a másik milyen szolgáltatást tud nyújtani, milyen bemenő paramétereket vár, milyen formában adja vissza az eredményt. Így még az olyan ágensek is megértik egymást, melyeket nem direkt arra terveztek, hogy együttműködjenek.
Ez úgy valósul meg, hogy amit küldeni akar, azt először is átírja közös nyelvre (valószínűleg RDF-re, vagy legalábbis XML-re). A kis elkészült csomagot küldi el és amit visszakap, az szintén ilyen nyelven írt adathalmaz, amit a saját belső nyelvére kódol vissza.
No és hogyan találja meg a megfelelő ágenst a mi ágensünk? Ugyanúgy, ahogy az emberek azt, amit szeretnének: vagy kereső segítségével, vagy egy portálon keresztül. Utóbbi olyan hely, ahol a különféle szolgáltatásokat nyújtó programok vannak összegyűjtve. Azt viszont már nehezebb megmondani, hogy a visszakapott információ helyes-e. Csak akkor lehetünk biztosak benne, ha több ágenst is megkérdezünk és mind ezt mondja. Az sem biztos, hogy az ágens tényleg azt csinálja, amire megkértük, mert bár azt állítja, hogy egyfajta szolgáltatást végez, de lehet, hogy egészen másra használja fel a tőlünk kapott adatokat.
A fontosabb honlapokon, ahol személyi adatokat is kezelnek, már évek óta megjelentek mindenféle biztonsági módszerek. A Semantic Web-en a számítógépek és ágensek által küldött minden adatot digitális aláírással kell ellátni (és persze titkosítani az adatokat), hogy a fogadó tudja, megbízható forrásból érkezett-e az üzenet. Sőt, ha egy állítással találkozik az ágensünk, addig nem is szabad teljesen elhinnie, amíg a forrásokat le nem ellenőrizte.
Természetesen ha egy bonyolult dologra akarunk rákerestetni a saját ágensünkkel, akkor nem valószínű, hogy egyből talál egy olyan szolgáltatást - valószínűleg nincs is olyan -, ami ezt a kérdést ki tudja elégíteni. Viszont a szemantikának hála ki tudja használni azon szolgáltatásokat is, melyek csak részlegesen oldják meg a problémát.
Több szolgáltatást is meg kell keresnünk, hogy azok eredményeiből összerakjuk a végső eredményt. A szolgáltatások saját számításaikhoz, működésükhöz és következtetéseikhez persze további szolgáltatókat is igénybe vehetnek. Ha bonyolult megoldása van a kérdésünknek, akkor igencsak sok programot meg kell mozgatnia az ágensünknek.
Bár még kicsit messze van a Semantic Web-től, de már léteznek fejlesztések arra, hogy megértsék egymást az eszközök. Kitaláltak egy CC/PP nevű, RDF-re épülő szabványt, amivel leírhatók a készülékek tulajdonságai, úgymint képernyőméret, szolgáltatás, paraméterezhetőség, stb. Például a digitális fényképezőgépemben is van egy XML fájl, mely tartalmazza, hogy ha egyből erről akarok e-mailben képeket elküldeni valakinek, akkor ez hogyan lehetséges. Leírja a fájlban, hogy ez e-mail generálásra való, milyen kiterjesztésű és méretű fájlokat lehet feltölteni, milyen esetleges paraméterek lehetnek, sőt, még egy természetes nyelvű leírás is van mellette, arról, hogy mi ez.
Egy-két szó esett az ontológiákról. Web-es fejlesztés közben előjöhet a probléma, hogy milyen legyen az ontológia. Ha csak magunkra gondolunk, egy konkrét feladatra gyorsan meg lehet írni egy hatékony ontológiát. De ezek alapelvei közé tartozik az újrafelhasználhatóság és az érthetőség. Ha egy csoport csak úgy magának fejlesztget, az eredmény olyan lesz, amit rajtuk kívül nem ért meg senki. Lehet úgy is fejleszteni, hogy már kész ontológiákat veszünk alapul. Ezek megkeresése és elemzése felhasználhatósági szempontból hosszabb fejlesztési időt eredményez, de cserébe az ontológia jól érthető mások számára is. De veszélyes is felhasználni mondjuk tízféle forrást, mert az Internet ugyebár állandóan változik. Megszűnhet vagy elköltözhet valamelyik alapul vett dokumentum és ez máris felborít mindent... URI-kkal nevezünk el mindent és könnyedén definiálhatunk értelmet az egyes szavaknak. De más valaki más néven definiálhatja ugyanezt. Szerencsére az ontológia nyelv lehetőséget ad arra, hogy ezeket egyesítsük. El tudok képzelni olyat, hogy a jövőben olyan ága is lesz a programozásnak, hogy "ontológia-egyesítő", aki össze tud kötni két különböző projektet, egy olyan ontológiát hozva létre, mely mind a két eredetit lekezeli. A következő alfejezetben megnézzük, hogy a W3C az ontológiákra milyen feltételeket szabott ki.
Jó pár feltételt határoztak meg arra, hogy egy ontológia nyelvnek miket kell tudnia. De meg is dicsérhetjük őket, mert az OWL ezeket mind teljesíti. Nyolc fő tervezési célt jelöltek ki:
- Osztott ontológiák: Azt jelenti, hogy az ontológiáknak ugyanolyan elosztottságot kell biztosítani, mint a Web-nek. Ott ugyanis akárhonnan hivatkozhatunk akármire. Az ontológia attól osztott, hogy több fájlba szétdarabolhatjuk, melyeket akár egymástól távoli számítógépeken is elhelyezhetünk. Másrészt, az egy valahol már létező ontológiát bárhol máshol lévő fájlban kiterjeszthetünk. Utóbbi az újrahasznosíthatóságot is támogatja. Mert ha valaki ontológiát akar fejleszteni, előtte érdemes körülnéznie, mivel biztosan talál olyat, mely többé-kevésbé megfelel a feladatra és csak egy kisebb részt kell hozzáadnia.
- Fejlődés: Ha elkészült egy ontológia és felkerült a Net-re, akkor már nem módosíthatjuk. Ugyanis születhetnek újabb ontológiák, melyek ezt tekintik alapnak (vagy legalábbis felhasználják egy részét). Viszont szükség lehet a fejlesztésére, de az új változattal nem helyettesíthetjük az eredetit, hanem egy másik fájlban kell tárolnunk. Ezért verziószámmal kell ellátni az ontológiákat. Szükséges azt is jelezni, hogy az új kompatibilis-e a régivel, vagy úgy megváltozott, hogy nem.
- Ontológia összekapcsolás: Erről többször is volt már szó: ha két különböző ember vagy cég kifejleszt egy-egy ontológiát ugyanarról a témáról, akkor biztos, hogy nem ugyanazokat az elnevezéseket használják, vagyis teljesen máshogy modelleznek. A nyelvnek támogatnia kell ezen ontológiák összekapcsolhatóságát vagy hogy az egyiket átalakíthassuk a másikra.
- Ellentmondások észlelése: Ugyebár az elosztottságból és abból, hogy különböző gondolkodásmódú emberek írják az ontológiákat, előfordulhatnak ellentmondások. Ezeket képesnek kell lenni a nyelvnek érzékelni, méghozzá automatikusan.
- Kifejezések sokszínűsége: A nyelvnek sokféle kifejezés-formát kell ismernie, hogy a valódi világ sokszínűségét, sokrétűségét kellően tudjuk reprezentálni. Ha azonban túlságosan sok minden áll rendelkezésre, az már a következtetések rovására megy: nehezebb pontos értelmet adni valaminek. A nyelvnek megfelelő egyensúlyt kell találnia, hogy ne legyen se sok, se kevés. Ha túl kevés a lehetőség, akkor nehéz leírni pontosan azt, amit szeretnénk. Ha viszont sok, akkor nehéz a feldolgozás: többmilliárd honlap létezik és rengeteg információt kell kezelni, így a következtetőgépeknek nem árt gyorsnak lenni, amit úgy érhetünk el, ha minél egyszerűbbek a kifejezések. Azt sem árt megjegyezi, hogy minél bonyolultabb egy nyelv, annál könnyebb neki olyan kérdést feltenni, ami paradoxonhoz vezet.
- Könnyű használhatóság: Könnyű legyen megtanulni a nyelv használatát, a fogalmak, jelentések egyértelműek legyenek és függetlenek a szintaktikától. Természetesen ahogy HTML szerkesztők megjelentek és úgy tud mindenki honlapot írni, hogy azt se tudja, milyen HTML parancsok vannak, ugyanúgy Semantic Web-es szerkesztők is lesznek és nem kell megtanulni az ontológia nyelvet. Mégis, a forrásnak olyannak kell lenni, hogy ne csak a gép, de az emberek is könnyen olvashassák.
- Kompatibilitás más nyelvekkel: Olyan nyelvekkel, melyeket gyakran használnak és ipari szabványok is. Például ilyen az XML és leszármazottai: XML Schema vagy RDF.
- Nyelvek támogatása: Vagyis, hogy több nyelven is lehessen dokumentálni az ontológiát, azaz, hogy többféle nyelven "szólaljon meg". Ha például német és angol nyelven egyaránt megadjuk a megfelelő elemek leírását (címkék, megjegyzések, stb.), akkor anyanyelvén kezelheti a német és az angol felhasználó is az alkalmazást. Web-en, nemzetközi honlapokon ez alapelvárás. (Már az XML is támogatja.)
A W3C szabta ezeket a feltételeket, így természetes, hogy az általuk kifejlesztett ontológia nyelv, az OWL, eleget tesz nekik.
Az XML, teljes nevén Extensible Markup Language, egy leíró nyelv, amivel elektronikus dokumentumokat tudunk leírni, és az egyes elemeiket hierarchiába is rendezhetjük.
Az XML a SGML-ből származtatható. Az SGML egy általános dokumentum leíró nyelv. Ebből született például a HTML vagy az XML. A HTML-t szinte mindenki ismeri, ha máshonnan nem is, de onnan, hogy az internetes címek végén gyakran áll ott. Ha azonban az átlagember meghallja azt a betűszót, hogy XML, leginkább tanácstalanul rázza a fejét - pedig az XML már sokkal nagyobb területet fed le a való életben, mint a HTML. Nagyon széles körben elterjedt, mint egy szabványos leíró nyelv. Számos alkalmazás (még játékok is) tárolja XML-ben az adatokat, de a számítógépen kívüli világban is gyakran előfordul. Tulajdonképpen bármilyen digitális eszközben előfordulhat, fényképezőgépben, flash drive-on, vagy bármiben.
Az ipari szabványoknak is egyre többje megjelenik XML-ben is. Jó pár éve megjelent már és viharos gyorsasággal elterjedt. Számos alkalmazás és programkönyvtár született azóta, melyekkel kezelni lehet az XML dokumentumokat, így nem csoda, hogy egyre többen használják.
Sikerét annak köszönheti, hogy egyszerű a szerkezete, mégis nagyon sok mindent leírhatunk benne, platform-független, a forrása is jól olvasható vagy szerkeszthető.
Az XML dokumentum a nyers szöveg vagy adat mellett tartalmaz jelöléseket is, amik jelentős részét tag-eknek hívják. (Vannak egyéb jelölésfajták is, de mi csak ezekkel foglalkozunk.) Ezek mindig < és > közé zárt azonosítók. A HTML-ben ugyan nem mindenhol kötelező, de az XML-ben mindig le is kell zárni a tageket, ami úgy néz ki, hogy egy perjelet írunk a név elé. Vagyis ha <valami> volt a nyitó tag, annak zárása </valami> lesz. Ha nincs szükség külön záró tag-re, akkor a nyitó tag végén is állhat a lezáró perjel: <valami/>. A nyitó tagekben tulajdonságokat is megadhatunk, név=érték párosok formájában. A nyitó és záró tag közti rész a egy elem. (Beletartoznak maguk a tagek is). Az elemek belsejében természetesen további elemek adhatók meg, amivel egy hierarchikus rendszert hozhatunk létre.
Fontos megemlítenünk az URI-kat is, ami az Uniform Resource Identifier rövidítése és vele bármire hivatkozhatunk! Nem csak egy valahol az Internet másik végében lévő fájlra, de annak a belsejében lévő elemre ugyanúgy, ahogy valós, fizikai eszközökre is, mint egy számítógépre, vagy hálózatra kötött kamerára.
Az XML névtér-specifikáció vezeti be a minősített nevek használatát, amelyek lehetővé teszik a névütközésekből származó problémák elkerülését. A névtér deklarációkat az elemek nyitó tagjében adhatjuk meg, előírt formájú attribútum-specifikációkkal. Ezek egy-egy ún. névtér prefixhez egy-egy névtér URI-t rendelnek hozzá. A prefixeket pedig elemek és attribútumok nevei előtt használjuk. (Két alfejezettel lejjebb, az OWL-nél példa is lesz a névterekre.)
Az OWL sokban támaszkodik az RDF-re, kiegészíti azt a Szemantikus Web leírásához szükséges eszközökkel, ezért erről is ejtenünk kell néhány szót. Az RDF szerkezetileg a W3C többi leíró nyelvéhez hasonlít, mint amilyen például a HTML vagy az XML, amelyekről mindenki tud többet-kevesebbet; utóbbiról ebben a dolgozatban is esett már többször szó. Ám a hasonlóság itt ki is merül például a HTML-lel: míg az alapvetően embereknek szánt médiát ír le (leginkább szövegek vannak benne, valamint képekre és ilyesmikre való hivatkozások), addig az RDF egy adatmodellt definiál.
Magával az RDF-fel (Resource Description Framework, vagyis erőforrás-leíró keretrendszer) nevéhez híven erőforrásokat írhatunk le, információt reprezentálhatunk a weben. Legtöbbször XML-ben, a megszokott módon írhatjuk le az adatokat, de az RDF-ben leírt modell struktúrája nem feltétlenül egy fa, hanem egy irányított gráf is lehet. Ám a modell tárolása nem csak XML formátumban lehetséges, hanem egy jóval tömörebb módon is, ahol soronként egy tripletet írunk le. (Hogy mi ez a triplet, magyarul hármas, arról a következő oldalon majd olvashatunk.)
Az RDF létrehozásának több oka is volt: információt szolgáltat webes erőforrásokról, de felhasználhatják olyan alkalmazások is, melyek nyitott modellt kívánnak meg, például szervezeti folyamatok leírásához vagy tevékenységek ütemzéséhez. Továbbá lehetővé teszi, hogy az információt gépek dolgozzák fel: az adatokat nem ott hasznosítják, ahol létrejöttek, hanem az Internet valamely más részén. Az alkalmazások egymás között is kommunikálhatnak vele (gyakran erre XML-t használnak, de nem biztos, hogy az elég). Fontos még az is, hogy az információt szoftver ágensek automatikusan feldolgozhatják, vagyis a weben nem csak ember által olvasható információkhoz juthatunk, hanem egy intelligens világméretű hálózathoz, melynek részei megértik egymást és képesek együttműködni.
Tervezésekor odafigyeltek arra, hogy az adatmodell egyszerű legyen, könnyű legyen létrehozni, feldolgozni, módosítani, használni. Az adatmodell minden elemének elnevezéséhez URI-kat használ, ennek egyik következménye az is, hogy így a szókészlete teljes mértékben kiterjeszthető. Sokban kötődik az XML-hez: ugyanolyan módszerrel tárolja az adatokat, felhasználja az XML Schema-ban megismert adattípusokat, viszont az XML Schema-val támogatott XML dokumentumok tartalmát egy alkalmazás nyugodtan, kétkedés nélkül felhasználhatja, az RDF-ben viszont bárki tehet bármiről kijelentést, ami nem biztos, hogy helyes következtetés. Ha az RDF dokumentum többfelé van darabolva, azaz a feldolgozó program több helyről szedi össze az információt, egyes helyek lehet, hogy nem érhetők el. Az alkalmazásnak oda kell figyelni, kell valamilyen módszert találni arra, hogy mit kezdjen a hiányzó és az ellentmondásos adatokkal. Tervezési igény volt még természetesen, hogy tetszőleges információkat tudjuk tárolni az RDF-ben, amennyiben azokat egyszerű tényekkel ki lehet fejezni.
Az RDF által leírt adatszerkezet egy irányított gráf. Két csomópontot ha él köt össze, akkor a csomópontokat és a élt együtt egy hármasnak, angolul tipletnek nevezzük. Az él egy tulajdonságot jelöl, méghozzá a nyíl kezdőpontja felőli csomópont egy tulajdonsága, melynek értéke a nyíl végén lévő csomópont. Például a varjú csomópontnak lehet egy szín tulajdonsága, és van még egy fekete nevű csomópont is. Akkor a varjúból mutathat egy szín címkéjű él a feketére. A tripletekkel ilyen egyszerű állításokat lehet megfogalmazni, mint például "a varjú fekete". Az állítások között mindig ÉS kapcsolat van, nem tudunk VAGY-ot vagy tagadást kifejezni. Ezért azt, hogy "a varjú nem piros", már nem tudjuk RDF-ben leírni. Mind a csomópontokat, mind az éleket URI hivatkozásokkal azonosítjuk. A csomópontnál ez azt mutatja, hogy mit is reprezentál, az élnél pedig a kettő közötti kapcsolatot. Utóbbinak a címkéje egyben a gráf egy csomópontja is lehet! Ugyanis a tulajdonságokat is ugyanúgy kell definiálnunk. (Hogy pontosan hogyan, arról nemsokára szó lesz.) URI-nak szinte akármilyen címet megadhatunk, nem is fontos, hogy létező erőforrásra mutasson. (Leginkább azért van rá szükség, hogy megmondhassuk vele, mi hová tartozik.) Van néhány általánosan elfogadott név. A http://www.w3.org/1999/02/22-rdf-syntax cím például az RDF névtér URI-ja, és ezért gyakran az rdf névtér prefixet rendeljük hozzá, vagy az RDF Schema címe a http://www.w3.org/2000/01/rdf-schema#, ehhez pedig az rdfs-t szokás. Ezen a kettőn belül jókora szókészlet van definiálva, olyan alap dolgok, mint Class (osztály) vagy Property (tulajdonság).
Szükség van típusokra is. Az RDF az XML Schema-ban leírt adattípusokat használja, de természetesen újakat is lehet definiálni. Van néhány, melyek az RDF bizonyos megkötései miatt nem használhatók, de a legfontosabbak, leggyakoribbak igen, mint például az xsd:boolean vagy xsd:integer. (Az xsd előtag itt az XML Schema datatype-ot akarja jelenteni.)
Ahogy pár sorral feljebb írtam, az URI szinte akármilyen cím lehet. Az RDF-ben az URI két fő részből áll: az egyik maga a tényleges cím, a másik pedig egy ún. töredék azonosító (fragment identifier), amivel az RDF dokumentumon belülre hivatkozhatunk. A kettőt egy # választja el, ha a második egyáltalán szerepel, mert ez nem kötelező. Az URI tehát így néz ki: url#frag, amiből az RDF-et feldolgozó programnak tudnia kell, hogy az url cím azonosítja az RDF dokumentumot, és azon belül kell megkeresni a frag részt. Amennyiben a címen nem érhető el a dokumentum, akkor természetesen a benne lévő objektumot sem érjük el. (Ettől függetlenül még állításokat hozhatunk róla.)
Az egyes tulajdonságokat és kapcsolatokat ugyan megadhatjuk az RDF-ben, de a jelentésüket már nem. Ezért van nagy szükség az RDF Schema-ra, vagyis az RDFS-re, ami az RDF szókészletek leíró nyelve. Olyan erőforrásokat (osztályokat és tulajdonságokat) definiál, melyekkel leírhatunk osztályokat, tulajdonságokat vagy más erőforrásokat. Úgy is mondhatjuk, hogy az RDFS az RDF-et szemantikus tartalommal egészíti ki, azáltal, hogy módszert biztosít egymással kapcsolatban álló erőforrások és maguk a kapcsolatok leírására. Azt mondjuk, hogy szótárt ad további szótárak definiálására, ahol a szótár olyan erőforrás-gyűjtemény, melyet egy adott célra használunk és elemei adott jelentéssel bírnak. Az RDFS így az eddigieket olyan dolgokkal egészíti ki, mint például a tulajdonságok értelmezési tartománya és értékkészlete, vagy az osztályok hierarchiája. Az RDFS-t felhasználva már lehet nagyon kezdetleges Semantic Web alkalmazásokat írni, de azért nem képes mindenre. Ezért találták ki a gazdagabb szókészlettel rendelkező ontológia nyelveket, amilyen például a DAML+OIL, vagy az OWL, amik sokkal alkalmasabbak erre a feladatra. Az OWL-ről a következő fejezetben lesz szó.
Az erőforrásokat osztályokba csoportosítjuk. Az osztályok tagjai pedig a példányok. Nagyon hasonló ez a kapcsolat az objektum orientált nyelvekben megismert osztályokhoz és példányokhoz. De az RDFS-ben olyan is előfordulhat, hogy egy osztály a saját osztálya kiterjesztésének tagja (erről később), vagy hogy saját maga példánya. Az osztályok mind rdfs:Class megjelölésűek. Az osztályok hierarchiába rendezhetők. Ha A-nak van egy rdfs:subClassOf tulajdonsága, és ennek értéke S, akkor azt mondjuk, hogy A az S alosztálya és S az A szuperosztálya. Az A örökli az S tulajdonságait, vagyis ahol S-t kellene használnunk, ott használhatjuk helyette A-t is. Ugyanez persze érvényes a példányokra is: A minden példánya egyben S példánya is. Hogy érthetőbb legyen: a Majom alosztálya az Emlős-nek és természetesen Csita - a Majom egy példánya - is emlős.
Vannak speciális osztályok is. Az egyik az rdfs:Literal, ami elemi értékeket vehet fel, például lehet egy szám vagy egy egyszerű szöveg. Másik az rdfs:Datatype, ami az adattípusok osztálya.
Az rdf:Property az RDF jellemzők osztálya. A tulajdonságok mindig összekötnek valahogyan két erőforrást. Szükség lehet hát az értelmezési tartományára (rdfs:domain) és az értékkészletére (rdfs:range), melyeket azonban nem kötelező megadni. Ha egy Személy-ről van szó, az anyja tulajdonság értékkészlete lehet szintén Személy, de lehet akár Nő is, vagy a fenti példánál maradva: Emlős. De akár több értékkészlete is lehet. Az értelmezési tartománnyal hasonló a helyzet, de kicsit zűrösebb. Egy súly nevű jellemzőhöz ha hozzárendeljük a Könyv értelmezési tartományt, akkor minden erőforrás, melynek van súly tulajdonsága, az a Könyv egy példánya. Viszont itt is rendelhetünk több tartományt egy jellemzőhöz. Ha hozzárendeljük a Jármű-t is, akkor minden súllyal rendelkező erőforrás egyszerre a Könyv és a Jármű példánya is, amiknek viszont nem sok közük van egymáshoz.
A tulajdonságok hasonlóan hierarchiába rendezhetők, mint az osztályok: ugyanúgy létezik az rdfs:subPropertyOf tulajdonság, és az altulajdonság itt is örökli a felette lévő jellemzőit és ugyanúgy helyettesítheti, ahol arra lenne szükség.
Ezeken kívül az RDF-ben/RDFS-ben egyéb lehetőségek is vannak, például listákat hozhatunk létre, megszorításokat adhatunk a hármasokra, megjegyzésekkel, utalásokkal és egyebekkel láthatjuk el az erőforrásokat - ezek azonban számunkra most nem annyira fontosak.
Elérkeztünk a tetőponthoz: az OWL az a nyelv, mellyel teljes lesz a Semantic Web; ez adja azt a szükséges pluszt, mellyel megfelelő bonyolultságú kifejezések is leírhatók.
Már évekkel ezelőtt megszületett a nyelv. Régen DAML+OIL volt a neve, de már annyit változtattak rajta, hogy eléggé eltér az eredetitől és ezért új nevet adtak neki, így jött létre az OWL, azaz a Web Ontology Language. Igaz, hogy majdnem minden az elődből származik, de itt azzal nem foglalkozunk. Az OWL nem mondható ősrégi, poros témának, hiszen csak 2004. február 10-én vált W3C-s ajánlássá, tehát hivatalossá. Természetesen már a kidolgozási időszak alatt is hozzáférhető volt a leírása, így születhettek róla cikkek, melyek megvitatták előnyeit és hiányait, ezáltal tippeket adva a szerzőinek esetleges változtatásokra. Ugyanúgy a szoftveres támogatás is megkezdődött, C és Java nyelven egyaránt találhatunk programkönyvtárakat, melyek képesek a feldolgozásra és egyszerűbb következtetőgépeket is írtak hozzájuk, valamint támogatják újabb következtetők a rendszerhez hozzáadását.
Az OWL egy olyan nyelvet biztosít, mellyel részletesen leírhatunk webes dokumentumokhoz és alkalmazásokhoz kapcsolt ontológiákat, illetve azokban definiált osztályokat és kapcsolataikat. Mivel az OWL a Semantic Web "szíve", ezért kicsit részletesebben foglalkozok vele ebben az fejezetben, mint az XML-lel vagy az RDF-fel. Látni fogjuk, mennyi mindenre képes ez a nyelv és mik azok, amikre mégsem. A könnyebb érthetőség kedvéért példákkal is bemutatom az egyes képességeket. Ezekről viszont részletesen nem fogom leírni, mit művelnek, mert egyrészt ott lesz felettük az éppen tárgyalt téma, amihez kapcsolódnak, másrészt egyszerű, a való életből vett triviális kapcsolatok OWL-es reprezentációi lesznek. Hála az XML nemzeti betűkészlet-támogatásának (Unicode karaktereket használhatunk), az egyes osztályneveket és társaikat magyarul is megadhatjuk.
Kezdjük ott, hogy mi is az ontológia. A W3C ezt a szót a filozófiából lopta, ami annak a tudományát jelöli, ahogy a világ egységeit és kapcsolataikat leírjuk. Az OWL ontológiákban osztályokat, tulajdonságokat és ezek példányait tudjuk leírni. Továbbá specifikálja, hogy milyen logikai következmények vonhatóak le róluk vonatkozóan, melyeket nem is kell fizikailag beleírni az ontológiába, mivel a szemantika vonja őket maga után. A következmények nem is feltétlenül egy dokumentumból származnak, hanem akár több osztottból is, melyeket megfelelő OWL-es módszerekkel kapcsoltak össze.
Az OWL-ben héjszerűen három alnyelv épül egymásra.
Az OWL Lite azon felhasználóknak készült, akik csak le akarják írni az osztályaikat egy hierarchikus rendszerben és egyszerűbb megszorításokat akarnak csak tenni. Például, bár támogatja a számossági megszorításokat - vagyis hogy hány különböző előfordulása lehet egy jellemzőnek -, de ezek értéke csak 0 vagy 1 lehet, míg a másik két alnyelvben egyéb számok is.
Az OWL DL-ben több minden kifejezhető és megmaradunk a kiszámíthatóságnál: minden következtetés művelete véges időn belül befejeződik és garantáltan kiszámítható. Nevében a DL a Description Logic-et jelöli, azaz leíró logikát; leginkább ezt támogatja és így a következtető rendszerek vehetik nagy hasznát.
Végül az OWL Full azoknak készült, akik ki akarják használni az OWL-ben rejlő összes lehetőséget és mindent leírhatnak, amit RDF/OWL-ben csak lehet. Az OWL Full-ban nagyon kevés megkötés van, akár mondjuk az is előfordulhat, hogy egy osztály saját maga példánya vagy éppen egy tulajdonság is. Szerintem túlságosan is nagy szabadságot enged meg és a W3C is beismerte, hogy nem tartja valószínűnek, hogy valaha is lesz olyan következtető szoftver, mely az OWL Full minden részét támogatná. De legalább elvileg bármit leírhatunk benne.
Az alnyelvek természetesen azért is hasznosak, mert egy egyszerűbb nyelvet nyílván egyszerűbb leprogramozni is. Ha nincs szükség olyan komoly eszközökre, melyek csak az OWL Full-ban vannak, felesleges egy bonyolult programot futtatnunk és (viszonylag) bonyolult nyelvet használnunk. Továbbá az is csak pénzkidobás, ha mondjuk egy kisebb feladatok elvégzésére képes karórába vagy zsebkomputerbe az OWL Lite-nál komplexebb nyelvet értő chipet ültetnek.
Ahogy írtam, a nyelvek egymásra épülnek, vagyis egymás kiterjesztései, így ami például a Lite-ban érvényes állítás vagy ontológia, az a másik kettőben is - fordítottja azonban nem feltétlenül igaz. Amikor valaki egy ontológiát akar írni, először is ki kell választania a legmegfelelőbb nyelvet. A Full ugyebár a leírt tulajdonságai miatt nem túl gyakran ajánlott, a másik kettő közötti döntés pedig attól függ, hogy szükség van-e a DL által nyújtott bővített kifejezésekre, megkötésekre. Mint látni fogjuk, a Lite nyelv tulajdonságai úgy lettek megadva, hogy viszonylag egyszerű legyen a feldolgozása, míg a DL-t már nehezebb. A Full-ra meg csak nagy ritkán lehet igény, meta-modellezésnél (például ha osztályok osztályait akarjuk definiálni).
Az OWL-t úgy tervezték, hogy maximálisan kompatibilis legyen az RDF(S)-vel, szintaktikája maradjon meg az XML/RDF-nél és ne kerüljenek bele más szerkezetű egységek. Így akár egy csak XML-t ismerő feldolgozó szoftver is be tudja olvasni - legfeljebb nem ért semmit belőle.
A Semantic Web az OWL technológián alapul, és mint szó volt róla, teljesen osztott környezetben működik. Emiatt az OWL-nek is támogatnia kell az információs erőforrások elosztását. Így az egyes ontológiák nem feltétlenül függetlenek egymástól, hanem kapcsolatban is állhatnak, információt importálhatnak másik ontológiából. Attól, hogy egy osztályt definiálunk egy ontológiában, egy egész más ontológia azt nyugodtan kiterjesztheti új információk hozzáadásával. Meg kell jegyeznünk, hogy ez a kiterjesztés monoton. Tehát nem lehet visszavonni azt, amit már definiált valaki; mindig csak kiegészíthetünk, de sohasem törölhetünk.
Egy fájlban több ontológia is állhat. Az OWL egy RDF dokumentum, csak OWL kiegészítésekkel. (Így külön MIME típusa sincs, hanem csak application/rdf+xml vagy application/xml.) Ha egy HTML dokumentum szemantikáját akarjuk megfogalmazni, el kell készítenünk egy RDF/OWL fájlt és a HTML fájlban hivatkozni rá. A HTML szabvány kimondja, hogy amit nem "ért" a böngésző, azt ki kell hagynia. Így a jelenlegiek egyszerűen nem vesznek tudomást róla. Ha viszont a közeljövő egy szemantikus keresője olvassa ezt a lapot, az megtalálja ezt a hivatkozást és az RDF fájlt letöltve megtudja, hogy mik állnak a HTML oldalon; ezen felül persze meta-információk is találhatók vagy különféle szolgáltatások. (Például egy orvos honlapján lehet egy határidőnapló a betegek fogadásához, és mivel a Semantic Webnek megfelelően van lekódolva a napló, a dátumok és minden ami kell, ezért a mi ágensünk automatikusan ki tudja ezt olvasni; összevetheti mondjuk a mi határidőnaplónkkal és megkeresheti azokat az időpontokat, ami mindkettőnknek alkalmas. Ez azonban már egy újabb téma, a Semantic Web szolgáltatások - hasonlóan a webszolgáltatásokhoz -, ami túl hosszú, hogy nagyon belemélyedjünk.) Ehhez az együttműködéshez ugyebár az kell, hogy egyet értsenek az ágensek. Az RDF és az arra épülő OWL biztosít egy alap-nyelvtant, amiben nem csak az osztálydefiníciókra van lehetőség, hanem sok minden egyébre is. Például megadható mellé típus, számosság, a vele ekvivalens osztályok, hierarchia, mindenféle halmazműveletek...
A fájl legtöbbször egy <rdf:RDF> tag-gel kezdődik, amiben a névterek megadását is letudjuk. Valami hasonló lehet:
<rdf:RDF
xmlns="http://valami.hu/fauna#"
xml:base="http://valami.hu/fauna#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema#">
...
Az elsővel egy alapértelmezett névteret definiálunk. Ez azt jelenti, hogy azok az elemnevek, ahol nincs kiírva prefix, azok ehhez az URI előtaghoz tartoznak. A második az aktuális fájl báziscíme, vagyis feltesszük, hogy ez a fájl a http://valami.hu/fauna.rdf. (No persze ez nem feltétlenül így van, hiszen mint már volt róla szó, az URI-k fiktív helyekre is nyugodtan mutathatnak.) A másik négy már ismerős prefix. Ezek az alap-nyelvtan definícióihoz tartozó névtér URI-k.
A fejrészben kell még megadnunk az ontológiákra vonatkozó állításokat egy <owl:Ontology> tag-ben.
Mint mindent, ami fejlődik, az ontológiákat is verziószámokkal lehet ellátni. Az <owl:versionInfo> szolgál erre. De megadható emellett még <owl:priorVersion> is, ami egy hivatkozás az ontológia eggyel korábbi változatára, <owl:backwardCompatibileWith>, hogy mely régebbiekkel kompatibilis és <owl:incompatibleWith>, hogy melyekkel nem. Ha nincs megadva kompatibilitás, akkor azt kell feltételezni, hogy a kettő nem kompatibilis egymással. (Állhat még a fájlban <owl:DeprecatedClass> és <owl:DeprecatedProperty> is, amikkel korábbi ontológiákban definiált osztályokat és tulajdonságokat lehet visszavonni, vagyis megjelölni, hogy az új dokumentumokban ezek nem használhatók.)
Aztán az RDFS-ből átvett előre definiált elemek is szerepelhetnek, úgymint: <rdfs:label> tartalmazza az ontológia nevét, <rdfs:comment> egy hosszabb-rövidebb természetes nyelvű leírását, <rdfs:seeAlso> mutathat egy olyan ontológiára, melyet érdemes lehet megtekinteni, mert közük van egymáshoz és az <rdfs:isDefinedBy> arra, amelyik definiálta ezt az ontológiát. Az első kettőnél gyakran használnak nyelvet jelölő attrbútumot (xml:lang) is, jelezve, hogy milyen nyelven írták, és több ilyet használva több nyelven is leírhatjuk. Sem a label, sem a comment nem jelentenek semmit a logikai értelmezésben; egyszerűen csak az ontológiák forrását néző emberek számára készültek és ezért csak opcionálisak.
Még mindig a fejrészben maradva, itt szokás összegyűjteni a dokumentumra vonatkozó meta-adatokat. Leginkább a Dublin Core-tól átvett adatok ezek, melyek a címet, szerzőt és hasonlókat tartalmazzák. Az OWL Full-ban nem kötelező, de a másik két nyelvben az ilyen magyarázó jellemzőket még deklarálnunk is kell az <owl:AnnotationProperty> tag-et használva. (Pl. <owl:AnnotationProperty rdf:about="dc;creator">.)
Ami nagyon fontos, hogy a többi ontológia importálása is itt történik, <owl:imports> sorokkal, és a beimportált ontológia ennek a részévé válik. Az importálás tranzitív, vagyis az importált ontológia által importáltak is belekerülnek. Ha saját magát próbálja importálni, akkor azt figyelmen kívül kell hagyni. Ha két ontológia egymást importálja, akkor azokat ekvivalensnek lehet tekinteni. Az importált ontológiákhoz is szokás névteret rendelni. Mivel előfordulhat, hogy a fájl nem található (megszűnt, nem elérhető a szerver vagy bármi más miatt), így nem biztos, hogy sikerül a megnyitás. Teljesen az implementációra bízzák, hogy ilyenkor mi történjen.
<!DOCTYPE rdf:RDF [
<!ENTITY lény "http://valami.hu/fauna#">
<!ENTITY növény "http://valami.hu/flora#">
]>
<owl:Ontology rdf:about="">
<rdfs:comment>Egy példa ontológia állatokra.</rdfs:comment>
<owl:imports rdf:resource="http://valami.hu/flora" />
<rdfs:label xml:lang="hu">Állat Ontológia</rdfs:label>
<rdfs:label xml:lang="en">Animal Ontology</rdfs:label>
</owl:Ontology>
A példából csak a DOCTYPE rész lehet ismeretlen: az XML fájlokban gyakran használják az ebben található entitásdeklarációkat az URI-k rövidítésére. Ezentúl ha bárhol leírjuk például azt, hogy "&lény;Ember", akkor azt a feldolgozó program automatikusan helyettesíti azzal, hogy "http://valami.hu/fauna#Ember". (Egyszerű szöveghelyettesítésről van szó.)
Az osztályok talán a legalapvetőbb elemei az OWL-nek. Bár osztályok már az RDFS-ben is vannak, de ezek különböznek az OWL-étől, így itt <owl:Class>-ok találhatók, az <rdfs:Class>-ok helyett és az OWL-es osztályok az RDFS-es osztályok alosztályai (mivel azokénál szigorúbb megkötések vonatkoznak rájuk). A különbségek miatt nem minden RDFS osztály legális OWL osztály, kivéve az OWL Full-ban, mert ott a kettő egyenértékű. Következtetéseket leginkább példányokról vonunk le. A példányok egy osztály kiterjesztésének a tagjai. Pontosabban fogalmazva, az osztály kiterjesztése a hozzá kapcsolt példányok halmaza, mely ugyan kapcsolatban áll magával az osztállyal, de nem egyezik meg vele! Előfordulhat, hogy két osztálynak ugyanaz a kiterjesztése és ők mégis két különböző osztály. (Megjegyzés: az OWL Full-ban megtörténhet, hogy egy példány egyben osztály is, míg a két másik alnyelvben ez ki van zárva.)
Meg kell határoznunk az osztályokat, amelyekhez a példányok tartoznak és hogy milyen tulajdonságokat örökölnek. Bár magukra a példányokra is tehetünk megkötéseket, leginkább az osztály definiálása határozza meg őket. Az osztály, mondhatjuk, hogy egy absztrakt váz, míg a példány ennek egy konkrét előfordulása. Például az Ember osztálynak lehet egy KovácsPistike nevű példánya. Amikor az ontológiákkal dolgozunk, az osztályokat és a példányokat is vizsgálhatjuk. Aki kicsit is ért az objektum-orientált modellezéshez, annak ez a bekezdés szinte semmi újat nem mondott. Hiszen az OWL is objektum-orientált az osztályaival, példányaival, öröklődési rendszerével - legfeljebb itt-ott van megkavarva kicsit a szokásostól eltérően.
Egy új osztályt mindenféle tulajdonságok nélkül létrehozni csak ennyibe kerül:
<owl:Class rdf:ID="Ember"/>
Így lett egy osztályunk, aminek már neve is van és létezik, egyébként viszont nem tudunk róla semmit és példányairól sem, hogy vannak-e vagy nincsenek. Jellemzőit megadhatjuk létrehozáskor is, de bármikor később is - ahogy arról már szó volt, egy osztály leírását akár egy másik dokumentumban is folytathatjuk, köszönhetően a teljes elosztottságnak. Ez viszont egy kritikus pont: ha egy másik fájlban módosítjuk az osztályt, az nem jár együtt az eredeti módosításával. Így az osztálynak létrejön egy egyszerűbb és egy bővebb alakja is. Kérdéses lehet, hogy most akkor melyiket használjuk?
A fenti sorral tehát létrejött az Ember osztály, amire ebben a dokumentumban #Ember azonosítóval, máshonnan teljes URI-val hivatkozhatunk. Ha egy osztályt bővíteni akarunk, akkor az rdf:ID helyett rdf:about-ot kell írnunk. (Az rdf:ID-vel létrehozni tudunk, míg az rdf:about-hoz egy URI tartozik, ami által mutatott erőforrásról valamilyen állítást teszünk.) Bővítsük megjegyzéssel a fentit:
<owl:Class rdf:about="#Ember">
<rdfs:comment>Egy személy adatait tartalmazza.</rdfs:comment>
</owl:Class>
Az osztályok hierarchiába szervezhetők. Két osztály között definiálható hierarchia, ha az egyik részletesebb, mint a másik. A részletesebb alosztálya az általánosabbnak, ami pedig szülő- vagy szuperosztálya az elsőnek. A hierarchia tranzitív tulajdonság: ha A alosztálya B-nek és B alosztálya C-nek, akkor A alosztálya C-nek is. Továbbá, ha A alosztálya B-nek, akkor A minden példánya B-nek is példánya. A hierarchia-fának a gyökerében az owl:Thing nevű osztály áll és természetesen minden példány, ami csak létezik, ennek is példánya, és minden általunk definiált osztály automatikusan alosztálya lesz. A halmazműveletek során juthatunk üres halmazhoz is, emiatt egy owl:Nothing nevű üres osztályt is definiáltak. Ez pedig alosztálya minden egyéb osztálynak.
<owl:Class rdf:ID="#Ember">
<rdfs:subClassOf rdf:resource="&lény;Emlős"/>
</owl:Class>
Az osztály definiálásának másik része a megkötések megadásából áll. Az osztály megszorításai természetesen a példányokra is érvényesek lesznek. Az alosztály-megjelölés is egy példa a megszorításokra, de látni fogunk még jó párat.
Az osztályt rdf:ID-vel hívjuk életre, de az nem kötelező, azaz nem is muszáj, hogy neve legyen az osztálynak. Nem csak ezen a módon hozhatók létre, hanem úgy is, hogy felsoroljuk a példányait vagy valamilyen halmazműveletet végzünk már létező osztály(ok)on. Ezekről kicsit később lesz szó.
Egy osztály tagjait, azaz konkrét előfordulásait példányoknak nevezzük. Létrehozásukhoz mindössze annyit kell tennünk, hogy egy osztály tagjaként deklaráljuk. Ha van például egy Ember osztályunk:
<Ember rdf:ID="KovácsPistike" />
Ha ahhoz van kedvünk, ugyanezt leírhatjuk hosszabban is:
<owl:Thing rdf:ID="KovácsPistike">
<rdf:type rdf:resource="#Ember"/>
</owl:Thing>
Amikor vizsgáljuk az objektumainkat, az osztályokat és a példányokat is megtekinthetjük. Az osztály valamilyen csoportosítás szerint összetartozó objektumokat ír le, tehát az osztályokat akkor vizsgáljuk, ha általánosan akarunk elmondani valamit például az Emberről. A példányok pedig valamely egyéni előfordulásai ezeknek, így a KovácsPistike példányt akkor nézzük, ha ennek az egyednek a tulajdonságaira vagyunk kíváncsiak. Természetesen a példány "bővebb" az osztálynál, hiszen abból származik; vagyis az osztályra jellemzőket a példányon keresztül is látjuk.
A kezelésük azért kissé eltér az objektum-orientált programozásban megszokottól. Ott ugyebár egyértelmű, hogy mi az osztály és mi a példány. Az OWL-ben azonban lehet, hogy egy objektum egyszer osztályként viselkedik, máskor viszont példányként. Például a Madár osztálynak lehet egy Feketerigó nevű példánya. Ez utóbbi viszont osztálynak is tekinthető, mert neki is lehetnek példányai, például egy Csőrike nevű feketerigó. A kérdés jogosan merülhet fel: a Feketerigó miért példány és nem alosztály?! Nem könnyű különbséget tenni a kettő között, mert bár látszólag mind a kettőt használhatnánk, a döntés mégsem önkényes. A Madár a madárfajták halmazát írja le és ezért a részhalmazainak a madárfajták egy részhalmazát kell jellemeznie. A Feketerigó azonban nem egy részhalmaza a madárfajtáknak, hanem egy madárfajta. Nagyon könnyű összekeverni a kétféle kapcsolatot és az efféle példáknál nagyon meg kell gondolnunk, hogy ez most éppen milyen is. A két kisebb OWL alnyelvben külön vannak választva az osztályok és a példányok. Ott tehát ha a Feketerigó egy példány, azt nem kezelhetjük osztályként. Úgy kell akkor vennünk, mint a Madár egy alosztálya. Az OWL Full viszont megengedi, hogy mindkettőként használható legyen, ott tehát ez a megkötés nem gátol miket.
Mint látható, egy ontológia fejlesztését nagyban befolyásolja, hogy mire akarjuk használni és milyen alnyelvben.
Természetesen vannak olyan esetek is, amikor nyilvánvaló, hogy alosztályt vagy példányt használunk. Visszatérve az emberekhez: egyértelmű, hogy a Programozó vagy a Takarító alosztálya az Ember-nek. Az EnyedyGyula pedig példánya a Programozó-nak, valamint a MarikaNéni és az IrénkeNéni a Takarító-nak. Mind a három egyben példánya az Ember-nek is. Sajnos nem mindig ilyen egyszerű a döntés.
Az eddig leírtakkal már definiálhatunk taxonómiákat. A taxonómia rendszertant vagy osztályozástant jelent és az osztályokkal ez meg is valósítható; a már sokat tárgyalt példában egy élőlény rendszertan teljes hierarchiája megadható, kiindulva onnan, hogy Élőlény vagy Állat, akár olyan mélységig, hogy Császárpingvin. Ennél azonban jóval többre képes az OWL. A tulajdonságokkal tudjuk jellemezni az osztályokat, kimondani róluk általános tényeket, de jellemezhetjük a példányokat is, ha valamely speciális kijelentést akarunk róluk tenni.
A tulajdonság egy bináris reláció két objektum között. Kétféle tulajdonságot különböztetünk meg, aszerint, hogy mik között létesít kapcsolatot.
Az egyik az objektum tulajdonság, ami két példány között áll fenn, a másik pedig az adattípus tulajdonság, ahol egyik oldalon egy példány áll, a másikon pedig egy RDF literál vagy egy XML séma adattípus értéke. (A tulajdonság definiálásakor természetesen nem egy konkrét példányra, hanem annak az osztályára hivatkozunk.)
A jellemzőkből is példányok születnek, de a tulajdonság-példányok csak úgy magukban nem fordulnak elő, csak osztály-példányokon belül. Lehet, hogy egy példányhoz nem tartozik az adott tulajdonságból egy konkrét előfordulás sem, de az is lehet, hogy több is. Az épp imént említett császárpingvines példánál maradva: ha van mondjuk egy fialásánakÉve nevű tulajdonság, az egy pár napos egyednél biztosan nem jelenik meg, de egy idősebb nőstény pingvinnél több is lehet belőle, attól függően, hogy hányszor szült világra utódokat.
Akárcsak az osztályok esetén, a tulajdonságokra is megkötéseket tehetünk. Ha több megkötést is teszünk és nem adunk meg összekapcsoló operátort, akkor az alapértelmezés a konjunkció, azaz az ÉS kapcsolat. Az alábbi példában a megkötés az a táplálkozás tulajdonságra, hogy értelmezési tartománya az Ember és értékkészlete a TáplálkozásTípus. (Az értelmezési tartományra és az értékkészletre (domain és range) az RDFS-nél már tárgyaltak érvényesek.)
<owl:ObjectProperty rdf:ID="táplálkozása">
<rdfs:domain rdf:resource="#Állat"/>
<rdfs:range rdf:resource="#TáplálkozásTípus"/>
</owl:ObjectProperty>
Ez azt jelenti, hogy egy Ember példányhoz társítható a táplálkozása jellemző és annak értéke egy TáplálkozásTípus példány. Értelmezési tartomány több is szerepelhet, ekkor azok metszete jön létre, vagyis csak olyan példányokra használható, melyek mindegyik felsorolt osztálynak példányai. Az értékkészletre is ugyanez érvényes.
A kettő együtt a programozási nyelvekben úgy fordul elő, mint paraméter és visszaadott érték (meghatározzák ezek típusait), a tulajdonság pedig mint egy paraméteres változó vagy függvény. OWL-ben az értékkészletre nem azt mondjuk, hogy a tulajdonság típusa, hanem hogy általa következtethetünk a típusra.
<owl:Thing rdf:ID="KovácsPistike">
<táplálkozása rdf:resource="#Mindenevő"/>
</owl:Thing>
Itt következtethetünk arra, hogy KovácsPistike egy állat (nem rossz értelemben), mivel a táplálkozása nevű tulajdonságnak az értelmezési tartománya az Állat.
A másik tulajdonságfajta az adattípusokra mutat. Az XML Schema-ban definiált típusok közül nagyon sokat használhatunk. Az OWL Full-ban ezeket kiegészítették még a felsorolásos típussal, de azzal most nem foglalkozunk.
<owl:DatatypeProperty rdf:ID="születésiDátuma">
<rdfs:domain rdf:resource="#Állat"/>
<rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</owl:DatatypeProperty>
(Néhány oldallal ezelőtt már volt egy említés az xsd prefixről, ami az XML Schema-ra mutat, a többi pedig magától értetődő.) A típusok között természetesen nem csak számok állnak, hanem szöveg, idő, dátum és hasonlók is. Használhatunk továbbá az RDF-ből felsorolás-listát. Furcsa módon az OWL következtető gépekkel szembeni elvárás csak az xsd:string és xsd:integer típusokra terjed ki, amit ismerniük kell. Egyéb típusokat úgy kell kezelni, hogy a literálok akkor egyenlőek, ha lexikálisan megegyeznek, egyébként pedig nem lehet eldönteni az egyenlőséget.
A tulajdonságok ugyanúgy hierarchiába szervezhetők, mint az osztályok, az rdfs:subPropertyOf segítségével.
<owl:ObjectProperty rdf:ID="bőrfelülete">
<rdfs:domain rdf:resource="#Állat"/>
<rdfs:range rdf:resource="#BőrfelületLeíró"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="bőrszíne">
<rdfs:subPropertyOf rdf:resource="#bőrfelülete"/>
<rdfs:range rdf:resource="#Bőrszín"/>
...
</owl:ObjectProperty>
Talán nem a legjobb példát sikerült felhozni... Az altulajdonságnak nem muszáj mindent örökölnie a szülőtől - erre utal a három pont. Kaphat új tulajdonságokat vagy kiegészítheti a "fentről" kapottakat. Itt például még egy értékkészletet adunk neki. (Említve volt, hogy ilyenkor a kettő metszete lesz az igazi.) Tehát a bőrszíne altulajdonsága annak, hogy bőrfelülete. Annak ugyanis lehetnek más részei is a színen kívül, például tapintás vagy kültakaró. Az altulajdonsági viszony azzal jár, hogy ha egy példánynak van bőrszíne, akkor kell legyen bőrfelülete is.
A tulajdonságokat nagyon egyszerű hozzárendelni a példányokhoz: az elem részben megadjuk a tulajdonság nevét és az értékét. Objektum tulajdonságoknál a megszokott rdf:resource-val, adattípus jellemzőnél pedig rdf:datatype-val.
<Ember rdf:ID="KovácsPistike">
<bőrszíne rdf:resource="#Fehér"/>
<születésiDátuma rdf:datatype="&xsd;nonNegativeInteger">
1999
</születésiDátuma>
</Ember>
A tulajdonságokat tovább pontosíthatjuk a típusuk megadásával, amivel a róla levont következtetéseket lehet finomítani. Az alábbi típusokba tartozhatnak: tranzitív, szimmetrikus, funkcionális, inverz és inverz funkcionális.
Ha egy T tulajdonság tranzitív (TransitiveProperty), akkor teljesül a következő: T(x,y) AND T(y,z) IMPL T(x,z). Például egy helyzete jellemző lehet tranzitív: mivel a Hajdúság HajdúBiharMegye-ben van, ami pedig Magyarország-ban, így a Hajdúság Magyarország-ban is van.
<owl:ObjectProperty rdf:ID="helyzete">
<rdf:type rdf:resource="&owl;TransitiveProperty"/>
<rdfs:domain rdf:resource="&owl;Thing"/>
<rdfs:range rdf:resource="#Térség"/>
</owl:ObjectProperty>
<Térség rdf:ID="Hajdúság">
<helyzete rdf:resource="#HajdúBiharMegye"/>
</Térség>
<Térség rdf:ID="HajdúBiharMegye">
<helyzete rdf:resource="#Magyarország"/>
</Térség>
A szimmetria (SymmetricProperty) még egyszerűbb: T(x,y) EQ T(y,x). A példában a szomszédja-t kell figyelni, a jellemző definiálását itt mellőzöm, de hasonló, mint az előzőnél:
<Térség rdf:about="#HajdúBiharMegye">
<szomszédja rdf:resource="#SzabolcsSzatmárBeregMegye"/>
</Térség>
A következő a funkcionális (FunctionalProperty) tulajdonság: T(x,y) AND T(x,z) IMPL y=z. Azt mondja ki, hogy a tulajdonságnak legfeljebb egy értéke lehet, vagyis egy példánynál ez a tulajdonság nem fordulhat elő többször, különböző értékkel. Például személyi igazolványa csak 1 lehet egy embernek.
<owl:DatatypeProperty rdf:ID="személyiIgazolványSzáma">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Ember"/>
<rdfs:range rdf:resource="&xsd;string"/>
</owl:DatatypeProperty>
A negyedik az inverz (inverseOf): T1(x,y) EQ T2(y,x). Két tulajdonság akkor inverze egymásnak, ha értelmezési tartományuk és értékkészletük megcserélve egyező. Egy személy és egy dokumentum között fennállhatnak a szerzője és a műve tulajdonságok, melyek egymás ellentétei. Míg a szerzője a dokumentumra vonatkozik és értéke a személy, addig a műve a személyhez köthető és értékül felveheti a dokumentumot.
Az utolsó pedig az inverz funkcionális (InverseFunctionalProperty) jellemző. A kettő egyesítéséből jött létre. Az ilyen tulajdonságok egyértelműen meghatározzák a példányt, vagyis nem lehet olyan, hogy ha két különböző példány is rendelkezik ezzel a tulajdonsággal, a tulajdonságok értéke megegyezzen. Mivel más példányokhoz más értékek tartoznak, ez olyan, mint az elsődleges kulcs az adatbázisokban. Például anyja csak 1 lehet valakinek, azaz nincs olyan, hogy két nő gyermeke ugyanaz legyen. (Természetesen az nem tiltott, hogy egy anyának több gyermeke is legyen, vagyis több különböző érték is rendelhető egy példányhoz.)
<owl:InverseFunctionalProperty rdf:ID="anyja">
<owl:domain rdf:resource="#Nő"/>
<owl:range rdf:resource="#Ember"/>
</owl:InverseFunctionalProperty>
Ezeken kívül még mindig vannak lehetőségeink a tulajdonságokkal kapcsolatban: mindenféle egyéb megszorításokat tehetünk rájuk. Ezeknek a megkötéseknek különleges alakjuk van: <owl:Restriction> blokkba kell zárni, egy <owl:onProperty> elem jelenti, hogy most megszorítás következik és a következő elem már maga a megkötés. Megadhatjuk, hogy honnan vegyenek fel értéket az egyes példányok eme tulajdonságuknak értékül, hogy hány ilyen tulajdonság tartozhat egy példányhoz, vagy hogy mi legyen a tulajdonság konkrét értéke.
Az első típusba az <owl:allValuesFrom> és az <owl:someValuesFrom> tartoznak. Az első kimondja, hogy minden olyan példány esetén, amelyikhez tartozik ilyen tulajdonság, ott a tulajdonság értékének a megadott osztály példányának kell lennie. Jöjjön egy példa, hogy érthetőbb legyen:
<owl:Class rdf:ID="Nagymacska">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#zsákmánya"/>
<owl:allValuesFrom rdf:resource="#Állat"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Vagyis egy ragadozó macskához akárhány zsákmánya tulajdonságot rendelünk, annak típusa mindenképp Állat kell legyen.
Természetes, hogy felbukkan egyesekben a kérdés: miért nem állítottuk be a zsákmánya tulajdonsághoz értékkészletnek az Állat-ot? Az a fajta módszer általánosan jelent értékkészletet, vagyis a tulajdonság minden konkrét előfordulására vonatkozik. Amit itt megírtunk, az viszont lokális, azaz csak a Nagymacska példányaira. Ha egy madár például kizárólag rovarokkal táplálkozik, nála is írható egy ilyen megszorítás, de ott Állat helyett Rovar áll.
A társa, az <owl:someValuesFrom> hasonló, de ahogy a neve is utal rá, csak néhány értékre ad megszorítást. Egészen pontosan azt jelenti, hogy a tulajdonság konkrét előfordulásai közül legalább egynek innen kell értéket felvennie. Amiben még különbözik, hogy ez a számosságra vonatkozóan legalább egyet ír elő. Tehát míg az allValuesFrom esetén lehet nulla darab ilyen tulajdonság is, itt minimum egy kell legyen, de persze lehet több is - ami fontos, hogy közülük legalább az egyik innen vegyen fel értéket, a többi pedig vehet máshonnan is.
Ha arra van szükség, a tulajdonságok számosságát pontosan is megkérhetjük. Erre az <owl:cardinality> használható. Például:
<owl:Class rdf:ID="Személy">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#születésiDátuma"/>
<owl:cardinality rdf:datatype="&xsd;date">
1
</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Mivelhogy születési dátuma csak egy van az embernek. Így minden Személy példánynál pontosan egy születésiDátuma lesz.
Az OWL Lite-ban a számosság mindössze 0 vagy 1 lehet. De már így is elég sok minden kérhető: a someValuesFrom-mal elérhetjük, hogy legalább egy ilyen jellemzője legyen valaminek; a FuncionalProperty-vel azt, hogy legfeljebb egy; a cardinality-vel pedig azt, hogy pontosan egy. A másik két nyelvben a cardinality helyett maxCardinality-t és minCardinality-t használunk és ezek értéke bármely természetes szám lehet.
Csak a két magasabb rendű nyelvben alkalmazható még az <owl:hasValue> is, amivel egy konkrét tulajdonság értéken alapuló osztályt hozhatunk létre. Azaz, pontosabban fogalmazva, egy példány akkor lesz ennek az osztálynak példánya, ha legalább egy olyan ilyen tulajdonsága van, ami a hasValue-nál megadott értéket veszi fel. Ez a tulajdonságra tett megkötés természetesen szintén csak lokális, erre az osztályra vonatkozó.
Az URI-k segítségével egyéni nevet adhatunk objektumainknak. Ez viszont nem jár azzal, hogy ha két objektum URI-ja különböző, akkor az objektumok is különbözőek kell legyenek. Ha össze akarunk kapcsolni már két létező ontológiát, akkor lehet, hogy vannak olyan osztályok, melyek ugyanazt jelentik. De az URI-juk különböző: egyrészt azért, mert külön fájlban vannak, másrészt az osztálynév is lehet eltérő. Például az egyikben Állat, a másikban Animal név alatt szerepel ugyanaz.
Természetesen kimondhatjuk két osztályról, hogy azok egyenértékűek. Ezzel azonban nem árt vigyázni: ha az ontológiák ellentmondásosak, akkor egyetlen olyan példány sem jön létre, mely mindkét osztály megkötéseinek megfelel. Tényleg csak akkor érdemes ezt kimondani, ha teljesen azonosan definiálták az osztályokat és pontosan ugyanazok a példányaik.
<owl:Class rdf:about="#Állat">
<owl:equivalentClass rdf:resource="&being;Animal"/>
</owl:Class>
Ha visszalapozunk a Nagymacska példához, ott láttuk, hogy zsákmányuk Állat. Azonban az, hogy valaminek Állat a zsákmánya, még nem jelenti, hogy Nagymacska. Az equivalentClass is állhat ilyen megkötésnél: ha a subClassOf-ot lecserélnénk equivalentClass-ra, akkor a megszorítás nem csak szükséges, de elégséges feltétel is lenne; azaz pontosan azok a nagymacskák, akik állatokat esznek, és akik állatokat esznek, azok a nagymacskák. A példa azért rossz, mert a valóságban ez nem így van, de ami nekünk most fontos: így is biztosíthatunk ekvivalenciát az objektumok között.
A tulajdonságokkal hasonló a helyzet. Ott is lehet, hogy mindkét helyen definiáltak egy jellemzőt és azok ugyanazt jelentik. Az ezek közötti azonosságot az <owl:equivalentProperty> elemmel mondhatjuk ki.
Természetesen a példányok is lehetnek ekvivalensek, amiket az <owl:sameAs>-szel kapcsolunk össze. Leginkább ennek is olyankor van értelme, ha két különböző ontológiában van a két példány és mi egyesíteni akarjuk az ontológiákat.
OWL Full-ban bármit egyenlővé tehetünk bármivel, azaz ott a sameAs mindenre használható. Ekvivalenssé tehetünk vele például egy osztályt egy tulajdonsággal (és ilyenkor mindkettőt példányként kell kezelni). (Szerintem az OWL Full itt túlságosan is nagy szabadságot enged meg és nagy zűrzavart képesek okozni az ilyen lehetőségek.)
Az <owl:differentFrom> ennek az ellentéte: a két példány különbözik egymástól. Például egy Martinihez megadhatjuk tulajdonságként, hogy édes vagy száraz. Egyéb kikötések nélkül lehet, hogy mindkét értéket felveszi, ami nevetséges. Ha azonban az édest és a szárazt különbözővé tesszük, akkor nem veheti fel mindkét értéket. Megmondhatnánk azt is, hogy a tulajdonság számossága legfeljebb 1 lehet: ekkor azonban ha azt is megadja valaki, hogy édes, meg azt is hogy száraz, akkor a következtető gép kétféleképp dönthet: vagy azt mondja, hogy hibás a megadás, vagy azt, hogy mivel csak egy értéke lehet és kettőt adtunk meg, akkor a kettő nyílván egyenértékű. Pedig épp ellenkezőleg! Ha viszont számosságot is megadunk és a differentFrom-ot is, akkor ilyen esetben a következtető gép máris tudja, hogy ez egy ellentmondás. Normál esetben pedig azt szűri le ebből a kijelentésből, hogy ami édes, az nem száraz.
Ha kettőnél többről kell kimondanunk, hogy mind különbözőek, akkor nagyon hosszú lenne ilyen párokat írni. Erre inkább az <owl:AllDifferent> és az <owl:distinctMembers> páros használható:
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<Szín rdf:about="#Piros"/>
<Szín rdf:about="#Fehér"/>
<Szín rdf:about="#Zöld"/>
</owl:distinctMembers>
</owl:AllDifferent>
Sajnos arra nincs lehetőség, hogy ezt a listát később, a fájl egy másik részében vagy egy másik fájlban bővítsük, azaz nincs olyan elem, amivel hozzá lehetne adni egy új tagot, ha mondjuk definiáltunk egy új színt. Ilyenkor vagy le kell másolnunk ezt a listát, kiegészítve az új színnel, vagy az új szín és minden már létező szín között ki kell adnunk a differentFrom tag-et.
Még egy kifejezésről essék szó, az <owl:disjointWith>-ről: azt mondja ki, hogy két osztály diszjunkt; nem lehet olyan, hogy egy példány mind a két osztálynak példánya legyen.
<owl:Class rdf:ID="Emlős">
<owl:disjointWith rdf:resource="#Madár"/>
<owl:disjointWith rdf:resource="#Hal"/>
...
</owl:Class>
Meg kell jegyeznünk, hogy ezzel csak azt mondtuk, hogy az Emlős az se nem Madár, se nem Hal. Azt viszont ez nem mondja ki, hogy a Madár és a Hal is diszjunkt!
Már volt szó arról, hogy osztályokat nem csak az rdf:ID-vel hozhatunk létre. Itt az ideje, hogy megismerjük a többi módszert: a halmazműveleteket és a felsorolást.
A matematikából ismert halmazoperátorok használhatók: metszet, unió és komplemens, sorban intersectionOf, unionOf és complementOf. Az első kettő természetesen két dolgot kapcsol össze, míg az utolsó egyre vonatkozik. A műveletben nem feltétlenül osztályok vesznek részt, ugyanúgy megszorítások is előfordulhatnak. Például az alábbiban:
<owl:Class rdf:ID="Tigris">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Nagymacska"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#mintázata"/>
<owl:hasValue rdf:resource="#Csíkos"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
Itt azt mondtuk ki, hogy azok a tigrisek, amik nagymacskák és csíkos mintázatuk van. A dolog visszafelé is igaz: ha egy példány Nagymacska, ezenkívül létezik mintázata tulajdonsága, méghozzá Csíkos értékkel, akkor abból következik, hogy a példány a Tigris egy példánya is.
Egyenértékű eredményt biztosítana az is, ha a Tigris-t egyaránt a Nagymacska alosztályaként és a megszorítás alosztályaként is definiálnánk, mivel ilyenkor is metszet keletkezik.
Az unió megadása hasonló, de mint tudjuk, ott az kellett, hogy a példány mindkét osztályba vagy megkötésbe beleessen, az uniónál viszont elég az egyikbe.
<owl:Class rdf:ID="Élőlény">
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Állat"/>
<owl:Class rdf:about="&növény;Növény"/>
</owl:unionOf>
</owl:Class>
Megjegyzés: amikor a fejrészről és a névterekről volt szó, ott importáltuk a flora.rdf-et, amihez a növény rövidítés készült, és feltesszük, hogy abban definiáltuk a Növény osztályt.
A harmadik lehetőség a komplemens-képzés. Egy osztály komplemensébe minden beletartozik, ami az osztályba nem. Ez így természetesen egy nagyon nagy halmazt eredményez, ezért gyakran áll a komplemens-képzés után egy metszet-képzés is, a halmaz méretének csökkentésére.
A halmaz kivonásra nincs külön művelet, de az intersectionOf-fal és a complementOf-fal egyszerűen megoldható.
Osztályt még úgy is létrehozhatunk, ha felsoroljuk az elemeit. A felsorolásnak teljesnek kell lennie, ezeken kívül nem lehetnek más példányok az osztály elemei.
<owl:Class rdf:ID="TáplálkozásTípus">
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Ragadozó"/>
<owl:Thing rdf:about="#Növényevő"/>
<owl:Thing rdf:about="#Mindenevő"/>
</owl:oneOf>
</owl:Class>
(Az owl:Thing helyett állhatott volna az is, hogy TáplálkozásTípus.)
A dolgozatban leginkább egy állat otológia volt a példák tárgya, mely egy növény ontológiát is importált, így adva ki együtt egy élőlény ontológiát. Ezek a dokumentumok a valóságban nem léteznek, csak én találtam ki a példákat.
A W3C azonban a Semantic Web-hez, illetve az OWL nyelvéhez készített egy bor és étel ontológiát, melynek az a célja, hogy egy bizonyos ételfajtához vagy -menühöz felajánlja a leginkább hozzáillő bort. Sajnos ezt kipróbálni nem tudtam, de a fájlok megtekinthetők a honlapjukon (www.w3.org).
Létezik viszont a fájlok egy régebbi változata is, mely a nyelv korábbi változatában, DAML-ben íródott. Írtak egy Wine Agent nevű alkalmazást, mely leginkább erre az ontológiára támaszkodva borokat és egyéb kiegészítőket (pl. hozzá illő poharakat) ajánl fel az ételek mellé. A programot folyamatosan fejlesztik jelenleg is. Megtekinthető ezen a címen.
A W3C egy munkatársa kifejlesztett egy terület-ontológiát, direkt a wine.rdf-hez kapcsolódóan, mivel a boroknál nagyon meghatározó, hogy hol termelték a szőlőt, hol készült belőle bor. Több olvasható róla itt.
Az elektronikus kereskedelemben is fontos lesz a Semantic Web. Gépi alapú kommunikáció folyik a vásárló és az eladó között, a piacokat képes összekötni, és különböző piacokon használhatjuk ugyanazokat a leírásokat. Ezeket nyújtja a VerticalNet, mely gyűjtőhelye az ipar alapú e-kereskedőhelyeknek. A Gene Ontology Consortium orvosi ontológiákat definiál; génkutatással, proteinekkel és hasonlókkal kapcsolatosakat. A Semantic Web terjeszkedik, így egyre több honlapon elő fog fordulni.
Nem könnyű a Semantic Web jövőjéről írni, tekintve, hogy maga a Semantic Web is egyelőre csak jövő... Mivel még abszolút nem elterjedt, ezért rengeteget változhat a végső alakjáig (ha van ilyen egyáltalán). Megjelent ugyan pár cikk már magyarul, az origo-n, az index-en és egyéb hírportálokon; ezek minden esetben boldogan újságolták, hogy milyen jó lesz ez nekünk. Leginkább a keresést emelték ki, amin sokat "dobna". Úgy vettem észre, hogy még sincs egyáltalán a köztudatban; én legalábbis akárkinek, akár internetes guruknak is, említettem azt, hogy "Semantic Web", csak rázták a fejüket tanácstalanul.
Amíg pedig valami nincs elterjedve, addig sokat változhat.
Lássuk csak, milyen a most kigondolt irány! Az XML-nek nagy a sikertörténete, roppant gyorsan elterjedt és már mindenhol használják. Az RDF nem túl ismert nyelv, de mivel csak kicsit öregebb az OWL-nél, ne is várjunk túl sokat. Végül az OWL maga, az ontológia nyelv, ami ezen a tudományterületen kívül (vagyis a laikusok számára) szintén nem túl ismert; a cikkekben nem is nagyon említették az OWL-t, csak annyiban, hogy valamilyen ontológia nyelvre is szükség van.
A W3C bízik benne, hogy az OWL lesz a Semantic Web ontológia nyelve. Egyrészt más jelenleg nincs is (A DAML+OIL már elavultabb az OWL-nél), másrészt a W3C a WWW nagy atyja, egy többszáz szervezetből álló társulás, olyan hatalmas tagokkal, mint a Sun, a Microsoft vagy az IBM, vagyis alighanem az lesz, amit ők szeretnének.
Két olyan dolog van, melyhez az OWL-nek köze kellene, hogy legyen. Az egyik a weblapok tartalma, a másik az önálló szolgáltatások, ágensek világa.
A weblapok mellé rendelhetünk egy RDF vagy OWL fájlt, melyben a lapot leírjuk szemantikusan is, vagyis megfogalmazzuk, hogy miről is szól az adott oldal. Mint ahogy a jelenlegi keresők letárolják az oldal szövegét, a szemantikus keresők pedig letárolják a témáját. Kereséskor így pontosabban tudunk kutakodni, biztosabban találunk rá arra az oldalra, mely valóban azzal foglalkozik, ami minket érdekel.
Világos, hogy nem csak a szemantikus keresők létrejöttére kell várnunk; ami problémásabb, azok a szemantikus oldalak! Ez azt jelenti, hogy az oldalhoz társítunk egy RDF dokumentumot is, amiben meghatározzuk az oldal tartalmát. (Azért RDF, és nem OWL dokumentumot készítünk, mert egyrészt nincs szükség rá, másrészt jóval bonyolultabb is lenne. Az OWL dokumentumokat csak a téma szakértői készítik majd, például következtetésekhez. Hogy akkor miért is beszéltem ennyit az OWL-ről? Azért, mert azon alapul a Semantic Web. Az RDF-ben az egyszerű weblapkészítők megadhatják az oldalak tartalmát, de többet ne várjunk tőlük. Ha azonban valami bonyolultabb dolgot is akarunk az adatokkal, méghozzá egységes keretek között, akkor az OWL-re van szükség.) Jelenleg csak néhány oldal mellett található ilyen leírás, pedig a működéshez az kell, hogy minden oldalhoz társuljon. Ehhez pedig újabb generációs webszerkesztő programok kellenek, melyek kevés, a felhasználóhoz intézett kérdés alapján automatikusan legenerálják a szemantikát. (De mint ahogy most is van, aki egy egyszerű szövegszerkesztővel írja a HTML lapokat, az ugyanúgy "kézzel" készíthet OWL fájlokat is.) Aztán ha megjelentek ezek a programok, a felhasználókat rá kell venni, hogy fektessenek kis plusz energiát abba, hogy az OWL-t is elkészíttessék a szövegszerkesztővel. Talán ha a nagyobb honlapokon megjelenik a szemantika, az hatással lesz a kisebbekre is, akik nem akarnak kimaradni. Talán pár év múlva már mindenki tudni fogja, mit jelent az a szó, hogy ontológia. Ez az oka, hogy még éveket kell várni a keresési módszerek változására, mert amíg nincs miben keresni, addig hiába léteznének a keresőprogramok, csak éhen halnának.
A másik irány a szemantikus ágensek birodalmának kiépülése. Az előbb leírt miatt ennek megvalósulását tartom hamarabbinak, hiába ennek a megalkotása a bonyolultabb. Az egyik alfejezetben viszonylag részletesen foglalkoztam az ágensekkel, az ott leírtakat nem akarom még egyszer elmondani, csak annyit, hogy: az elvárások megvalósíthatóak. Lehet, hogy értelem nélküli ágensek nem tudnak egy igazán bonyolult keresést pusztán az OWL, az egyszerű következtetések alapján megoldani, és itt-ott szükség lesz holmi mesterséges intelligenciára is, de működőképesnek tűnik.
A Semantic Web-ről író cikkek mindig valami frappáns példát is említenek, hogy mire lesz képes ez az új rendszer. Remélem nem tekintik lopásnak, ha idézek ezekből a példákból és hozzájuk csapom saját véleményemet.
Miguel Salmeron írt egy nagyon jó cikket a Scientific American-be[4] és egy elég hosszú példát is írt: Pete hallgatta a music centerjét, amikor felhívta a húga, hogy az anyjának keresniük kellene egy doktort. Amikor felvette a telefont, az automatikusan lecsendesítette a többi hangeszközt a környezetében. Aztán a palmtopját (vagy egyéb személyes ágensét) megbízta, hogy keressen egy megfelelő doktort 20 km-es körzetben és egyeztesse a lehetséges időpontokat az orvos, valamit Pete és húga határidőnaplójából, amikor elvihetik hozzá, mondjuk hetente egyszer az anyjukat.
Elképzelni nem rossz, belegondolva talán egy-két apróság szemet szúrhat. Az ugye nem elképzelhetetlen, hogy a mobil mondjuk 5-10 méteres körzetben (hogy a távolságot hogyan határozzuk meg, az persze újabb probléma) minden olyan eszköznek, mely tartalmaz hangerőszabályzót (és az eszközök, mint ágensek, hirdetik minden tulajdonságukat), kiadja a parancsot, hogy halkuljanak le. Nem nekünk kellene a mindenféle távirányítók felé nyúlkálni, mint ahogy az manapság történik. Ám jönnek a kérdések: Kitől-mitől fogadjanak el parancsot az egyes eszközök? Milyen eszközök milyen eszközök alá vannak rendelve? Honnan vesszük, hogy joga van a telefonnak, hogy szabályozza a környezetében lévő hangsugárzókat? Pláne ha valaki másnál vagyunk, amikor csöng a telefonunk: akkor nála is megpróbálná a halkítást? A távolság is kérdéses. A közeljövőben alighanem nagyon elterjedt lesz a vezeték nélküli kapcsolat, melynek korlátolt a hatósugara. De mondjuk egy panelházban nincsenek nagy távolságok: mi van, ha két méterrel odébb a szomszéd Pistike adja ki a parancsot, az ő hifijének? Ne is folytassuk ezt a témát.
Ott volt még az egyeztetés, amikor Pete és húga határidőnaplóját olvastuk. Újabb kérdések. Ha el is tudja érni a hugica saját készülékét, joga biztosan nincs annak olvasására.
A többi viszont mind megvalósítható! Tehát például a bejegyzés az orvos fogadó-órarendjébe megvalósítható, hiszen az ágensünk felismeri, hogy oda egy dátumot kell beszúrni, meghatározott formátumban. Egy közeli orvos megkeresése sem ütközik akadályokba. Vagyis a Semantic Web-en sok mindent meg tudunk majd tenni egyszerűbben, mint most. De a gépeket vissza kell fogni, hogy mit tehetnek és mit nem. Nem hagyhatjuk, hogy a fejünkre nőjenek...! (Gondolom mindenki ismeri a Terminátort, vagy egyéb klasszikus sci-fi filmeket.)
Volt még egy nagyon rossz példa: A web-képes mikrosütőnk megkeresi a belerakott ételt forgalmazó gyár weboldalán a megfelelő főzési paramétereket.
Ez szerintem még nagyon messze van, pláne Magyarországon. Amíg nincs mindenkinek korlátlan, ingyenes, szélessávú internete, addig az ilyenek csak a kezdő háziasszonyok álmaiban szerepelhetnek.
Na persze nem akartam én kigúnyolni ezeket a példákat és a Semantic Web-hez sem állok hozzá pesszimistán. Szerintem is nagy dolgokra lesz képes, sokat javíthat a jelenlegi helyzeten, de csodát azért nem kell tőle várni. Voltak példák, melyek valóban elképzelhetőek. Például ha egy alkatrészt keresünk valamihez, akkor helyettünk az ágensünk végigböngészheti a katalógusokat, hogy hol a legolcsóbb vagy legjobb. Efféle, a Semantic Web-en könnyen automatizálható feladatokat fogunk tudni szerintem eleinte kérni a gépektől. Aztán egyre bonyolultabbakat.
Lehet, hogy nemsoká a Semantic Web olyan dolgokra is képes lesz, amikről még nem is álmodunk.
Valaki felvetette, hogy a Semantic Web is ugyanabba a hibába fog esni, mint a WWW. Hogy exponenciálisan növekedik az ontológiák száma, és nagyon nehéz lesz nemcsak kezelni őket, de eligazodni is közöttük, mit válasszunk, ha százféle ontológia is ugyanarról a témáról szól, csak mégsem ugyanúgy. A szerzőjük is ember, akire kihat saját társadalmán, vallásán, környezetén és még sok máson alapuló gondolkodásmódja; könnyen találhatunk majd egymásnak teljesen ellentmondó ontológiákat.
Még egy-két szót a sötétebb oldaláról is ejtenék: A fejlődést támogatja az OWL. Egyrészt maga az OWL is formálódhat még, másrészt magukat az ontológiákat is tovább lehet fejleszteni, újítani vagy javítani rajtuk. De hogy meddig, hány évig lesz használható a Semantic Web? Azt senki sem tudja megmondani. Mindig van fejlődés, mindig lesznek jobb ötletek. Viszont dicséret illeti a W3C-t, mert gondosan odafigyeltek a fejlesztésre és úgy tűnik, az OWL, ha nem is tökéletes, de be tudja váltani az ígéreteket; amikre jelenleg szüksége lehet az embereknek, azokat meg tudja majd tenni. Abba, hogy tíz év múlva mi lesz, felesleges belegondolni. Hiszen a világ napról napra változik.
A Semantic Web-hez megint egy újabb emberi generáció felnövésére lesz szükség. Olyan emberekre, akik meg tudnak bízni a számítógépben. Ha egy kérdésre egyértelmű választ ad a gép, az vagy megnyugtató, vagy éppenséggel elgondolkoztató. Honnan tudja a gép, hogy ez a legjobb megoldás? Mi lenne, ha én keresnék, vajon találnék jobbat? És még hasonló kérdések sora. Akik eddig idegenkedtek a számítógépektől, azok most sem igen fogják megkedvelni őket, látva, hogy "Hát ez mindent jobban tud, mint én?!"
A hackerek is tovább fogják folytatni tevékenységüket. Az ágensünk azt hiszi, hogy biztonságos elküldeni az adatainkat, de ha mégis elfogja azokat egy hacker, bármire felhasználhatja azokat. Mivel mindent a számítógépre bízunk, kevésbé vesszük majd észre, ha valaki a mi nevünkben garázdálkodik. Lehet, hogy valami egészen másra használja fel adatainkat egy szolgáltatásnyújtó program, mint ahogy hirdeti magáról. Biztos vagyok benne, hogy a biztonságosság kérdése nagyon sok gondot okoz majd.
Sőt, én már az OWL vírusokat is elképzeltem magamban. Ezek beférkőznek mindenhová, az előtérbe helyezik magukat, mutatják, hogy mennyire jók, és szándékosan helytelen eredményeket produkálnak, összezavarva ezzel egy kérdést. Ha nem közvetlenül tőle kértünk valamit, hanem csak a kérdés-kiértékelésben részt vevő ágensek láncolatának egy szeme, nehéz lenne kinyomozni, hogy ez vétett hibát. Ha nem is ellenőrzünk, könnyen válhatunk a vírus áldozatává...
Zárásnak ez nem volt éppen pozitív kicsengésű, csak el akartam mondani, hogy semmi sem lehet tökéletes. A W3C viszont mindent megtett, hogy egy jól használható rendszert alkosson, és úgy vélem, hogy sikerük lesz. Nem csak rajtuk áll, hogy "mi sül ki a Semantic Web-ből", de bíztatóak a kilátások.
Ha így megvalósul a Semantic Web, akkor az Internet valóban sokat lép előbbre és válik még inkább nélkülözhetetlen társsá a mindennapokban.
A diplomadolgozat mellé készült egy kisebb példaprogram is, mely egy OWL ontológiában definiált osztályokat és tulajdonságokat tud megjeleníteni, egy gráfként kirajzolva a kapcsolataikat.
Bár az OWL még egyáltalán nem túl elterjedt nyelv, már vannak olyan programok, melyekkel kezelhetjük őket, Java nyelven például egy Jena nevű csomaggal.
A program futtatásához szükség van a Java legalább 1.4-es verziójára (mivel a kezelőfelület Swing-et használ), a Jena 2.0-ra, valamint a GraphViz nevű segédprogramra.
A Jena éppen a nekünk kellő dolgokkal foglalkozik. RDF tripleteket tartalmazó modelleket lehet létrehozni vagy beolvastatni vele. Tehát be tud tölteni egy RDF vagy OWL fájlt. Minden olyan eszköz megtalálható benne, amikre maga az OWL nyelv is lehetőséget ad. Vagyis lehet létrehozni új osztályokat, példányokat, tulajdonságokat, velük különböző műveleteket is végezhetünk, mint például két osztály uniója vagy metszete. Ezen kívül még következtető gépeket is használhatunk; néhány egyszerűbb beépítve megtalálható a Jena-ban, de természetesen lehetőséget ad továbbiak hozzáadására, a már megszokott módszerekkel (Factory, regisztrálás, stb.)
A program a Jena-nak csak egy nagyon kis részét használja fel. Be kell töltetni vele egy OWL fájlt egy modellbe, abban megkeresni az összes osztályt és/vagy tulajdonságot, aztán mindegyikhez a leszármazottjait is (alosztály illetve altulajdonság).
Az eredményt grafikusan szeretnénk megjeleníttetni. Egy igazán szép gráfrajzoló program megírása meghaladja egy diplomamunka kereteit, de nincs is erre szükség, mert egy nagyon jó és ingyenes szoftver, a GraphViz, pontosabban egy alprogramja, a dot ezt megoldja helyettünk. Sok-sok éven át fejlesztették igazi szakemberek (nem csak programozók, de matematikusok is) és valóban tetszőlegesen bonyolult gráfot nagyon szépen meg tud jeleníteni, ráadásul több platform alatt is működik (Win32, Linux, stb.)
Bemenetként egy egyszerű szövegfájlt kér, melyben leírjuk a gráfot, hogy melyik csomópontból hová kell nyilat húzni, valamint a formázásra is rengeteg fajta lehetőséget biztosít. Ezt a fájlt generálja le a programom.
Az alkalmazást elindítva (java OWLdot [forrásURI] [dotPath]) egy grafikus felhasználói felület jelenik meg. Az ablakban a következőket láthatjuk:
Az első mezőbe az OWL fájl kerül. Ez egy URI hivatkozás, tehát valamely internetes címet vár. A fájl le is lehet töltve a gépre, beírhatjuk az útvonalat (URI formában), de használható a Tallóz... gomb is, amivel megkereshetjük. Alatta a kimeneti fájl nevét adhatjuk meg, ha nem adunk útvonalat, akkor az aktuális könyvtárban jön létre. Ha nem akarjuk, hogy az átmeneti owl.dot fájl megmaradjon, ikszeljük be a mellette látható jelölőnégyzetet.
A kimenet típusa lehet .jpg vagy .gif, ha egy raszteres képet szeretnénk kapni, .svg, ha vektorgrafikust és .ps, ha PostScript dokumentumot. Maga a dot ennél jóval többet támogat, de ezeket tartottam csak fontosnak beletenni. (Ha egyéb formátumra van szükségünk, akkor a legenerált owl.dot fájlt magunknak kell beolvastatnunk a dot-tal.)
A következők egyértelműek: az elsőt beikszelve megjelennek az osztályok, a másodikat kijelölve pedig a tulajdonságok, melyek a fájlban lettek definiálva, vagy van rájuk hivatkozás. A harmadik pedig ha ki van jelölve, akkor lefut a dot, és megrajzolja a gráfot. Az útvonalát be kell állítanunk, ehhez is van egy Tallóz... gomb.
Végül a Mehet-tel indíthatunk, vagy a Bezár-ral kiléphetünk. A futtatás sikeréről vagy sikertelenségéről egy üzenet-ablakban kapunk tájékoztatást.
A program indítható egy vagy két paraméterrel is. Az első a forrás-URI, azaz hogy mit szeretnénk feldolgozni, a második pedig a dot útvonala. (Ezt érdemes beírni egy batch fájlba, és akkor nem kell minden futtatáskor a tallózással megkeresnünk a helyét.)
Ha valami nem lenne egyértelmű, segíthetnek a gyorstippek: az egérrel valamilyen elemre mutatva megjelenik mellette egy rövid segítség.
A gráfban az osztályokat téglalapok, a tulajdonságokat pedig ellipszisek jelölik. Címkéjükként a nevüket kapják. A nyilak az alosztályokra/altulajdonságokra mutatnak. A tulajdonságok mellett szaggatott vonalú nyilak is lehetnek, melyek az értelmezési tartományra és értékkészletre mutatnak (d=domain, r=range). Amiről a kép készült, az egy kis példa ontológia, saját termék, a diplomamunkában megjelent példák nagy százalékát tartalmazza. (Amennyiben valakit érdekel a forrása is, megtekintheti ezen a címen.)