2.1 Alapfogalmak

Képzeljük el, hogy ki akarjuk jelenteni egy adott weblapról, hogy annak szerzője egy bizonyos John Smith. A hagyományos formája ennek az, hogy valamely természetes nyelven, pl. angolul, nyílt szöveggel megfogalmazzuk ezt:

http://www.example.org/index.html has a creator whose value is John Smith

(Magyarul: A http://www.example.org/index.html URL-en elérhető weblapnak van egy szerzője nevű tulajdonsága, amelynek értéke John Smith.)

A kijelentés egyes részeit kövér szedéssel hangsúlyoztuk, hogy illusztráljuk: ha le akarjuk írni valaminek a tulajdonságait, szükséges, hogy megnevezzünk, vagy azonosítsunk néhány dolgot:

• azt a dolgot, amelyről a kijelentés szól (esetünkben ez a weblap)
• annak a dolognak egy meghatározott tulajdonságát, amelyről a kijelentés szól (esetünkben szerzője vagy kreátora)
• azt a dolgot, amely a kijelentés szerint a tulajdonság értéke (value), vagyis esetünkben a weblapkészítő nevét.

Azt a weblapot, amelyről az állítás szól, a weblap URL-jével, azaz egységes webforrás-címével azonosítottuk. A "szerzője" (creator) kifejezést használtuk a tulajdonság azonosítására, a "John Smith" szövegadatot pedig annak a dolognak az azonosítására, mely a "szerzője" tulajdonság értéke.

Ennek a weblapnak a többi tulajdonságait is leírhatnánk hasonló angol nyelvű mondatokkal, ahol szintén az URL-lel azonosítanánk a weblapot, és szavakkal vagy kifejezésekkel a tulajdonságokat, és ezek értékeit. Például azt a dátumot, amikor a lapot készítették (creation-date), és azt a nyelvet (language), amelyen íródott, az alábbi mondatokkal lehetne leírni:

http://www.example.org/index.html has a creation-date whose value is August 16, 1999
http://www.example.org/index.html has a language whose value is English

Az RDF arra az elvre épül, hogy a leírásra kerülő dolognak több tulajdonsága, a tulajdonságoknak pedig értéke van, és hogy az erőforrások leírhatók a fentiekhez hasonló kijelentésekkel, amelyek specifikálják az erőforrások tulajdonságait és a tulajdonságok értékeit. Az RDF egy meghatározott terminológiát használ az ilyen kijelentő mondatok különböző részeinek a megnevezésére. Például a mondatnak azt a részét, amelyik azt azonosítja, akiről/amiről az állítás szól, alanynak nevezi (a példánkban ez a weblap). Azt a részt, amelyik az alany tulajdonságait, jellemzőit azonosítja (a példánkban creator, creation-date, language), állítmánynak, és azt a részt, amelyik e tulajdonságok értékeit azonosítja, tárgynak nevezi. Így tehát az alábbi angol mondatban:

http://www.example.org/index.html has a creator whose value is John Smith

az RDF kifejezések, amelyek a mondat egyes részeit leírják, az alábbiak:

• az alany (subject) a http://www.example.org/index.html URL
• az állítmány (predicate) a "creator" szó
• a tárgy (object) a "John Smith" kifejezés

De amíg az Angol két (angolul tudó) ember közötti kommunikációra szolgál, az RDF géppel feldolgozható állítások megfogalmazására készült. Ahhoz, hogy az ilyen állításokat gépi feldolgozásra alkalmassá tegyük, két dologra van szükségünk:

• olyan, géppel feldolgozható azonosítók rendszerére, amelyek alkalmasak az alany, az állítmány és a tárgy azonosítására anélkül, hogy a gép összetévesztené ezeket olyan, hasonló kinézésű azonosítókkal, amelyeket esetleg mások használnak a weben
• olyan, géppel feldolgozható nyelvre, amelyen a kijelentések egzakt módon ábrázolhatók és a gépek között kicserélhetők.

Szerencsére, a Web meglévő architektúrája mindkét szükséges eszközt tartalmazza.

Mint korábban bemutattuk, a weben már rendelkezésre áll az azonosító egy formája, az URL (az egységes webforrás-cím). Az első példában URL-t használtunk annak a weblapnak az azonosítására, amelyet John Smith készített. Az URL egy karakterlánc, mely oly módon azonosítja a webforrást, hogy ábrázolja annak elsődleges hozzáférési mechanizmusát (lényegében a hálózati címét). Ám az RDF-ben szükséges, hogy információkat adhassunk meg sok olyan dologról is, amelynek nincs hálózati címe (URL-je).

A weben rendelkezésre áll az azonosításnak egy még általánosabb formája ilyen célokra, amelyet Egységes Erőforrás-azonosítónak (Uniform Resource Identifier-nek vagy URI-nek) nevezünk. Az URL az URI egy specifikus fajtája. Minden URI rendelkezik azzal a tulajdonsággal, hogy különböző személyek vagy szervezetek egymástól függetlenül kreálhatnak ilyeneket, és ezeket bárminek az azonosítására használhatják. Az URI-k nincsenek arra korlátozva, hogy csak olyan dolgokat azonosítsanak, amelyek hálózati címmel rendelkeznek, vagy amelyek számítógépes hozzáférési mechanizmust feltételeznek. Valójában kreálhatunk egy URI-t bárminek az azonosítására, amelyre hivatkozni szeretnénk egy kijelentésben, beleértve:

• a hálózaton azonosítható dolgokat, mint pl. egy elektronikus dokumentum, egy kép, egy szolgáltatás (pl ."A mai időjárás-előrejelzés Los Angeles területére"), vagy erőforrások egy csoportja;
• az olyan dolgokat, amelyek hálózaton keresztül nem elérhetők, mint pl. emberek, cégek, vagy a könyvtárak papír alapú könyvei;
• az elvont fogalmakat, amelyek fizikailag nem is léteznek, mint például "szerző".

Ez a nagyobb általánosság indokolja, hogy az RDF URI-ket használ annak a mechanizmusnak az alapjaként, amellyel az állítások alanyát, állítmányát és tárgyát azonosítja. Szabatosabban fogalmazva: az RDF URI hivatkozásokat ([URIS]) használ. Egy URI hivatkozás (vagy URIref) egy URI egy opcionális erőforrásrész-azonosítóval (fragment identifier-rel) a végén. Például a http://www.example.org/index.html#section2 URI hivatkozás URI-je: http://www.example.org/index.html, erőforrásrész-azonosítója pedig a "#" karakterrel elválasztott Section2 azonosító. Az RDF URI hivatkozásai [UNICODE] karakterekkel vannak leírva (lásd [RDF-FOGALMAK]), lehetővé téve ezáltal, hogy több nyelven is lehessen ilyen hivatkozásokat kreálni. Az RDF úgy definiálja az erőforrás fogalmát, hogy az bármi lehet, ami azonosítható egy URI hivatkozással. Így az RDF gyakorlatilag bármilyen dolgokat meg tud nevezni, és a köztük lévő viszonyokat is le tudja írni. Az URI hivatkozások és az erőforrásrész-azonosítók további tárgyalása megtalálható az A. függelékben, valamint az [RDF-FOGALMAK] dokumentumában.

A mondatok géppel feldolgozható módon való ábrázolásához az RDF a Bővíthető Jelölőnyelvet (Extensible Markup Language – [XML]) használja. Az XML-t arra tervezték, hogy segítségével bárki kialakíthassa a saját dokumentumformátumát, és azután meg is írhassa a dokumentumait ebben a formátumban. Az RDF egy specifikus XML jelölőnyelvet definiál, amelyet RDF/XML-nek nevezünk, és amelyet RDF információk ábrázolására, illetve gépek közötti cseréjére alkalmazunk. Az 1. fejezetben, az 1. példa kapcsán már találkoztunk RDF/XML ábrázolással. Ebben a példában szerepelt egy <contact:fullName>, és egy <contact:personalTitle> teg, amelyek az Eric Miller, illetve a Dr. szövegtartalmat határolták. Ezek a tegek lehetővé teszik, hogy az ábrázoláskor és a feldolgozáskor a programok megértsék a tegek által közrefogott tartalom jelentését. Az XML adattartalom, és (bizonyos kivételekkel) a tegek is tartalmazhatnak [UNICODE] kódolású karaktereket, hogy az RDF lehetővé tegye a különböző nyelveken megfogalmazott információ közvetlen ábrázolását. A B. függelék további háttér-információkkal szolgál az XML-ről általában. A specifikus XML szintaxist, amelyet az RDF-hez használunk (RDF/XML), részletesebben a 3. fejezet tárgyalja, és ennek normatív definíciója az [RDF-SZINTAXIS] dokumentumban található.

2.2 Az RDF modell

A 2.1 szekció már bepillantást engedett az RDF mondat alapfogalmaiba: egyrészt az URI hivatkozások lényegébe, amelyekkel az RDF mondatokban hivatkozott dolgokat azonosítjuk, másrészt pedig az RDF/XML szintaxisba, amelynek segítségével, géppel feldolgozható módon lehet ábrázolni az RDF mondatait. Erre a háttér-ismeretre támaszkodva, ez a szekció leírja, hogy az RDF-ben miként használjuk az URI hivatkozásokat az erőforrásokkal kapcsolatos állítások megfogalmazására. Az előző fejezetben láttuk, hogy az RDF arra az elvre épült, hogy olyan elemi állításokat fogalmazhassunk meg az erőforrásokról, ahol minden mondat csupán egy alanyt, egy állítmányt, és egy tárgyat tartalmaz. Az alábbi angol nyelvű mondat:

http://www.example.org/index.html has a creator whose value is John Smith

egy olyan RDF mondattal ábrázolható, mely az alábbi mondatrészeket tartalmazza:

• alany: http://www.example.org/index.html
• állítmány: http://purl.org/dc/elements/1.1/creator
• tárgy: http://www.example.org/staffid/85740

Figyeljük meg, hogy itt az eredeti mondatnak nemcsak az alanyát, de az állítmányát és a tárgyát is egy-egy URI-vel ábrázoltuk ahelyett, hogy a "creator", illetve a "John Smith" szavakat használtuk volna. (Az URI ilyen használatának hatásait később tárgyaljuk ebben a szekcióban.)

Az RDF az állításokat egy gráf csomópontjaival és éleivel modellezi. Az RDF gráfmodelljét az [RDF-FOGALMAK] dokumentum ismerteti bővebben. Ebben a modellben egy kijelentést az alábbi módon ábrázolunk:

• egy csomopont jelöli az alanyt
• egy másik csomópont a tárgyat
• egy él pedig az állítmányt (az él mindig az alany csomóponttól a tárgy csomópont felé mutat).

Ennek megfelelően, a fenti RDF mondatot a 2. ábrán szereplő gráffal ábrázolhatjuk:

2. ábra: Egy elemi RDF kijelentés ábrázolása

Ehhez hasonló állítások csoportját is ugyanígy, a nekik megfelelő csomópontokkal és élekkel ábrázolhatjuk. A korábbi példákból ismert másik két angol mondatot:

http://www.example.org/index.html has a creation-date whose value is August 16, 1999
http://www.example.org/index.html has a language whose value is English

a 3. ábrán szereplő gráf-részlettel lehetne ábrázolni, amelyben megfelelő URI hivatkozásokat használunk a "creation-date" és a "language" tulajdonságok azonosítására:

3. ábra: Több kijelentés ugyanarról az erőforrásról

A 3. ábra azt is illusztrálja, hogy az RDF kijelentéseinek tárgyai egyaránt lehetnek URI hivatkozások és konstans értékek (ún. literálok). Ez utóbbiakat olyan karakterláncokkal ábrázoljuk, amelyek a tulajdonságok értékeit reprezentálják. (A http://purl.org/dc/elements/1.1/language tulajdonság esetében a literál egy nemzetközi szabvány szerinti kétbetűs kód, mely egyezményesen az Angolt jelenti. Literálokat azonban nem használhatunk az RDF állítások alanyaként vagy állítmányaként. Az RDF gráfok megrajzolásakor azokat a csomópontokat, amelyeket URI-vel azonosítunk, ellipszissel ábrázoljuk, míg az olyan csomópontokat, amelyeket literállal adunk meg, szögletes dobozok reprezentálják. (Azokat az egyszerű karakterlánc-literálokat, amelyeket ebben a példában használtunk, típus nélküli literáloknak (plain literals) nevezzük, megkülönböztetésül a tipizált literáloktól (typed literals), amelyek ismertetésére majd a 2.4 szekcióban kerül sor. A különböző literáltípusokat, amelyeket az RDF-ben használhatunk, az [RDF-FOGALMAK] dokumentuma definiálja. Mind a tipizált, mind a típus nélküli literálok megadhatók [UNICODE] kódolású karakterekkel, hogy lehetővé váljék a különböző nyelveken megfogalmazott információk közvetlen ábrázolása.

Sokszor nem az a legalkalmasabb ábrázolás, hogy gráfokat rajzolunk, amikor még vitatjuk a tartalmukat. Van egy alternatív módja is az állítások leírásának: a tripletek módszere (triples). A tripletekkel történő ábrázolás során a gráfban szereplő minden kijelentést egy egyszerű alany-állítmány-tárgy hármassal írunk le, ebben a sorrendben. Például a 3. ábrán szereplő három állítást a tripletek módszerével így jegyeznénk le:

<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> .

<http://www.example.org/index.html> <http://www.example.org/terms/creation-date> "August 16, 1999" .

<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/language> "en" .

Minden triplet egy-egy olyan él a gráfban, mely egy kezdő-, és egy végcsomóponttal rendelkezik (ez a kijelentés alanya és tárgya). Szemben a rajzolt gráffal, de hasonlóan az eredeti kijelentésekhez, a tripletes írásmód megkívánja, hogy a megfelelő csomópontokat külön-külön azonosítsuk minden kijelentésben, amelyben megjelennek. Így tehát, például, a http://www.example.org/index.html azonosító háromszor is megjelenik, ha tripletekkel ábrázoljuk a gráfot, míg a rajzolt gráf esetében csak egyszer. Ennek ellenére a tripletek pontosan ugyanazt az információt reprezentálják, mint a rajzolt gráf. És ez egy kulcskérdés. Ami ugyanis alapvető az RDF-ben, az a kijelentések gráfmodellje. Az a konkrét mód, azonban, ahogyan leírjuk, vagy lerajzoljuk a gráfmodellt, csupán másodlagos.

A komplett tripletes írásmód azt igényli, hogy az URI hivatkozásokat hegyes zárójelek között, teljes terjedelmükben kiírjuk, ám ez, mint a fenti példa is mutatja, nagyon hosszú mondatokat eredményez a lapon. Ennek elkerülése céljából (és kényelmi okokból is), ebben a tankönyvben a tripletek URI hivatkozásainak egy rövidített formáját használjuk (ugyanezt a rövidített formát alkalmazza a többi RDF dokumentum is). Itt a rövidítés egy XML minősített név (qualified name, vagy Qname) használatát jelenti, hegyes zárójelek nélkül, mely az URI hivatkozás egy rövidített változatának felel meg. (A minősített neveket a B. függelék tárgyalja részletesebben). A minősített név egy előtét-nevet (ún. prefixet) tartalmaz, mely egy névtér URI-hez van rendelve. A prefixet egy kettőspont, majd pedig egy helyi név követi. A teljes URI hivatkozást a minősített névből úgy állítjuk vissza, hogy egy lokális nevet toldunk ahhoz a névtér URI-hez, mely a prefixhez van rendelve. Így tehát, ha pl. a foo prefix a http://example.org/somewhere/ névtér-URI-hez van rendelve, akkor a foo:bar minősített névre rövidül le a http://example.org/somewhere/bar URI hivatkozás. Tankönyvünk példái több "jól ismert" minősítettnév-prefixet használnak anélkül, hogy ezeket minden egyes alkalommal explicit módon definiálnák. Az ilyen prefixeket és az előre hozzájuk rendelt névtér-URI-ket az alábbi lista tartalmazza:

prefix = rdf:, névtér-URI = http://www.w3.org/1999/02/22-rdf-syntax-ns#
prefix = rdfs:, névtér-URI = http://www.w3.org/2000/01/rdf-schema#
prefix = dc:, névtér-URI = http://purl.org/dc/elements/1.1/
prefix = owl:, névtér-URI = http://www.w3.org/2002/07/owl#
prefix = ex:, névtér-URI = http://www.example.org/ (vagy .com )
prefix = xsd:, névtér-URI = http://www.w3.org/2001/XMLSchema#

A listában szereplő ex: prefixnek, mely az "example" kifejezés rövidítése, és amelyet a példáinkban általánosan használunk, több variánsa is meg fog jelenni a tankönyvünkben. Az adott példa jellege szerint ezek általában ilyenek, mint:

prefix = exterms:, névtér-URI = http://www.example.org/terms/ (olyan fogalmak névtér-azonosítójaként, amelyeket egy példabeli szervezet használ),

prefix = exstaff:, névtér-URI = http://www.example.org/staffid/ (olyan kifejezések névtér-azonosítójaként, amelyek egy szervezet személyi azonosítói),

prefix = ex2:, névtér-URI = http://www.domain2.example.org/ (egy második példabeli szervezet fogalmainak névtér-azonosítójaként), és így tovább.

Ezzel a rövidítési mechanizmussal az előző három, hosszú tripletet így írhatjuk:

ex:index.html  dc:creator             exstaff:85740 .

ex:index.html  exterms:creation-date  "August 16, 1999" .

ex:index.html  dc:language            "en" .

ex:index.html  dc:creator  exstaff:85740 .

ex:index.html  dc:creator  exstaff:27354 .

ex:index.html  dc:creator  exstaff:00816 .

Ezek a példák talán már kezdik érzékeltetni annak az RDF elvnek néhány előnyét, hogy alapvetően URI hivatkozásokat (röviden URIref-eket) használunk a dolgok azonosítására. Például az első állításban, ahelyett, hogy a weblap szerzőjének a nevét a "John Smith" karakterlánccal azonosítanánk, hozzárendeltünk egy URI hivatkozást, mely ebben az esetben John Smith alkalmazott-azonosítójára épül, és így néz ki: http://www.example.org/staffid/85740. Az URIref használata ebben az esetben például azzal az előnnyel jár, hogy a kijelentés alanyának azonosítása pontosabb lehet. Vagyis, a szerző itt nem csupán a "John Smith" karakterlánc, vagy bárki, a sok ezer John Smith közül, hanem egy bizonyos John Smith, aki ehhez az URIref-hez van asszociálva (bárki legyen is a szerző, az URIref definiálja a megfelelő asszociációt). Még tovább menve: minthogy létezik egy URIref, amely John Smith-re hivatkozik, ő most már egy teljes értékű erőforrás, és így további információkat is megadhatunk róla oly módon, hogy újabb RDF kijelentéseket írunk, amelyekben John Smith URIref-je lesz az alany. A 4. ábra további adatokat ábrázol John Smith-ről, az index.html weblap szerzőjéről: konkrétan a nevét (name) és az életkorát (age).

4. ábra: További információk John Smith-ről

Ez a példa azt is illusztrálja, hogy az RDF kijelentésekben állítmányként is használhatunk URI hivatkozásokat. Vagyis ahelyett, hogy ilyen szavakat, vagy karakterláncokat használnánk itt a tulajdonságok azonosítására, mint a "creator" és a "name", az RDF-ben inkább URI hivatkozásokat használunk ilyen célra. Ennek a lehetősége több okból is fontos. Először is: ez egyértelműen megkülönbözteti az egyik környezetben definiált tulajdonságot egy másik környezetben definiálttól, amikor azonos karakterlánccal ábrázolnak különféleképpen értelmezett tulajdonságokat. Például a 4. ábrán bemutatott példában az example.org a "name" kifejezést használja valakinek a teljes nevére gondolva, amelynek az értékét egy karakterlánc-literállal írják ki (pl. "John Smith"), de valaki más a "name" alatt esetleg egészen mást ért (pl. egy programban szereplő változó nevét). Ha tehát egy program, amelyik több forrásból igyekszik adatokat egyesíteni, s így több webforrásból is beolvassa a "name" karakterláncot, mint egy tulajdonság azonosítóját, nem biztos, hogy képes lesz megkülönböztetni a két "name" jelentését. Ha azonban az egyik szervezet, mondjuk a http://www.example.org/terms/name URI -t használja, egy másik pedig a http://www.domain2.example.org/genealogy/terms/name URI-t, akkor világos, hogy itt két különböző "name" tulajdonságról van szó, még akkor is, ha az adott program automatikusan nem tudná eldönteni a különbözőség kérdését. Emellett a tulajdonságok URI hivatkozásokkal történő azonosítása lehetővé teszi, hogy magukat a tulajdonságokat is erőforrásoknak tekintsük, s így további információkat regisztrálhassunk róluk (pl. az angol nyelvű leírását annak, hogy az example.org mit ért az alatt, hogy "name"). Ezt, a John Smith esetével analóg módon, olyan további RDF kijelentésekkel adhatjuk meg, amelyeknek a közös alanya a "name" tulajdonság URIref-je lesz.

Mindemellett, az URI hivatkozásoknak alanyként, állítmányként és tárgyként történő használata az RDF kijelentésekben ösztönzi és támogatja a közös szókészletek fejlesztését és közös használatát a weben. A fejlesztők ugyanis így felfedezhetik, és elkezdhetik alkalmazni azokat a szókészleteket, amelyeket mások már használnak a saját adatábrázolásaikhoz, és ez a közös használat a fogalmak közös értelmezését is jelenti. Ha például az alábbi triplet:

ex:index.html   dc:creator   exstaff:85740 .

dc:creator nevű állítmányát teljes URI hivatkozássá terjesztjük ki, egy egyértelmű URI hivatkozást kapunk a "creator" nevű attribútumra a Dublin Core meta-adatok halmazában. (Ez olyan attribútumok széles körben használt gyűjteménye, amelyekkel sokféle információforrás alapvető tulajdonságai leírhatók – ahogy azt a 6.1 szekcióban bővebben tárgyaljuk). A fenti triplet írója lényegében azt jelenti ki, hogy a viszony a (http://www.example.org/index.html URI-vel azonosított) weblap, és annak meghatározott szerzője között (akit a http://www.example.org/staffid/85740 URI azonosít), nem más, mint az a fogalom, amelyet a http://purl.org/dc/elements/1.1/creator URI azonosít. Ha mármost egy másik fejlesztő, aki ismeri a Dublin Core szókészletet, vagy aki rájön (pl. a weben történő kereséssel), hogy mi a dc:creator pontos jelentése, az megérti azt is, hogy mit jelent a fenti tripletben kijelentett viszony. És támaszkodva erre a megértésre, ez a fejlesztő tud olyan programot írni, amely e fogalom jelentésének megfelelően képes működni, amikor feldolgozza a dc:creator állítmányt tartalmazó tripletet.

Természetesen, ez a kedvező hatás olyan arányban nő, amilyen arányban terjed az URI hivatkozások használata a dolgok azonosítására a literálok helyett; pl. az olyan URI hivatkozások használata, mint az exstaff:85740 és a dc:creator az olyan karakterlánc-literálok helyett, mint "John Smith" és "creator". Ám még egy ilyen kedvező trend sem képes önmagában létrehozni a kívánt hatást, mert még így is előfordulhat, hogy két különböző URI-vel hivatkozunk ugyanarra a fogalomra. Ezért az a jó megoldás, hogy amikor csak lehet, próbáljuk meg létező szókészletekből importálni a fogalmainkat, pl. olyanokból, mint a Dublin Core, ahelyett, hogy újakat találnánk ki, amelyekkel esetleg átfednénk a már létező, stabil és elterjedt szókészleteket. Ugyanis folyamatosan fejlesztenek szókészleteket a weben specifikus alkalmazások céljaira, ahogyan azt a 6. fejezetben látni fogjuk. Azonban, ha keletkeznek is olykor szinonimák, mégis az a tény, hogy ezek a különböző URI hivatkozások a közösen használt "webtérben" kerülnek felhasználásra, kedvező lehetőséget teremt mind az eltérő hivatkozások közötti lényegi azonosság felismerésére, mind pedig a közös hivatkozások használatának elterjedésére.

Indokolt továbbá különbséget tenni a között a jelentés között, amelyet maga az RDF asszociál azokhoz a kifejezésekhez, amelyeket az RDF kijelentésekben használunk (mint pl. a dc:creator az előző példában), valamint azok között az egyéb, kívülről definiált jelentések között, amelyeket az emberek (vagy emberek által írt programok) asszociálhatnak ezekhez a kifejezésekhez. Mint nyelv, az RDF csupán három dolgot definiál közvetlenül: egyrészt az alany-állítmány-tárgy tripletek gráf-szintaxisát, másrészt az rdf: szókészletben szereplő URI hivatkozásokhoz kapcsolódó bizonyos jelentéseket, és harmadrészt, néhány olyan fogalmat, amelyekkel később foglalkozunk; ezeknek a dolgoknak a normatív definíciója az [RDF-SZEMANTIKA] és az [RDF-FOGALMAK] dokumentumban található. Az RDF azonban nem definiálja az RDF állításokban használható olyan kifejezések jelentését, amelyeket más szókészletek tartalmaznak (mint pl. dc:creator). Várható, hogy további specifikus szókészleteket fognak majd összeállítani, s ezek kifejezéseihez specifikus jelentéseket fognak társítani, de ez már az RDF-en kívül történik. Azok az RDF kijelentések, amelyek az ilyen szókészletekből használnak fel URI hivatkozásokat, átvihetik az ezekhez társuló specifikus jelentéseket azokhoz az emberekhez, akik ismerik az adott szókészleteket, és átvihetik az olyan alkalmazásokhoz is, amelyek képesek ezeket a szókészleteket feldolgozni; nem mondanak azonban semmit az olyan RDF alkalmazások számára, amelyeket nem kifejezetten az ilyen szókészletek feldolgozására terveztek.

ex:index.html  dc:creator  exstaff:85740 .

fy:joefy.iunm  ed:dsfbups  fytubgg:85740 .

Az RDF állítások nagyon hasonlóak több más, ismert adatformátumhoz, amelyet információk rögzítésére használnak, mint például:

• az egyszerű bejegyzések a katalógus-rekordokban, amelyek erőforrásokat írnak le egy adatfeldolgozó rendszer számára,
• az egyszerű sorok egy relációs adatbázis táblázatában,
• az egyszerű kijelentések a formális logikában,

Az ilyen formátumú információk (egy minimális formátum-konverzióval) RDF kijelentésekként is interpretálhatók, lehetővé téve ily módon, hogy az RDF segítségével sokféle forrásból adatokat integrálhassunk.

2.3 Strukturált tulajdonságértékek és üres csomópontok

Nagyon könnyű lenne az élet, ha a dolgokról rögzítendő információk már eleve a fentebb illusztrált, egyszerű RDF kijelentések formájában állnának rendelkezésünkre. Sajnos azonban, a való világ legtöbb adata ennél jóval összetettebb szerkezetű, legalábbis ami a külső megjelenését illeti. Például a kedvenc példánkban azt az információt, mely a John Smith által kreált weblap keletkezési dátumát rögzíti az exterms:creation-date tulajdonság értékeként, egyetlen típus nélküli literál formájában ábrázoltuk. De mi lenne, ha ezt a tulajdonságot három, külön is kezelhető információként, mondjuk év, hónap és nap formában kellene rögzíteni? Vagy, ha John Smith személyi adatait, mondjuk a lakcímét kellene regisztrálni? Természetesen, kiírhatnánk a teljes címet akár egyetlen típus nélküli literál formájában is, mint ahogy ebben a tripletben tesszük:

exstaff:85740   exterms:address   "1501 Grant Avenue, Bedford, Massachusetts 01730" .

De hogyan járnánk el akkor, ha a címet egy olyan struktúra formájában kellene rögzíteni, mely külön is kezelhető adatként ábrázolja az utca, a város, az állam és az irányítószám (street, city, state, és postal code) értékeit? Hogyan lehetne ezt leírni RDF-ben?

Az efféle strukturált információt úgy ábrázoljuk az RDF-ben, hogy az olyan összetett adatot, mint pl. John Smith lakcíme, egy önálló erőforrásnak tekintjük, és azután elemi kijelentéseket fogalmazunk meg erről az új erőforrásról. Mivel ehhez az RDF gráfban előbb komponenseire kell bontanunk John Smith címét, ezért a címfogalom számára készítünk egy új csomópontot, amelyet egy új URI hivatkozással azonosítunk. (Ez lehet pl. http://www.example.org/addressid/85740, amelyet exaddressid:85740 formában rövidítünk). Ezután már további élek és csomópontok segítségével ábrázolhatjuk az elemi információk rögzítéséhez szükséges RDF kijelentéseket, amelyek mindegyikében az új csomópont lesz az alany, amíg végül ki nem alakul az 5. ábrán látható gráf:

5. ábra: John Smith címének felbontása

Ugyanez triplet formában írva:

exstaff:85740       exterms:address        exaddressid:85740 .
exaddressid:85740   exterms:street         "1501 Grant Avenue" .
exaddressid:85740   exterms:city           "Bedford" .
exaddressid:85740   exterms:state          "Massachusetts" .
exaddressid:85740   exterms:postalCode     "01730" .

Az RDF-ben a strukturált információk ábrázolása számos ilyen "közbülső" URIref előállítását igényelheti, mint az exaddressid:85740, ha sok olyan összetett fogalmat kell ábrázolnunk, mint John Smith lakcíme. Mivel azonban az ilyen segédfogalmakra általában nem kell az adott gráfon kívülről hivatkozni, ezért általában nincs is szükség globális azonosítókra az elérésükhöz. Amikor tehát gráffal ábrázoltuk az 5. ábrán szereplő RDF kijelentéseket, a John Smith címéhez rendelt URIref előállítására és feltüntetésére nem is lett volna szükség, hiszen a gráfot úgy is megrajzolhattuk volna, ahogy az a 6. ábrán látható:

6. ábra: Üres csomópont használata

A 6. ábrán szereplő gráf, mely egy teljesen szabályos RDF gráf, egy URIref nélküli csomóponttal ábrázolja a John Smith címének megfelelő fogalmat. Ez az üres csomópont betölti a célját a rajzon anélkül, hogy szükség volna egy URIref-re, hiszen ez a csomópont önmagában is jól mutatja a kapcsolatokat a gráf különböző részei között. (Nem véletlen, hogy az üres csomópontokat az [RDF-MS]-ben anonimous resources, azaz névtelen erőforrások néven emlegették). Amikor azonban tripletek formájában kívánjuk leírni a gráfot, mégiscsak szükségünk lesz valamilyen explicit azonosítóra, hogy hivatkozni tudjunk erre az üres csomópontra. Hogy belássuk ezt, próbáljuk meg RDF mondatokkal leírni a 6. ábrán látható gráfot! Valami effélét kapnánk:

exstaff:85740   exterms:address         ??? .
???             exterms:street          "1501 Grant Avenue" .
???             exterms:city            "Bedford" .
???             exterms:state           "Massachusetts" .
???             exterms:postalCode      "01730" .

ahol a "???" az üres csomópontot próbálja jelezni. Mivel azonban egy összetettebb gráf több üres csomópontot is kénytelen előállítani, ezért szükség van egy olyan módszerre, amellyel megkülönböztethetjük ezeket, amikor RDF kijelentésekben hivatkozunk rájuk. Ezért a tripletekben ún. ürescsomópont-azonosítókat használunk, amelyeket _:name formában írunk. A fenti példában, mondjuk, a _:johnaddress azonosítóval hivatkozhatnánk az üres csomópontra, mely esetben az alábbi tripleteket kapnánk:

exstaff:85740   exterms:address         _:johnaddress .
_:johnaddress   exterms:street          "1501 Grant Avenue" .
_:johnaddress   exterms:city            "Bedford" .
_:johnaddress   exterms:state           "Massachusetts" .
_:johnaddress   exterms:postalCode      "01730" .

Egy gráf tripletes ábrázolása során minden üres csomópont saját azonosítót kap. De, eltérően az URI azonosítóktól és a literáloktól, az ürescsomópont-azonosítókat nem tekintjük a gráf tényleges részének (ez jól látható a 6. ábrán megrajzolt gráfon, ahol nincs is feltüntetve az azonosító). Az ilyen azonosítók csupán arra szolgálnak, hogy amikor a gráfot tripletek formájában írjuk le, meg tudjuk különböztetni, hogy melyik üres csomópontra hivatkozik egy adott kijelentés. Az ilyen azonosítóknak csak azokban a tripletekben van megkülönböztető érvényük, amelyek egyetlen gráfhoz tartoznak. Két különböző gráfban az üres csomópontok azonosítására nyugodtan használhatjuk ugyanazokat az azonosítókat, hiszen nem kell attól tartanunk, hogy ugyanarra a csomópontra hivatkoznak, mivel ezek lokális hatókörű azonosítók. Persze, ha várható, hogy egy csomópontra az adott gráfon kívülről is történik majd hivatkozás, akkor egy URI-t kell hozzárendelnünk. És végül, mivel az ilyen azonosítók mindig (üres) csomópontokat, és nem éleket azonosítanak, ezért csak a tripletek alanya vagy tárgya helyén alkalmazhatjuk őket; sohasem használhatók tehát az állítmány azonosítására.

Ennek a szekciónak az elején láttuk, hogy az olyan strukturált adatokat, mint pl. John Smith címe, úgy ábrázolhatjuk, hogy egy külön erőforrásnak tekintjük, és erre (mint alanyra) vonatkozólag különböző állításokat teszünk. Ez a példa az RDF egyik fontos aspektusát mutatja meg: azt, hogy az RDF kijelentései, közvetlenül, csak bináris relációkat képesek ábrázolni. Például azt a viszonyt, amely John Smith és a teljes címét ábrázoló egyetlen literál között fennáll. Amikor azonban John Smith, és a címét alkotó elemi komponensek közötti viszonyt kell ábrázolnunk, akkor már n-áris (n-ágú) relációról beszélünk, ahol történetesen n = 5, hiszen ezt az alanyt 4 tárgyhoz (utca, város, állam, irányítószám) kell kapcsolnunk. Ahhoz tehát, hogy az ilyen struktúrákat közvetlenül RDF-ben ábrázolhassuk, ezt az n-ágú viszonyt fel kell bontani több bináris viszonyra. Az üres csomópontok használata az egyik lehetőség erre. Minden n-áris relációban az egyik résztvevő elemet kinevezzük a reláció alanyának (esetünkben ez John Smith), és egy üres csomópontot kreálunk a reláció többi elemének a csatlakoztatása számára (esetünkben ez John Smith címe lesz). A reláció többi résztvevőjét (esetünkben az utca, város, állam, irányítószám komponenseket) az új erőforrás, vagyis az üres csomópont (mint alany) különböző tulajdonságaiként ábrázoljuk.

Az üres csomópontok alkalmazása azt is lehetővé teszi, hogy pontosabban fogalmazhassuk meg állításainkat az olyan erőforrásokról, amelyeknek esetleg nincs URI-jük, de amelyek leírhatók más, olyan erőforrásokhoz való viszonyuk alapján, amelyeknek van URI-jük. Például, amikor kijelentéseket teszünk egy személyről (ezúttal mondjuk Jane Smith-ről), akkor kézenfekvőnek tűnhet egy olyan URI használata az azonosításához, mint pl. az e-mail címe (mondjuk: mailto:jane@example.org ). Ez a megoldás azonban problémákat okozhat. Ilyenkor ugyanis információt kell regisztrálnunk mind az elektronikus postaládájáról (pl. a szerver címéről, amelyen ez tárolva van), mind pedig magáról, Jane Smith-ről (pl. a jelenlegi címéről, ahol fizikailag elérhető). Ha tehát egy olyan URI-t használunk Jane azonosítására, mely az e-mail címén alapszik, akkor nehéz lesz megállapítani, hogy maga Jane-e az alany, vagy csak az e-postaládája, amelyről a kijelentéseinket megfogalmazzuk. Ugyanez a probléma áll elő, amikor egy cég weblapjának URL-jét, mondjuk, a http://www.example.com/ URL-t magának a cégnek az URI-jeként használjuk. Itt is ugyanaz a helyzet áll elő, mint Jane esetében: információkat kellene rögzítenünk a weblapról, magáról, (hogy pl. ki készítette, és mikor), és külön a cégről is. Ha mármost a http://www.example.com/ URI-t használnánk mindkettőnek az azonosítására, nehéz lenne kívülről megállapítani, hogy ezek közül melyik a tényleges alany.

Az alapvető probléma az, hogy ha Jane e-mail címét használnánk Jane helyett, ez nem lenne pontos: Jane, és az e-mail címe nem ugyanaz a dolog, s ezért ezeket különbözőképpen kellene azonosítani. Ha Jane-nek nincs saját URI-je, egy üres csomópont sokkal alkalmasabb ennek a helyzetnek a modellezésére. Jane-t tehát egy üres csomóponttal ábrázoljuk, és ehhez az alanyhoz, állítmányként, megadjuk az exterms:mailbox azonosítót, amelynek tárgyára (a mailbox tulajdonság értékére) a mailto:jane@example.org azonosítóval hivatkozunk. Az üres csomópontot egyébként leírhatnánk az rdf:type tulajdonsággal is, amelynek az értéke, mondjuk, az exterms:Person (Személy) minősített név lehetne. (A típusokat a következő szekcióban tárgyaljuk bővebben). Így tehát, van egy olyan üres csomópontunk, amelyről most már minden jellemző információt megadhatunk. A nevét pl. az exterms:name tulajdonság értékeként, mely "Jane Smith", az alábbi tripletek segítségével adhatjuk meg:

_:jane   exterms:mailbox   <mailto:jane@example.org> .
_:jane   rdf:type          exterms:Person .
_:jane   exterms:name      "Jane Smith" .
_:jane   exterms:empID     "23748"  .
_:jane   exterms:age       "26" .

(Figyeljük meg, hogy az első tripletben a mailto:jane@example.org hegyes zárójelek között van megadva. Ez azért van így, mert a mailto:jane@example.org egy teljes URI séma, és nem egy rövidítés, azaz nem minősített név, tehát hegyes zárójelek közé kell tennünk a tripletek leírásánál.)

Ezek a tripletek lényegében ezt mondják: "adott egy Személy típusú erőforrás, amelynek az e-postaládája: mailto:jane@example.org, a neve: Jane Smith stb." Az üres csomópontot tehát így olvassuk: "adott egy erőforrás". Azok a kijelentések tehát, amelyek az üres csomóponttal megadott erőforrásra mint alanyra hivatkoznak, megadhatják az összes fontos információt erről az erőforrásról.

A gyakorlatban az üres csomópontok használata (ezekben az esetekben URI hivatkozások helyett) nem érinti lényegesen az ilyen típusú információk kezelését. Ha pl. tudjuk, hogy egy e-mail cím egyedileg azonosít egy személyt, mondjuk az example.org cégnél (különösen, ha a cég garantálja, hogy a címeket nem használják fel kétszer), ez mégiscsak alkalmas lehet arra, hogy többféle forrásból információkat kapcsoljunk ehhez a személyhez akkor is, ha az e-mail cím URI-je nem a személy URI-je. Ilyenkor, pl., ha valamilyen RDF-ben regisztrált adatot találunk a weben, amelyik leír egy könyvet, ahol a szerző azonosítójaként csupán az e-mail címe (itt: mailto:jane@example.org) van megadva, akkor célszerű, ha kombináljuk ezt az új információt a fenti tripletekben megadottakkal, hiszen így nemcsak azt tudhatjuk meg, hogy a szerző neve Jane Smith, hanem több más személyi adatához is hozzájuthatunk. A mondanivaló itt az, hogy ha valami ilyesmit közlünk, hogy "a könyv szerzője: mailto:jane@example.org", akkor ez lényegében annak a kijelentésnek a rövidített formája, hogy "a könyv szerzője olyan valaki, akinek az e-mail címe mailto:jane@example.org". Az üres csomópont használata ennek a "valakinek" az ábrázolására csupán egy precízebb módja a való világ egy adott szituációjának a modellezésére. (Egyébként, egyes RDF alapú sémanyelvek lehetővé teszik annak a specifikálását, hogy bizonyos tulajdonságok egyedi azonosítói azoknak az erőforrásoknak, amelyeket leírnak. Ezt az 5.5 szekció tárgyalja részletesebben.)

ex2terms:book78354   rdf:type          ex2terms:Book .
ex2terms:book78354   ex2terms:author   "Jane Smith" .

ex2terms:book78354   rdf:type          ex2terms:Book .
ex2terms:book78354   ex2terms:author   _:author78354 .
_:author78354        rdf:type          ex2terms:Person .
_:author78354        ex2terms:name     "Jane Smith" .

2.4 Tipizált literálok

Az előző szekció bemutatta, hogyan kezelhetjük azokat a szituációkat, amikor a típus nélküli literálokkal ábrázolt tulajdonságértékeket fel kell bontanunk strukturált értékekre, hogy ezeket egyenként ábrázolhassuk és visszakereshessük. Ezt a módszert alkalmazva, pl. ahelyett, hogy egy weblap keletkezési dátumát egy exterms:creation-date tulajdonság értékeként, egyetlen típus nélküli literállal ábrázolnánk, inkább egy olyan struktúrával ábrázoljuk, mely három önálló, típus nélküli literálból áll, amelyek értékei rendre: az év, a hónap és a nap. Eddig azonban minden konstans érték, amelyet RDF kijelentések tárgyaként használtunk, kizárólag ilyen típus nélküli (angolul: plain) literál volt, akkor is, amikor lényegében számértékeket kívántunk megadni (mint pl egy évszám, vagy egy életkor), vagy pedig egy másfajta, még specializáltabb értéket.

A 4. ábra például egy olyan RDF gráfot ábrázolt, mely John Smith-ről rögzített információkat. Az a gráf pl. John Smith exterms:age (életkora) tulajdonságának értékét a "27" típus nélküli literállal ábrázolta, ahogyan az a 7. ábrán is megjelenik:

7. ábra: John Smith életkorának ábrázolása

Itt a hipotetikus example.org cég nyilván számként kívánta értelmezni a "27" kifejezést, és nem egy olyan karakterláncként, mely a "2" és a "7" karakterekből áll (hiszen ez egy "életkor" számértéke akar lenni). Azonban a 7. ábra gráfjában nincs olyan információ, mely explicit módon jelezné, hogy a "27" kifejezést számként kell értelmezni. Ugyanígy, ez a cég nyilván azt szeretné, ha ezt a "27"-et decimális számként értelmeznék, amelynek értéke 27, és nem pl. oktális számként, amelynek értéke 23. De, szögezzük le ismét, nincs olyan információ a 7. ábra gráfjában, amely explicit módon jelezné ezt. Persze, egyes alkalmazásokat lehetne úgy tervezni, hogy az exterms:age tulajdonság értékét automatikusan decimális számnak értelmezzék. Ám ez azt jelentené, hogy az adott RDF kód helyes értelmezése olyan információtól függene, ami nincs megadva az RDF gráfban, vagyis olyan információtól, ami nem feltétlenül áll rendelkezésre a többi alkalmazás számára, amelyik szintén szeretné feldolgozni ezt az RDF kódot.

A programozási nyelvek és az adatbázis-rendszerek területén elterjedt gyakorlat az, hogy adattípust kapcsolnak a literálokhoz (pl. integer, decimal stb.), amelyből egyértelműen kiderül, hogy miként kell értelmezni az adott literált. Az olyan alkalmazás, amelyik ismeri ezt az adattípust, az meg tudja állapítani, hogy a "10" literál, a tíz vagy a kettő számértéket, vagy egy olyan karakterláncot ábrázol-e, amelyik az "1" és a "0" karakterekből áll, attól függően, hogy az adattípus integer, binary, vagy pedig string. (További specializált adattípusokat is használhatnánk, hogy egyértelműen azonosíthassuk az olyan mértékegységeket, mint pl. a "Font" vagy a "Kilogramm", ahogy az már, a 2.3 szekció végén is felmerült, habár ebben a könyvben nem dolgoztuk ki ezeket a típusokat). Az RDF-ben tipizált (vagyis típussal rendelkező) literálokat használunk az ilyen információk megadására.

Az RDF tipizált literáljait egy karakterláncból, és egy URI hivatkozásból alakítjuk ki, ahol az előbbi a literál lexikai megjelenését reprezentálja, az utóbbi pedig a típusát azonosítja. Az RDF gráfban ezt egy literál-csomóponttal ábrázoljuk, amelyben megjelenik ez a páros. A tipizált literál értéke az az érték, amit a megadott adattípus társít a megadott karakterlánchoz. Például, egy tipizált literál használatával John Smith életkorát (ami 27 év) triplet formájában így adhatnánk meg:

<http://www.example.org/staffid/85740>  <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> .

vagy, ha alkalmazzuk a minősített névvel történő rövidítést, akkor így:

exstaff:85740  exterms:age  "27"^^xsd:integer .

ha pedig gráffal kívánjuk megadni, akkor 8. ábrán látható módon rajzoljuk le:

8. ábra: John Smith életkora tipizált literál formájában

Hasonlóképpen, a 3. ábrán szereplő gráfban, amelyik információkat közöl egy weblapról, az exterms:creation-date (a készítés dátuma) tulajdonság értékét ezzel a típus nélküli literállal adtuk meg: "August 16, 1999". Egy tipizált literál használatával azonban a weblap készítésének dátumát egy "dátum" (date) típusú literállal explicit formában is megadhatnánk, ahogy az alábbi triplet mutatja:

ex:index.html  exterms:creation-date  "1999-08-16"^^xsd:date .

Gráf segítségével pedig úgy adhatnánk meg, ahogyan a 9. ábra mutatja:

9. ábra: Tipizált literál használata egy weblap készítési dátumának leírására

Szemben a tipikus programozási nyelvekkel és adatbázis-rendszerekkel, az RDF-nek nincsenek saját, beépített adattípusai, mint pl. egész számok, lebegőpontos számok, karakterláncok vagy dátumok. Ehelyett az RDF tipizált literálja inkább egy egyszerű módot biztosít annak explicit megjelölésére, hogy milyen adattípust kell használni az adott literál értelmezéséhez. Azokat az adattípusokat, amelyeket a tipizált literálokhoz használhatunk, az RDF-en kívül definiálták, és ún. adattípus URI-kkel azonosították. (Ez alól van egy kivétel: az RDF definiál egyetlen beépített adattípust, amelyet az rdf:XMLLiteral névvel azonosít, és amellyel XML tartalmat lehet ábrázolni literális érték formájában. Ezt az adattípust az [RDF-FOGALMAK] dokumentum definiálja, használatát pedig könyvünk 4.5 szekciója ismerteti.) A 8.ábrán és a 9.ábrán bemutatott példáknál már használtuk az integer (egész szám) és a date (dátum) adattípusokat az XML Séma adattípusai közül, amelyeket az XML Schema Part 2: Datatypes dokumentum ismertet (a referenciája: [XML-SCHEMA2]). Az adattípusok ilyen megvalósításának egyik előnye az a flexibilitás, hogy az RDF így közvetlenül ábrázolhat különböző forrásokból származó információkat anélkül, hogy típuskonverziót kellene végeznie e források adattípusai, és saját, belső adattípusai között. (Bizonyos konverzió azért mégis szükséges, amikor olyan rendszerek között kell adatokat átvinni, amelyek eltérő adattípus-halmazokkal dolgoznak, de az RDF ilyenkor sem végez extra konverziót a szabványos RDF típusokon, sem oda, sem vissza.)

Mivel egy adott tipizált literál jelentését annak adattípusa definiálja, és mivel az rdf:XMLLiteral kivételével az RDF nem definiál saját adattípusokat, ezért az RDF gráfban megjelenő tipizált literálok tényleges interpretációját (vagyis annak az értéknek a meghatározását, amelyet ezek a literálok ábrázolnak), egy szoftvernek kell elvégeznie, amelyet úgy írtak meg, hogy ne csupán az RDF kódot, hanem a literálok adattípusait is korrekt módon fel tudja dolgozni. Valójában tehát ennek a szoftvernek egy kiterjesztett nyelvet kell feldolgoznia, mely az RDF-en kívül az adattípusokat is tartalmazza, mintha ezek az RDF beépített szókészletéhez tartoznának. Ez felveti azt a kérdést, hogy mely adattípusok általánosan hozzáférhetők az RDF szoftverben. Általában az XML Séma adattípusok azok, amelyeket ide sorol az [RDF-SZEMANTIKA]. Ezeknek amolyan "elsők az egyenlők között" státusuk van az RDF-ben. Mint már említettük, a 8. és 9. ábra példái már használtak néhányat ezekből az XML Séma adattípusokból, de a könyvünk további részében bemutatandó példáink legtöbbjében is használunk ilyen tipizált literálokat. (Az XML Séma adattípusokhoz már eleve hozzá vannak rendelve a megfelelő URI hivatkozások, ezekre tehát bármikor hivatkozhatunk, lásd az [XML-SCHEMA2]-nél) Ezeket az adattípusokat egyébként ugyanúgy kezeljük, mint bármilyen más adattípust; az elsőbbségüket csupán az indokolja, hogy várhatólag szélesebb körben elterjednek, és így "hordozhatóak" lesznek a különböző szoftverek között. Ennek eredményeként pedig egyre több olyan szoftvert írnak majd, amelyek fel tudják dolgozni ezeket az adattípusokat. Persze, írhatunk olyan RDF szoftvert is, amely más adattípusokat is fel tud dolgozni, feltéve, hogy azok beleillenek az RDF keretbe (ennek kritériumait fentebb már ismertettük).

Előfordulhat, hogy egy RDF szoftvertől azt kérik, hogy dolgozzon fel olyan RDF adattípusokat, amelyek kezelésére nem készítették fel. Ilyenkor lesz néhány olyan feladat, amit a szoftver nem tud elvégezni. Például: minthogy az rdf:XMLLiteral kivételével az RDF nem definiálja azokat az URI hivatkozásokat, amelyek az adattípusokat azonosítják, így egy RDF szoftver, hacsak nem úgy írták meg, hogy meghatározott URI hivatkozásokat felismerjen, azt sem tudja megállapítani, hogy egy tipizált literálban szereplő URI hivatkozás létező adattípusra mutat-e egyáltalán. Továbbá: még akkor is, ha egy URI hivatkozás létező adattípust azonosít, az RDF maga nem definiálja az adott literál és az adott adattípus összepárosításának az érvényességét. Ezt az érvényességet csak a szoftverünk tudja megállapítani, ha úgy programoztuk, hogy fel tudja dolgozni ezt a bizonyos adattípust.

Tekintsük például azt a tipizált literált, mely az alábbi tripletben szerepel:

exstaff:85740  exterms:age  "pumpkin"^^xsd:integer .

vagy pillantsunk az alábbi gráfra a 10. ábrán:

10. példa: Egy érvénytelen tipizált literál John Smith korának leírására

Láthatjuk, hogy noha mindkét esetben (formailag) érvényes RDF ábrázolással van dolgunk, az mégis nyilvánvalóan hibás, hiszen az xsd:integer adattípushoz párosított "pumpkin" literál nincs benne az egész szám (integer) adattípus lexikális terében. Az olyan RDF szoftver, tehát, amelyet nem úgy írtak meg, hogy fel tudja dolgozni az xsd:integer adattípust, nem lenne képes felismerni ezt a hibát.

Ha azonban az RDF tipizált literálokat megfelelően kezeljük, akkor több információ áll rendelkezésünkre a literális értékek helyes interpretációjához, ami alkalmasabbá teszi az RDF kijelentéseket az alkalmazások közötti információcserére.

2.5 Az alapfogalmak összefoglalása

Egészében véve, az RDF lényegében egyszerű: csomópont-él-csomópont diagramok, amelyeket URI hivatkozásokkal azonosított dolgokról szóló kijelentésekként értelmezünk. Ez a szekció egy bevezetést adott ezekhez a fogalmakhoz. Mint korábban már megjegyeztük, ezeknek a fogalmaknak a normatív (azaz a definitív) specifikációja Az RDF alapfogalmai és absztrakt szintaxisa dokumentumban, e dokumentum referenciája pedig az[RDF-FOGALMAK] linken keresztül érhető el. További információkért célszerű ehhez a dokumentumhoz fordulni. Ezeknek a fogalmaknak a formális szemantikáját, azaz a pontos jelentését Az RDF Szemantikája című (normatív) dokumentum írja le.

Azonban azt is világosan kell látnunk, hogy az itt tárgyalt alapvető technikák mellett, amelyekkel RDF kijelentések formájában leírhatjuk a dolgokat, az embereknek vagy szervezeteknek szükségük van egy olyan módszerre is, amellyel le tudják írni azt a szókészletet (azt a specifikus terminológiát), amelyet az ilyen kijelentések szókincseként használni kívánnak, és ezen belül is, különösen az olyan kifejezéseket, amelyekkel:

• leírhatók a dolgok típusai (mint pl. exterms:Person)
• leírhatók a tulajdonságok (mint pl. exterms:age és exterms:creation-date), valamint
• leírhatók azon dolgok típusai, amelyeket a kijelentéseinkben szereplő tulajdonságok (állítmányok) alanyaiként és tárgyaiként kívánunk használni (például annak specifikálása céljából, hogy egy exterms:age tulajdonság értékének mindig xsd:integer típusúnak kell lennie).

Az ilyen szókészletek RDF-ben történő leírásának elemei Az RDF Szókészlet Leíró Nyelv 1.0: RDF Séma ([RDF-SZÓKÉSZLET]) dokumentumban találhatók, amelyek gyakorlati alkalmazását könyvünk 5. fejezete ismerteti.

A [WEBDATA] dokumentumban további háttér-információk találhatók az RDF alapelveiről, valamint az RDF-nek arról a szerepéről, hogy általános nyelvet biztosít a webes információk leírásához. Az RDF felhasznál elveket és megoldásokat a tudásábrázolás, a mesterséges intelligencia és az adatmenedzsment területéről, beleértve a konceptuális gráfokat, a logikai alapú tudásábrázolást, a keretrendszereket és a relációs adatbázisokat. Az ilyen témákkal kapcsolatos háttér-információk esetleges forrásaiként jól használhatók pl. ezek az anyagok: [SOWA], [CG], [KIF], [HAYES], [LUGER], [GRAY].

3.1 Alapelvek

Azok az alapelvek, amelyeken az RDF nyugszik, jól illusztrálhatók néhány olyan példával, amelyet korábban már bemutattunk. Vegyük elsőnek az alábbi, nyílt szövegű angol mondatot, mely magyarul kb. így hangzik "az ...index.html weblapnak van egy keletkezési dátuma, amelynek értéke 1999. augusztus 16."

http://www.example.org/index.html has a creation-date whose value is August 16, 1999

Ha feltesszük, hogy már hozzárendeltünk egy URI hivatkozást a creation-date (keletkezési dátuma) tulajdonsághoz, akkor az az RDF gráf, amely ezt az egyetlen mondatot leírja, úgy jelenne meg, ahogy az a 11. ábrán látható:

11. ábra: Egy weblap keletkezési dátumának leírása

Ugyanez tripletes ábrázolásban:

ex:index.html   exterms:creation-date   "August 16, 1999" .

(Figyeljük meg, hogy ebben a példában a dátum értékének ábrázolására nem tipizált literált használtunk. Az ilyen literálok RDF/XML-ben történő ábrázolására ebben a fejezetben még visszatérünk.)

A 2. példa bemutatja a 11. ábrának megfelelő RDF/XML szintaxist:

1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.             xmlns:exterms="http://www.example.org/terms/">

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.       <exterms:creation-date>August 16, 1999</exterms:creation-date>
6.   </rdf:Description>

7. </rdf:RDF>

(A sorok számozása csak a példa magyarázatának a könnyítését szolgálja.)

Ez a leírás túlságosan bőbeszédűnek tűnhet, ezért könnyebb lesz megérteni, hogy miről is van szó, ha egyenként megvizsgáljuk az XML szöveg sorait (a B. függelék egyébként tartalmaz egy rövid bevezetést az XML-hez).

Az 1. sor <?xml version="1.0"?> tegje az XML deklarációt tartalmazza, mely azt adja meg, hogy a következő tartalom XML-ben, és hogy milyen verziójú XML-ben van ábrázolva.

A 2. sorban szereplő rdf:RDF teggel megnyitunk egy elemet, mely azt jelzi, hogy a következő XML tartalom, mely a 7. sorban az </rdf:RDF> záróteggel ér véget, RDF adatokat ábrázol. Az rdf:RDF nyitóteget követően, ugyanebben a sorban láthatunk egy XML névtér-deklarációt, amelyet az RDF elem xmlns attribútumaként adunk meg. Ez a deklaráció azt mondja ki, hogy minden olyan név ebben a kontextusban, amely az rdf: prefixet viseli, annak a névtérnek a része, amelyet az attribútum értékeként megadott http://www.w3.org/1999/02/22-rdf-syntax-ns# névtér-URIref azonosít. Így tehát azok az URIref-ek, amelyek ezzel a hosszú karakterlánccal kezdődnek, az RDF szókészlet kifejezéseit jelölik meg.

A 3. sorban egy második XML névtér-deklaráció látható, ezúttal az exterms: prefix számára. Ezt a deklarációt az rdf:RDF elem második xmlns attribútuma adja meg, és azt specifikálja, hogy a http://www.example.org/terms/ teljes névtér-URIref prefixet az exterms: minősítettnév-prefixhez asszociáljuk. Így tehát azok az URIref-ek, amelyek ezzel a karakterlánccal kezdődnek, ahhoz a szókészlethez tartoznak, amelyet a példabeli cég: az example.org definiált. A ">" karakter, a 3. sor végén, a nyitó rdf:RDF teg végét jelöli. Az 1-3 sorok tehát általános információkat tartalmaznak az RDF/XML tartalom "kezeléséről", valamint deklarálják az RDF/XML tartalmon belül használt névtereket.

A 4-6. sorok azt az RDF/XML kódot tartalmazzák, amely leírja 11. ábrán szereplő specifikus kijelentést. Kézenfekvő dolog tehát úgy beszélni egy RDF kijelentésről, hogy az egy leírás (description), mely az alanyról szól. Esetünkben az alanyt a http://www.example.org/index.html URI azonosítja. Az RDF/XML-ben a kijelentések ábrázolásának szokásos módja a következő: A 4. sorban látható rdf:Description nyitóteg jelzi az erőforrás leírásának a kezdetét, amelyet szorosan követ annak az erőforrásnak (a kijelentés alanyának) az azonosítása amelyről (about) a kijelentés szól. Ez az rdf:about attribútum segítségével történik, amelynek értéke az erőforrást (alanyt) azonosító URIref. Az 5. sor a tulajdonság-elemet ábrázolja, amit az exterms:creation-date minősített név (mint nyitóteg) jelöl meg, és amely a kijelentés állítmányát azonosítja. Az exterms:creation-date minősített nevet úgy választottuk ki, hogy amikor a lokális creation-date nevet az exterms: prefixhez asszociált névtér-URIref (http://www.example.org/terms/) végéhez illesztjük, akkor megkapjuk az állítmány teljes azonosítóját, ami ily módon http://www.example.org/terms/creation-date lesz. Ennek a tulajdonság-elemnek a tartalma a kijelentés tárgya, amit az "August 19, 1999" tipizált literál ábrázol (és ami nem más, mint az erőforrás/alany "creation-date" tulajdonságának az értéke). A tulajdonság-elem bele van ágyazva az rdf:Description elembe, ami azt jelzi, hogy ez a tulajdonság arra az erőforrásra vonatkozik, amelyet az rdf:Description elem rdf:about attribútumával adunk meg. A 6. sorban látható ennek a specifikus rdf:Description elemnek a zárótegje.

És végül: a 7. sorban láthatjuk a 2. sorban megnyitott rdf:RDF elem zárótegjét. Az rdf:RDF elem használata az RDF/XML tartalom közrefogására azonban opcionális az olyan esetekben, ahol a kontextusból kiderül, hogy RDF/XML tartalomról van szó. Ezt az [RDF-SZINTAXIS] tárgyalja bővebben. Sohasem árthat azonban, ha megadjuk az RDF elemet; a tankönyvünkben is többnyire így járunk el.

A 2. példa bemutatta azokat az alapvető megoldásokat, amelyeket az RDF/XML használ egy RDF gráf kódolására: az XML elemeket, az attribútumokat, az elem tartalmát és az attribútum értékét. Az állítmányok URI hivatkozásait (ugyanúgy, mint néhány csomópontét) XML minősített nevekkel jelöltük meg, amelyek egy rövid prefixet (előtét-nevet) tartalmaznak, ami a névtér-URI-t helyettesíti, és amelyhez utónévként egy lokális név járul, amelyek így együtt egy névtérrel minősített elemet vagy attribútumot alkotnak, ahogyan azt a B. függelék leírja. Ez a névpár (vagyis a névtér-URIref és a lokális név) reprezentálja a megjelölendő gráfcsomópont vagy él (állítmány) teljes URI hivatkozását. Az alanyt ábrázoló csomópontok URI hivatkozásait XML attribútum-értékként adtuk meg, és néha ugyanígy adjuk meg a tárgyat ábrázoló csomópont URI hivatkozását is. A literális csomópontok, amelyek mindig tárgyat jelölő csomópontok, a tulajdonság-elemek szövegtartalmaként vagy attribútum-értékeként jelennek meg. (Tankönyvünk további részében még többet bemutatunk ezek közül a lehetőségek közül, de az összes ilyen opciót csak az [RDF-SZINTAXIS] sorolja fel.)

Egy több kijelentést ábrázoló RDF gráf egyes kijelentéseit a 2. példa 4-6. sorában bemutatotthoz hasonló módszerrel ábrázoljuk RDF/XML-ben. Például az alábbi két kijelentést, amelyet korábbi példákból már ismerünk:

ex:index.html   exterms:creation-date   "August 16, 1999" .
ex:index.html   dc:language             "en" .

RDF/XML-ben a 3. példában bemutatott módon írhatjuk le:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://www.example.org/terms/">

5.    <rdf:Description rdf:about="http://www.example.org/index.html">
6.        <exterms:creation-date>August 16, 1999</exterms:creation-date>
7.    </rdf:Description>

8.    <rdf:Description rdf:about="http://www.example.org/index.html">
9.        <dc:language>en</dc:language>
10.   </rdf:Description>

11. </rdf:RDF>

A 3. példa ugyanolyan, mint a 2. példa, azzal a különbséggel, hogy ebben megadtunk egy második rdf:Description elemet is (a 8-10. sorokban), hogy ezzel leírjuk a második kijelentést. (Egy további névtér-deklarációt is megadtunk a 3. sorban, hogy ez által azonosítsuk a második kijelentés állítmányának a dc névterét.) Tetszőleges számú további kijelentést írhatnánk ugyanilyen módon, egy-egy rdf:Description elem hatálya alatt.

Amint azt a 3. példa is mutatja, ha egyszer már megadtuk az XML deklarációt, valamint a használt névterek deklarációját, minden további RDF kijelentés hozzáadása már rutinszerűen megy, és szerkezetük sem túl bonyolult.

Az RDF/XML szintaxis egyéb rövidítési lehetőségeket is biztosít, hogy a gyakrabban előforduló dolgokat egyszerűbben leírhassuk. Például, amikor egy adott erőforrást egyszerre több tulajdonsággal, illetve értékkel kell jellemeznünk (ahogyan az a 3. példában is előfordult, ahol az ex:index.html erőforrás több kijelentés alanya), akkor ezeket tipikusan egyetlen rdf:Description elembe ágyazva adjuk meg, amelyik ilyenkor az összes állítmány alanyát reprezentálja. Példaképpen ábrázoljuk a következő három kijelentést a http://www.example.org/index.html alanyról:

ex:index.html   dc:creator              exstaff:85740 .
ex:index.html   exterms:creation-date   "August 16, 1999" .
ex:index.html   dc:language             "en" .

Ennek a gráfja (mely ugyanaz, mint a 3. ábráé) a 12. ábrán látható:

12. ábra: Több kijelentés ugyanarról az erőforrásról

Ennek a gráfnak az RDF/XML leírását pl. a 4. ábrán látható módon adhatnánk meg:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://www.example.org/terms/">

5.    <rdf:Description rdf:about="http://www.example.org/index.html">
6.         <exterms:creation-date>August 16, 1999</exterms:creation-date>
7.         <dc:language>en</dc:language>
8.         <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
9.    </rdf:Description>

10. </rdf:RDF>

Az előző két példához képest, a 4. példa egy további tulajdonságot (dc:creator) ad meg, mely a 8. sorban látható. Továbbá, a három tulajdonság-elem, amelynek az alanyát a http://www.example.org/index.html URI azonosítja, egyetlen rdf:Description elembe van beágyazva ahelyett, hogy három ilyen elem keretében adnánk meg a három tulajdonságot.

Emellett, a 8. sorban, bevezettük a tulajdonság-elemek megadásának egy új formáját is. Figyeljük meg, hogy a 7. sorban szereplő dc:language elem leírása hasonló a 6. sorban látható exterms:creation-date elem leírásához, amelyet már használtunk a 2. példában. E két elem mindegyikében a tulajdonság értékét típus nélküli literállal ábrázoltuk, és mint ilyent, a megfelelő tulajdonság-elem nyitó- és zárótegje közé kellett írnunk. A 8. sorban lévő dc:creator elem azonban egy olyan tulajdonságot reprezentál, amelynek az értéke egy külön erőforrás, tehát nem egy literál. Ha tehát ennek az erőforrásnak az URI-jét a dc:creator elem tegpárja közé írnánk, akkor ezzel azt mondanánk, hogy a "creator" (szerzője) tulajdonság értéke a "http://www.example.org/staffid/85740" karakterlánc, és nem egy olyan URIref, mely az értéket azonosítja. Hogy jelölhessük ezt az alapvető különbséget, egy olyan valamit kell használnunk, amelyet az XML üres elem teg-nek (empty-element tag) nevez, és amelyről tudnunk kell, hogy nincs külön zárótegje. Ebben az üres dc:creator elemben a tulajdonság értékét ábrázoló URI hivatkozást az elem rdf:resource attribútumának értékeként adjuk meg. Az rdf:resource attribútum azt jelzi, hogy az elem értéke egy külön erőforrás, amelyet az URI hivatkozása azonosít. Minthogy ezt az URI hivatkozást itt egy attribútum értékeként kell megadni, az RDF/XML elvárja, hogy ezt abszolút vagy relatív formában, de mindig teljesen kiírjuk. Vagyis, ezt nem rövidíthetjük le egy minősített névre, ahogyan azt megtehettük az elemek és az attribútumok nevei esetében. (Az abszolút és relatív URI hivatkozások témáját az A. függelék tárgyalja.)

Fontos, hogy megértsük: a 4. példa RDF/XML kódja egy rövidített változat. Az 5. példában szereplő RDF/XML kódban minden kijelentést külön írtunk, és ez pontosan ugyanazt az RDF gráfot írja le, mint a 4. példa (azaz a 12. ábrán látható gráfot):

 <?xml version="1.0"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:exterms="http://www.example.org/terms/">

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <exterms:creation-date>August 16, 1999</exterms:creation-date>
   </rdf:Description>

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <dc:language>en</dc:language>
   </rdf:Description>

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
   </rdf:Description>

 </rdf:RDF>

A további szekciókban még leírunk néhány más RDF/XML rövidítési lehetőséget is. (Az [RDF-SZINTAXIS] dokumentum tartalmazza az összes olyan rövidítést, amely alkalmazható RDF/XML-ben.)

Az RDF/XML-ben ábrázolhatunk olyan gráfokat is, amelyekben üres csomópontok vannak. (Mint már a 2.3 szekcióban leírtuk, ezek olyan csomópontok, amelyekhez nem tartozik URIref). Például, a 13. ábra, amelyet az [RDF-SZINTAXIS] dokumentumból vettünk át, egy olyan gráfot jelenít meg, mely azt mondja: "A 'http://www.w3.org/TR/rdf-syntax-grammar' URL-lel azonosított dokumentum címe: 'RDF/XML Syntax Specification (Revised)', ennek van egy szerkesztője, és a szerkesztőnek a neve: 'Dave Beckett', a honlapja pedig: 'http://purl.org/net/dajobe/' ".

13. ábra: Egy üres csomópontot tartalmazó gráf

Ez a gráf egy olyan alapelvet illusztrál, amelyet a 2.3 szekcióban már tárgyaltunk: az üres csomópont használatát olyan valaminek az ábrázolására, aminek nincs URI-je de leírható más információk megadásával. Esetünkben az üres csomópont egy személyt ábrázol, a dokumentum szerkesztőjét, akit a nevével és a honlapjával írunk le.

Az RDF/XML-ben több módszer is van az olyan gráfok ábrázolására, amelyek üres csomópontokat tartalmaznak (az [RDF-SZINTAXIS] dokumentumban ez mind megtalálható). Az a módszer, amit itt illusztrálunk (és ami a legközvetlenebb módszer), abból áll, hogy egy ürescsomópont-azonosítót rendelünk minden üres csomóponthoz. Az ilyen azonosító csak egyetlen adott RDF/XML dokumentumon belül képes egy üres csomópontot azonosítani: abban, amelyben allokálták, tehát szemben az URI hivatkozásokkal, az adott dokumentumon kívül ez ismeretlen. Az üres csomópontra az RDF-ben az rdf:nodeID attribútum segítségével hivatkozunk, amelynek az értéke egy ürescsomópont-azonosító. Ez az azonosító az RDF/XML kód olyan helyein használható, ahol egyébként egy erőforrás URIref-je is megjelenhetne. Specifikusan, az olyan kijelentéseket, amelyeknek az alanya egy üres csomópont, az RDF/XML-ben egy olyan rdf:Description elemmel is leírhatjuk, amelyben az rdf:about helyett egy rdf:nodeID attribútumot használunk az alany azonosítására. Hasonlóképpen, az olyan kijelentéseket, amelyeknek a tárgya egy üres csomópont, egy olyan tulajdonság-elemmel írhatjuk le, amelyben a tárgy azonosítóját az rdf:resource helyett egy rdf:nodeID attribútummal adjuk meg. A 6. példa azt mutatja be, hogy az rdf:nodeID segítségével hogyan lehet RDF/XML-ben leírni a 13. ábrán szereplő gráfot:

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://example.org/stuff/1.0/">

5.     <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
6.       <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
7.       <exterms:editor rdf:nodeID="abc"/>
8.     </rdf:Description>

9.     <rdf:Description rdf:nodeID="abc">
10.        <exterms:fullName>Dave Beckett</exterms:fullName>
11.        <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>
12.    </rdf:Description>

13. </rdf:RDF>

A 6. példa 9. sorában, az abc ürescsomópont-azonosítót használtuk a több kijelentés alanyát jelképező üres csomópont azonosítására. Ugyanezt az azonosítót használtuk a 7. sorban annak megjelölésére is, hogy ez az üres csomópont az alany (azaz a weblap) exterms:editor (szerkesztője) tulajdonságának az értéke. Az ürescsomópont-azonosító használatának az az előnye a többi módszerrel szemben, amelyet az [RDF-SZINTAXIS] leír, hogy ennek segítségével egy RDF/XML dokumentum több helyéről is hivatkozhatunk ugyanarra az üres csomópontra.

És végül, az RDF/XML-ben a 2.4 szekcióban megismert tipizált literálok is használhatók tulajdonságok értékeként, azok helyett a típus nélküli literálok helyett, amelyeket az eddigi példáinkban használtunk. Egy tipizált literált úgy ábrázolunk, hogy a tulajdonság-elemhez, mely közrefogja a literált, egy rdf:datatype attribútumot adunk, amelynek értéke egy, a literál adattípusát azonosító URIref.

Ha például meg akarnánk változtatni a 2. példában szereplő kijelentést úgy, hogy tipizált literált használjon típus nélküli helyett, az exterms:creation-date tulajdonság értékeként, akkor annak tripletes ábrázolása így nézne ki:

ex:index.html   exterms:creation-date   "1999-08-16"^^xsd:date .

Ugyanez a kijelentés RDF/XML szintaxissal leírva a 7. példában szemlélhető:

1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.             xmlns:exterms="http://www.example.org/terms/">

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.     <exterms:creation-date rdf:datatype=
         "http://www.w3.org/2001/XMLSchema#date">1999-08-16
       </exterms:creation-date>
6.   </rdf:Description>

7. </rdf:RDF>

A 7. példa 5. sorában egy tipizált literál van megadva az exterms:creation-date ("keletkezési dátuma") tulajdonság-elemben oly módon, hogy annak nyitótegjében egy rdf:datatype attribútum jelzi a literál adattípusát. Ennek az attribútumnak az értéke egy adattípus URIref-je, ami esetünkben a date (dátum) XML Séma adattípusra mutat. Minthogy ez az URIref itt most egy attribútum értéke, ezért teljes terjedelmében ki kell írnunk ahelyett, hogy megpróbálnánk xsd:date minősített névre lerövidíteni, ahogy megtettük ezt a tripletes változatban. A literál "1999-08-16" karakterláncát pedig, amely megfelel a date adattípusnak, a tulajdonság-elem tartalmaként ábrázoltuk.

<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 

1. <?xml version="1.0"?>
2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>

3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.             xmlns:exterms="http://www.example.org/terms/">

5.   <rdf:Description rdf:about="http://www.example.org/index.html">
6.     <exterms:creation-date rdf:datatype="&xsd;date">1999-08-16
       </exterms:creation-date>
7.   </rdf:Description>

8. </rdf:RDF>

Bár az RDF/XML adatok írásának több rövidített formája is létezik, az eddig ismertetett példáinkban mégis a rövidítő módszereknek csak az egyszerűbb, de általánosabb változatát használtuk a gráfok leírására. Összefoglalásul megismételjük, hogy ezek alkalmazásával hogyan írunk le egy RDF gráfot RDF/XML-ben:

• Minden üres csomóponthoz hozzárendelünk egy ürescsomópont-azonosítót.
• Azokat a csomópontokat, amelyeket le akarunk írni, egy nem beágyazott rdf:Description elem alanyaként adjuk meg. Ez történhet vagy egy rdf:about attribútum segítségével (ha a csomópontot URIref azonosítja), vagy egy rdf:nodeID segítségével (ha a csomópont üres).

  Minden egyes gráf-triplet számára, amelynek az így azonosított csomópont az alanya, egy megfelelő tulajdonság-elemet készítünk, amelynek a tárgya vagy literál tartalom, vagy ha ez üres, akkor egy erőforrás. Ezt az erőforrást vagy egy rdf:resource attribútum specifikálja (ha a tárgy csomópontja egy URIref), vagy egy rdf:nodeID attribútum (ha a tárgy csomópontja üres).

Összehasonlítva az [RDF-SZINTAXIS] néhány, ennél jelentősebb rövidítést lehetővé tevő opciójával, ez az egyszerű módszer adja a gráf-struktúra legközvetlenebb ábrázolását, és ezért különösen ajánlható az olyan alkalmazások számára, ahol a kimenő RDF/XML kód további RDF feldolgozások bemenő adata lesz.

3.2 Az URI hivatkozások rövidítése és szervezése

Az eddigi példáink feltételezték, hogy az éppen leírt erőforrásoknak már van URI hivatkozásuk. Így pl. a kezdetben bemutatott példáinkban a különböző adataival jellemeztük a hipotetikus example.org szervezet weblapját amelynek URI hivatkozása: http://www.example.org/index.html volt. Ezt az erőforrást az RDF/XML-ben az rdf:about attribútum segítségével azonosítottuk, amelyben teljes formájában idéztük ezt az URI-t. Noha az RDF nem specifikálja, és nem is ellenőrzi, hogy miként rendelnek hozzá egy URI hivatkozást egy erőforráshoz, néha azonban jó lenne, ha olyan erőforrásokhoz rendelnénk az URI hivatkozásokat, amelyek egy szervezett csoportot alkotnak. Példaképpen képzeljünk el egy sportszergyártó céget, amelynek a neve example.com, és amely szeretne kiadni egy RDF alapú katalógust az ilyen termékeiről, mint sátrak, túrabakancsok stb., és mindezt egy RDF/XML dokumentum formájában kívánják publikálni a http://www.example.com/2002/04/products URI-vel azonosított webhelyen. Ebben a dokumentumban minden termékhez megadhatnának egy külön RDF leírást. Ezt a katalógust (amelyben most még csak egyetlen árufajta szerepel: az "Overnighter" modellnevű sátor) úgy írhatjuk le RDF/XML-ben, ahogyan azt a 9. példa mutatja:

1.   <?xml version="1.0"?>
2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.               xmlns:exterms="http://www.example.com/terms/">

5.     <rdf:Description rdf:ID="item10245">
6.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
7.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
8.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
9.          <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
10.    </rdf:Description>

  ...további termékek leírásai...

11.  </rdf:RDF>

A 9. példa hasonló a korábbi példákhoz, abban a módban, ahogyan ábrázolja pl. a sátor (tent) tulajdonságait: a modellt (model), a fekvőhelyek számát (sleeps), a súlyt (weight) és a szállítási méretet (packedSize).

(Itt a keretül szolgáló xml-, DOCTYPE-, RDF- és névtér-deklarációk az 1-4 sorokban, és a 11. sorban szerepelnek. Ez olyan információ, amelyet csak egyszer kell megadni egy katalógus megírásánál, azaz nem kell megismételni a többi termék leírásához. Figyeljük meg azt is, hogy azokat az adattípusokat, amelyeket a sátor különböző tulajdonságaihoz társítottunk, explicit módon adtuk meg, míg az egyes tulajdonságértékekhez tartozó mértékegységeket nem jeleztük, pedig ezeknek is rendelkezésre kellene állniuk ahhoz, hogy helyesen interpretáljuk az értékeket. (A 4.4 szekció ismerteti az olyan mértékegységek és egyéb információk ábrázolását, amelyek a tulajdonságok értékeihez társulhatnak.) A példából csupán sejthető, hogy az exterms:sleeps tulajdonság értéke azon személyek száma, akik a sátorban éjszakázhatnak, hogy az exterms:weight értéke (a sátor súlya) kilogrammban van kifejezve, és hogy az exterms:packedSize (az összecsomagolt sátor mérete) négyzetcentiméterben van megadva.

Az egyik fontos különbség a korábbi példáink és a jelenlegi között az, hogy az 5. sorban az rdf:Description elemnek rdf:ID attribútuma van rdf:about helyett. Az rdf:ID használatával itt egy erőforrásrész-azonosítót (fragment identifier) specifikáltunk, amelyet az rdf:ID attribútum értékeként adtunk meg. Ez az azonosító az item10245, mely nyilván az example.com cég által megadott egyik katalógustétel száma, és egyben annak a teljes URI hivatkozásnak a rövidítése, mely az éppen leírt erőforrást (azaz a terméket: az "Overnighter" típusú sátort) azonosítja. Az item10245 erőforrásrész-azonosító egy bázis-URI-hez viszonyítva értendő, ami esetünkben a katalógust tartalmazó dokumentum URI-je. A sátort azonosító teljes URI hivatkozást úgy kapjuk meg, hogy a dokumentum bázis-URI-jének végéhez, egy "#" karakterrel elválasztva, hozzáillesztjük az erőforrásrész-azonosítót. Ez tehát így néz ki: http://www.example.com/2002/04/products#item10245.

Az rdf:ID attribútum némileg hasonlít az XML és a HTML által használt ID attribútumhoz, mégpedig annyiban, hogy ez is egy olyan nevet definiál, mely egyedi az aktuális bázis-URI által azonosított dokumentumon (esetünkben a katalóguson) belül. A példából kitűnik, hogy az rdf:ID attribútum az item10245 nevet rendelte az "Overnighter" típusú sátorhoz. Bármilyen más RDF/XML leírás, ami ezen a katalóguson belül van, hivatkozhat erre a termékre akár az abszolút URI hivatkozással, ami http://www.example.com/2002/04/products#item10245, akár a relatív változatával, ami #item10245.

Ismét hangsúlyozzuk: a relatív URIref úgy értendő, hogy az egy olyan URIref, amelyet a katalógus bázis-URI-jéhez viszonyítva definiálunk. Egy hasonló rövidítést használva, az adott sátortípusra vonatkozó URI hivatkozást így is megadhatnánk a fenti katalógus bejegyzésben: rdf:about="#item10245" (azaz közvetlenül a relatív URI-vel, ahelyett, hogy az rdf:ID="item10245" formát választanánk). Mint rövidítő mechanizmus, a két forma lényegében szinonim, hiszen az RDF/XML az értéküket mindkét esetben a http://www.example.com/2002/04/products#item10245 abszolút URI hivatkozássá terjeszti ki. Az rdf:ID használatakor azonban egy ellenőrzés is megvalósul, amikor valamilyen nevet rendelünk hozzá, ugyanis az rdf:ID attribútummal csak egyszer szabad definiálnunk egy nevet relatív URI-ként ugyanahhoz a bázis-URI-hez viszonyítva. (Vagyis, ugyanazon a dokumentumon belül egy helyi név csak egyszer deklarálható, de akárhányszor hivatkozhatunk rá más elemekből).

Bármelyik relatív hivatkozási formát is használnánk, az example.com két lépésben rendelné hozzá az URI hivatkozást a sátorhoz: először is hozzárendelne egy URI hivatkozást magához a katalógushoz, majd pedig, már a katalóguson belül, a sátor tulajdonságainak leírásakor hozzárendelné az adott katalógustételhez a relatív hivatkozás nevét. A relatív URIref ilyen használatát úgy is felfoghatjuk, hogy ez annak a teljes URI-nek a rövidítése, amely az RDF-től függetlenül már hozzá van rendelve a sátorhoz, és csak hivatkozunk erre (az rdf:about attribútum segítségével), de felfoghatjuk úgy is, hogy a relatív URIref-et a dokumentumon belül éppen most deklaráljuk, és éppen most rendeljük hozzá ehhez a katalógustételhez (az rdf:ID segítségével).

Egy olyan RDF leírás, mely a katalóguson kívül van, az URIref abszolút változatával hivatkozhatna erre a katalógustételre. Ezt, mint már említettük, a sátorra mutató relatív URIref és a katalógust azonosító bázis-URI egybetoldásával állítjuk elő. Tegyük fel, hogy egy túrasportokkal foglalkozó web alapú szolgáltatás, nevezzük exampleRatings.com-nak, RDF-et használna a különböző sátrak fogyasztói tetszési indexének a publikálására. Azt az ötcsillagos minősítést, amelyet az egyik vásárló (Richard Roe) a 9. példában leírt sátorra adott, az exampleRatings.com webhely a 10. példában látható módon regisztrálhatná:

1.  <?xml version="1.0"?>
2.  <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
3.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.              xmlns:sportex="http://www.exampleRatings.com/terms/">

5.    <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
6.         <sportex:ratingBy rdf:datatype="&xsd;string">Richard Roe</sportex:ratingBy>
7.         <sportex:numberStars rdf:datatype="&xsd;integer">5</sportex:numberStars>
8.    </rdf:Description>
9.  </rdf:RDF>

A 10 példa 5. sora egy rdf:Description elemet használ egy rdf:about attribútummal, amelynek az értéke a sátort azonosító abszolút URIref. Ennek a használata egyértelművé teszi, hogy a minősítés (rating) pontosan melyik termékre vonatkozik.

Ezek a példák több lényeges dolgot is illusztrálnak. Mindenekelőtt azt, hogy bár az RDF nem specifikálja, és nem is ellenőrzi, hogy miként rendeljék/rendelték hozzá az URI hivatkozásokat az erőforrásokhoz (esetünkben a katalógusban szereplő különböző sátrakhoz és más tételekhez), mégis létrejön az a kívánatos eredmény, hogy a megfelelő URI hivatkozások a megfelelő erőforrásokhoz vannak hozzárendelve. Ez az eredmény mindig két folyamat kombinációja révén jön létre: az egyik egy RDF-en kívüli folyamat, amelynek során egy olyan dokumentumot (esetünkben egy katalógust) látunk el azonosítóval, mely tartalmazza ezeknek az erőforrásoknak a leírását, a másik pedig egy olyan, RDF-en belüli folyamat, amelynek során ezen a dokumentumon belül, az erőforrások leírásakor, a rájuk hivatkozó relatív URI hivatkozásokat az rdf:ID segítségével deklaráljuk. Például az example.com cég használhatná ezt a katalógust egy olyan központi forrásként, amelyben a termékei le vannak írva, annak implicit elfogadásával, hogy ha egy áru termékszáma nem szerepel a katalógus valamelyik tételének a leírásában, akkor ez az áru nem tartozik az example.com termékei közé. (Megjegyzendő, hogy az RDF nem tételezi fel, hogy bármilyen konkrét kapcsolat létezik két erőforrás között, csak mert az URI hivatkozásuknak ugyanaz a bázis-URI-je, vagy mert más módon hasonlóak. Egy ilyen kapcsolat esetleg ismert lehet az example.com számára, de ezt nem definiálja közvetlenül az RDF.)

Ezek a példák egyébként a Web egyik alapvető architekturális alapelvére is rávilágítanak: arra, hogy bárki szabadon megadhat információkat egy létező erőforrásról egy tetszése szerinti szókészlet használatával [BERNERS-LEE98]. Ezek a példák azt is mutatják, hogy az RDF segítségével leírt erőforrásoknak nem kell egyetlen helyen összegyűjtve lenniük, hanem a weben szétszórva is elhelyezkedhetnek. Ez nemcsak a példabeli esetünkre igaz, amelyben az egyik szervezet minősít, vagy kommentál egy olyan erőforrást, amelyet egy másik definiált, hanem olyan esetekre is érvényes, ahol az erőforrás eredeti definiálója (vagy bárki más) további információk megadásával erősíteni és gazdagítani kívánja annak az erőforrásnak a leírását. Ez megtörténhet magának a dokumentumnak a módosításával, amelyben az erőforrást eredetileg definiálták, vagy pedig, ahogy az exampleRatings.com is teszi, egy új, külön dokumentum elkészítésével, amelyben további tulajdonságokat és értékeket ad meg egy rdf:Description elemben, mely az eredeti erőforrásra hivatkozik egy rdf:about attribútummal megadott URI-ref segítségével.

A fenti diszkusszió jelezte, hogy a relatív URI hivatkozások, mint pl. a #item10245, egy bázis-URI-hez viszonyítva értelmezhetők. Ez implicit módon annak az erőforrásnak az URI-je lesz, amelyikben a relatív URIref-et használjuk. Egyes esetekben azonban kívánatos, hogy explicit módon is specifikálhassuk ezt a bázis-URI-t. Tételezzük fel például, hogy a http://www.example.com/2002/04/products URI-vel azonosított katalógust az example.org cég egy duplikát változatban, egy másik, ún. tükröző webhelyen (mirror site) is szeretné publikálni, amelyet azonosítson, mondjuk, a http://mirror.example.com/2002/04/products URIref. Ez problémát okozhatna, hiszen ha az eredeti katalógushoz a tükrözött webhelyen kívánnánk hozzáférni, akkor a példabeli sátor teljes URI hivatkozását a leírást tartalmazó dokumentum bázis-URI-jéből állítanánk elő, ami ebben az esetben a http://mirror.example.com/2002/04/products#item10245 URIref lenne, és nem a kívánt http://www.example.com/2002/04/products#item10245, vagyis más erőforrásra hivatkoznánk, mint amire akartunk. Ennek elkerülése érdekében az example.org feltehetőleg egy explicit bázis-URI-t rendelne a termékeit azonosító URI hivatkozásokhoz ahelyett, hogy a problémát megkerülendő, csak egy helyen publikálná a katalógusát.

Hogy az ilyen helyzetekre megoldást adjon, az RDF/XML támogatja az XML bázis opciót (XML Base [XML-BASE]), mely lehetővé teszi, hogy az XML dokumentum specifikáljon egy olyan bázis-URI-t, amelyik független a saját bázis-URI-jétől. A 11. példa azt mutatja meg, hogy miként írnánk meg a korábbi katalógust az XML Base felhasználásával:

1.   <?xml version="1.0"?>
2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.               xmlns:exterms="http://www.example.com/terms/"
5.               xml:base="http://www.example.com/2002/04/products">

6.     <rdf:Description rdf:ID="item10245">
7.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
8.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
9.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
10.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
11.    </rdf:Description>

  ...további termékek leírásai...

12.  </rdf:RDF>

A 11. példa 5. sorában látható xml:base deklaráció azt specifikálja, hogy egy esetleges további xml:base deklaráció előfordulásáig, az rdf:RDF elemen belül a http://www.example.com/2002/04/products URI tekintendő bázis-URI-nek, és így minden relatív URIref, mely az adott xml:base attribútum hatályán belül van, a deklarált bázishoz viszonyítva értendő, mindegy, hogy mi az aktuális dokumentum saját bázis-URI-je. Ennek eredményeképpen a sátrat azonosító #item10245 relatív hivatkozást úgy értelmezi az RDF/XML, hogy annak abszolút URI hivatkozása http://www.example.com/2002/04/products#item10245, függetlenül attól, hogy éppen melyik webhelyen publikálják a katalógust. Vagyis, függetlenül attól, hogy mi a dokumentum aktuális URI-je, sőt még attól is, hogy a bázis-URI-ref azonosít-e egyáltalán valamilyen konkrét dokumentumot.

Eddig a példánk csupán egyetlen termék leírását: egy meghatározott sátortípus leírását mutatta be. Az example.com azonban valószínűleg ajánlani szeretne többféle sátormodellt, és más termékfajtából is többfélét, például hátizsákokat, túrabakancsokat stb. A dolgok különböző fajtákba vagy kategóriákba történő besorolása/osztályozása hasonló koncepció, mint a programnyelvekben használt objektumok különböző típusokba vagy osztályokba sorolása. Az RDF támogatja ezt a fogalmat egy előre definiált tulajdonság, az rdf:type bevezetésével. Amikor egy RDF erőforrást valamely tulajdonságával leírunk, akkor ennek a tulajdonságnak az értékét egy olyan erőforrásnak tekintjük, mely a dolgok egy kategóriáját vagy osztályát képviseli; ennek a tulajdonságnak az alanyát pedig a saját kategóriája vagy osztálya egyik esetének, előfordulásának (instance), vagy más szóval: egyedének (individual) tekintjük. A 12. példa az rdf:type használatával bemutatja, hogy az example.com miként jelezhetné azt, hogy az "item10245" katalógustétel leírása egy sátorra vonatkozik:

1.   <?xml version="1.0"?>
2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.               xmlns:exterms="http://www.example.com/terms/"
5.               xml:base="http://www.example.com/2002/04/products">

6.     <rdf:Description rdf:ID="item10245">
7.          <rdf:type rdf:resource="http://www.example.com/terms/Tent"/>
8.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
9.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
10.         <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
11.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
12.    </rdf:Description>

  ...további termékek leírásai...

13.  </rdf:RDF>

A 12. példa 7.sorában az rdf:type tulajdonság azt jelzi, hogy az éppen leírt erőforrás a http://www.example.com/terms/Tent URI hivatkozással azonosított Sátor osztálynak egyik konkrét előfordulása, vagy más szóval: egyik egyede. Ez feltételezi, hogy az example.com cég már előre definiálta a saját termék-osztályait ugyanannak a szókészletnek a részeként, mely a cég többi sajátos szakkifejezését is tartalmazza (mint pl. az exterms:weight), s így a Tent osztály abszolút URI-jével hivatkozhatunk rá. Ha az example.com cég a termék-osztályait a katalóguson belül definiálta volna, akkor a #Tent relatív URIref segítségével is hivatkozhatnánk a sátorok osztályára.

Az RDF, maga, nem tartalmaz eszközöket a dolgok olyan alkalmazás-specifikus osztályainak a definiálására, mint pl. a "Sátor", vagy az olyan tulajdonságaik definiálására, mint pl. az exterms:weight. Az ilyen osztályokat és tulajdonságokat egy RDF séma keretében lehet definiálni az RDF Séma nyelv segítségével, amelyet az 5. fejezet tárgyal. Az osztályok és tulajdonságok definiálására más eszközök is léteznek, mint pl. a DAML+OIL és az OWL nyelvek; ezeket az 5.5 szekció mutatja be röviden.

Meglehetősen általános az RDF használatában, hogy az erőforrásokhoz típust rendelünk az rdf:type tulajdonság segítségével, mely úgy jellemzi ezeket a forrásokat, mint típusok vagy osztályok konkrét előfordulását/egyedét. Az ilyen erőforrásokat a gráfban tipizált csomópontoknak (typed nodes), az RDF/XML leírásban pedig tipizált csomópont-elemeknek nevezzük. Az RDF/XML szintaxis az ilyen elemek leírásánál egy speciális rövidítést tesz lehetővé. Ennél a rövidítésnél kihagyjuk az rdf:type tulajdonságot és az értékét, az rdf:Description elemet pedig egy másik elemmel helyettesítjük, amelynek a neve egy olyan minősített név, mely megfelel a kihagyott rdf:type tulajdonság értékének (vagyis annak az URI hivatkozásnak, amelyik megnevezi az osztályt). Ennek a rövidítésnek a használatával az example.com 12. példabeli sátrát a 13. példában megadott módon lehetne leírni:

1.   <?xml version="1.0"?>
2.   <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
3.   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.               xmlns:exterms="http://www.example.com/terms/"
5.               xml:base="http://www.example.com/2002/04/products">

6.     <exterms:Tent rdf:ID="item10245">
7.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
8.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
9.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
10.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
11.    </exterms:Tent>

  ...tov@?bbi termékek leírásai...

12.  </rdf:RDF>

A 12. és a 13. példa egyaránt jól mutatta, hogy az RDF kijelentéseket le lehet írni az RDF/XML-ben olyan módon is, amely nagyon emlékeztet a közvetlenül XML-ben (tehát nem RDF/XML-ben) készült leírásokra. Ez egy lényeges aspektus, tekintettel a különféle XML alkalmazások egyre növekvő számára, hiszen ez azt sejteti, hogy az RDF használható lenne ezekben az alkalmazásokban anélkül, hogy nagyobb változtatásokat kellene végrehajtani abban a módban, ahogyan az információikat strukturálják.

3.3 Az RDF/XML összefoglalása

A fenti példák illusztrálták az RDF/XML szintaxis néhány fundamentális elemét. Ezek a példák elegendő információt nyújtottak ahhoz, hogy elkezdjünk hasznos RDF/XML dokumentumokat készíteni. Az RDF/XML szintaxis specifikációja című (normatív) dokumentum egy alaposabb diszkussziót tartalmaz azokról az elvekről is, amelyekre az RDF gráfok XML-ben történő modellezése épül, és amelyeket összefoglalóan "csíkozás" (striping) néven emleget az RDF/XML zsargon. Ugyanez a dokumentum további lehetőségeket mutat be az RDF/XML kód írásának rövidítésére, valamint további részleteket és példákat közöl az RDF adatok XML-be történő átírásához.

4.1 RDF konténerek

Gyakran szükség van arra, hogy dolgokból csoportokat képezzünk, és így írjuk le őket. Például Ilyen eset az, amikor ki kell jelentenünk, hogy egy könyvnek több szerzője, egy tanfolyamnak több hallgatója, vagy egy szoftvernek több modulja van, és ezeket csoportként kell jellemeznünk és kezelnünk. Az RDF rendelkezik több, előre definiált (beépített) típussal és tulajdonsággal, amelyeket arra használhatunk, hogy az ilyen csoportokat leírjuk.

Először is, az RDF-nek van egy konténer szókészlete, mely három előre definiált típust tartalmaz (néhány ezekhez kapcsolódó tulajdonsággal együtt). A konténer egy olyan erőforrás, mely több dolgot tartalmaz. Ezeket a dolgokat tagoknak nevezzük. A konténer tagjai lehetnek erőforrások (beleértve az üres csomópontokat is), és lehetnek literálok. Az RDF háromféle típusú konténert definiál:

• rdf:Bag (zsák)
• rdf:Seq (sorozat, v. szekvencia)
• rdf:Alt (alternativa-csoport)

A zsák egy olyan erőforrás, amelynek típusa rdf:Bag, és olyan erőforrások vagy literálok csoportját ábrázolja, amelyben duplikát tagok is előfordulhatnak, és amelyben nincs jelentősége a tagok sorrendjének. Egy Bag konténer leírhatja például alkatrész-számok egy csoportját, ahol a tagok feldolgozásánál a sorrendnek nincs szerepe.

A sorozat vagy szekvencia egy olyan erőforrás, amelynek típusa rdf:Seq, és olyan erőforrások vagy literálok csoportját ábrázolja, amelyben duplikát tagok is előfordulhatnak, és amelyben a tagok sorrendje szignifikáns. Egy Seq konténer leírhat például egy olyan csoportot, amelynek a tagjait név szerinti ábécésorrendben kell tartani.

Az alternatíva-csoport, amelynek típusa rdf:Alt, olyan erőforrások vagy literálok csoportját ábrázolja, amelyek alternatívák (tipikusan egy tulajdonság értékének az alternatívái). Egy Alt konténer leírhatja például egy könyv címének különböző nyelvű, alternatív fordításait, vagy alternatív webhelyek egy listáját, amelyben egy erőforrás megtalálható. Egy alkalmazásnak, mely olyan tulajdonságot használ, amelynek értéke egy Alt konténer, tudnia kell, hogy a konténer bármelyik tagját választhatja a tulajdonság értékének, amelyik a számára megfelel.

Ahhoz, hogy leírjunk egy erőforrást, mint e konténertípusok egyikét, az erőforrásnak egy rdf:type tulajdonságot adunk, amelynek értéke az rdf:Bag, rdf:Seq, vagy rdf:Alt előre definiált erőforrás valamelyike lesz, attól függően, hogy melyikre van szükségünk. A konténer erőforrás, ami ugyanúgy lehet egy üres csomópont, mint egy URI hivatkozással azonosított erőforrás, megjelöli a csoportot mint egészet. A konténer tagjait úgy írhatjuk le, hogy mindegyikük számára definiálunk egy konténertagság-tulajdonságot (röviden: tagságtulajdonságot), amelyeknek alanya egy konténer típusú erőforrás, tárgya pedig a konténer éppen definiált tagja. A tagságtulajdonságok nevének formátuma rdf:_n, ahol n egy nem nulla értékű decimális egész szám, bevezető nullák nélkül, mint pl. rdf:_1, rdf:_2, rdf:_3 stb. Ezeket specifikusan a konténer tagjainak leírására használjuk. A konténertagság és az rdf:type mellett, a konténer-erőforrásoknak lehetnek más olyan tulajdonságaik is, amelyek leírják a konténert.

Lényeges, hogy megértsük: noha ezeket a konténertípusokat előre definiált RDF típusokkal és tulajdonságokkal írjuk le, azok a speciális jelentések, amelyeket ezekhez a konténerekhez társítunk (pl., hogy egy Alt konténer tagjai alternatív értékek), csupán szándékolt jelentések. Ezeket a specifikus konténertípusokat, és ezek definícióit azzal a szándékkal tervezték, hogy egy közös konvenciót teremtsenek azok között, akik csoportokat kívánnak leírni. Amit az RDF tesz, az csak annyi, hogy biztosítja azokat a típusokat és tulajdonságokat, amelyekkel leírható bármelyik konténerfajta gráfja. Az RDF ugyanúgy nem érti önmagától, hogy milyen erőforrás az rdf:Bag típusú erőforrás, mint ahogy nem érti, milyen erőforrás, mondjuk, az ex:Tent típusú erőforrás (a 3.2 szekcióból). Minden egyes esetben az alkalmazásokat úgy kell megírni, hogy annak a jelentésnek megfelelően működjenek, amelyet az általuk alkalmazott konténertípusok hordoznak. Ezt a témát a következő példák kapcsán bővebben is kifejtjük.

Egy konténer tipikus alkalmazása annak a jelzése, hogy egy tulajdonság értéke bizonyos dolgok egy csoportja. Például, ha azt a mondatot akarjuk ábrázolni, hogy "A 6.001 számú tanfolyam hallgatói: Mohamed, Johann, Maria és Phuong", akkor a tanfolyamot úgy írhatjuk le, hogy adunk neki egy s:students tulajdonságot (egy megfelelő szókészletből), amelynek értéke egy rdf:Bag típusú konténer, mely a hallgatók csoportját ábrázolja. Azután a konténertagság-tulajdonság segítségével az egyes hallgatókat úgy azonosítjuk, mint ennek a csoportnak a tagjait, ahogy a 14. ábrán látható gráf mutatja:

14. ábra: Egy egyszerű Bag konténer leírása gráffal

Mivel az s:students tulajdonság értéke ebben a példában egy Bag formájában van leírva, nincs szándékolt jelentése annak a sorrendnek, amelyben a hallgatókat azonosító URI hivatkozások fel vannak sorolva, akkor sem, ha a gráfban a tagságtulajdonságok sorszámokat tartalmaznak a nevükben. Kizárólag azoknak az alkalmazásoknak a kompetenciája, hogy figyelembe veszik-e, vagy sem a tagságtulajdonságokban szereplő nevek (számmal jelzett) sorrendjét, amelyek előállítják vagy feldolgozzák az rdf:Bag típusú konténert tartalmazó gráfot.

Az RDF/XML tartalmaz néhány olyan speciális szintaktikai elemet, illetve rövidítési lehetőséget, amelyek egyszerűbbé teszik az ilyen konténerek leírását. A 14. példa a következőképpen írja le a 14. ábrán bemutatott gráfot:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/students/vocab#">

   <rdf:Description rdf:about="http://example.org/courses/6.001">
      <s:students>
         <rdf:Bag>
            <rdf:li rdf:resource="http://example.org/students/Amy"/>
            <rdf:li rdf:resource="http://example.org/students/Mohamed"/>
            <rdf:li rdf:resource="http://example.org/students/Johann"/>
            <rdf:li rdf:resource="http://example.org/students/Maria"/>
            <rdf:li rdf:resource="http://example.org/students/Phuong"/>
         </rdf:Bag>
      </s:students>
   </rdf:Description>
</rdf:RDF>

A 14. példából látható, hogy az RDF/XML-nek van egy rdf:li nevű beépített tulajdonsága, amellyel elkerülhetjük, hogy explicit módon sorszámoznunk kelljen az összes tagságtulajdonságot. Ennek használatakor a gráfnak megfelelő rdf:_1, rdf:_2 stb. számozott tulajdonságokat az rdf:li elemekből generálja az RDF/XML. Az rdf:li elem mnemonikus neve a HTML-ből is ismert "list item" (lista-elem) kifejezés rövidítése. Vegyük észre azt is, hogy az <rdf:Bag> elem itt bele van ágyazva az <s:students> tulajdonság-elembe. Az <rdf:Bag> elem egy újabb példája a 13. példában már alkalmazott rövidítésnek, ahol egyetlen elemmel helyettesítettük az rdf:Description és az rdf:type elemet, amikor leírtuk egy típus egyik előfordulását. (Esetünkben az rdf:Bag egyik előfordulását írjuk le ilyen rövidített formában, amikor beágyazzuk az s:students elembe.) Minthogy itt nem specifikáltunk URI hivatkozást, a Bag konténert egy üres csomópont reprezentálja a gráfban. Ennek beágyazása az <s:students> elembe egy rövidített ábrázolása annak, hogy az üres csomópont az <s:students> tulajdonság értéke. Az ilyen rövidítési módszereket az [RDF-SZINTAXIS] tárgyalja bővebben.

A rdf:Seq konténer gráfstruktúrája, és az annak megfelelő RDF/XML leírás hasonló az rdf:Bag ugyanilyen ábrázolásához, azzal a különbséggel, hogy a konténertípus itt rdf:Seq. Itt is hangsúlyozzuk, hogy bár az rdf:Seq konténer szándékoltan explicit sorrendet ábrázol a tagok között, mégis kizárólag a gráfot előállító és felhasználó alkalmazások dolga, hogy megfelelően interpretálják az egész számokkal megadott tulajdonságnevek sorrendjét.

Azért, hogy illusztráljunk egy Alt konténert is, a 15. ábrán ábrázoljuk a következő mondat gráfját: "Az X11 forráskódja megtalálható az ftp.example.org, az ftp1.example.org vagy az ftp2.example.org webhelyen":

15. ábra: Egy egyszerű Alt konténer ábrázolása

A 15. példa azt illusztrálja, hogy miként írhatjuk le RDF/XML-ben a 15. ábrán ábrázolt gráfot:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/packages/vocab#">

   <rdf:Description rdf:about="http://example.org/packages/X11">
      <s:DistributionSite>
         <rdf:Alt>
            <rdf:li rdf:resource="ftp://ftp.example.org"/>
            <rdf:li rdf:resource="ftp://ftp1.example.org"/>
            <rdf:li rdf:resource="ftp://ftp2.example.org"/>
         </rdf:Alt>
      </s:DistributionSite>
   </rdf:Description>
</rdf:RDF>

Az Alt konténert arra tervezték, hogy legalább egy tagot tartalmazzon, amelyet az rdf:_1 tulajdonság azonosít. Az ehhez társított tagot a tulajdonság alapértelmezett értékének, vagy preferált értékének tekintjük. A többi tag sorrendje közömbös, és a rangjuk is azonos.

A 15. ábrán szereplő RDF gráf (ahogyan le van leírva) egyszerűen azt mondja ki, hogy az s:DistributionSite tulajdonság maga az Alt konténer erőforrás. Minden további jelentés, ami ennek a gráfnak tulajdonítható (például, hogy az Alt konténer egyik tagja az s:DistributionSite tulajdonság értékének tekintendő, vagy hogy az ftp://ftp.example.org az alapértelmezett érték), bele kell hogy épüljön a feldolgozó alkalmazásnak az Alt konténer vagy az s:DistributionSite tulajdonság szándékolt jelentését interpretáló logikájába.

Az Alt konténereket gyakran használják a nyelvi címkézéssel összefüggésben. (Az RDF/XML megengedi az xml:lang attribútum használatát, amelyet az [XML] dokumentum definiál, és amely annak jelzésére szolgál, hogy az adott elem tartalma az attribútum értékeként megadott természetes nyelven íródott. Az xml:lang használatát az [RDF-SZINTAXIS] ismerteti, az illusztrációja pedig könyvünk 6.2 szekciójában látható.) Például egy olyan publikációnak a title tulajdonsága, amelynek a címét több nyelvre is lefordították, egy olyan Alt konténerre mutathat, amelynek a literál-értékekkel megadott tagjai a cím különböző nyelvű fordításait ábrázolják.

A Bag és az Alt szándékolt jelentése közötti különbséget jól illusztrálja pl. a "Huckleberry Finn kalandjai" című regény szerzőjének ábrázolása. A könyvnek egyetlen szerzője van, de két néven is ismerjük (Mark Twain és Samuel Clemens). Bármelyik név elégséges arra, hogy specifikáljuk vele a szerzőt. Így, ha egy Alt konténert használunk a szerző neveinek megadására, az pontosabban írja le a szerzőségi viszonyt, mintha egy Bag konténerrel adtuk volna meg (amelyik azt sugallná, hogy a könyvnek két különböző szerzője van).

A felhasználók szabadon eldönthetik, hogy mivel, és hogyan írják le az erőforrások csoportjait, ha nem kívánják az RDF konténer-szókészletét használni. Ezt ugyanis csak azért definiálták, hogy legyenek olyan közös definíciók, amelyeket, ha általánosan használunk, megnövelik azoknak az alkalmazásoknak az együttműködőképességét, amelyek erőforrás-csoportokat tartalmazó adatokat használnak.

Néha egyenértékű alternatívákat találunk az RDF konténertípusainak használata helyett. Például egy erőforrás, és más erőforrások egy csoportja közötti viszony ábrázolható úgy is, hogy az első erőforrást több olyan kijelentés alanyává tesszük, amelyek ugyanazt a tulajdonságot használják. Ez strukturálisan különbözik attól a megoldástól, ahol ez az erőforrás csupán egyetlen olyan kijelentés alanya, amelynek a tárgya egy több tagot tartalmazó konténer. Ez a két különböző struktúra egyik esetben jelentheti ugyanazt, a másik esetben pedig nem. Amikor el kell döntenünk, hogy egy adott szituációban melyiket használjuk, az esetleges különbséget fel kell ismernünk.

Példaképpen tekintsük egy írónő és a publikációi között fennálló viszonyt az alábbi mondatban:

Sue has written "Anthology of Time", "Zoological Reasoning", and "Gravitational Reflections".

(Ez a mondat azt jelenti ki, hogy Sue írta az idézett című publikációkat). Ebben az esetben három erőforrásunk van, amelyek mindegyikéről önállóan kijelenthető, hogy ugyanaz a szerző írta. Ezt kifejezhetjük ismételt tulajdonságok használatával:

exstaff:Sue   exterms:publication   ex:AnthologyOfTime .
exstaff:Sue   exterms:publication   ex:ZoologicalReasoning .
exstaff:Sue   exterms:publication   ex:GravitationalReflections .

Ebben a példában nem állapítunk meg egyéb viszonyt ezek között a publikációk között, mint azt, hogy ugyanaz a szerző írta őket. A kijelentések mindegyike egy független tény, s ezért az ismételt tulajdonságok használata értelmes választás lenne. De ugyanilyen értelmes lenne ezt a viszonyt egyetlen olyan kijelentéssel ábrázolni, mely olyan erőforrások csoportjára vonatkozik, amelyeket Sue írt:

exstaff:Sue   exterms:publication   _:z .
_:z           rdf:type              rdf:Bag .
_:z           rdf:_1                ex:AnthologyOfTime .
_:z           rdf:_2                ex:ZoologicalReasoning .
_:z           rdf:_3                ex:GravitationalReflections .

Nézzük meg ugyanakkor az alábbi mondatot:

The resolution was approved by the Rules Committee, having members Fred, Wilma, and Dino.

Ez azt mondja: "A határozatot (resolution) elfogadta (approved by) a Szabálybizottság (Rules Committee), amelynek a tagjai Fred, Wilma és Dino. Ez a mondat csak azt állítja, hogy a bizottság mint egész elfogadta a határozatot, azt azonban nem, hogy minden tagja egyenként is elfogadta volna. Ebben az esetben félrevezető lenne három külön exterms:approvedBy elemi kijelentéssel modellezni a fenti mondatot, mint ahogy ezt az alábbi RDF leírás teszi:

ex:resolution   exterms:approvedBy   ex:Fred .
ex:resolution   exterms:approvedBy   ex:Wilma .
ex:resolution   exterms:approvedBy   ex:Dino .

hiszen ez a leírás minden bizottsági tagról egyenként kijelenteni, hogy elfogadta a határozatot, holott az eredeti mondatban nem erről van szó.

Ebben az esetben célszerűbb lenne egyetlen olyan exterms:approvedBy kijelentéssel modellezni a mondatot, amelynek alanya az ex:resolution, tárgya pedig az ex:rulesCommittee. Ezzel már (helyesen) azt jelentenénk ki, hogy a határozatot elfogadta a bizottság mint egész. A Rules Commitee erőforrás azután leírható egy Bag konténerrel, amelynek a tagjai azonosak a bizottság tagjaival, ahogy az alábbi tripletekben látható:

ex:resolution       exterms:approvedBy   ex:rulesCommittee .
ex:rulesCommittee   rdf:type             rdf:Bag .
ex:rulesCommittee   rdf:_1               ex:Fred .
ex:rulesCommittee   rdf:_2               ex:Wilma .
ex:rulesCommittee   rdf:_3               ex:Dino .

Amikor RDF konténereket használunk, fontos megértenünk, hogy a kijelentéseink nem konstruálják a konténert, mint a programozási nyelvek adatstruktúrái esetén. Valójában a kijelentések itt csupán leírják a konténert (a dolgok egy csoportját), amely feltehetően a világban létező entitás. Például az imént látott példában a Szabálybizottság mindenképpen emberek rendezetlen halmaza, akár ilyennek írjuk le RDF-ben, akár nem. Azzal, hogy azt mondjuk az ex:rulesCommittee erőforrásról, hogy annak típusa rdf:Bag, még nem állítjuk, hogy a Szabálybizottság egy adatstruktúra, és nem is konstruálunk ezzel egy konkrét adatstruktúrát a csoport tagjai számára (a Szabálybizottság leírható volna Bag konténerként anélkül is, hogy akár egyetlen tagját is leírnánk). Ehelyett csupán azt állítjuk a Szabálybizottságról, hogy olyan jellemzőkkel rendelkezik, amelyek megfelelnek a Bag konténerhez társított jellemzőknek, nevezetesen, hogy tagjai vannak, és hogy a tagok leírásának sorrendje nem szignifikáns. Hasonlóképpen, a konténertagság-tulajdonságok használatával is csupán azt írjuk le a konténer erőforrásról, hogy bizonyos dolgokat tartalmaz, amelyeket a tagjainak tekintünk. Ez pedig nem szükségszerűen jelenti azt, hogy a tagjaiként leírt dolgokon kívül nincsenek más tagjai. Például a fenti tripletek, amelyekkel leírtuk a bizottság tagjait, csupán azt mondják ki, hogy Fred, Wilma és Dino tagjai a bizottságnak, de azt nem, hogy csak ők a tagjai.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/packages/vocab#"> 
 
 <rdf:Description rdf:about="http://example.org/packages/X11">
    <s:DistributionSite>
       <rdf:Alt>
          <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/> 
          <rdf:_2 rdf:resource="ftp://ftp.example.org"/>
          <rdf:_2 rdf:resource="ftp://ftp1.example.org"/>
          <rdf:_5 rdf:resource="ftp://ftp2.example.org"/>
      </rdf:Alt>
    </s:DistributionSite>
 </rdf:Description>
</rdf:RDF>

4.2 RDF kollekciók

A 4.1 szekcióban ismertetett konténerek egyik hiányossága, hogy nem adnak lehetőséget arra, hogy lezárjuk őket, vagyis, hogy azt mondjuk: "ez az összes tagja a konténernek". Mint a 4.1 szekcióban megjegyeztük, egy konténer mindössze azt mondja, hogy néhány azonosított erőforrás a tagja; azt azonban nem jelenti ki, hogy nincsenek más tagjai. Így akkor is, amikor egy gráf leírja egy konténer néhány tagját, nem lehet kizárni, hogy esetleg létezik valahol egy másik olyan gráf, mely néhány további tagját is leírja. Szerencsére, az RDF támogatja olyan csoportok leírását is, RDF kollekciók formájában, amelyekről biztosan tudható, hogy csakis a leírt tagokat tartalmazzák. Egy RDF kollekció a dolgok egy csoportja, amelyet egy lista-struktúra formájában ábrázolunk az RDF gráfban. Ezt a lista-struktúrát egy előre definiált kollekció szókészlet segítségével konstruáljuk, mely az rdf:List típusból, az rdf:first ("első eleme") és rdf:rest ("maradék része") tulajdonságokból, valamint a szintén előre definiált rdf:nil ("üres lista") erőforrásból áll.

Ha kollekcióval kívánnánk leírni pl. azt a mondatot, hogy "A 6.001. számú tanfolyam hallgatói Amy, Mohamed és Johann", akkor a 16. ábrán látható gráfot ábrázolnánk:

16. ábra: Egy RDF kollekció (listaszerkezet)

Ebben a gráfban a kollekció minden egyes tagja, mint pl. s:Amy, egy rdf:first tulajdonság tárgya, s ez utóbbinak az alanya pedig egy erőforrás (példánkban ez üres csomópont), mely a listát képviseli. Ezt a lista típusú erőforrást egy rdf:rest tulajdonsággal kapcsoljuk a lista maradék részéhez. A lista végét egy rdf:nil értékkel rendelkező rdf:rest tulajdonság jelzi, ahol az rdf:nil egy rdf:List típusú üres listát reprezentál. Ez a szerkezet ismerős lehet azok számára, akik ismerik a Lisp programozási nyelvet. Ugyanúgy, mint a Lisp-ben, az rdf:first és az rdf:rest tulajdonságok lehetővé teszik az alkalmazásoknak, hogy sorban végigmenjenek a struktúrán. Minden üres csomópont, mely ezt a listát alkotja, eleve rdf:List típusú (azaz, e csomópontok mindegyikének van egy implicit rdf:type tulajdonsága, amelynek az értéke az rdf:List előre definiált típus), habár ezt explicit módon nem mutatja a gráf. Az RDF Séma nyelv [RDF-SZÓKÉSZLET] úgy definiálja az rdf:first és az rdf:rest tulajdonságot, hogy ezek alanya egy rdf:List típusú csomópont, tehát az a tény, hogy ezek a csomópontok listák, általában kikövetkeztethető, s így a nekik megfelelő rdf:type tripleteket nem kell állandóan ismételve kiírni.

Az RDF/XML támogat egy speciális írásmódot is, amelyik megkönnyíti az ilyen gráffal megadott kollekciók leírását. Az RDF/XML-ben egy kollekció leírható egy olyan tulajdonságelemmel, amelynek van egy rdf:parseType="Collection" attribútuma, és amelynek a tartalma olyan beágyazott elemek egy csoportja, amelyek a kollekció tagjait ábrázolják. Az RDF/XML annak jelzésére használja az rdf:parseType attribútumot, hogy az adott elem tartalmát speciális módon kell értelmezni. Esetünkben az rdf:parseType="Collection" attribútum azt jelzi, hogy a beágyazott elemeket a kollekciónak megfelelő listaszerkezetet ábrázoló gráf előállítására kell használni, vagy hogy egy ilyen gráf RDF/XML leírásaként kell értelmezni. (Az rdf:parseType attribútum egyéb lehetséges értékeit tankönyvünk későbbi fejezeteiben tárgyaljuk.)

Annak érzékeltetésére, hogy hogyan működik az rdf:parseType="Collection", a 17. példában leírjuk azt az RDF/XML kódot, mely a 16. ábrán szereplő gráfot eredményezi:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/students/vocab#">

   <rdf:Description rdf:about="http://example.org/courses/6.001">
      <s:students rdf:parseType="Collection">
            <rdf:Description rdf:about="http://example.org/students/Amy"/>
            <rdf:Description rdf:about="http://example.org/students/Mohamed"/>
            <rdf:Description rdf:about="http://example.org/students/Johann"/>
      </s:students>
   </rdf:Description>
</rdf:RDF>

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/students/vocab#"> 

<rdf:Description rdf:about="http://example.org/courses/6.001"> 
   <s:students rdf:nodeID="sch1"/>
</rdf:Description>
 
<rdf:Description rdf:nodeID="sch1"> 
   <rdf:first rdf:resource="http://example.org/students/Amy"/>
   <rdf:rest rdf:nodeID="sch2"/> 
</rdf:Description>
 
<rdf:Description rdf:nodeID="sch2"> 
   <rdf:first rdf:resource="http://example.org/students/Mohamed"/>
   <rdf:rest rdf:nodeID="sch3"/> 
</rdf:Description>
 
<rdf:Description rdf:nodeID="sch3"> 
   <rdf:first rdf:resource="http://example.org/students/Johann"/>
   <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/> 
</rdf:Description>
</rdf:RDF>

4.3 RDF tárgyiasítás (reification)

Az RDF alkalmazásoknak néha RDF kijelentésekkel kell leírniuk más RDF kijelentéseket. Ilyen eset pl. az, ha információt kell rögzíteni arról, hogy mikor készítették az adott kijelentéseket, ki készítette őket, vagy más hasonló információt, amelyeket néha származási információknak hívunk. Emlékezzünk a 3.2 szekcióban bemutatott 9. példára, mely leír egy exproducts:item10245 URI hivatkozással azonosított sátort, amelyet az example.com ajánl az Interneten: ennek a leírásnak az egyik tripletje, mely leírja a sátor súlyát, a következő volt:

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

Itt nagyon hasznos lenne, ha az example.com azt is rögzítené, hogy kitől származik ez az információ.

Az RDF-nek van egy olyan beépített szókészlete, amellyel magukról az RDF kijelentésekről is lehet kijelentéseket tenni. Azt az eljárást, amelynek során ezzel a szókészlettel leírunk egy kijelentést, tárgyiasításnak hívjuk, e művelet eredményét pedig az adott kijelentés tárgyiasulásának, vagy megtestesülésének nevezzük. Az RDF tárgyiasító szókészlete az rdf:Statement típusból és az rdf:subject, rdf:predicate és rdf:object tulajdonságokból áll (ezek jelentése ebben a sorrendben: Kijelentés, "alanya", "állítmánya", "tárgya"). Az RDF rendelkezésünkre bocsátja ugyan ezt a tárgyiasító szókészletet, de csak óvatosan szabad élnünk vele, mert nagyon könnyű abba a tévedésbe esni, hogy a szókészlettel olyan dolgokat definiálunk, amelyek ténylegesen még nincsenek definiálva. Erről később még ejtünk néhány szót.

A tárgyiasító szókészlet használatával most tárgyiasítsuk az említett sátor súlyáról szóló kijelentést oly módon, hogy hozzárendeljük az exproducts:triple12345 URI hivatkozást, mely alanyként ezt a kijelentést azonosítja, majd pedig leírjuk az eredeti kijelentés egyes részeit az alábbi tripletekkel:

exproducts:triple12345   rdf:type        rdf:Statement .
exproducts:triple12345   rdf:subject     exproducts:item10245 .
exproducts:triple12345   rdf:predicate   exterms:weight . 
exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

Ezek az elemi kijelentések azt fogalmazzák meg, hogy az exproducts:triple12345 URI hivatkozással azonosított erőforrás "típusa" Kijelentés, és ennek a kijelentésnek az "alanya" az exproducts:item10245 erőforrásra mutat, az "állítmánya" az exterms:weight tulajdonságra, a "tárgya" pedig egy olyan decimális egész számra, amelyet a "2.4"^^xsd:decimal tipizált literál ábrázol. Tegyük fel, hogy az eredeti kijelentést ténylegesen az exproducts:triple12345 azonosítja, és hasonlítsuk össze az eredeti kijelentést a tárgyiasult változatával: világosan látható hogy a tárgyiasítás ténylegesen leírja az eredeti kijelentést. Az RDF tárgyiasító szókészletének konvenció szerinti használata során mindig a fenti minta szerinti négy kijelentéssel (a "tárgyiasító négyes"-nek is nevezett kijelentésekkel) írunk le egy másik kijelentést.

A tárgyiasítás konvencionális használatával az example.com cég rögzíthetné pl. azt a tényt, hogy John Smith írta a fenti kijelentést a sátor súlyáról, oly módon, hogy először hozzárendelné az exproducts:triple12345 URI hivatkozást, mint az előbb, majd elvégezné az eredeti kijelentés tárgyiasítását a fentebb megadott módon, és végül, folytatva a tárgyiasítást, hozzá adna egy elemi kijelentést arról, hogy az exproducts:triple12345 URI-vel azonosított eredeti kijelentés szerzője (dc:creator) az exstaff:85740 alkalmazotti sorszámmal azonosított John Smith. Az eljárás során az alábbi kijelentéseket kellene leírnunk:

exproducts:triple12345   rdf:type        rdf:Statement .
exproducts:triple12345   rdf:subject     exproducts:item10245 . 
exproducts:triple12345   rdf:predicate   exterms:weight . 
exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .
exproducts:triple12345   dc:creator      exstaff:85740 . 

Az eredeti kijelentés, annak tárgyiasított változata, valamint az ehhez hozzáadott új kijelentés John Smith szerzőségéről, a 17. ábrán látható gráfot eredményezné:

17. ábra: Egy kijelentés, valamint a tárgyiasítása és a jellemzése

Ezt a gráfot, RDF/XML-ben, a 19. példában bemutatott módon írhatjuk le:

19. példa: A tárgyiasítási példa RDF/XML leírása

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:exterms="http://www.example.com/terms/"
            xml:base="http://www.example.com/2002/04/products">

  <rdf:Description rdf:ID="item10245">
     <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
  </rdf:Description>

  <rdf:Statement rdf:about="#triple12345">
     <rdf:subject rdf:resource="http://www.example.com/2002/04/products#item10245"/>
     <rdf:predicate rdf:resource="http://www.example.com/terms/weight"/>
     <rdf:object rdf:datatype="&xsd;decimal">2.4</rdf:object>

     <dc:creator rdf:resource="http://www.example.com/staffid/85740"/>
  </rdf:Statement>

</rdf:RDF>

A 3.2 szekció bemutatta az rdf:ID attribútum használatát RDF/XML-ben, amelynek segítségével egy rdf:Description elemben lerövidíthettük a kijelentés alanyát azonosító URI hivatkozást. Az rdf:ID azonban használható egy tulajdonság-elemben is, például arra, hogy automatikusan előállítsa annak a tripletnek a tárgyiasítását, amelyet a tulajdonság-elem generál. A 20. példa megmutatja, hogyan használhatjuk ki ezt a lehetőséget arra, hogy előállítsuk ugyanazt a gráfot, amelyet a 19. példában már előállítottunk:

20. példa: Tárgyiasítás generálása rdf:ID használatával

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:exterms="http://www.example.com/terms/"
            xml:base="http://www.example.com/2002/04/products">

  <rdf:Description rdf:ID="item10245">
     <exterms:weight rdf:ID="triple12345" rdf:datatype="&xsd;decimal">2.4
     </exterms:weight>
  </rdf:Description>

  <rdf:Description rdf:about="#triple12345">
     <dc:creator rdf:resource="http://www.example.com/staffid/85740"/>
  </rdf:Description>

</rdf:RDF>

Ebben a változatban az rdf:ID="triple12345" attribútum megadása az exterms:weight elemben azt az eredeti tripletet eredményezi, amelyik leírta a sátor súlyát:

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

valamint a tárgyiasításának tripletjeit:

exproducts:triple12345   rdf:type        rdf:Statement .
exproducts:triple12345   rdf:subject     exproducts:item10245 .
exproducts:triple12345   rdf:predicate   exterms:weight . 
exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

Ezeknek a tárgyiasító tripleteknek az alanya egy olyan teljes URIref, amely úgy alakul ki, hogy egybetoldjuk a bázis URI-t (amelyet az xml:base deklarációban adtunk meg) egy "#" karakterrel (ami jelzi, hogy erőforrásrész-azonosító következik), valamint az rdf:ID attribútum értékével; vagyis a tripleteknek ugyanaz lesz az alanyuk, mint az előző példákban: exproducts:triple12345.

Jegyezzük meg azonban, hogy a tárgyiasítás kijelentése nem azonos az eredeti kijelentéssel, és nem is implikálja azt. Ha ugyanis valaki azt mondja, hogy John mondott valamit a sátor súlyáról, az nem magáról a sátor súlyáról állít valamit, hanem arról, hogy John mondott valamit valamiről. Vagy megfordítva: amikor valaki leírja a sátor súlyát, az nem arról állít valamit, hogy ki, mit mondott.

A fenti szöveg nem véletlenül fogalmazott úgy, több helyen is, hogy a "tárgyiasítás konvenció szerinti használata". Mint már korábban megjegyeztük, óvatosságra van szükség, amikor a tárgyiasító szókészletet használjuk, mert könnyű úgy képzelni, hogy ezzel a szókészlettel valami olyan dolgot definiálunk, ami még nincs definiálva. Ha vannak olyan alkalmazások, amelyek sikeresen használják a tárgyiasítást, akkor ez azért van, mert bizonyos konvenciókat követnek, és olyan feltételezésekkel élnek, amelyek többletet jelentenek ahhoz a tényleges jelentéshez képest, amit az RDF definiál a tárgyiasító szókészletében, és többletet jelentenek azokhoz az eszközökhöz képest is, amelyeket ennek a szókészletnek a támogatásához az RDF nyújt.

Mindenekelőtt fontos megjegyezni, hogy a tárgyiasítás konvenciószerű használatánál a tárgyiasító tripletek alanyáról feltételezzük, hogy az egy konkrét tripletet azonosít egy konkrét RDF dokumentumban, és nem valamiféle tetszőleges tripletet, amelynek ugyanaz az alanya, az állítmánya és a tárgya. Ezt a konvenciót azért használjuk, mert a tárgyiasítást elsősorban olyan tulajdonságok kifejezésére szánták, mint pl. a kijelentés készítési dátuma, vagy az információ eredete (amire az eddigi példáinkban is használtuk), és az ilyen tulajdonságokat mindig meghatározott tripletekre alkalmazzuk. Létezhet több olyan triplet, amelynek ugyanaz az alanya, állítmánya és tárgya, és noha egy gráf mindig tripletek halmazaként van definiálva, ugyanaz a triplet-struktúra előfordulhat több különböző dokumentumban is. Hogy tehát ezt a konvenciót teljes mértékben támogassuk, kell valami olyan eszköz, amivel összekapcsolhatjuk a tárgyiasító tripletek alanyát egy meghatározott triplettel valamelyik dokumentumban. Az RDF azonban nem ad ehhez támogatást.

A fenti példákban például nincs olyan explicit információ (sem a tripletekben, sem az RDF/XML kódban), amely jelezné, hogy az eredeti kijelentés, amelyik leírja a sátor súlyát, ténylegesen az az exproducts:triple12345 nevű erőforrás, amelyet a négy tárgyiasító kijelentésnek, valamint annak az ötödik kijelentésnek az alanyaként adtunk meg, amely John Smith szerzőségéről szól. Ez rögtön kiderül, ha ránézünk a 17. ábrán felrajzolt gráfra. Az eredeti kijelentés természetesen része ennek a gráfnak, de ami a gráfban szereplő információt illeti, az exproducts:triple12345 egy külön erőforrás, és a gráfnak nem ezt a részét azonosítja. Az RDF-ben nincs olyan beépített lehetőség, amellyel jelezni lehetne, hogy egy olyan URIref, mint az exproducts:triple12345 össze van kapcsolva egy konkrét kijelentéssel vagy gráffal, azon túl, hogy van egy olyan beépített lehetősége, amellyel jelezni tudjuk, hogy egy olyan URIref, mint az exproducts:item10245 miként kapcsolódik egy tényleges sátorhoz. Ez azt jelenti, hogy egy meghatározott URIref-nek valamilyen specifikus erőforráshoz (esetünkben egy kijelentéshez) való kapcsolását valamilyen RDF-en kívüli mechanizmussal kell megoldani.

Az rdf:ID-nek a 20. példában bemutatott használata automatikusan generálja a tárgyiasítást, és megfelelő lehetőséget nyújt arra is, hogy megnevezzük azt az URI hivatkozást, amelyet a tárgyiasító kijelentések alanyaként kívánunk használni. Sőt ez még egyfajta "csáklyát" is jelent, ami összekapcsolja a tárgyiasító tripleteket azzal az RDF/XML kódrésszel, amelyik ezeket a tripleteket generálja, minthogy az rdf:ID attribútum triple12345 értékéből áll elő az az URIref is, amely a tárgyiasító tripletek alanyát azonosítja. Ismételten hangsúlyozzuk azonban, hogy ez a viszony szintén csak az RDF-en kívül létezik, mivel semmi nincs a generált tripletekben, ami explicit módon kimondaná, hogy az eredeti triplet URI hivatkozása az exproducts:triple12345. (Az RDF ugyanis nem feltételezi, hogy valamilyen viszony van egy URIref és egy olyan RDF/XML kódrész között, amelyben ezt – akár teljes hosszban, akár rövidített formában – használják.)

Egy olyan beépített eszköz hiánya, amellyel URI hivatkozásokat tripletekhez (kijelentésekhez) lehet asszociálni, nem jelenti azt, hogy efféle "származási" információkat nem lehet kifejezni RDF-ben, hanem csak azt, hogy ezt nem lehet megtenni pusztán arra a jelentésre alapozva, amelyet az RDF maga asszociál a tárgyiasító szókészletéhez. Például: ha egy RDF dokumentumnak (mondjuk, egy weblapnak) van egy URI-je, akkor kijelentéseket tehetünk arról az erőforrásról, amelyet ez az URI azonosít, majd pedig, alapozva arra az alkalmazásfüggő, "külső tudásra", hogy miként kell ezeket a kijelentéseket értelmezni, az alkalmazás értelmezheti pl. úgy, hogy ezek a kijelentések a dokumentum összes állítására vonatkoznak. Ugyanígy, ha létezne valamilyen mechanizmus (az RDF-en kívül) arra, hogy URI hivatkozásokat kapcsoljunk egyedi RDF kijelentésekhez, akkor bizonyára tehetnénk kijelentéseket ezekről az egyedi kijelentésekről is az őket azonosító URI-k segítségével. Ilyen esetekben azonban nem lenne feltétlenül szükséges konvenciószerűen használni a tárgyiasító szókészletet.

Hogy bemutassuk ezt, tekintsük ismét az eredeti kijelentésünket a sátor súlyáról:

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

Ha ennek a kijelentésnek az azonosítása céljából hozzá kapcsolhatnánk ehhez az exproducts:triple12345 URIref-et, akkor ennek a kijelentésnek a szerzőségét egyszerű módon John Smith-hez társíthatnánk a következő kijelentéssel:

exproducts:triple12345   dc:creator   exstaff:85740 .

És tehetnénk mindezt anélkül is, hogy használnánk a tárgyiasító szókészletet (bár annak a leírásához, hogy az exproducts:triple12345 URIref által azonosított dolog típusa: "kijelentés" (rdf:type = rdf:Statement), nem lenne haszontalan a szókészlet alkalmazása).

Emellett, a tárgyiasító szókészletet közvetlenül is használhatnánk, a fentebb definiált konvenciónak megfelelően, azzal az alkalmazásfüggő tudással kombinálva, hogy miként kell egyes tripleteket a tárgyiasulásukhoz kapcsolni. Ilyenkor azonban azok az alkalmazások, amelyek megkapják az ilyen RDF kódot, nem szükségszerűen rendelkeznek ugyanezzel az alkalmazásfűggő tudással, és így nem feltétlenül interpretálnák helyesen annak a gráfjait.

Azt is fontos megjegyezni, hogy a tárgyiasítás imént leírt értelmezése nem azonos az "idézet" fogalmával, amelyet egyes számítógép-nyelvekben használnak. A tárgyiasítás ugyanis egy viszonyt ír le egy konkrét triplet és azon erőforrások között, amelyekre a triplet hivatkozik. Tehát intuitív módon, valahogy így kellene olvasnunk a tárgyiasítást: "ez az RDF triplet ezekről a dolgokról szól", és nem úgy, ahogy az idézet teszi: "ennek az RDF tripletnek ez a formája". Így tehát az alábbi tárgyiasítási példa:

exproducts:triple12345   rdf:subject   exproducts:item10245 .

amelyet már használtunk ebben a szekcióban, és amelyik az eredeti kijelentés alanyát írja le, azt mondja ki (az rdf:subject tulajdonság révén), hogy a kijelentés alanya az az erőforrás (a sátor), amelyet az exproducts:item10245 URIref azonosít. Nem azt mondja tehát, hogy a kijelentés alanya maga az URIref (azaz egy olyan karakterlánc, amelyik bizonyos karakterekből áll), ahogyan ezt az "idézet" teszi.

4.4 További ismeretek a strukturált értékekről: rdf:value

A 2.3 szekcióban már szó volt arról, hogy az RDF modell csak bináris relációkat képes leírni a beépített lehetőségeivel; azaz, egy kijelentés csak két erőforrás között állapíthat meg valamilyen viszonyt. Például az alábbi kijelentés:

exstaff:85740   exterms:manager   exstaff:62345 .

azt mondja, hogy az "igazgatója" (exterms:manager) viszony áll fenn két alkalmazott között (feltehetően az egyik igazgatja a másikat).

Bizonyos esetekben azonban olyan információkat kell ábrázolnunk, amelyekben kettőnél több erőforrás között kell a viszonyokat leírnunk, vagyis, kettőnél több ágú (azaz magasabb "aritású") relációkat kell kezelnünk RDF-ben. A 2.3. szekció már bemutatott erre egy példát, ahol az volt a probléma, hogy ábrázolnunk kell a viszonyt John Smith és a lakáscíme között, és ahol John címe egy strukturált érték volt, mely utcanévből, városnévből, az állam nevéből és az irányítószámból állt. Ha ezt az információt reláció formájában akarjuk leírni, akkor láthatjuk, hogy itt már egy n-áris (több ágú, angolul: n-ary) relációról van szó, ahol n=5:

address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730")

A 2.3 szekcióban már megjegyeztük, hogy az ilyen jellegű strukturált információt úgy ábrázoljuk RDF-ben, hogy ezt az összetett dolgot (azaz John címét) egy önálló erőforrásnak tekintve írjuk le úgy, hogy több külön kijelentést teszünk erről az új erőforrásról, ahogy az alábbi tripletek mutatják:

exstaff:85740   exterms:address        _:johnaddress .
_:johnaddress   exterms:street         "1501 Grant Avenue" .
_:johnaddress   exterms:city           "Bedford" .
_:johnaddress   exterms:state          "Massachusetts" .
_:johnaddress   exterms:postalCode     "01730" .

(Itt _:johnaddress egy ürescsomópont-azonosító, mely John címét reprezentálja.)

Az RDF-ben bármilyen n-áris reláció ábrázolásának ez a szokásos módja: válaszd a résztvevők egyikét az eredeti bináris reláció (esetünkben az address) alanyának (esetünkben ez John), majd specifikálj egy közbülső (akár üres, akár URI-vel azonosított) erőforrást (esetünkben ez _:johnaddress), mely az eredeti bináris reláció tárgyaként, s egyszersmind egy sor újabb bináris reláció alanyaként is funkcionál, amelyek az n-áris reláció további komponenseit (esetünkben a cím elemeit) ábrázolják a tulajdonságok és értékeik megadásával.

John címe esetében a strukturált érték egyetlen egyedi részét sem tekintjük a cím (exterms:address) tulajdonság "fő" értékének; minden rész azonos mértékben járul hozzá az összetett érték kialakításához. Egyes esetekben azonban a strukturált érték összetevőinek egyikét "fő" értéknek kell tekintenünk, míg a többi összetevők kiegészítő jellegű kontextuális, vagy egyéb információt szállítanak, amelyek minősítik a fő értéket. Például a 3.2 szekció által bemutatott 9. példában egy meghatározott sátortípus súlyaként a 2.4 decimális értéket adtuk meg tipizált literál segítségével:

exproduct:item10245   exterms:weight   "2.4"^^xsd:decimal .

Valójában, a súly kielégítő leírása 2.4 kilogramm volna, hiszen a 2.4 szám a mértékegység nélkül nem pontosan specifikálja a súlyt. Hogy ezt is megadhassuk, az exterms:weight (súly) tulajdonságnak két komponensből kellene állnia: a decimális érték tipizált literáljából, valamint a mértékegység (kilogramm) jelzéséből. Ilyen esetben a decimális értéket az exterms:weight tulajdonság "fő" értékének kell tekintenünk, hiszen ezt az értéket legtöbbször egyetlen tipizált literállal adják meg (mint a fenti tripletben is), és rábízzák az ezeket használó programokra, vagy felhasználókra, hogy a hiányzó mértékegységet a kontextus alapján "derítsék ki".

Az RDF modellben az efféle minősített tulajdonságértéket egyszerűen egy másfajta strukturált értéknek tekintjük. Hogy ezt ábrázolhassuk, egy külön erőforrást használunk a strukturált értéknek mint egésznek az ábrázolására, mely az eredeti kijelentés (exterms:weight) tárgyaként jelenik meg. Ehhez az erőforráshoz azután olyan tulajdonságokat rendelünk, amelyek a strukturált érték részeit ábrázolják. Esetünkben kell egy tulajdonság a decimális értéket reprezentáló tipizált literál megadására, és kell egy másik tulajdonság a mértékegység leírására. Az RDF-ben van egy előre definiált tulajdonság, az rdf:value, amelyik a strukturált adat fő értékének leírására szolgál (ha van ilyen). Így tehát, esetünkben, a súlyt ábrázoló tipizált literált az rdf:value értékeként adhatjuk meg, míg a súlyegységet (exunits:kilograms) a mértékegység (exterms:units) tulajdonság értékeként (feltéve persze, hogy az itt említett három kifejezést már definiálták az example.org saját szókészletében). Ha ezek a feltételek fennállnak, akkor az eredményül kapott tripletek az alábbiak lesznek:

exproduct:item10245   exterms:weight   _:weight10245 .
_:weight10245         rdf:value        "2.4"^^xsd:decimal .
_:weight10245         exterms:units    exunits:kilograms .

Ugyanezt az RDF/XML használatával a 21. példában leírt módon fejezhetjük ki:

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:exterms="http://www.example.org/terms/">

  <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
     <exterms:weight rdf:parseType="Resource">
       <rdf:value rdf:datatype="&xsd;decimal">2.4</rdf:value>
       <exterms:units rdf:resource="http://www.example.org/units/kilograms"/>
     </exterms:weight>
  </rdf:Description>

</rdf:RDF>

A 21. példa illusztrálja a 4.2. szekcióban ismertetett rdf:parseType attribútumnak egy újabb alkalmazását, ahol az értéke ezúttal nem "Collection", hanem "Resource". Az rdf:parseType="Resource" típusú attribútumot annak jelzésére használjuk, hogy az ilyen attribútumú elem tartalmának elemzésekor (parsing) azt egy új erőforrás (Resource) leírásának (egy üres csomópontnak) kell értelmezni anélkül, hogy megadnánk egy beágyazott rdf:Description elemet. Esetünkben az exterms:weight tulajdonság-elemben használt rdf:parseType="Resource" attribútum azt jelzi, hogy egy üres csomópontot kell kreálni az exterms:weight tulajdonság értékeként, és hogy a két közrefogott elem (az rdf:value és az exterms:units) ezt az üres csomópontot írja le. (Az [RDF-SZINTAXIS] dokumentumban további részletek találhatók az rdf:parseType="Resource" attribútumról.)

Ugyanezt a módszert használjuk akkor is, ha bármilyen más mértékegységben megadott mennyiséget ábrázolunk, és akkor is, ha az ábrázolandó értékeket különböző osztályozó vagy minősítő rendszerekből vesszük: minden esetben az rdf:value tulajdonsággal adjuk meg a fő értéket, a további tulajdonságokkal pedig egyéb olyan információkat adunk meg, amelyek szükségesek a fő érték pontos értelmezéséhez (pl. ezekkel azonosíthatjuk az osztályozó/minősítő sémát).

Nem kötelező azonban az rdf:value tulajdonságot használni erre a célra; pl. egy olyan, felhasználó által definiált tulajdonságnevet is használhattunk volna a 21. példában, mint exterms:amount, az rdf:value helyett, hiszen az RDF nem társít semmilyen speciális jelentést ehhez a névhez. Ez csupán egy kényelmi eszköz egy gyakran előforduló leírási szituáció megoldására.

Tény, hogy ma még, a különböző adatbázisokban, a weben (sőt még a későbbi példáinkban is) többnyire a legegyszerűbb formában vannak megadva az olyan tulajdonságok értékei, mint a súly, a fogyasztói ár stb. Mégis hangsúlyoznunk kell azt az alapelvet, hogy az értékek ilyen egyszerűsített megadása gyakran nem elegendő ahhoz, hogy pontosan leírják a tulajdonságot. Egy olyan globális környezetben, mint a Web, általában nem biztonságos azzal a feltételezéssel élni, hogy aki elolvassa egy tulajdonság értékét, az feltétlenül érti is, hogy milyen egységben van az megadva, vagy hogy ismeri azokat a környezetfüggő információkat, amelyek az adat helyes értelmezéséhez szükségesek. Például az Egyesült Államokban egy webhely megadhat egy súlyértéket Fontban, ám egy más országbeli szörföző könnyen azt hiheti, hogy ez a súly Kilogrammban van megadva. A weben található adatok korrekt értelmezése tehát azt igényli, hogy az adatokkal együtt explicit módon megadjuk azok interpretációs adatait is (legalább a mértékegységüket). Ezt sokféle módon meg lehet valósítani: pl. az rdf:value mechanizmusának fentebb ismertetett használatával, a mértékegységnek a tulajdonság nevébe történő beépítésével (pl. exterms:weightInKg), specializált adattípusok definiálásával, amelyek mértékegység-információt is tartalmaznak (pl. extypes:kilograms), vagy éppen a felhasználó által definiált, olyan tulajdonságok megadásával, amelyekkel specifikálhatók az aktuálisan használt mértékegységek (pl. exterms:unitOfWeight). És az ilyen információközlést célszerű alkalmazni mind az egyes termékek leírásában, mind a nagyobb adathalmazok leírásában (mint pl. katalógus-adatok, vagy egy adott webhely adatai), mind pedig a sémákban (amelyekről az 5. fejezetben még szólunk).

5.1 Az osztályok leírása

Bármilyen leírási folyamatban az egyik alapvető lépés a leírandó dolgok különböző fajtáinak azonosítása. Az RDF Séma a "dolgok fajtáit" osztályoknak nevezi. Az RDF Sémában az osztály fogalma nagyjából megfelel a típus vagy a kategória általános fogalmának, és némileg hasonlít az olyan objektumorientált nyelvek osztályfogalmához, mint a Java. Az RDF osztályai a dolgok csaknem minden kategóriájának az ábrázolására alkalmasak, legyenek azok pl. weblapok, emberek, dokumentumtípusok, adatbázisok, vagy akár elvont fogalmak. Az osztályokat az rdfs:Class és az rdfs:Resource nevű RDF Séma erőforrások, valamint az rdf:type és az rdfs:subClassOf nevű tulajdonságok segítségével írhatjuk le.

Tételezzük fel, például, hogy egy szervezet, az example.org, arra szeretné használni az RDF-et, hogy információkat nyújtson különféle gépjárművekről. Ennek a cégnek a saját RDF sémájában (privát szókészletében) először is szüksége lesz egy olyan osztályra, amelyik a Gépjármű kategóriát képviseli. Azokat az erőforrásokat, amelyek valamilyen osztályhoz tartoznak, az osztály példányainak (instance) vagy egyedeinek (individual) nevezzük. Esetünkben az example.org cég ennek az osztálynak az egyedei alatt olyan erőforrásokat ért, amelyek mind gépjárművek.

Az RDF Sémában osztálynak tekintünk minden olyan erőforrást, amelyiknek a leírásában szerepel egy olyan rdf:type tulajdonság, amelynek az értéke az Osztály nevű erőforrás (rdfs:Class). Így tehát a gépjármű (motor vehicle) osztályt úgy írhatjuk le, hogy nevet adunk neki (pontosabban: hozzá rendelünk egy URI hivatkozást), mondjuk, az ex:MotorVehicle minősített nevet (ahol ex: a http://www.example.org/schemas/vehicles URI hivatkozás rövidítése, amely prefixként az example.org szókészletét azonosítja), majd pedig kijelentjük az így azonosított erőforrásról, hogy annak típusa (rdf:type) = Osztály (rdfs:Class). Az example.org tehát a következő RDF kijelentéssel definiálhatná ezt az új osztályt:

ex:MotorVehicle   rdf:type   rdfs:Class .

Mint már jeleztük a 3.2 szekcióban, az rdf:type tulajdonságot annak kijelentésére használjuk, hogy a vele jellemzett erőforrás valamely osztálynak az egyede. Így, ha az ex:MotorVehicle erőforrást már osztályként definiáltuk, akkor pl a "cégautó" (exthings:companyCar) nevű egyedi erőforrást RDF-ben így deklarálhatnánk gépjárműnek:

exthings:companyCar   rdf:type   ex:MotorVehicle .

(Ez a kijelentés használja azt az általános konvenciót, hogy az osztályneveket nagy kezdőbetűvel írjuk, a tulajdonságok és az egyedek nevét pedig kicsivel. Ennek a konvenciónak a betartását azonban sem az RDF, sem az RDF Séma nem várja el, és nem is ellenőrzi. A fenti kijelentés prefixei azt is elárulják, hogy az example.org úgy döntött, hogy külön-külön szókészletben definiálja az osztályokat és az egyedeket.)

Magának az rdfs:Class erőforrásnak a típusa szintén rdfs:Class. Egy erőforrás több osztálynak is lehet az egyede.

Az example.org, miután leírta az ex:MotorVehicle osztályt, definiálhat további osztályokat is, amelyek a gépjárművek különféle speciális csoportjait képviselik, mint pl. Személygépkocsi (Passanger Vehicle), Tehergépkocsi (Truck), Van, Mini-Van stb. Ezeket az osztályokat is ugyanúgy írja le, mint fentebb a Gépjármű osztályt (ex:MotorVehicle), vagyis mindegyiknek egy nevet (URI hivatkozást) ad, és egy-egy kijelentéssel osztálynak deklarálja őket, a következőképpen:

ex:Van     rdf:type   rdfs:Class .
ex:Truck   rdf:type   rdfs:Class .

és így tovább. De ezek a kijelentések, önmagukban, csak az egyes osztályokat írják le. Az example.org cég azonban jelölni akarja ezeknek a viszonyát a Gépjármű (ex:MotorVehicle) osztályhoz, mondván, hogy ezek nem egyebek, mint a Gépjármű specializált fajtái.

Az ilyen specializációs viszonyt, két osztály között, a beépített rdfs:subClassOf (alosztálya ~nak) tulajdonsággal írjuk le. [A tulajdonságnevek magyar fordításának olvasásakor a tilde karakter (~) helyére képzeljük a triplet tárgyát. Így a magyarra fordított tripletekben is fenntarthatjuk a tripletek eredeti szórendjét – a ford.]. Például, ha az example.org ki akarja jelenteni, hogy a Van egy speciális fajtája a Gépjárműnek, akkor az RDF Séma segítségével ezt így írja le:

ex:Van   rdfs:subClassOf   ex:MotorVehicle .

Ebben a kijelentésben az "alosztálya ~nak" (rdfs:subClassOf) viszony jelentése az, hogy az ex:Van osztály bármelyik egyede egyben az ex:MotorVehicle osztálynak is egyede. Így tehát, ha pl. az exthings:companyVan az ex:Van osztály egyik egyede, akkor az olyan szoftver, amelyik érti az RDF Séma szókészletét, a fenti rdfs:subClassOf reláció alapján ki tudja következtetni ebből azt, a mondatban egyébként explicite nem szereplő információt is, hogy az exthings:companyVan egy Gépjármű.

Ez az exthings:companyVan példa jól illusztrálja azt a korábbi megjegyzésünket, hogy az RDF Séma az RDF szemantikai kiterjesztését definiálja. Az RDF, maga, ugyanis nem definiálja az RDF Séma szókészletéből való ilyen kifejezések speciális jelentését, mint pl. az rdfs:subClassOf. Így, ha a cég RDF sémája definiálná az rdfs:subClassOf viszonyt az ex:Van és az ex:MotorVehicle között, akkor az olyan RDF szoftver, amelyik nem érti az RDF Séma kifejezéseit, felismerné ugyan, hogy ez egy triplet, amelynek az állítmánya rdfs:subClassOf, de nem értené ennek a speciális "mondanivalóját", és így nem is tudná "kitermelni" a mondatból azt a plusz információt, hogy az exthings:companyVan szintén egy gépjármű (lévén az ex:MotorVehicle osztály egyede).

Az rdfs:subClassOf tulajdonság tranzitív. Ez azt jelenti, hogy, ha például adott az alábbi két RDF kijelentés:

ex:Van       rdfs:subClassOf   ex:MotorVehicle .
ex:MiniVan   rdfs:subClassOf   ex:Van .

akkor az RDF Séma a tranzitivitás elve alapján, implicit módon, ezt a tripletet is definiálta: ex:MiniVan rdfs:subClassOf ex:MotorVehicle. A tranzivitás jelentése alapján tehát az RDF Sémát ismerő alkalmazás "rájöhet" arra, hogy azok az erőforrások, amelyek az ex:MiniVan osztály egyedei, nemcsak az ex:Van osztálynak, de az ex:MotorVehicle osztálynak is egyedei. Egy osztály egyszerre több osztálynak is lehet alosztálya (pl. a MiniVan osztály egyszerre lehet alosztálya a Van osztálynak és a Személygépkocsi osztálynak is). Az RDF Séma minden osztályt eleve az Erőforrás (rdfs:Resource) osztály alosztályaként értelmez (minthogy az összes osztály egyedei erőforrások).

A 18. ábra a teljes osztályhierarchiát mutatja, amelyet a fenti példákban tárgyaltunk:

18. ábra: A gépjárművek osztályhierarchiája

(Hogy egyszerűsítsük az ábrát, az rdf:type tulajdonságokat, amelyek minden osztályt az rdfs:Class osztályhoz kapcsoltak, kihagytuk a 18. ábrából. Valójában az RDF Séma minden olyan erőforrást, amelyik megjelenik az rdfs:subClassOf tulajdonság alanyaként vagy tárgyaként, eleve rdfs:Class típusú erőforrásnak tekint, ez tehát külön definíció nélkül is kikövetkeztethető. Amikor azonban valódi sémákat írunk, a helyes gyakorlat az, hogy mégis explicit módon megadjuk ezt az információt.)

A 18. ábrán látható séma tripletekkel is leírható:

ex:MotorVehicle       rdf:type          rdfs:Class .
ex:PassengerVehicle   rdf:type          rdfs:Class .
ex:Van                rdf:type          rdfs:Class .
ex:Truck              rdf:type          rdfs:Class .
ex:MiniVan            rdf:type          rdfs:Class .

ex:PassengerVehicle   rdfs:subClassOf   ex:MotorVehicle .
ex:Van                rdfs:subClassOf   ex:MotorVehicle .
ex:Truck              rdfs:subClassOf   ex:MotorVehicle .

ex:MiniVan            rdfs:subClassOf   ex:Van .
ex:MiniVan            rdfs:subClassOf   ex:PassengerVehicle .

A 23. példa azt mutatja, hogyan írnánk le ugyanezt a sémát RDF/XML-ben:

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdf:Description rdf:ID="MotorVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Truck">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Van">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="MiniVan">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>

</rdf:RDF>

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdfs:Class rdf:ID="MotorVehicle"/>

<rdfs:Class rdf:ID="PassengerVehicle">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Truck">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Van">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="MiniVan">
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdfs:Class>

</rdf:RDF>

A 23. és a 24. példában bemutatott RDF/XML leírás neveket vezet be (mint pl. MotorVehicle) az erőforrások (osztályok) számára, amelyeket az rdf:ID segítségével rendel az osztályokhoz, jelezve, hogy ezek a nevek relatív URI hivatkozások az éppen leírt sémadokumentumon belül, ahogyan ezt már a 3.2 szekcióban is láttuk. Az rdf:ID itt kétszeresen is hasznos, mert egyrészt rövidíti a hivatkozást, és emellett ellenőrzi azt is, hogy a segítségével megadott név egyedi-e az aktuális bázis-URI-vel azonosított dokumentumon belül. Ez segít észrevenni, ha véletlenül egynél többször definiálunk egy osztálynevet az adott RDF sémában. Az ilyen neveken alapuló relatív URI-kkel azután a sémadokumentumon belül más osztályokból, akárhányszor hivatkozhatunk ezekre az osztályokra, ahogyan pl. a #MotorVehicle relatív hivatkozást használtuk néhány osztály definíciójában. Ha az aktuális sémánk pl. a http://example.org/schemas/vehicles dokumentum lenne, akkor ennek az osztálynak a teljes URI hivatkozása így nézne ki: http://example.org/schemas/vehicles#MotorVehicle (ahogy a 18. ábra legfelső erőforrásánál is látható). Mint a 3.2. szekcióban már megjegyeztük: ahhoz, hogy a sémában szereplő osztályokra történő hivatkozás akkor is konzisztens maradjon, ha esetleg ugyanezt a sémát valamilyen okból két webhelyen is hozzáférhetővé kell tenni, vagy ha várható, hogy a részeit elosztva kell tárolni, akkor a sémát alkotó dokumentumok alkalmazhatnak egy explicit bázis-URI deklarációt, ami esetünkben xml:base="http://example.org/schemas/vehicles" lenne. (Az xml:base használata helyes gyakorlatnak tekinthető, ezért mi is használtuk ezt mindkét példánkban.)

Ha az example.org cég helyesen akar hivatkozni ezekre az osztályokra az egyedek RDF-ben történő leírásánál (pl. a fenti gépjármű-osztályokhoz tartozó egyedi járművek jellemzésénél) abban az esetben is, ha ezeket az osztályokat előzőleg más dokumentumban definiálta, akkor vagy teljesen kiírt abszolút (az aktuális bázis URI-n alapuló) URI hivatkozásokat kell használnia, vagy pedig olyan minősített nevekkel kell az osztályokra hivatkoznia, amelyek egy megfelelő névtérprefix-deklaráció révén ugyanezt az abszolút URI hivatkozást eredményezik. A 25. példánkban a "cégautó" (companyCar) nevű erőforrást a 24. példában definiált ex:MotorVehicle osztály egyedének deklaráljuk:

<?xml version="1.0"?>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:ex="http://example.org/schemas/vehicles#"
  xml:base="http://example.org/things">

   <ex:MotorVehicle rdf:ID="companyCar"/>

</rdf:RDF>

5.2 A tulajdonságok leírása

Amellett, hogy előre definiálni tudják azoknak a dolgoknak az osztályait, amelyeket majd később jellemezni szeretnének, a felhasználói közösségeknek szükségük van olyan lehetőségre is, hogy előre definiálhassák azokat a specifikus tulajdonságokat is, amelyekkel ezeket az osztályokat jellemezhetik. (Ilyen tulajdonság lehet pl. a Személygépkocsi osztályban a hátsó ülések előtt, az utasok lábai számára fenntartott terület nagysága, amelyről rearSeatLegRoom néven még többször lesz szó a további példáinkban). Az RDF Sémában a tulajdonságokat a Tulajdonság (rdf:Property) nevű RDF osztály, valamint az "érvényességi kör" (rdfs:domain) az "értéktartomány" (rdfs:range) és az "altulajdonsága ~nak" (rdfs:subPropertyOf) nevű RDF Séma tulajdonságok (más szóval: tulajdonságkorlátozások) használatával írjuk le. [A tulajdonságnevek magyar fordításának olvasásakor a tilde karakter (~) helyére képzeljük a triplet tárgyát. Így a magyarra fordított tripletekben is fenntarthatjuk a tripletek eredeti szórendjét – a ford.]

Az RDF-ben minden tulajdonságot az rdf:Property osztály egyedeként írunk le. Így, ha egy olyan új tulajdonságot definiálunk, mint pl. "kilogrammban mért súly" (exterms:weightInKg), akkor először is adunk neki egy ilyen nevet (pontosabban: hozzá rendelünk a fogalomhoz egy ilyen URI hivatkozást), majd pedig egy olyan rdf:type megadásával, amelynek értéke az rdf:Property osztály, tulajdonságként definiáljuk ezt az egyedet. A "kilogrammban mért súly" egyedi tulajdonság pl. az alábbi kijelentéssel definiálható:

exterms:weightInKg   rdf:type   rdf:Property .

Az RDF Séma egy olyan szókészletet is tartalmaz, amellyel leírhatjuk, hogy mely tulajdonságokat, mely osztályokkal összefüggésben kívánunk használni az RDF adatok leírásakor. A legfontosabb ilyen jellegű információt az "érvényességi köre" (rdfs:domain) illetve az "értéktartománya" (rdfs:range) RDF Séma tulajdonságokkal adhatjuk meg (ezeket tulajdonságkorlátozásoknak is nevezzük) .

Az rdfs:range tulajdonságot annak jelzésére használjuk, hogy egy adott tulajdonság értéke csak a megjelölt osztály valamelyik egyede lehet. Például, ha az example.org cég azt akarná jelezni, hogy a "szerzője" (ex:author) tulajdonság csak a Személy (ex:Person) osztály egyedei közül kerülhet ki, akkor az alábbi RDF kijelentéseket írná le:

ex:Person   rdf:type     rdfs:Class .
ex:author   rdf:type     rdf:Property .
ex:author   rdfs:range   ex:Person .

Ezek a kijelentések azt mondják, hogy az ex:Person egy osztály, az ex:author egy tulajdonság, valamint, hogy egy olyan jövőbeli RDF kijelentés, amelyik majd az ex:author tulajdonságot használja, ennek értékeként (azaz, a mondat tárgyaként) csak az ex:Person osztály valamelyik egyedét jelölheti meg.

Egy olyan tulajdonsághoz, mint pl. "anyja" (ex:hasMother), hozzárendelhetünk zéró, egy, vagy több "értéktartománya" tulajdonságkorlátozást. Ha nem adunk meg egyet sem, akkor ez azt jelenti, hogy nem kívánjuk korlátozni az "anyja" tulajdonság lehetséges értékeit. Ha megadunk egyet, mondjuk az ex:Person osztályt, akkor ezzel azt deklaráljuk, hogy az ex:hasMother tulajdonság lehetséges értékei az ex:Person osztály egyedei. Ha több értéktartományt adunk meg az ex:hasMother tulajdonság számára, mondjuk az ex:Person osztály mellett még az ex:Female (NőneműLény) osztályt is, akkor ezzel azt fejezzük ki, hogy az "anyja" tulajdonság értéke lehet bármi, ami Személy és ugyanakkor NőneműLény is.

ex:hasMother   rdfs:range   ex:Female .
ex:hasMother   rdfs:range   ex:Person .

exstaff:frank   ex:hasMother   exstaff:frances .

Az rdfs:range értéke nemcsak valamilyen felhasználó által definiált osztály lehet, hanem egy XML Séma adattípus is, mint pl. xsd:integer, mely történetesen az egész számok osztályát reprezentálja. (Az ilyen adattípusokat a 2.4. szekcióban a tipizált literálok ábrázolásával kapcsolatban már tárgyaltuk). Ha például az example.org cég azt akarná jelezni, hogy az "életkora" (ex:age) tulajdonság értéke csakis egész szám (vagyis az XML Séma adattípus xsd:integer osztályának egyik egyede) lehet, akkor az ex:age tulajdonságot így definiálná RDF-ben:

ex:age   rdf:type     rdf:Property .
ex:age   rdfs:range   xsd:integer .

Az xsd:integer adattípust az URI hivatkozásával azonosítjuk, amelynek teljes változata: http://www.w3.org/2001/XMLSchema#integer. Ez az URIref anélkül használható, hogy explicit módon kijelentenénk a sémában, hogy egy adattípust reprezentál. Mégis, gyakran hasznos explicit módon kijelenteni, hogy egy adott URIref valamilyen adattípust azonosít. Ezt az rdfs:Datatype nevű RDF Séma osztály használatával tehetjük meg. Ha az example.org ki akarná jelenteni, hogy az xsd:integer egy adattípus, akkor a következő RDF mondatot írhatná:

xsd:integer   rdf:type   rdfs:Datatype .

Ez a kijelentés azt mondja, hogy az xsd:integer egy olyan adattípus URI hivatkozása, amelyről feltételezzük, hogy megfelel az [RDF-FOGALMAK] dokumentumában leírt követelményeknek. Egy ilyen kijelentés nem jelent adattípus-definíciót (abban az értelemben, hogy az example.com egy új adattípust definiál). Az RDF Sémában nincs is lehetőség arra, hogy adattípusokat definiáljunk. Amint a 2.4 szekcióban már jeleztük, az adattípusok definiálása az RDF-en és az RDF Sémán kívül történik. Az RDF mondatokból csak hivatkozhatunk ezekre, az URIref-jeik segítségével. A fenti mondat pusztán csak arra szolgál, hogy dokumentálja az adattípus létezését, és jelezze, hogy ebben a sémában használni fogjuk azt.

Az "érvényességi köre" (rdfs:domain) RDF Séma tulajdonságot (más szóval: tulajdonságkorlátozást) annak jelzésére használjuk, hogy egy adott tulajdonság a megjelölt osztályra vonatkozik (vagyis, csak arra érvényes). Ha pl. az example.org cég azt szeretné jelezni, hogy a "szerzője" (ex:author) tulajdonság csak a Könyv (ex:Book) osztály egyedeire legyen érvényes, akkor a következő RDF kijelentéseket tenné:

ex:Book     rdf:type      rdfs:Class .
ex:author   rdf:type      rdf:Property .
ex:author   rdfs:domain   ex:Book .

Ezek a mondatok azt jelentik, hogy az ex:Book egy osztály, az ex:author egy tulajdonság, valamint, hogy az ex:author tulajdonság alanya csak az ex:Book osztály valamelyik egyede lehet (vagy másként kifejezve: az ex:author tulajdonság érvényességi köre az ex:Book osztály egyedeinek halmaza).

Egy adott tulajdonság, pl. a "súlya" ( exterms:weight), rendelkezhet zéró, egy, vagy több "érvényességi köre" (rdfs:domain) tulajdonságkorlátozással. Ha egyetlen ilyent sem adunk meg, akkor ez azt jelenti, hogy nem akarjuk korlátozni a tulajdonság érvényességi körét, tehát bármelyik erőforrásnak lehet "súlya" tulajdonsága. Ha csak egyetlen ilyen korlátozást adunk meg, amelyik pl. a Könyv osztályt jelöli meg e tulajdonság érvényességi körének, akkor ez a tulajdonság kizárólag a Könyv osztály egyedeire lesz alkalmazható. Ha azonban több korlátozást adnánk meg a "súlya" tulajdonságra, amelyek közül az egyik pl. a Könyv osztályt, a másik pedig a Gépjármű osztályt nevezné meg érvényességi körnek, akkor ezzel azt jelentenénk ki, hogy bármely erőforrás, amelynek lehet olyan tulajdonsága, hogy "súlya", az a Gépjármű osztálynak, és a Könyv osztálynak egyaránt egyede kell hogy legyen. (Ez utóbbi példa azt is illusztrálja, hogy mennyire óvatosnak kell lennünk az ilyen többszörös korlátozásokkal.)

Ugyanúgy mint az "értéktartománya" (rdfs:range) tulajdonságkorlátozás használatánál, itt is elsőre nehéz lehet elképzelni, miként adhatunk két különböző értéket az rdfs:domain tulajdonságnak, hogy deklaráljuk a kettős korlátozást. A magyarázat azonban itt is hasonló: két külön mondatban rendeljük az exterms:weight tulajdonsághoz a két rdfs:domain értéket:

exterms:weight   rdfs:domain   ex:Book .
exterms:weight   rdfs:domain   ex:MotorVehicle .

exthings:companyCar   exterms:weight   "2500"^^xsd:integer .

Az rdfs:range és az rdfs:domain tulajdonságkorlátozások leírása jól illusztrálható a "Gépjármű" sémánk olyan kiterjesztésével, hogy megadunk két gépjármű-tulajdonságot: a "tulajdonosa" és a "hátsóÜlésElőttiTérNagysága" (a példákban: ex:registeredTo, illetve ex:rearSeatLegRoom néven), valamint bevezetünk egy új osztályt "Személy" (ex:Person) néven, és leírjuk, hogy az xsd:integer-t mint adattípust fogjuk használni ebben a sémában. A "tulajdonosa" (ex:registeredTo) tulajdonságot úgy definiáljuk, hogy alanya csak az ex:MotorVehicle osztályból, értéke pedig csak az ex:Person osztályból származó erőforrás lehessen. Ebben példában az ex:rearSeatLegRoom tulajdonságot az ex:PassengerVehicle (Személygépkocsi) osztály egyedeire korlátozzuk, és ennek értéke egy egész szám (xsd:integer) típusú adat lesz, mely a "hátsóÜlésElőttiTérNagysága" tulajdonságot centiméterekben adja meg. Ezek a leírások a 26. példában láthatók.

<rdf:Property rdf:ID="registeredTo">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
  <rdfs:range rdf:resource="#Person"/>
</rdf:Property>

<rdf:Property rdf:ID="rearSeatLegRoom">
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="&xsd;integer"/>
</rdf:Property>

<rdfs:Class rdf:ID="Person"/>

<rdfs:Datatype rdf:about="&xsd;integer"/>

Figyeljük meg, hogy a 26. példában nem használunk <rdf:RDF> elemet, mert úgy tekintjük ezt a kis kódrészletet, hogy később beillesztjük a 24. példában szereplő Gépjármű séma szövegébe. Ugyanilyen alapon használunk relatív URI hivatkozást a sémában definiált ilyen osztályokra is, mint pl. a Gépjármű (MotorVehicle).

Az RDF Séma az osztályok mellett a tulajdonságok esetében is lehetővé teszi a specializációt. A specializációs viszonyt két tulajdonság között az előre definiált "altulajdonsága ~nak" (rdfs:subPropertyOf) RDF Séma tulajdonsággal írjuk le. Ha pl. a "segédvezetője" (ex:secondaryDriver) és a "vezetője" (ex:driver) egyaránt tulajdonságok, akkor az example.org cég a következőképpen definiálná ezt a két tulajdonságot és a kettejük közötti specializációs viszonyt (vagyis azt, hogy a "segédvezetője" tulajdonság a "vezetője" tulajdonság speciális esete):

ex:driver            rdf:type             rdf:Property .
ex:secondaryDriver   rdf:type             rdf:Property .
ex:secondaryDriver   rdfs:subPropertyOf   ex:driver .

Az rdfs:subPropertyOf viszony következménye itt az, hogy ha pl. azt mondjuk, hogy az exstaff:fred személy egyed az ex:companyVan gépjármű egyed "segédvezetője", akkor az RDF Séma implicit módon azt a kijelentést is generálja, hogy Fred "vezetője" is ennek a gépjárműnek. Azt az RDF/XML kódot, mely leírja ezeket a tulajdonságokat (ismét feltételezve, hogy ezt majd beépítjük a 24. példában látható sémába) a 27. példa mutatja:

<rdf:Property rdf:ID="driver">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
</rdf:Property>

<rdf:Property rdf:ID="secondaryDriver">
  <rdfs:subPropertyOf rdf:resource="#driver"/>
</rdf:Property>

Egy tulajdonság zéró, egy, vagy több tulajdonságnak is altulajdonsága lehet. Minden rdfs:range és rdfs:domain tulajdonságkorlátozás, amelyet valamely tulajdonságra megadunk, érvényes annak összes altulajdonságára is. Ezen összefüggés révén a fenti példa (implicit módon) azt is definiálja, hogy az ex:secondaryDriver tulajdonság érvényességi körébe (rdfs:domain) az ex:MotorVehicle is beletartozik, hiszen az ex:secondaryDriver tulajdonság az alosztály-reláció révén örökli az ex:driver tulajdonság korlátozásait.

A 28. példa mutatja azt az RDF/XML kódot, mely tartalmazza a Gépjármű sémánkhoz eddig megadott összes leírást:

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdfs:Class rdf:ID="MotorVehicle"/>

<rdfs:Class rdf:ID="PassengerVehicle">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Truck">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Van">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="MiniVan">
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Person"/>

<rdfs:Datatype rdf:about="&xsd;integer"/>

<rdf:Property rdf:ID="registeredTo">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
  <rdfs:range rdf:resource="#Person"/>
</rdf:Property>

<rdf:Property rdf:ID="rearSeatLegRoom">
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="&xsd;integer"/>
</rdf:Property>

<rdf:Property rdf:ID="driver">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
</rdf:Property>

<rdf:Property rdf:ID="secondaryDriver">
  <rdfs:subPropertyOf rdf:resource="#driver"/>
</rdf:Property>

</rdf:RDF>

Miután láttuk, hogy hogyan írjuk le az osztályokat és tulajdonságokat az RDF Séma segítségével, most már illusztrálhatjuk azokat az egyedeket is, amelyek az így definiált osztályokat és tulajdonságokat használják. A 29. példa leírja a 28. példából ismert Személygépkocsi osztály (ex:PassengerVehicle) egyik egyedét, néhány tulajdonságával együtt, amelyeknek itt most csak hipotetikus értékeket adunk.

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:ex="http://example.org/schemas/vehicles#"
            xml:base="http://example.org/things">

  <ex:PassengerVehicle rdf:ID="johnSmithsCar">
       <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
       <ex:rearSeatLegRoom 
           rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom>
       <ex:secondaryDriver rdf:resource="http://www.example.org/staffid/85740"/>
  </ex:PassengerVehicle>
</rdf:RDF>

Vegyük észre, hogy a "tulajdonosa" (ex:registeredTo) tulajdonság nyugodtan használható a Személygépkocsi osztálynak erre az egyedére (johnSmithsCar), mert a 28. példa sémájában a Személygépkocsi osztályt a Gépjármű osztály alosztályának definiáltuk, s ezért örökli a Gépjármű osztály tulajdonságkorlátait. Figyeljük meg azt is, hogy egy tipizált literált használunk az egyed "hátsóÜlésElőttiTérNagysága" (ex:rearSetLegRoom) tulajdonságának értékeként, ahelyett, hogy ezt az értéket az <ex:rearSeatLegRoom>127</ex:rearSeatLegRoom> típus nélküli literállal adtuk volna meg. Mivel a séma ennek a tulajdonságnak az értéktartományát xsd:integer-ként definiálta, ezért e tulajdonság értékeként csakis egy ennek az adattípusnak megfelelő tipizált literált fogad el az RDF. Egyéb információt is megadhatnánk (akár a sémában, akár az egyedet leíró dokumentumban) ennek az értéknek a további pontosítására: pl. az adat mértékegységét (centiméter), ahogyan azt a 4.4.szekcióban már részleteztük.

5.3 Az RDF sémadeklarációk értelmezése

Mint már korábban megjegyeztük, az RDF Séma típus-rendszere némely tekintetben hasonlít az olyan objektumorientált programozási nyelvek típus-rendszerére, mint pl. a Java. Az RDF azonban több lényeges kérdésben eltér a programozási nyelvek típus-rendszerétől.

Az egyik fontos eltérés, hogy ahelyett, hogy úgy írnánk le egy osztályt, mint amelyik rendelkezik egy sor tulajdonsággal, az RDF séma a tulajdonságokat írja le úgy (az érvényességi körük és az értéktartományuk segítségével), hogy azok az egyedek meghatározott osztályaira vonatkoznak. Egy tipikus objektumorientált rendszer például definiálna egy Könyv osztályt egy olyan attribútummal, mint pl. "szerzője", amelynek az értéke Személy típusú. Az ennek megfelelő RDF séma viszont előbb definiálna egy Könyv osztályt, majd egy külön leírásban definiálna egy "szerzője" tulajdonságot úgy, hogy ennek "érvényességi köre" a Könyv osztály, az "értéktartománya" pedig a Személy osztály lenne.

A két közelítés közötti különbség első pillantásra csak szintaktikai jellegűnek tűnik, ám valójában jelentős különbségről van szó. Egy programozási nyelv osztályleírásában a "szerzője" attribútum a Könyv osztály leírásának a része, és csak a Könyv osztály egyedeire érvényes. Egy másik osztálynak (mondjuk, a Szoftver Modulnak) szintén lehetne egy "szerzője" attribútuma, de ezt már különböző attribútumnak tekintenénk. Más szóval: egy attribútum-leírás szkópja (hatóköre) a legtöbb programozási nyelvben arra az osztályra korlátozódik, amelyikben definiálták. Ugyanakkor az RDF-ben a tulajdonságok eleve függetlenek az osztálydefinícióktól, és a hatókörük alapértelmezésben globális (szükség esetén azonban meghatározott osztály(ok)ra korlátozhatjuk ezeket az "érvényességi köre" és az "értéktartománya" RDF Séma tulajdonságok segítségével.)

Ennek megfelelően egy RDF séma leírhatna egy olyan tulajdonságot, mint pl. "súly" anélkül, hogy érvényességi kört definiálna a számára. Ezt a tulajdonságát azután használhatnánk bármelyik osztály egyedének a leírásához, amelyikről úgy gondoljuk, hogy van súlya. Az RDF tulajdonság alapú közelítésének egyik előnye az, hogy ezzel könnyebbé válik valamely tulajdonság használatának a kiterjesztése olyan helyzetekre is, amelyeket nem lehetett előre látni a tulajdonság eredeti deklarációja idején. Ugyanakkor ez egy olyan előny, amelyet csak körültekintően szabad kihasználni, hogy elkerüljük a nem megfelelő esetekre történő alkalmazását.

További következménye az RDF tulajdonságok globális hatókörének az, hogy egy RDF sémában nem lehet úgy definiálni egy adott tulajdonságot, hogy helyileg különböző értéktartománya legyen attól függően, hogy melyik osztályhoz tartozik az egyed, amelyre alkalmazzuk. Például a "szülője" tulajdonság definiálásánál kívánatos lenne, ha azt tudnánk deklarálni, hogy amikor ezt az Ember osztályhoz tartozó erőforrás leírására használjuk, akkor az értéktartománya is az Ember osztály legyen, amikor pedig egy Tigris osztályú egyed leírására használjuk, akkor az értéktartománya automatikusan a Tigris osztály legyen. Egy ilyenfajta definíció nem lehetséges az RDF Sémában. Ehelyett minden értéktartomány, amelyet egy RDF tulajdonságra megadunk, érvényes a tulajdonság minden egyes használatánál, s ezért az értéktartományok definiálása óvatosságot igényel. Noha az RDF Sémában nem lehet ilyen, helyileg különböző értéktartományokat definiálni, ez megvalósítható a gazdagabb sémanyelvekben, amelyeket az 5.5. szekcióban ismertetünk.

Ugyancsak fontos különbség, hogy az RDF Séma leírásai nem feltétlenül előírás jellegűek, abban az értelemben, ahogy a programozási nyelvek típusdeklarációi jellemzően azok. Ha például egy programozási nyelv definiál egy Könyv osztályt egy "szerzője" attribútummal, amelynek értékei Személy típusúak, akkor ezeket tipikusan szigorú korlátozásoknak értelmezi. Ezért az ilyen nyelv nem engedi meg, hogy úgy kreáljuk a Könyv osztály valamelyik példányát, hogy az ne rendelkezzék a "szerzője" attribútummal, és azt sem engedi meg, hogy egy ilyen példány "szerzője" attribútumának értéke ne Személy típusú legyen. Sőt, ha a "szerzője" az egyetlen attribútum, amelyet ehhez az osztályhoz deklaráltunk, akkor a nyelv azt sem engedi meg, hogy az osztálynak egy más attribútummal is rendelkező egyedét kreáljuk.

Az RDF Séma viszont lehetővé teszi, hogy a sémainformációk további adatokkal pontosítsák az erőforrások leírását, de nem írja elő, hogy ezeket a leírásokat hogyan kell használnia egy alkalmazásnak. Tegyük fel, például, hogy egy RDF séma azt definiálja, hogy a "szerzője" tulajdonság értéktartománya a Személy osztály. Ez az RDF kijelentés nem mond többet, csak annyit, hogy az olyan RDF állításokban, ahol a "szerzője" tulajdonság az állítmány, a kijelentés tárgya Személy típusú.

Ezt a sémainformációt különböző módokon lehet felhasználni. Az egyik alkalmazás értelmezheti a fenti állítást úgy, mint egy olyan RDF adatminta részét, amelynek megfelelő adatokat az alkalmazásnak elő kell állítania, és annak biztosítására használja az információt, hogy "szerzője" tulajdonság értéke mindig a Személy osztályból származzék. Vagyis, ez az alkalmazás a sémaleírást korlátozásként értelmezi, ahogyan ezt egy programozási nyelv is tenné. Egy másik RDF alkalmazás azonban interpretálhatja ezt az állítást úgy is, hogy az plusz információt nyújt arról az adatról amit kap: olyan információt, mely explicit módon nem szerepel az eredeti adatban. Ez a második alkalmazás például kaphat egy olyan adatot, amelyben szerepel egy "szerzője" tulajdonság, amelynek értéke egy ismeretlen osztályhoz tartozó egyed, és ilyenkor a sémainformáció alapján kikövetkeztetheti, hogy ez a Személy osztályhoz tartozik. Egy harmadik alkalmazás kaphat egy olyan RDF adatot, amelyben a "szerzője" tulajdonság tárgya a Testület osztályhoz tartozik, és ilyenkor arra használja a fenti állítást, hogy annak alapján kiad egy figyelmeztetést: "Ebben az adatban lehet, hogy inkonzisztencia van, de lehet, hogy nem". Másutt létezhet esetleg egy olyan további deklaráció, mely feloldja ezt kétséget azáltal, hogy kikövetkeztethető belőle: a Testület a szerzőség tekintetében a Személy osztályhoz tartozik (pl. azon az alapon, hogy a testület jogi személy).

Továbbá, attól függően, hogy miként interpretálja az alkalmazás a tulajdonságok leírásait, egy egyed leírása érvényesnek tekinthető akár néhány séma specifikálta tulajdonság nélkül is (pl. létezhet egy Könyv osztályú egyed "szerzője" tulajdonság nélkül akkor is, ha a "szerzője" tulajdonságra azt adták meg, hogy az "érvényességi köre" a Könyv osztály), de érvényesnek tekinthető az egyed leírása akkor is, ha hozzáadott tulajdonságokkal rendelkezik (létezhet pl. egy Könyv osztályú egyednek egy "szerkesztője" tulajdonsága akkor is, ha a Könyv osztályt eredetileg leíró séma még nem adott meg az osztály számára ilyen tulajdonságot).

Más szavakkal összefoglalva: az RDF Séma kijelentései mindig leírások. Ezek tekinthetők előírás jellegűeknek (azaz korlátozásoknak), de csak akkor, ha az ezeket értelmező alkalmazás ilyenként kívánja kezelni őket. Amit az RDF Séma nyújt, az nem más, mint egy lehetőség arra, hogy megadjuk ezeket a többletinformációkat. Annak megállapítása, hogy ez az új információ ütközik-e az explicit módon specifikált egyedi adatokkal, kizárólag az adott alkalmazástól függ (mint ahogy az is, hogy az alkalmazás miként reagál erre a megállapításra).

5.4 Egyéb sémainformációk

Az RDF Séma rendelkezik több más, beépített tulajdonsággal, amelyek dokumentálják, vagy kommentálják az RDF sémánkat, vagy az abban definiált egyedeket. Például a "kommentárja" (rdfs:comment) tulajdonság ember által olvasható módon írhatja le az erőforrást. A "címkéje" (rdfs:label) tulajdonság egy erőforrás nevének ember által olvashatóbb változatát adhatja meg. A "lásd továbbá" (rdfs:seeAlso) tulajdonság utalást jelent egy másik erőforrásra, mely további információt nyújthat az alanyként megadott erőforrásról. A "definiálja" (rdfs:isDefinedBy) tulajdonság a "lásd továbbá" (rdfs:seeAlso) tulajdonság altulajdonsága, és egy olyan erőforrás megjelölésére használható, amely valamilyen formában definiálja az alanyként megadott erőforrást. Azért használtuk itt a "valamilyen formában" kifejezést, mert előfordulhat, hogy az rdfs:isDefinedBy segítségével megnevezett erőforrás valamilyen RDF által nem specifikált értelemben definiálja az alanyt (pl. a megadott erőforrás esetleg nem egy RDF séma). Az RDF Szókészlet Leíró Nyelv 1.0: RDF Séma [RDF-SZÓKÉSZLET] dokumentum tárgyalja részletesen ezeket a tulajdonságokat.

Miként több beépített RDF tulajdonság (rdf:value stb.) használati leírása, ugyanúgy az RDF Séma tulajdonságok használati leírása is csupán ezek szándékolt használatát adja meg. Az [RDF-SZEMANTIKA] nem tulajdonít speciális jelentést ezeknek a tulajdonságoknak, és az RDF Séma sem definiál semmilyen korlátozást ezekre a tulajdonságokra a szándékolt használat alapján. Semmilyen szabály nem írja elő, például, hogy egy "lásd továbbá" tulajdonság köteles további információt nyújtani annak a kijelentésnek az alanyáról, amelyben megjelenik.

5.5 Gazdagabb sémanyelvek

Az RDF Séma biztosítja az alapvető eszközöket az RDF szókészletek leírására, de léteznek további olyan eszközök is, amelyek szintén hasznosak lehetnek. Ilyen eszközökhöz juthatunk az RDF Séma továbbfejlesztésével, vagy más olyan nyelvek alkalmazásával, amelyek az RDF-en alapulnak. Azok a további, gazdagabb sémaleíró lehetőségek, amelyekről tudjuk, hogy hasznosak, de amelyek nem szerepelnek az RDF Sémában, egyebek között az alábbiak lehetnek:

• kardinalitáskorlátozások specifikálása a tulajdonságokra, pl., hogy egy Személynek kizárólag egy "biológiai apja" lehet (a kardinalitás egy olyan tulajdonságkorlátozás, amely megadja, hogy egy adott a tulajdonságnak hány különböző értéke lehet).
• annak specifikálása, hogy egy adott tulajdonság (mint pl. "felmenője") tranzitív (vagyis, ha A "felmenője" B, és B "felmenője" C, akkor A "felmenője" C.)
• annak specifikálása, hogy egy adott tulajdonság egy adott osztály valamelyik egyedének egyedi azonosítója (vagy kulcsa) .
• annak specifikálása, hogy két olyan osztály, amelyik két különböző URI hivatkozással érhető el, ténylegesen ugyanazt az osztályt reprezentálja.
• annak specifikálása, hogy két olyan egyed, amelyik két különböző URI hivatkozással érhető el, ténylegesen ugyanazt az egyedet reprezentálja.
• egy tulajdonság értéktartományának vagy kardinalitásának helyi korlátozása arra az osztályra vagy erőforrásra, vonatkoztatva, amelyikkel kapcsolatban éppen definiáljuk. Erre azért van szükség, hogy képesek legyünk pl. ilyen korlátokat specifikálni: a "játékosa" tulajdonság a Futballcsapat erőforrás esetén 11-szer adható meg, 11 különböző értékkel, amely egy-egy játékost reprezentál, míg a Kosárlabda-csapat erőforrás esetén ez a szám csak 5 lehet.
• új osztályok leírása egy vagy több osztály halmazuniójaként vagy metszeteként, továbbá annak kijelentése, hogy két osztály diszjunkt (más szóval két idegen osztály, mert nincsenek közös egyedeik).

Az itt említett fejlettebb képességeket, sok más hasznos képességgel együtt, az olyan ontológianyelvek célozzák meg, mint a DAML+OIL [DAML+OIL] és az OWL [OWL]. E két nyelv mindegyike az RDF-en és az RDF Sémán alapszik (és jelenleg mindegyik tartalmazza a fentebb leírt plusz képességeket). Az ontológianyelvek célja, hogy további, géppel feldolgozható szemantikai információt kapcsoljanak az erőforrásokhoz, és ezáltal az erőforrások gépi ábrázolását jobban közelítsék azok való világbeli megfelelőihez. Noha az ilyen képességek nem feltétlenül szükségesek ahhoz, hogy hasznos alkalmazásokat készítsünk RDF-ben (a 6. fejezet bemutat egy sor létező RDF alkalmazást), mégis, az ilyen nyelvek fejlesztése nagyon aktív munkaterület a Szemantikus Web fejlesztésében.

6.1 A Dublin Core meta-adat kezdeményezés

A meta-adat nem más, mint adat az adatról. Konkrétabban ez a kifejezés olyan adatokat jelent, amelyeket erőforrások azonosítására, leírására és megkeresésére használunk, legyenek ezek az erőforrások akár fizikaiak, akár elektronikusak. Jóllehet, a számítógéppel feldolgozható strukturált meta-adatok viszonylag újak, a meta-adat alapkoncepcióját már sok éve használjuk a nagy információgyűjtemények kezelésének és használatának segítésére. (A könyvtárak kártyakatalógusai ismert példái a meta-adatoknak.)

A Dublin Core ("a dublini mag") tulajdonképpen "elemek" (tulajdonságok) egy halmaza, dokumentumok leírása, vagyis meta-adatok rögzítése céljára. Az elemek halmazát eredetileg az Ohio állambeli Dublin-ban, 1995-ben megrendezett első Meta-adat Műhelykonferencián fejlesztették ki, majd későbbi ilyenek rendezvények során tovább tökéletesítették, jelenleg pedig a Dublin Core Metadata Initiative nevű szervezet tartja karban. A Dublin Core célja szabványos adatleíró elemek egy olyan minimális halmazának a biztosítása, amely lehetővé teszi az Interneten tárolt, dokumentum jellegű objektumok leírását és automatikus indexelését, a könyvtári kártyakatalógusok analógiájára. A Dublin Core meta-adathalmazt úgy alakították ki, hogy alkalmas legyen az Internet olyan erőforrás felfedező eszközeivel történő feldolgozásra, mint a népszerű World Wide Web keresőrendszerek által alkalmazott "webcrawlerek". Emellett a Dublin Core-t igyekeztek úgy összeállítani, hogy a legkülönbözőbb szerzők és eseti publikálók, akik a weben adják közre az anyagaikat, könnyen megérthessék és egyszerű módon használhassák azt. A Dublin Core (dc) elemeket ma már széles körben használják az internetes erőforrások dokumentálásában (ezek közül a creator elemet már a korábbi példáinkban is használtuk). A Dublin Core jelenlegi elemeit a DC Meta-adat Elemhalmaz definiálja, amelyet a Dublin Core Metadata Element Set, Version 1.1: Reference Description [DC], hipertext hivatkozáson keresztül érhetünk el, és az alábbi tulajdonságok definícióit tartalmazza:

• Title (Címe): A dokumentum jellegű erőforrás neve.
• Creator (Szerzője): Az az entitás (személy vagy szervezet), mely elsődlegesen felelős az erőforrás tartalmának elkészítéséért.
• Subject (Témája): Az erőforrás tartalmának a tárgya.
• Description (Leírása:) Az erőforrás tartalmának összefoglalása.
• Publisher (Kiadója): Az az entitás (személy vagy szervezet), mely felelős az erőforrás nyilvánosságra hozásáért.
• Contributor (Társszerzője): Egy olyan entitás (személy vagy szervezet), amely munkájával hozzájárult az erőforrás tartalmának létrehozásához.
• Date (Dátuma): Az erőforrás életciklusának valamely eseményéhez kapcsolódó időpont.
• Type (Típusa): Az erőforrás tartalmának természete, jellege vagy zsánere.
• Format (Formátuma): Az erőforrás fizikai vagy digitális megjelenési formája.
• Identifier (Azonosítója): Egy egyértelmű hivatkozás az erőforrásra az adott kontextuson belül.
• Source (Forrás): Hivatkozás egy olyan erőforrásra, ahonnan a jelenlegi erőforrás eredetileg származik.
• Language (Nyelve): Az a nyelv, amelyen az erőforrás szellemi tartalma megjelenik.
• Relation (Kapcsolata): Hivatkozás egy, a leírt erőforráshoz kapcsolódó másik erőforrásra.
• Coverage (Lefedése): Az erőforrás tartalmának tematikai/területi átfogása.
• Rights (Szerzői és egyéb jogok): Információ azokról a jogokról, amelyek az erőforráshoz fűződnek, vagy rajta keresztül keletkeznek.

A Dublin Core (DC) elemeket használó információkat bármilyen alkalmas nyelven (pl. HTML meta elemek segítségével is) megadhatjuk. Az RDF mindenesetre ideális eszköz a DC információ ábrázolására. Az alábbi példák egy sor erőforrás egyszerű leírását mutatják be a DC szókészlet felhasználásával (megjegyzendő azonban, hogy az itt bemutatott DC szókészlet nem a hivatalos változat. A hivatalos változatot a DC referencia-anyag (Dublin Core Reference Description [DC] ) tartalmazza.

Az első DC példánk (a 30. példa ), egy webhely honlapját írja le a DC elemeinek segítségével:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <rdf:Description rdf:about="http://www.dlib.org">
      <dc:title>D-Lib Program - Research in Digital Libraries</dc:title>
      <dc:description>The D-Lib program supports the community of people
       with research interests in digital libraries and electronic
       publishing.</dc:description>
      <dc:publisher>Corporation For National Research Initiatives</dc:publisher>
      <dc:date>1995-01-07</dc:date>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>Research; statistical methods</rdf:li>
          <rdf:li>Education, research, related topics</rdf:li>
          <rdf:li>Library use Studies</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:type>World Wide Web Home Page</dc:type>
      <dc:format>text/html</dc:format>
      <dc:language>en</dc:language>
    </rdf:Description>
</rdf:RDF>

Figyeljük meg, hogy az RDF, ugyanúgy, mint a Dublin Core, használ egy XML elemet, amelyet "leírásnak" (Description) nevez, bár a DC esetén ezt kisbetűvel írják. (De még ha nagy kezdőbetűvel is írnák a DC "description" tegjét, az XML névtér-mechanizmusa akkor is lehetővé tenné a két elem megkülönböztetését, hiszen az egyiket rdf:Description, a másikat dc:description formában írjuk. Ha az olvasót érdekli, egy Web-böngésző segítségével elérheti a [DC] RDF-es deklarációját a http://purl.org/dc/elements/1.1/ hivatkozáson keresztül, mely egyben a példánkban használt DC szókészlet névtér URI-je is. – Mindenesetre, a könyvünk írásakor ez még elérhető volt ezen a webhelyen).

Második DC példánk, a 31. példa, leír egy rendszeresen publikált magazint:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
    <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/05contents.html">
      <dc:title>DLIB Magazine - The Magazine for Digital Library Research
        - May 1998</dc:title>
      <dc:description>D-LIB magazine is a monthly compilation of
       contributed stories, commentary, and briefings.</dc:description>
      <dc:contributor>Amy Friedlander</dc:contributor>
      <dc:publisher>Corporation for National Research Initiatives</dc:publisher>
      <dc:date>1998-01-05</dc:date>
      <dc:type>electronic journal</dc:type>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>library use studies</rdf:li>
          <rdf:li>magazines and newspapers</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:format>text/html</dc:format>
      <dc:identifier rdf:resource="urn:issn:1082-9873"/>
      <dcterms:isPartOf rdf:resource="http://www.dlib.org"/>
    </rdf:Description>
 </rdf:RDF>

A 31. példában, alulról a harmadik sorban megadtunk egy minősítő tulajdonságot (qualifier-t) egy külön szókészletből, isPartOf néven, annak jelölésére, hogy a jelen magazin az előző példában definiált webhely "része".

A harmadik DC példánk, a 32. példa, leír egy konkrét cikket a 31. példában meta-adatolt magazinból:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
    <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/miller/05miller.html">
      <dc:title>An Introduction to the Resource Description Framework</dc:title>
      <dc:creator>Eric J. Miller</dc:creator>
      <dc:description>The Resource Description Framework (RDF) is an
       infrastructure that enables the encoding, exchange and reuse of
       structured metadata. rdf is an application of xml that imposes needed
       structural constraints to provide unambiguous methods of expressing
       semantics. rdf additionally provides a means for publishing both
       human-readable and machine-processable vocabularies designed to
       encourage the reuse and extension of metadata semantics among
       disparate information communities. the structural constraints rdf
       imposes to support the consistent encoding and exchange of
       standardized metadata provides for the interchangeability of separate
       packages of metadata defined by different resource description
       communities. </dc:description>
      <dc:publisher>Corporation for National Research Initiatives</dc:publisher>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>machine-readable catalog record formats</rdf:li>
          <rdf:li>applications of computer file organization and
           access methods</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:rights>Copyright Š 1998 Eric Miller</dc:rights>
      <dc:type>Electronic Document</dc:type>
      <dc:format>text/html</dc:format>
      <dc:language>en</dc:language>
      <dcterms:isPartOf rdf:resource="http://www.dlib.org/dlib/may98/05contents.html"/>
    </rdf:Description>
</rdf:RDF>

A 32. példa is használja az isPartOf qualifier-t, de ez alkalommal azt jelezzük vele, hogy a cikk a fentebb leírt magazin része ("part of").

<?xml version="1.0"?>
<svg width="4in" height="3in" version="1.1"
    xmlns = 'http://www.w3.org/2000/svg'>
    <desc xmlns:myfoo="http://example.org/myfoo">
      <myfoo:title>This is a financial report</myfoo:title>
      <myfoo:descr>The global description uses markup from the
        <myfoo:emph>myfoo</myfoo:emph> namespace.</myfoo:descr>
      <myfoo:scene><myfoo:what>widget $growth</myfoo:what>
      <myfoo:contains>$three $graph-bar</myfoo:contains>
        <myfoo:when>1998 $through 2000</myfoo:when> </myfoo:scene>
   </desc>
    <metadata>
      <rdf:RDF
           xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc = "http://purl.org/dc/elements/1.1/" >
        <rdf:Description rdf:about="http://example.org/myfoo"
             dc:title="MyFoo Financial Report"
             dc:description="$three $bar $thousands $dollars $from 1998 $through 2000"
             dc:publisher="Example Organization"
             dc:date="2000-04-11"
             dc:format="image/svg+xml"
             dc:language="en" >
          <dc:creator>
            <rdf:Bag>
              <rdf:li>Irving Bird</rdf:li>
              <rdf:li>Mary Lambert</rdf:li>
            </rdf:Bag>
          </dc:creator>
        </rdf:Description>
      </rdf:RDF>
    </metadata>
</svg>

6.2 PRISM

A folyóiratok kiadásával foglalkozó szervezetek is kidolgozták a maguk metaadat-specifikációját PRISM: Publishing Requirements for Industry Standard Metadata [PRISM] néven. A folyóirat-kiadó cégek és a termékeik forgalmazói megalapították a PRISM munkacsoportot (PRISM Working Group), hogy felmérjék a szakma metaadat-rögzítési igényeit, és egy olyan specifikációt definiáljanak, mely megfelel ezeknek az igényeknek. A kiadók sokféle módon szeretnék felhasználni a meglévő tartalmat annak érdekében, hogy jobban megtérüljenek a befektetéseik. Egyik példája ennek a magazinok cikkeinek HTML-re történő konvertálása abból a célból, hogy azok az Interneten keresztül is publikálhatók legyenek. Egy másik példa a cikkek publikációs licenceinek eladása tematikus cikkgyűjtemélyeket kiadó, olyan cégek számára, mint pl. a LexisNexis. Ezek mind "első publikálói" a tartalomnak, hiszen tipikusan az eredeti magazinok megjelenésével egy időben publikálják a megvásárolt cikkeket. A kiadók azt is szeretnék, hogy az általuk egyszer már publikált tartalom "örökzöld" maradna, vagyis ha új kiadásokban is használni lehetne azt, pl. retrospektív cikkek formájában. Emellett a régi tartalmat a kiadók szeretnék újra felhasználni más üzleti területeiken is, például olyan anyagok könyv formában történő megjelentetésénél, mint pl. fotók, receptek stb. Egy másik lehetséges alkalmazás az, amikor valamilyen korlátozott licencként kiadják az anyagaikat kívülállóknak, pl. reprint kiadási vagy recenzálási célokra, esetleg egy másik kiadónál történő retrospektív megjelentetésre. Ezek az általános célok egy olyan meta-adat rendszert igényelnek, amelyek a hangsúlyt az erőforrások felfedezésére, a jogok nyomon követésére, valamint a meta-adatok folyamatos megőrzésére fekteti. Ezeket a célokat az alábbiakban röviden ismertetjük:

Az erőforrások felfedezése: Ez egy általános kifejezés a tartalom megtalálásának folyamatára, mely magában foglalja a keresést, a böngészést, a tartalom irányítását és más technikákat is. Amikor a felfedezés kérdése kerül szóba, elsősorban a nyilvános webhelyeknek a fogyasztók általi megtalálására gondolunk. A tartalom felfedezése azonban ennél jóval szélesebb fogalmat takar. A közönség ugyanis a fogyasztók mellett olyan belső felhasználókat is magában foglal, mint a kutatók, a tervezők, a fotószerkesztők, a licenc-ügynökök stb. A PRISM, hogy növelje a felfedezés valószínűségét, olyan tulajdonságokat definiál, amelyekkel leírható az erőforrások témája, formátuma, jellege, eredete és kontextusa. De eszközöket biztosít az erőforrások kategorizálására is, tematikus taxonómiák formájában.

A jogok nyomon követése: A magazinok gyakran vesznek át anyagokat más magazinoktól, kiadói licencek alapján. Ennek leggyakoribb formája fotóügynökségek, fotóarchívumok anyagainak licencelése, de előfordulhat cikkek, mellékcikkek és más hasonló tartalom licenc alapján történő publikálása is. Azonban néha szinte reménytelen megtudni, hogy pl. egy bizonyos tartalmat egyszeri használatra licenceltek-e, hogy kell e utána szerzői jogdíjat fizetni, vagy hogy fenntart-e minden jogot az elsődleges kiadó stb. Ezért a PRISM rendszer olyan elemeket tartalmaz, amelyekkel nyomon követhetők az efféle jogok. A RRISM specifikációja egy külön szókészletet definiál azoknak a helyeknek, időpontoknak és kiadói szakmáknak a leírására, ahol az adott tartalom felhasználható, illetve, ahol nem felhasználható.

A meta-adatok megőrzése: A legtöbb publikált tartalom már ma is el van látva meta-adatokkal. Azonban, ahogy a tartalom mozog a rendszerek között, a meta-adatokat gyakran eldobják, hogy azután a produkciós folyamat során, jelentős költséggel újra előállítsák azokat. A PRISM megpróbálja csökkenteni ezt a problémát azzal, hogy olyan metaadat-specifikációt készít, amelyik használható a tartalom előállítási folyamatának minden fázisában. A PRISM specifikációjának fontos jellemzője a meglévő specifikációk alkalmazása. A PRISM Munkacsoport ahelyett, hogy elkezdett volna elölről kidolgozni egy teljesen új dolgot, elhatározta, hogy amennyire lehet, felhasználja a már létező specifikációkat, és csak ott definiál új dolgokat, ahol az feltétlenül szükséges. Ebből a célból kiindulva, a PRISM specifikáció felhasználja az XML, az RDF, a Dublin Core specifikációit, valamint a különböző ISO szabványú formátumokat és szókészleteket.

Egy PRISM leírás olyan egyszerű, mint néhány Dublin Core tulajdonság megadása típus nélküli literál-értékekkel. A 34. példa egy fényképfelvétel meta-adatait írja le alapvető információkkal a felvétel címéről, a fotósról, a formátumról stb.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xml:lang="en-US">

 <rdf:Description rdf:about="http://travel.example.com/2000/08/Corfu.jpg">
  <dc:title>Walking on the Beach in Corfu</dc:title>
  <dc:description>Photograph taken at 6:00 am on Corfu with two models
  </dc:description>
  <dc:creator>John Peterson</dc:creator>
  <dc:contributor>Sally Smith, lighting</dc:contributor>
  <dc:format>image/jpeg</dc:format>
 </rdf:Description>
</rdf:RDF>

A PRISM tovább bővíti a Dublin Core-t is abból a célból, hogy még részletesebb leírásokat lehessen készíteni vele. A bővítményeket három új szókészletben definiálja, amelyeket a névtér-prefixeik alapján általában prism:, pcv: és prl: néven emlegetnek. Ezek szerepe a következő:

A prism: minősítettnév-prefix a PRISM fő szókészletét azonosítja, amelyben a kifejezések a http://prismstandard.org/namespaces/basic/1.0/ URI-prefixet használják. Ebben a szókészletben a legtöbb tulajdonság a Dublin Core tulajdonságok specifikusabb változata. Például a "dátum" (dc:date) tulajdonság specifikusabb változatai: "a publikálás ideje", "a kiadás ideje" és "az elévülés ideje" (prism:publicationTime, prism:releaseTime, prism:expirationTime) stb.

A pcv: prefix a PRISM Controlled Vocabulary kifejezés rövidítése, mely a PRISM "szabályozott" (controlled) szókészletét azonosítja. Ennek a szókészletnek a kifejezései mind a http://prismstandard.org/namespaces/pcv/1.0/ URI prefixet használják. A jelenlegi gyakorlat egy cikk tárgyának vagy tárgyainak leírására a kulcsszavak megadása. Sajnos azonban, az egyszerű kulcsszavak nem növelik jelentősen a találat valószínűségét, főleg amiatt, hogy az emberek néha különböző kulcsszavakat használnak azonos fogalmak megnevezésére [BATES96]. A legjobb módszer az lenne, ha a cikkek témáit egy "szabályozott" (controlled) szókészletből vennék a cikk tartalmát leírók. Ennek a szókészletnek minél több szinonimát kellene megadnia a benne szereplő fogalmakra, hogy a keresők és az indexelők által használt kifejezések minél nagyobb valószínűséggel találkozhassanak. A pcv: szókészlet olyan tulajdonságokat tartalmaz, amelyekkel kifejezéseket definiálhatunk, leírhatjuk a köztük lévő viszonyokat, és alternatív változatokat is kapcsolhatunk hozzájuk.

A prl: prefix a PRISM Rights Language (PRISM jogok nyelve) nevű szókészlet rövidítése, amelynek a kifejezései mind a http://prismstandard.org/namespaces/prl/1.0/ URI prefixet használják. A digitális jogok kezelése napjainkban egy lendületesen fejlődő terület. Számos javaslat látott napvilágot jogkezelő nyelvekre vonatkozóan, de eddig egyikük sem nyerte el a szakma egyértelmű tetszését. Mivel nem volt miből választani, átmeneti megoldásként a PRL nyelvet definiálták erre a célra. Ez olyan tulajdonságokat tartalmaz, amelyekkel kijelenthetjük, hogy egy erőforrás használható-e, vagy nem használható, az időtől a helytől és a szakmától függően. Ezt egy 80/20 százalékos arányú kompromisszumnak tekintik, amely bizonyos megtakarításokat eredményezhet a kiadóknak, ha elkezdik nyomon követni a jogaik érvényesülését. A PRL-t nem szánták sem egy általános jogkezelő nyelvnek, sem pedig egy olyan automatikus mechanizmusnak, amellyel a kiadók korlátozhatják a tartalom fogyasztók általi felhasználását.

A PRISM rendszer azért használja az RDF-et, mert ez lehetővé teszi a legkülönbözőbb komplexitású leírások kezelését is. Jelenleg nagyon sok meta-adat csupán egyszerű karakterláncokat használ (többnyire típus nélküli literál-értékek leírására), mint pl a következő példa is:

<dc:coverage>Greece</dc:coverage>

A PRISM rendszer fejlesztői remélik, hogy idővel a PRISM specifikációi egyre kifinomultabbak lesznek, és az egyszerű adatértékektől a strukturáltabbak felé haladnak. Ezeknek az értéknek a köre az a kérdés, amely most válaszra vár. Néhány kiadó már kifinomult, ún. "szabályozott" szókészleteket használ, míg mások csak egyszerű, manuálisan megadott kulcsszavakat használnak. Ennek illusztrálására bemutatunk néhány példát a dc:coverage tulajdonság különböző lehetséges értékeire:

<dc:coverage>Greece</dc:coverage>

<dc:coverage rdf:resource="http://prismstandard.org/vocabs/ISO-3166/GR"/>

Itt előbb egy típus nélküli literál használatával, majd egy URIref segítségével azonosítottuk Görögországot (Greece). Az alábbi példában pedig már egy strukturált értéket adunk meg a Coverage tulajdonság értékeként, amelyben szerepel az előbbi URIref, valamint Görögország neve két további nyelven.

<dc:coverage>
  <pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">
    <pcv:label xml:lang="en">Greece</pcv:label>
    <pcv:label xml:lang="fr">Grčce</pcv:label>
  </pcv:Descriptor>
</dc:coverage>

Figyeljük meg azt is, hogy léteznek olyan tulajdonságok, amelyeknek a jelentése hasonló, vagy amelyek más tulajdonságok altulajdonságai. Például egy erőforrás geográfiai tárgyát megadhatnánk a következő tulajdonságokkal:

<prism:subject>Greece</prism:subject>
<dc:coverage>Greece</dc:coverage>

de megadhatjuk egy harmadik tulajdonsággal is:

<prism:location>Greece</prism:location>

E tulajdonságok bármelyike használható akár egyszerű literál-értékkel, akár egy komplex strukturált értékkel. Az ilyen szélsőséges határok között mozgó értéktartományokat azonban már nem lehet megfelelően leírni DTD-kkel, de még az újabb XML sémákkal sem. Erre sokkal alkalmasabb az RDF, bár igaz, hogy ennél a leírások többféle szintaktikai változatban is megjelenhetnek. Az RDF gráfmodellje azonban egyszerű szerkezetű: lényegében tripletek halmaza. Ezért a meta-adatok tripletek szintjén történő kezelése megkönnyítheti a szoftverek számára a folyton bővülő tartalomhoz való alkalmazkodást.

Ezt a szekciót két példával zárjuk: a 35. példa azt mondja, hogy a .../Corfu.jpg kép nem felhasználható (#none) a dohányiparban, amelynek a kódszáma 21 az ipari tevékenységek (USA-beli) szabványos osztályozási rendszerében (SIC):

<rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/"
         xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">

 <rdf:Description rdf:about="http://travel.example.com/2000/08/Corfu.jpg">
  <dc:rights rdf:parseType="Resource"
         xml:base="http://prismstandard.org/vocabularies/1.0/usage.xml">
     <prl:usage rdf:resource="#none"/>
     <prl:industry rdf:resource="http://prismstandard.org/vocabs/SIC/21"/>
  </dc:rights>
 </rdf:Description>
</rdf:RDF>

A 36. példa azt mondja, hogy a Corfuban készült felvétel fotográfusa a 3845. számú alkalmazott, akit John Peterson néven ismernek. A leírásból az is kiderül, hogy a fotó földrajzi területe (coverage) Görögország. Figyeljük meg, hogy itt egy szabályozott szókészletből (pcv) vesszük a kifejezéseket, amelyeknek még a verziójáról is van információ a leírásban (az xmlns:pcv névtér-deklaráció URI-jében).

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:pcv="http://prismstandard.org/namespaces/pcv/1.0/"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xml:base="http://travel.example.com/">

  <rdf:Description rdf:about="/2000/08/Corfu.jpg">
    <dc:identifier rdf:resource="/content/2357845" />
    <dc:creator>
      <pcv:Descriptor rdf:about="/emp3845">
        <pcv:label>John Peterson</pcv:label>
      </pcv:Descriptor>
    </dc:creator>
    <dc:coverage>
      <pcv:Descriptor
          rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">
        <pcv:label xml:lang="en">Greece</pcv:label>
        <pcv:label xml:lang="fr">Grece</pcv:label>
      </pcv:Descriptor>
    </dc:coverage>
  </rdf:Description>
</rdf:RDF>

6.3 XPackage

<?xml version="1.0"?>
<xpackage:description>
  <rdf:RDF>

    (description of individual resources go here)

  </rdf:RDF>
</xpackage:description>

<?xml version="1.0"?> 
<xpackage:description 
           xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#"
           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:mime="http://xpackage.org/namespaces/2003/mime#" 
           xmlns:x="http://xpackage.org/namespaces/2003/xml#"
           xmlns:xlink="http://www.w3.org/1999/xlink">  
    <rdf:RDF>

    <!--doc.html-->
    <rdf:Description rdf:about="urn:example:xhtmldocument-doc">
      <rdfs:comment>The XHTML document.</rdfs:comment>
      <xpackage:location xlink:href="doc.html"/>
      <mime:contentType>application/xhtml+xml</mime:contentType>
      <x:namespace rdf:resource="http://www.w3.org/1999/xhtml"/>
      <x:style rdf:resource="urn:example:xhtmldocument-stylesheet"/>
      <dc:creator>Garret Wilson</dc:creator>
      <xpackage:manifest rdf:parseType="Collection">
         <rdf:Description rdf:about="urn:example:xhtmldocument-stylesheet"/>
         <rdf:Description rdf:about="urn:example:xhtmldocument-image"/>
      </xpackage:manifest>
    </rdf:Description>

    </rdf:RDF> 
</xpackage:description>

<?xml version="1.0"?> 
<xpackage:description 
           xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#"
           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:mime="http://xpackage.org/namespaces/2003/mime#" 
           xmlns:x="http://xpackage.org/namespaces/2003/xml#"
           xmlns:xlink="http://www.w3.org/1999/xlink">  
    <rdf:RDF> 

    <!--stylesheet.css-->
    <rdf:Description rdf:about="urn:example:xhtmldocument-css">
      <rdfs:comment>The document style sheet.</rdfs:comment>
      <xpackage:location xlink:href="stylesheet.css"/>
      <mime:contentType>text/css</mime:contentType>
    </rdf:Description>

    </rdf:RDF> 
</xpackage:description>

6.4 RSS 1.0: RDF webhely-összefoglaló

Néha szükségünk van arra, hogy napi rendszerességgel hozzáférhessünk sokféle információhoz a weben (pl. ilyenekhez, mint menetrendek, teendők listája, kereséséi eredmények, "Mi az új a webhelyen?" típusú információk stb.). Ahogy az erőforrások mennyisége és változatossága növekszik a weben, egyre nehezebb lesz kezelni és koherens egésszé integrálni az ilyen információkat. Az RDF Webhely-összefoglaló (RDF Site Summary: RSS 1.0) egy olyan RDF szókészlet, mely egy könnyű, de hatékony lehetőséget ad az olyan információk leírására és újrafelhasználására, amelyeket meghatározott időben, nagy tömegben kell az érdekeltekhez eljuttatni. Ezért az RSS 1.0 talán a legszélesebb körben használt RDF alkalmazás a weben.

Hogy egy egyszerű példát említsünk, maga a W3C honlapja is egy elsődleges találkozási pont a közönséggel, mely részben arra szolgál, hogy szétküldje a Konzorcium által produkált anyagokról szóló információkat az érdekeltek számára. A W3C honlapnak egy meghatározott napon megjelent állapotát mutatja a 19. ábra. A hírek középső hasábja gyakran változik. Hogy támogassa ennek az információnak az időzített szétosztását, a W3C készített egy RSS 1.0 alapú hírtovábbító alkalmazást, mely a középső hasáb tartalmát mások számára is hozzáférhetővé teszi, hogy tetszésük szerint felhasználhassák azt. Az RSS használatával a hírcsoportosító webhelyek összefoglalót készíthetnek a napok legfontosabb híreiből, míg mások, az olvasóik kiszolgálása érdekében, hiperszöveg hivatkozások formájában kiírhatják a címeket a saját honlapjukra. Az is egyre gyakoribb, hogy egyének előfizetnek egyes hírcsomagok automatikus továbbítására és vételére, egy erre alkalmas asztaliszámítógép-szoftver segítségével. Az ilyen asztali RSS olvasó programok lehetővé teszik a felhasználóknak, hogy akár webhelyek százait is figyelemmel kövessék anélkül, hogy akárcsak egyet is fel kellene keresniük a böngészőjük segítségével.

19. ábra: A W3C honlapja

Számtalan webhely nyújt RSS 1.0 alapú információ továbbító szolgáltatást. A 40. példa a W3C feed egyik küldeményét mutatja (ez egy másik dátumról származik):

<?xml version="1.0" encoding="utf-8"?>

<rdf:RDF xmlns="http://purl.org/rss/1.0/"
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

  <channel rdf:about="http://www.w3.org/2000/08/w3c-synd/home.rss">
    <title>The World Wide Web Consortium</title>
    <description>Leading the Web to its Full Potential...</description>
    <link>http://www.w3.org/</link>

    <dc:date>2002-10-28T08:07:21Z</dc:date>

    <items>
        <rdf:Seq>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item164"/>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item168"/>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item167"/>
        </rdf:Seq>
    </items>

  </channel>

  <item rdf:about="http://www.w3.org/News/2002#item164">
    <title>User Agent Accessibility Guidelines Become a W3C 
       Proposed Recommendation</title>
    <description>17 October 2002: W3C is pleased to announce the 
       advancement of User Agent Accessibility Guidelines 1.0 to 
       Proposed Recommendation. Comments are welcome through 14 November. 
       Written for developers of user agents, the guidelines lower 
       barriers to Web accessibility for people with disabilities 
       (visual, hearing, physical, cognitive, and neurological). 
       The companion Techniques Working Draft is updated. Read about 
       the Web Accessibility Initiative. (News archive)</description>
    <link>http://www.w3.org/News/2002#item164</link>
    <dc:date>2002-10-17</dc:date>
  </item>

  <item rdf:about="http://www.w3.org/News/2002#item168">
    <title>Working Draft of Authoring Challenges for Device 
       Independence Published</title>
    <description>25 October 2002: The Device Independence 
       Working Group has released the first public Working Draft of 
       Authoring Challenges for Device Independence. The draft describes 
       the considerations that Web authors face in supporting access to 
       their sites from a variety of different devices. It is written 
       for authors, language developers, device experts and developers 
       of Web applications and authoring systems. Read about the Device 
       Independence Activity (News archive)</description>
    <link>http://www.w3.org/News/2002#item168</link>
    <dc:date>2002-10-25</dc:date>
  </item>

  <item rdf:about="http://www.w3.org/News/2002#item167">
    <title>CSS3 Last Call Working Drafts Published</title>
    <description>24 October 2002: The CSS Working Group has 
       released two Last Call Working Drafts and welcomes comments 
       on them through 27 November. CSS3 module: text is a set of 
       text formatting properties and addresses international contexts. 
       CSS3 module: Ruby is properties for ruby, a short run of text 
       alongside base text typically used in East Asia. CSS3 module: 
       The box model for the layout of textual documents in visual 
       media is also updated. Cascading Style Sheets (CSS) is a 
       language used to render structured documents like HTML and 
       XML on screen, on paper, and in speech. Visit the CSS home 
       page. (News archive)</description>
    <link>http://www.w3.org/News/2002#item167</link>
    <dc:date>2002-10-24</dc:date>
  </item>

</rdf:RDF>

Mint a 40. példa mutatja, a formátumot úgy tervezték meg, hogy a tartalmat könnyen megkülönböztethető szekciókba lehessen csomagolni. A hírportálok, a webnaplók, a sporteredmények, a tőzsdei hírek, és ehhez hasonló információküldő szolgáltatások az RSS 1.0. tipikus alkalmazási esetei.

Az RSS információküldés bármelyik alkalmazáson keresztül igényelhető, amelyik használja a HTTP protokollt. Az utóbbi időben azonban az RSS 1.0 alkalmazások kezdenek három különböző kategóriára bomlani:

• On-line tartalomegyesítő webhelyek: a 20. ábra két ilyent ábrázol egymás mellé állítva (Meerkat és NewsIsFree, mindkettő tükrözi a W3C hírrovatát is). Ezek, források ezreiből gyűjtik az automatikusan küldött anyagokat, és először szétszedik <item> tegek szerint, majd pedig nagy, tematikus csoportokba ismét összerakják őket, végül az ilyen csoportot kereshetővé teszik. Ilyen módon megkereshetjük a több száz webhelyről származó legfrissebb híreket pl. a "Java" programozási rendszerről anélkül, hogy akárcsak egyet is fel kellene keresnünk ezek közül.
• Asztali hírolvasó programok: pl. az Amphetadesk és a NetNewsWire Lite, lehetővé teszik a felhasználóiknak, hogy az íróasztalukról előfizessenek akár több száz automatikusan küldött információra is. Ezek az olvasóprogramok általában óránként frissítik a rajtuk keresztül megrendelt híreket, hogy a felhasználó mindig napra kész legyen az adott témában.
• Inzertek (scripts): Az RSS eredeti célja az volt, hogy lehetővé tegye a webmesterek számára, hogy a más webhelyekről származó információt beépítsék a sajátjukba. Az RSS 1.0-t még ma is sok webhelyen (pl. a Slashdot-nál is) arra használják, hogy segítségével beépítik az RSS küldeményeket a saját honlapjukba.

20. ábra: A MeerKat és a NewsIsFree

Az RSS 1.0 tervezés útján bővíthető. További RDF szókészletek (vagy modulok – ahogy az RSS közösségekben hívják őket) importálásával az RSS 1.0 fejlesztő nagy mennyiségű meta-adatot és kezelési instrukciót adhat át a fájlt fogadó alkalmazás számára. Modulokat bárki írhat, ugyanúgy, ahogy általánosabb RDF szókészleteket. Jelenleg 3 hivatalos modul és 19 javasolt modul ismeretes; ezeket széles körben elfogadja az RSS alkalmazói közösség. Ezek a modulok a komplett Dublin Core module-tól a specializáltabb RSS-centrikus modulokig terjednek, mint pl. az információegyesítési modul (Aggregation module).

Bizonyos óvatosságra van szükség, amikor RDF értelemben beszélünk az RSS-ről, ugyanis jelenleg két szálon fut az RSS specifikációs tevékenység: az egyik szál (RSS 0.91, 0.92, 0.93, 0.94 és 2.0) nem használja az RDF-et, míg a másik (RSS 0.9 és 1.0) használja.

6.5 CIM/XML

Az elektromos közműhálózatok többféle célra használnak energiaellátórendszer-modelleket. Az ilyen rendszerek szimulációja elengedhetetlen mind a tervezéshez, mind pedig a biztonsági elemzésekhez, de ilyen modelleket használnak az üzemeltetés során is pl. a teherelosztó-központok energiagazdálkodási rendszereiben (Energy Management Systems – EMS). Egy üzemeltetési célú energiaellátórendszer-modell akár információ-osztályok ezreit is tartalmazhatja. És ezeket a modelleket nemcsak "házon belül" használják, de az elektromos közművek ki is cserélik egymás között a modell-információkat, mind tervezési, mind üzemeltetési célokra (pl. az energiatovábbítás koordinálására és a megbízható üzemeltetés biztosítására). Az egyes elektromos közműhálózatok azonban különböző szoftvereket használnak erre, és emiatt a rendszermodelleket különböző formátumokban tárolják, megnehezítve ezzel a modellek cseréjét.

Hogy támogassák a rendszermodellek hordozhatóságát, az energiaszolgáltatóknak meg kellett egyezniük a rendszerek entitásainak és a köztük lévő viszonyoknak a közös definíciójában. Ebből a célból az EPRI, (Electric Power Research Institute, egy kaliforniai, nonprofit energiakutató konzorcium), kifejlesztett egy közös információs modellt (Common Information Model [CIM] néven). A CIM egy közös szemantikát definiál a villamosenergia-hálózatok erőforrásai, ezek jellemzői és kapcsolatai számára. Emellett, hogy támogassák a CIM modellek elektronikus továbbítását is, a villamosenergia-ipari szakma kifejlesztett egy nyelvet a CIM modellek leírására, CIM/XML néven. A CIM/XML egy RDF alkalmazás, mely az RDF-et és az RDF Sémát használja az XML struktúrák szervezésére. A North American Electric Reliability Council (egy ipari hátterű, észak-amerikai nonprofit szervezet, amelyet az elektromos energia szállításának biztonságosabbá tétele céljából alapítottak) ipari szabványként adoptálta a CIM/XML-t az energiaszállító rendszerek üzemeltetői közötti modellcsere céljára. A CIM/XML nemzetközi IEC szabványosítása is folyamatban van. A CIM/XML nyelv egy kitűnő ismertetését adja a [DWZ01]. [Nota bene: ez a villamosenergia-ipari CIM nem tévesztendő össze a Distributed Management Task Force által kifejlesztett hasonló nevű (DMTF CIM) produktummal, mely vállalatirányítási információ ábrázolására szolgál elosztott szoftverek, hálózatok és vállalatok környezetében. A DMTF CIM-nek is van egy XML reprezentációja, bár ez még nem használ RDF-et, de már folynak független kutatások ez irányban is.]

A CIM segítségével ábrázolhatók az elektromos közművek által használt objektumosztályok, valamint ezek attribútumainak és viszonyainak túlnyomó többsége. A CIM arra használja ezeket az objektumosztályokat és attribútumaikat, hogy támogassa az egymástól függetlenül fejlesztett alkalmazások integrálását (például: gyártó-specifikus energiagazdálkodási rendszerek (EMS-ek) egymás közötti integrációját, vagy EMS-eknek olyan rendszerekkel való integrációját, amelyek az energiarendszerek egyéb aspektusaival foglalkoznak, mint pl. a villamos energia előállításának és szállításának irányítása).

A CIM-et osztálydiagramok halmazaként specifikálták az Egységes Modellező Nyelv (Unified Modeling Language – UML) segítségével. A CIM bázis-osztálya az Energiarendszer-erőforrás (PowerSystemResource) osztály, mely további, egyre specializáltabb osztályokra bomlik, mint pl. Alállomás (Substation), Kapcsoló (Switch) és Megszakító (Breaker), amelyeket egymás alosztályaiként definiáltak. A CIM/XML a CIM szókészletét RDF Séma szókészletként ábrázolja, az RDF/XML nyelvet pedig a specifikus rendszermodellek adatcsere-nyelveként használja. A 41. példa CIM/XML alapú osztály- és tulajdonságdefiníciókat mutat be:

<rdfs:Class rdf:ID="PowerSystemResource"> 
  <rdfs:label xml:lang="en">PowerSystemResource</rdfs:label> 
  <rdfs:comment>"A power system component that can be either an
    individual element such as a switch or a set of elements 
    such as a substation. PowerSystemResources that are sets 
    could be members of other sets. For example a Switch is a 
    member of a Substation and a Substation could be a member 
    of a division of a Company"</rdfs:comment> 
</rdfs:Class>

<rdfs:Class rdf:ID="Breaker"> 
  <rdfs:label xml:lang="en">Breaker</rdfs:label> 
  <rdfs:subClassOf rdf:resource="#Switch" /> 
  <rdfs:comment>"A mechanical switching device capable of making, 
     carrying, and breaking currents under normal circuit conditions 
     and also making, carrying for a specified time, and breaking 
     currents under specified abnormal circuit conditions e.g. those 
     of short circuit. The typeName is the type of breaker, e.g., 
     oil, air blast, vacuum, SF6."</rdfs:comment> 
</rdfs:Class>

<rdf:Property rdf:ID="Breaker.ampRating"> 
   <rdfs:label xml:lang="en">ampRating</rdfs:label> 
   <rdfs:domain rdf:resource="#Breaker" /> 
   <rdfs:range rdf:resource="#CurrentFlow" /> 
   <rdfs:comment>"Fault interrupting rating in amperes"</rdfs:comment> 
</rdf:Property>

A CIM/XML a teljes RDF/XML szintaxisnak csak egy részhalmazát használja, hogy egyszerűsítse a modell-alkotást. Ugyanakkor a CIM/XML implementál néhány további bővítményt is az RDF Séma szókészletéhez. Ezek a bővítmények az inverz szerepet és a multiplicitás (RDF terminológiával: kardinalitás) korlátozását támogatják. Ez utóbbi korlátozás azt jelenti, hogy egy adott tulajdonság hány különböző értékkel alkalmazható egy adott erőforrás jellemzésére (ennek megengedett értékei itt: zéró-vagy-egy, pontosan-egy, zéró-vagy-több, egy-vagy-több). A 42. példában látható tulajdonságok ezeket a bővítményeket illusztrálják. (Ezeket a példában a cims: minősítettnév-prefixszel azonosítjuk):

<rdf:Property rdf:ID="Breaker.OperatedBy"> 
   <rdfs:label xml:lang="en">OperatedBy</rdfs:label> 
   <rdfs:domain rdf:resource="#Breaker" /> 
   <rdfs:range rdf:resource="#ProtectionEquipment" /> 
   <cims:inverseRoleName rdf:resource="#ProtectionEquipment.Operates" /> 
   <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" />
   <rdfs:comment>"Circuit breakers may be operated by 
       protection relays."</rdfs:comment>
</rdf:Property>

<rdf:Property rdf:ID="ProtectionEquipment.Operates"> 
   <rdfs:label xml:lang="en">Operates</rdfs:label> 
   <rdfs:domain rdf:resource="#ProtectionEquipment" /> 
   <rdfs:range rdf:resource="#Breaker" /> 
   <cims:inverseRoleName rdf:resource="#Breaker.OperatedBy" /> 
   <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" />
   <rdfs:comment>"Circuit breakers may be operated by 
       protection relays."</rdfs:comment>
</rdf:Property>

Az EPRI sikeres együttműködőképesség-teszteket hajtott végre a CIM/XML felhasználásával gyakorlati célú, nagy méretű modellek különböző gyártóktól származó produktumok közötti cseréje útján, ahol az egyik tesztben több, mint 2000 alállomás leírását tartalmazó adat is szerepelt. Ezek a tesztek megerősítették, hogy a modelleket korrekt módon interpretálnák a tipikus alkalmazások. Annak ellenére, hogy a CIM-et eredetileg EMS rendszerek céljaira szánták, sikerült azt oly módon kibővíteni, hogy támogatni tudja az energiaelosztást és más alkalmazásokat is.

Az Object Management Group (OMG) elfogadott egy objektum-interfész szabványt a CIM energiarendszer-modellek elérésére, amelyet Adatelérési eszköznek (Data Access Facility [DAF]) nevezett el. Ugyanúgy, mint a CIM/XML nyelv, a DAF is az RDF modellen alapszik, és ugyanazt a CIM sémát használja. De amíg a CIM/XML dokumentumok formájában teszi lehetővé a modellek cseréjét, addig a DAF objektumhalmazok formájában biztosítja ugyanezt.

A CIM/XML jól illusztrálja azt a hasznos szerepet, amelyet az RDF játszhat az olyan információk XML alapú cseréjében, amelyek természetes módon kifejezhetők entitások közötti viszonyok, vagy pedig objektumorientált osztályok, attribútumok és a közöttük lévő viszonyok segítségével (akkor is, ha ezek az információk nem szükségszerűen elérhetők a weben keresztül). Ezekben az esetekben az RDF egy alapvető struktúrát biztosít az XML számára az objektumok azonosításának, és strukturált viszonyokban való alkalmazásának támogatására. Ezt az összefüggést jól illusztrálja az a sok alkalmazás, mely az RDF/XML-t használja információcsere céljára, de jól illusztrálja az a számos projekt is, amelyik keresi a kapcsolatot az RDF (vagy az ontológianyelvek, mint pl. az OWL) és az UML (vagy annak XML reprezentációja) között. A CIM/XML-nek az a szükséglete, amely miatt ki kellett bővítenie az RDF Sémát a multiplicitáskorlázozás (kardinalitáskorlátozás) és az inverz viszonyok támogatásához szükséges elemekkel, ugyanazokat az igénytípusokat jelzi, amelyek az olyan, nagyobb teljesítményű RDF alapú séma- vagy ontológianyelvek kifejlesztéséhez vezettek, mint milyen az 5.5 szekcióban már ismertetett DAML+OIL és OWL. Ezek a nyelvek tehát alkalmasak lehetnek sok hasonló modellező alkalmazás támogatására.

És végül, a CIM/XML egy másik fontos tényt is illusztrál azok számára, akik további "RDF a gyakorlatban" típusú példákat keresnek: az RDF alkalmazásokhoz használt nyelveket sokszor csak úgy emlegetik, mint "XML" nyelveket, vagy egyes rendszerekre úgy hivatkoznak, mint amelyek "XML"-t használnak, miközben ténylegesen RDF/XML-ről van szó, tehát valójában RDF alkalmazásokról kellene beszélnünk. Néha meglehetősen mélyen bele kell ásnunk magunkat az ilyen nyelvek leírásába, hogy ezt észrevegyük (néhány általunk felfedezett alkalmazási esetnél egyszer sem említették meg explicit módon az RDF nevét, de a mintaként megvizsgált adatok világosan kimutatták, hogy RDF/XML-ről van szó). Sőt, egyes alkalmazásokban, mint pl. a CIM/XML, az előállított RDF kód nem is jelenik meg a weben, minthogy ezt lokális szoftverkomponensek közötti információcsere céljára szánják, nem pedig általános hozzáférés céljára (habár elképzelhetők olyan jövőbeli alkalmazási variánsok is, amelyekben az ilyen típusú RDF adatok is hozzáférhetővé válnak a weben).

6.6 GO (Gén-ontológiai Konzorcium)

Az olyan strukturált meta-adatok, amelyek szabályozott (controlled) szókészleteket használnak, mint például az orvostudományi terminológiát leíró SNOMED RT (Systematized Nomenclature of Medicine Reference Terminology), vagy az orvostudomány címszavait rendszerező szótár MeSH (Medical Subject Headings) fontos szerepet játszanak az orvostudományban azáltal, hogy lehetővé teszik a hatékonyabb irodalomkutatást, és segítik az orvostani ismeretek terjesztését és cseréjét [COWAN]. Az orvostudomány azonban gyorsan fejlődik, és ez szükségessé teszi egyre újabb szókészletek kifejlesztését.

A Gén-ontológiai Konzorcium (Gene Ontology (GO) Consortium,[GO]) célja olyan szókészletek rendelkezésre bocsátása, amelyek leírják a génproduktumok specifikus aspektusait. Az együttműködő adatbázisok GO kifejezésekkel címkézik (annotálják) a génproduktumokat (vagy a géneket), és ezáltal kölcsönös hivatkozási lehetőségeket teremtenek, valamint jelzik azt is, hogy milyen bizonyítékok támasztják alá ezeket az annotációkat. A közös GO kifejezések használata ezekben az adatbázisokban megkönnyíti az egységes lekérdezést. A GO-féle ontológiák strukturáltak, hogy mind a jellemzést, mind pedig a lekérdezést el lehessen végezni a részletesség (granularitás) különböző szintjein. A GO szókészletek dinamikusak, hiszen a gének és proteinek sejtbeli szerepével kapcsolatos ismeretek folyamatosan szaporodnak és változnak.

A GO három szervezési alapelve a molekuláris funkció, a biológiai folyamat és a sejtkomponens. Egy génproduktumnak egy vagy több molekuláris funkciója van, és egy vagy több biológiai folyamatban használják fel; ez esetleg kapcsolatban lehet egy vagy több sejtkomponenssel. A kifejezések definícióját e három ontológiában egy-egy szövegfájl tartalmazza. Mindhárom szövegfájlból havonta generálnak egy-egy XML formátumú változatot, amelyek tartalmazzák az összes rendelkezésre álló GO kifejezést.

A funkciókat, folyamatokat és komponenseket nemciklikus irányított gráfok vagy hálók formájában ábrázolják. Itt egy gyermekfogalom kétféle viszonyban lehet a szülőfogalmával: lehet annak egyik "esete" (ez az alosztály-osztály, vagy "is a" [isa] reláció), vagy lehet annak egyik "komponense" (ez a rész-egész, vagy "part of" reláció). Egy gyermekfogalomnak lehet egynél több szülőfogalma, és a gyermek lehet különböző típusú viszonyban a különböző szülőivel. A GO ontológiák ábrázolják a szinonimákat és az adatbázisok közötti kereszthivatkozásokat is. A GO rendszer RDF/XML-t használ a fogalmak közötti viszonyok ábrázolására az ontológiák XML változatában, mivel ez kellőképpen flexibilis az ilyen gráfstruktúrák ábrázolásában, és széleskörű eszköztámogatással is rendelkezik. Ugyanakkor a GO jelenleg nem-RDF típusú beágyazott struktúrákat használ a kifejezések leírásában, tehát a használt nyelv nem teljesen tiszta RDF/XML.

A 43. példa néhány minta jellegű GO információt mutat be, amelyek a GO dokumentációjából származnak:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE go:go> 
<go:go xmlns:go="http://www.geneontology.org/xml-dtd/go.dtd#" 
       xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
  <go:version timestamp="Wed May 9 23:55:02 2001" /> 

  <rdf:RDF> 
     <go:term rdf:about="http://www.geneontology.org/go#GO:0003673"> 
        <go:accession>GO:0003673</go:accession> 
        <go:name>Gene_Ontology</go:name> 
        <go:definition></go:definition> 
     </go:term> 

     <go:term rdf:about="http://www.geneontology.org/go#GO:0003674"> 
        <go:accession>GO:0003674</go:accession> 
        <go:name>molecular_function</go:name> 
        <go:definition>The action characteristic of a gene product.</go:definition> 
        <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" /> 
        <go:dbxref> 
           <go:database_symbol>go</go:database_symbol> 
           <go:reference>curators</go:reference> 
        </go:dbxref> 
     </go:term> 

     <go:term rdf:about="http://www.geneontology.org/go#GO:0016209"> 
        <go:accession>GO:0016209</go:accession> 
        <go:name>antioxidant</go:name> 
        <go:definition></go:definition> 
        <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" /> 
        <go:association> 
           <go:evidence evidence_code="ISS"> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>fbrf0105495</go:reference> 
              </go:dbxref> 
           </go:evidence> 
           <go:gene_product> 
              <go:name>CG7217</go:name> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>FBgn0038570</go:reference> 
              </go:dbxref> 
           </go:gene_product> 
        </go:association> 
        <go:association> 
           <go:evidence evidence_code="ISS"> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>fbrf0105495</go:reference> 
              </go:dbxref> 
           </go:evidence> 
           <go:gene_product> 
              <go:name>Jafrac1</go:name> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>FBgn0040309</go:reference> 
              </go:dbxref> 
           </go:gene_product> 
        </go:association> 
      </go:term> 
  </rdf:RDF> 
</go:go> 

A 43. példából látható, hogy a go:term kifejezés az alapvető elem. Egyes esetekre a GO saját kifejezéseket definiált ahelyett, hogy az RDF Sémát használta volna. Például a GO:0016209 kifejezésnek van egy ilyen eleme: <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" />. Ez a teg a "GO:0016209 isa GO:0003674" összefüggést reprezentálja, amelynek a jelentése itt: "Antioxidant is a molecular function" (az antioxidáns egy molekuláris funkció). Egy másik sajátos GO viszony a "része ~nak" (part of) reláció. Például a GO:0003674-nek van egy ilyen eleme: <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" />. Ennek a jelentése: "Molecular function is part of the Gene Ontology" (a molekuláris funkció része a gén-ontológiának).

Minden annotációt (címkézést, hozzáfűzött megjegyzést) valamilyen forráshoz kell kapcsolni, mely lehet egy szakirodalmi hivatkozás, egy másik adatbázis, vagy egy számítógépes elemzés. Az annotációnak jeleznie kell, milyen bizonyíték található az idézett forrásban, mely alátámasztja az asszociációt a génproduktum és a GO kifejezés között. Egy egyszerű szabályozott szókészletet használnak a bizonyítékok rögzítésére. Néhány példa a bizonyíték típusokra:

• ISS: ennek jelentése "inferred from sequence similarity [with <database:sequence_id>]" ("következtetés a szekvencia hasonlósága alapján) [egy <database:sequence_id> elemmel együtt]
• IDA: ennek jelentése "inferred from direct assay" (következtetés közvetlen vizsgálatból)
• TAS: ennek jelentése "traceable author statement" (ellenőrizhető szerzői kijelentés)

A go:dbxref elem ábrázolja valamely külső adatbázis egyik kifejezését, a go:association pedig egy kifejezés asszociációját egy génhez. A go:association elemben lehet mind go:evidence elem (amelynek van egy go:dbxref kereszthivatkozása az asszociációt indokoló bizonyítékra), mind pedig go:gene_product elem, mely tartalmazza a gén szimbólumát és egy gén hivatkozást (go:reference). Ezek az elemek is mutatják, hogy a GO XML szintaxisa nem "tiszta" RDF/XML, hiszen más elemek beágyazása ezekbe az elemekbe nem felel meg a váltakozó csomópont-él-csomópont-él "csíkozásnak", ahogy ez az [RDF-SZINTAXIS] dokumentum 2.1 és 2.2 szekciójában szerepel.

A GO több érdekes kérdésre is rávilágít. Először is megmutatja, hogy az XML használati értéke az információcserében növelhető azáltal, hogy RDF alapon strukturáljuk az XML kódot. Ez különösen igaz az olyan adatokra, amelyek egy átfogó gráf- vagy hálóstruktúrát, nem pedig szigorú hierarchiát alkotnak. A GO szintén egyik példája az olyan eseteknek, ahol az RDF-et használó adatok nem szükségszerűen jelennek meg az Interneten (közvetlenül használható formában), bár a fájlok, maguk, elérhetők a weben. Továbbá, a GO adatstruktúrái példának tekinthetők arra a jelenségre is, hogy a felületen "XML"-nek látszanak, de egy mélyebb elemzés kimutatja, hogy valójában RDF/XML eszközöket használnak (még ha nem is "tiszta" RDF/XML formában). És végül, a GO jól mutatja, hogy az RDF milyen szerepet játszhat az ontológiák ábrázolásában. Ez a szerep egyre jelentősebb lesz, ahogy a gazdagabb RDF alapú ontológianyelvek egyre szélesebb körben elterjednek (ilyen ontológianyelv a DAML+OIL vagy az OWL, amelyek lényegét az 5.5 szekcióban tömören ismertettük). Ennek látható jele az is, hogy a következő generációs GO projekt (Gene Ontology Next Generation) már az ilyen, gazdagabb nyelvek segítségével kívánja ábrázolni a GO ontológiákat.

6.7 A készüléktulajdonságok és felhasználói preferenciák leírása

Az utóbbi években nagyszámú, olyan mobil készülék jelent meg a forgalomban, amellyel böngészni lehet a webet. Ezek közül sok készülék nagyon különböző képességekkel rendelkezik az input-output opciók és a nyelvtámogatás szintje tekintetében. A mobil készülékek a hálózati csatlakozási lehetőségeiket tekintve is elég széles skálán mozogatnak. Ezeknek az új készülékeknek a használói a készülék képességeire és a hálózat pillanatnyi állapotára való tekintet nélkül elvárják a használható minőségű tartalomkijelzést. Hasonlóképpen elvárják azt is, hogy amikor egy alkalmazás vagy egy webtartalom megjelenik a készüléken, akkor az vegye figyelembe a felhasználó dinamikusan változó preferenciáit (pl. kapcsolja ki, vagy be a hangot). A realitás azonban az, hogy a készülékek különbözősége, és egy olyan szabványos módszer hiánya, amellyel közvetíteni lehetne a felhasználó preferenciáit a kiszolgáló felé, oda vezet, hogy olyan tartalom is megjelenik, amelyik vagy nem tárolható, vagy nem megjeleníthető a készüléken, vagy esetleg sérti a felhasználó érdekeit. Sőt, az ilyen tartalom átvitele a hálózaton keresztül az előfizető készülékére még túl hosszú időt is igényelhet.

Egy olyan megoldás, mely ezeket a problémákat megszüntetné, az lehetne, ha a felhasználó valahogy kódolhatná a saját vételi környezetét – a készülék képességeit, a felhasználói preferenciáit, a hálózat jellemzőit stb. – úgy, hogy a kiszolgáló felhasználhatná ezt a környezeti információt a tartalomnak a készülék képességei és a felhasználó kívánságai szerinti "konfekcionálására" (lásd [DIPRINC]-nél a vételi környezet [delivery context] definícióját). A W3C Összetett Képesség/Preferencia Profil című specifikációja (Composite Capabilities/Preferences Profile specification [CC/PP]) segít megoldani ezt a problémát azáltal, hogy definiál egy generikus keretet a vételi környezet leírására.

A CC/PP-keret egy viszonylag egyszerű szerkezetet definiál, mely a komponensek és attribútum-érték párok kétszintű hierarchiájából áll. Egy-egy komponenst használhatunk a vételi környezet egy-egy részének (mint. pl. hálózati jellemzők, a készülék szoftverkonfigurációja, vagy a készülék hardver jellemzői) specifikálására. Egy komponens egy vagy több attribútumot tartalmazhat. Például egy olyan komponens, mely a felhasználó preferenciáit kódolja, tartalmazhat egy attribútumot, mely azt adja meg, hogy kívánatos-e a hang megjelenítése is.

A CC/PP az imént felvázolt struktúráit az RDF Séma segítségével definiálja (a struktúra sémájának részleteit lásd a [CC/PP]-nél). A CC/PP-vel definiálhatjuk az egyes komponenseket, és az ezek attribútumait leíró szókészletet, de a CC/PP, maga, nem definiál előre ilyen szókészleteket. A szókészleteket más szervezetek vagy alkalmazások definiálják (ahogy azt alább bemutatjuk). A CC/PP nem definiál olyan protokollt sem, amely az ilyen szókészlet-példányok átvitelét szabályozná.

A CC/PP szókészlet egy példányát profilnak nevezzük. A CC/PP attribútumait RDF tulajdonságok formájában kódoljuk a profilban. A 44. példa egy olyan profilrészletet mutat be, amelyben az a felhasználói preferencia van kódolva, hogy kívánatos a hang kijelzése:

 <ccpp:component>
  <rdf:Description rdf:ID="UserPreferences">
   <rdf:type rdf:resource="http://www.example.org/profiles/prefs/v1_0#UserPreferences"/>
   <ex:AudioOutput>Yes</ex:AudioOutput>
   <ex:Graphics>No</ex:Graphics>
   <ex:Languages>
    <rdf:Seq>
     <rdf:li>en-cockney</rdf:li>
     <rdf:li>en</rdf:li>
    </rdf:Seq>
   </ex:Languages>
  </rdf:Description>
 </ccpp:component>

Ebben az alkalmazásban több előnye is van az RDF használatának. Az egyik ilyen, hogy egy CC/PP-vel kódolt profil olyan attribútumokat tartalmazhat, amelyek különböző szervezetek által definiált sémákból származnak. Az RDF használata az ilyen profilok készítésére nagyon is kézenfekvő, hiszen nehezen elképzelhető, hogy egyetlen szervezet előállítana egy olyan szupersémát, mely egyesített adatként tartalmazná az összes profilt. Az RDF másik nagy előnye, hogy gráf alapú adatmodelljénél fogva megkönnyíti bármilyen újabb attribútum (RDF tulajdonság) beépítését a profilba. Ez különösen hasznos az olyan profiloknál, amelyek gyakran változó adatokat tartalmaznak (mint pl. a helyszínnel kapcsolatos információk).

A Nyílt Mobil Szövetség (Open Mobile Alliance) definiált egy Felhasználói Ügynök Profilt (User Agent Profile, UAProf, lásd: [UAPROF]) – egy CC/PP alapú keretet, mely tartalmaz egy szókészletet a készülék képességeinek, a felhasználó oldali ágens képességeinek, a hálózati jellemzőknek és más hasonló komponenseknek a leírására, továbbá tartalmaz egy protokollt is a profilok átvitelére. Ez az UAProf hat komponenst definiál, köztük pl. a HardwarePlatform, a SoftwarePlatform, a NetworkCharacteristics és a BrowserUA komponenst. Az UAProf minden egyes komponens számára több attribútumot is definiál, de ezek az attribútumok nem rögzítettek, azokat felül lehet írni, vagy ki lehet egészíteni. A 45. példa az UAProf "HardwarePlatform" komponensének egy részletét mutatja be:

 <prf:component>
  <rdf:Description rdf:ID="HardwarePlatform">
   <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20021113#HardwarePlatform"/>
   <prf:ScreenSizeChar>15x6</prf:ScreenSizeChar>
   <prf:BitsPerPixel>2</prf:BitsPerPixel>
   <prf:ColorCapable>No</prf:ColorCapable>
   <prf:BluetoothProfile>
    <rdf:Bag>
     <rdf:li>headset</rdf:li>
     <rdf:li>dialup</rdf:li>
     <rdf:li>lanaccess</rdf:li>
    </rdf:Bag>
   </prf:BluetoothProfile>
  </rdf:Description>
 </prf:component>

Az UAProf protokoll támogatja mind a statikus, mind a dinamikus profilokat. A statikus profil egy URI segítségével érhető el. Ennek több előnye is van: a kliensnek a kiszolgálóhoz küldött lekérdezése csupán egy URI leadását igényli egy bőbeszédű XML dokumentum helyett, s ezzel csökkenthető a rádióforgalom; a felhasználó készülékén nem szükséges tárolni és/vagy előállítani a profilt; a készülék oldali szoftver implementációja egyszerűbb lehet. A dinamikus profilok előállítása menetközben történik, s ezért nem kapcsolódik hozzájuk egy URI. Ez állhat egy részprofilból is, mely csupán a statikus profilhoz viszonyított különbséget tartalmazza, de tartalmazhat olyan egyedülálló adatot is, mely nem szerepel a kliens statikus profiljában. A lekérdezés tetszőleges számú statikus és dinamikus profilt tartalmazhat, de nem közömbös a profilok leadási sorrendje, mert a későbbiek felülírják a korábbiakat a lekérdezésben. (Az UAProf protokollról, és ezen belül a többszörös protokoll problémájának feloldásáról további információk találhatók a [UAPROF] dokumentumban.)

Több más közösség is definiált CC/PP alapú szókészleteket (ilyen pl. a 3GPP TS 26.234 specifikációja [3GPP] és a WAP Fórum "Multimedia Messaging Service Client Transactions Specification" [MMS-CTR] nevű szókészlete). A CC/PP használatának eredményeképpen egy profil élvezheti az RDF elosztott jellegének előnyeit, és magába olvaszthat különböző szókészletekből származó komponenseket. A 46. példa egy ilyen profilt mutat be:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#"
         xmlns:mms="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#"
     xmlns:pss="http://www.3gpp.org/profiles/PSS/ccppschema-YYYYMMDD#">

 <rdf:Description rdf:ID="SomeDevice">
  <prf:component>
   <rdf:Description rdf:ID="Streaming">
    <rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS5#Streaming"/>
    <pss:AudioChannels>Stereo</pss:AudioChannels>
    <pss:VideoPreDecoderBufferSize>30720</pss:VideoPreDecoderBufferSize>
    <pss:VideoInitialPostDecoderBufferingPeriod>0</pss:VideoInitialPostDecoderBufferingPeriod>
    <pss:VideoDecodingByteRate>16000</pss:VideoDecodingByteRate>
   </rdf:Description>
  </prf:component>
 
  <prf:component>
   <rdf:Description rdf:ID="MmsCharacteristics">
    <rdf:type rdf:resource="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#Streaming"/>
    <mms:MmsMaxMessageSize>2048</mms:MmsMaxMessageSize>
    <mms:MmsMaxImageResolution>80x60</mms:MmsMaxImageResolution>
    <mms:MmsVersion>2.0</mms:MmsVersion>
   </rdf:Description>
  </prf:component>

  <prf:component>
   <rdf:Description rdf:ID="PushCharacteristics">
    <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20010330#PushCharacteristics"/>
    <prf:Push-MsgSize>1024</prf:Push-MsgSize>
    <prf:Push-MaxPushReq>5</prf:Push-MaxPushReq>
    <prf:Push-Accept>
     <rdf:Bag>
      <rdf:li>text/html</rdf:li>
      <rdf:li>text/plain</rdf:li>
      <rdf:li>image/gif</rdf:li>
     </rdf:Bag>
    </prf:Push-Accept>
   </rdf:Description>
  </prf:component>

 </rdf:Description>
</rdf:RDF>

Egy vételi környezet definíciója, valamint a környezeten belüli adatok fokozatosan alakulnak ki, és állandóan változnak. Ezért az RDF természetes bővíthetősége, és ezáltal a dinamikusan változó szókészletek támogatása megfelelő keretet biztosít a vételi környezet kódolására.

7.1 Az RDF szemantikája

Mint ahogy azt már tárgyaltuk az előző fejezetekben, az RDF-et arra tervezték, hogy a segítségével kijelentéseket, megállapításokat fogalmazhassunk meg az erőforrásokról, gráfok formájában, olyan specifikus szókészletek felhasználásával, amelyek az erőforrások, tulajdonságok, osztályok és hasonló komponensek neveit tartalmazzák. Emellett az RDF-et további olyan, fejlettebb leírónyelvek kiindulási alapjának is szánták, mint amilyeneket az 5.5 szekcióban felsoroltunk. Hogy a nyelv megfeleljen ezeknek a követelményeknek, az RDF "jelentését" rendkívül precízen szükséges definiálni.

Hogy – köznapi értelemben véve – pontosan mi képezi egy RDF gráf "jelentését", az sok tényezőtől függhet, amelyek közül a leglényegesebb a konvenció, vagyis az, hogy egy adott közösség milyen specifikus módon értelmezi a felhasználók által definiált RDF osztályokat és tulajdonságokat, a természetes nyelvű kommentárokat, és azokat a hivatkozásokat, amelyek más tartalomhordozó dokumentumokra mutatnak. Mint már röviden utaltunk rá a 2.2 szekcióban, azoknak a jelentéseknek a zöme, amelyeket ilyen módon értelmezünk, a gépi feldolgozás számára közvetlenül nem hozzáférhető. Hozzáférhető azonban ez a jelentés az emberi értelmezés számára, s így azon programozók számára is, akik olyan szoftvert fejlesztenek, amelyek különböző módon feldolgozzák majd az ilyen RDF információt. Az RDF információnak azonban van egy formális jelentése is, mely matematikai pontossággal meghatározza azokat a konklúziókat (vagy következményeket), amelyeket a gép le tud vonni egy RDF gráfból. Az RDF szemantikája – [RDF-SZEMANTIKA] dokumentum definiálja ezt a formális jelentést, mégpedig egy olyan technika segítségével, amelyet modell-elméletnek (model theory) nevezünk, és amely arra szolgál, hogy specifikáljuk általa egy formális nyelv szemantikáját. Az [RDF-SZEMANTIKA] definiálja az RDF nyelv szemantikai bővítményeit is, amelyeket az RDF Séma és az egyedi adattípusok reprezentálnak. Más szóval, az RDF modell-elmélete szolgáltatja az RDF fogalmak formális alátámasztását. A modell-elméletben definiált szemantika alapján egy RDF gráf könnyen lefordítható egy olyan logikai kifejezésre (matematikai formulára), amelynek lényegében a gráffal azonos marad a jelentése.

7.2 Az RDF tesztsorozata

Az RDF tesztsorozata – [RDF-TESZTEK] dokumentum kiegészíti az RDF szöveges specifikációját olyan teszt-példákkal, amelyekkel tesztelhetők az RDF-mag Munkacsoport (RDF Core Working Group) által meghatározott technikai problémák és szituációk. Hogy segítse ezeknek a példáknak a leírását, a Tesztsorozat dokumentum bevezeti az N-tripletek (N-Triples) fogalmát, amelyek a bázisát képezik annak a tripletes írásmódnak, amelyet tankönyvünkben is végig alkalmazunk.

A teszt-esetek példáit géppel olvasható formában is publikálják olyan webhelyeken, amelyekre Az RDF tesztsorozata dokumentum hivatkozik, így a fejlesztők ezeket az RDF szoftvereik automatikus tesztelésére is felhasználhatják.

A teszt-eseteket az alábbi kategóriákba sorolták:

• Pozitív és negatív szintaxiselemző-tesztek: Ezek azt ellenőrzik, hogy az RDF/XML elemzők (parserek) a megfelelő N-tripleteket produkálják-e a legális RDF/XML input dokumentumokból, illetve, hogy korrekt hibajelentéseket írnak-e ki, ha az input dokumentum valahol illegális RDF/XML kódot tartalmaz.
• Pozitív és Negatív következmény (entailment) tesztek: ezek azt vizsgálják, hogy a tesztelt szoftver megfelelő konklúziókat (következményeket) vont-e le, illetve, hogy hibásakat nem vont-e le az inputként megadott RDF kijelentésekből.
• Adattípus-érzékeny következmény (entailment) tesztek: ezek olyan pozitív vagy negatív adatértelmezési tesztek, amelyek speciális adattípusokat tartalmaznak, és így speciális támogatást igényelnek a feldolgozó szoftvertől a bennük szereplő adattípusok feldolgozásához.
• Egyéb tesztek: ezek olyan ellenőrzéseket végeznek, amelyek nem tartoznak a fenti kategóriák egyikébe sem.

A tesztsorozat nem reprezentálja az RDF teljes specifikációját, és a fontosság tekintetében sem előzi meg a többi specifikációs dokumentumot. Az RDF-mag Munkacsoport ezzel a tesztsorozattal lényegében az RDF konstrukciójával kapcsolatos szándékait kívánta illusztrálni, de a fejlesztők számára abban a tekintetben is hasznosak lehetnek ezek a tesztek, hogy eligazítást adhatnak, ha valamilyen részletkérdésben a többi dokumentum megfogalmazásai esetleg nem lennének elég világosak.

8.1 Normatív hivatkozások

[RDF-FOGALMAK]

Az RDF Erőforrás Leíró Keretrendszer alapfogalmai és absztrakt szintaxisa, W3C Ajánlás, 2004. február 10. Szerkesztők: Klyne G., Carroll J. A legutolsó (angol nyelvű) változat URL-je: http://www.w3.org/TR/rdf-concepts/.

[RDF-MIME-TYPE]

MIME Media Types, The Internet Assigned Numbers Authority (IANA). This document is http://www.iana.org/assignments/media-types/ . The registration for application/rdf+xml is archived at http://www.w3.org/2001/sw/RDFCore/mediatype-registration .

[RDF-MS]

Resource Description Framework (RDF) Model and Syntax Specification, Lassila O., Swick R. (Editors), World Wide Web Consortium, 22 February 1999. This version is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. The latest version is http://www.w3.org/TR/REC-rdf-syntax/.

[RDF-SZEMANTIKA]

Az RDF Szemantikája, W3C Ajánlás, 2004. február 10. Szerkesztők: Hayes P. A legutolsó (angol nyelvű) változat URL-je: http://www.w3.org/TR/rdf-mt/.

[RDF-SZINTAXIS]

Az RDF/XML szintaxis specifikációja (átdolgozott kiadás), W3C Ajánlás, 2004. február 10. Szerkesztő: Beckett D. A legutolsó (angol nyelvű) változat URL-je: http://www.w3.org/TR/rdf-syntax-grammar/.

[RDF-TESZTEK]

Az RDF tesztsorozata, W3C Ajánlás, 2004. február 10. Szerkesztők: Grant J., Beckett D. A legutolsó (angol nyelvű) változat URL-je: http://www.w3.org/TR/rdf-testcases/.

[RDF-SZÓKÉSZLET]

Az RDF Szókészlet Leíró Nyelv 1.0: RDF Séma, W3C Ajánlás, 2004. február 10. Szerkesztők: Brickley D., Guha R.V. A legutolsó (angol nyelvű) változat URL-je: http://www.w3.org/TR/rdf-schema/.

[UNICODE]

The Unicode Standard, Version 3, The Unicode Consortium, Addison-Wesley, 2000. ISBN 0-201-61633-5, as updated from time to time by the publication of new versions. (See http://www.unicode.org/unicode/standard/versions/ for the latest version and additional information on versions of the standard and of the Unicode Character Database).

[URIS]

RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, Berners-Lee T., Fielding R., Masinter L., IETF, August 1998, http://www.isi.edu/in-notes/rfc2396.txt.

[XML]

Extensible Markup Language (XML) 1.0, Second Edition, Bray T., Paoli J., Sperberg-McQueen C.M., Maler E. (Editors), World Wide Web Consortium, 6 October 2000. This version is http://www.w3.org/TR/2000/REC-xml-20001006. The latest version is http://www.w3.org/TR/REC-xml.

[XML-BASE]

XML Base, Marsh J. (Editor), World Wide Web Consortium, 27 June 2001. This version is http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The latest version is http://www.w3.org/TR/xmlbase/.

[XML-NS]

Namespaces in XML, Bray T., Hollander D., Layman A. (Editors), World Wide Web Consortium, 14 January 1999. This version is http://www.w3.org/TR/1999/REC-xml-names-19990114/. The latest version is http://www.w3.org/TR/REC-xml-names/.

[XML-XC14N]

Exclusive XML Canonicalization Version 1.0, Boyer J., Eastlake D.E. 3rd, Reagle J. (Authors/Editors), World Wide Web Consortium, 18 July 2002. This version is http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/. The latest version is http://www.w3.org/TR/xml-exc-c14n/.

8.2 Informatív hivatkozások

[3GPP]

3GPP TS 26.234. 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service; Protocols and codecs V5.2.0 (2002-09). This document is available at http://www.3gpp.org/specs/specs.htm via directory ftp://ftp.3gpp.org/specs/2002-09/Rel-5/26_series/.

[ADDRESS-SCHEMES]

Addressing Schemes, Connolly D., 2001. This document is http://www.w3.org/Addressing/schemes.html.

[BATES96]

Indexing and Access for Digital Libraries and the Internet: Human, Database, and Domain Factors, Bates M.J., 1996. This document is http://is.gseis.ucla.edu/research/mjbates.html.

[BERNERS-LEE98]

What the Semantic Web can represent, Berners-Lee T., 1998. This document is http://www.w3.org/DesignIssues/RDFnot.html.

[CC/PP]

Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies, Klyne G., Reynolds F., Woodrow C., Ohto H., Hjelm J., Butler M., Tran, L., W3C Recommendation, 15 January 2004. This version is http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/. The latest version is http://www.w3.org/TR/CCPP-struct-vocab/.

[CG]

Conceptual Graphs, Sowa J., ISO working document ISO/JTC1/SC32/WG2 N 000, 2 April 2001 (work in progress). Available at http://users.bestweb.net/~sowa/cg/cgstand.htm.

[CHARMOD]

Character Model for the World Wide Web 1.0, Dürst M., Yergeau F., Ishida R., Wolf M., Freytag A., Texin T. (Editors), World Wide Web Consortium, 20 February 2002 (work in progress). This version is http://www.w3.org/TR/2002/WD-charmod-20020220/. The latest version is http://www.w3.org/TR/charmod/.

[CIM]

Common Information Model (CIM): CIM 10 Version, EPRI, Palo Alto, CA: 2001, 1001976. This document is available at http://www.epri.com/attachments/286161_1001976(1).pdf (267pp.).

[COWAN]

Metadata, Reuters Health Information, and Cross-Media Publishing , Cowan J., 2002. Presentation at Seybold New York 2002 Enterprise Publishing Conference. This document is http://seminars.seyboldreports.com/seminars/2002_new_york/presentations/014/cowan_john.ppt. An accompanying transcript is http://seminars.seyboldreports.com/2002_new_york/files/transcripts/doc/transcript_EP7.doc

[DAF]

Utility Management System (UMS) Data Access Facility, version 2.0, Object Management Group, November 2002. This document is available at http://www.omg.org/technology/documents/formal/UMS_Data_Access_Facility.htm.

[DAML+OIL]

DAML+OIL (March 2001) Reference Description, Connolly D., van Harmelen F., Horrocks I., McGuinness D.L., Patel-Schneider P.F., Stein L.A., World Wide Web Consortium, 18 December 2001. This document is http://www.w3.org/TR/daml+oil-reference.

[DC]

Dublin Core Metadata Element Set, Version 1.1: Reference Description, 02 June 2003. This version is http://dublincore.org/documents/2003/06/02/dces/. The latest version is http://dublincore.org/documents/dces/.

[DIPRINC]

Device Independence Principles. Gimson, R., Finkelstein, S., Maes, S., Suryanarayana, L., World Wide Web Consortium, 18 September 2001 (work in progress). This version is http://www.w3.org/TR/2001/WD-di-princ-20010918. The latest version is http://www.w3.org/TR/di-princ/.

[DWZ01]

XML for CIM Model Exchange , deVos A., Widergreen S.E., Zhu J., Proc. IEEE Conference on Power Industry Computer Systems, Sydney, Australia, 2001. This document is http://www.langdale.com.au/PICA/.

[GO]

Gene Ontology: tool for the unification of biology, The Gene Ontology Consortium, Nature Genetics, Vol. 25: 25-29, May 2000. Available at http://www.geneontology.org/GO_nature_genetics_2000.pdf

[GRAY]

Logic, Algebra and Databases, Gray P., Ellis Horwood Ltd., 1984. ISBN 0-85312-709-3, 0-85312-803-0, 0-470-20103-7, 0-470-20259-9.

[HAYES]

In Defense of Logic, Hayes P., Proceedings from the International Joint Conference on Artificial Intelligence, 1975, San Francisco. Morgan Kaufmann Inc., 1977. Also in Computation and Intelligence: Collected Readings, Luger G. (ed), AAAI press/MIT press, 1995. ISBN 0-262-62101-0.

[KIF]

Knowledge Interchange Format, Genesereth M., draft proposed American National Standard NCITS.T2/98-004. Available at http://logic.stanford.edu/kif/dpans.html.

[LBASE]

LBase: Semantics for Languages of the Semantic Web, Guha R. V., Hayes P., W3C Note, 10 October 2003. This version is http://www.w3.org/TR/2003/NOTE-lbase-20031010/. The latest version is http://www.w3.org/TR/lbase/.

[LUGER]

Artificial Intelligence: Structures and Strategies for Complex Problem Solving (3rd ed.), Luger G., Stubblefield W., Addison Wesley Longman, 1998. ISBN 0-805-31196-3.

[MATHML]

Mathematical Markup Language (MathML) Version 2.0, Carlisle D., Ion P., Miner R., Poppelier N. (Editors); Ausbrooks R., Buswell S., Dalmas S., Devitt S., Diaz A., Hunter R., Smith B., Soiffer N., Sutor R., Watt S. (Principal Authors), World Wide Web Consortium, 21 February 2001. This version is http://www.w3.org/TR/2001/REC-MathML2-20010221/. The latest version is http://www.w3.org/TR/MathML2/.

[MMS-CTR]

Multimedia Messaging Service Client Transactions Specification. WAP-206-MMSCTR-20020115-a. This document is available at http://www.openmobilealliance.org/.

[NAMEADDRESS]

Naming and Addressing: URIs, URLs, ..., Connolly D., 2002. This document is http://www.w3.org/Addressing/.

[OWL]

Az OWL Web Ontológia Nyelv – Referencia, W3C Ajánlás, 2004. február 10. Szerkesztők: Dean M., Schreiber G.; Serzők: van Harmelen F., Hendler J., Horrocks I., McGuinness D.L., Patel-Schneider P.F., Stein L.A. A legutolsó (angol nyelvű) változat URL-je: http://www.w3.org/TR/owl-ref/.

[PRISM]

PRISM: Publishing Requirements for Industry Standard Metadata, Version 1.1, 19 February 2002. The latest version of the PRISM specification is available at http://www.prismstandard.org/.

[RDFISSUE]

RDF Issue Tracking, McBride B., 2002. This document is http://www.w3.org/2000/03/rdf-tracking/.

[RDF-S]

Resource Description Framework (RDF) Schema Specification 1.0 , Brickley D., Guha, R.V. (Editors), World Wide Web Consortium. 27 March 2000. This version is http://www.w3.org/TR/2000/CR-rdf-schema-20000327/.

[RSS]

RDF Site Summary (RSS) 1.0, Beged-Dov G., Brickley D., Dornfest R., Davis I., Dodds L., Eisenzopf J., Galbraith D., Guha R.V., MacLeod K., Miller E., Swartz A., van der Vlist E., 2000. This document is http://purl.org/rss/1.0/spec.

[RUBY]

Ruby Annotation, Sawicki M., Suignard M., Ishikawa M., Dürst M., Texin T. (Editors), World Wide Web Consortium, 31 May 2001. This version is http://www.w3.org/TR/2001/REC-ruby-20010531/. The latest version is http://www.w3.org/TR/ruby/.

[SOWA]

Knowledge Representation: Logical, Philosophical and Computational Foundations, Sowa J., Brookes/Cole, 2000. ISBN 0-534-94965-7.

[SVG]

Scalable Vector Graphics (SVG) 1.1 Specification, Ferraiolo J., Fujisawa J., Jackson D. (Editors), World Wide Web Consortium, 14 January 2003. This version is http://www.w3.org/TR/2003/REC-SVG11-20030114/. The latest version is http://www.w3.org/TR/SVG11/.

[UAPROF]

User Agent Profile. OMA-WAP-UAProf-v1_1. This document is available at http://www.openmobilealliance.org/.

[WEBDATA]

Web Architecture: Describing and Exchanging Data, Berners-Lee T., Connolly D., Swick R., World Wide Web Consortium, 7 June 1999. This document is http://www.w3.org/1999/04/WebData.

[XLINK]

XML Linking Language (XLink) Version 1.0, DeRose S., Maler E., Orchard D. (Editors), World Wide Web Consortium, 27 June 2001. This version is http://www.w3.org/TR/2001/REC-xlink-20010627/. The latest version is http://www.w3.org/TR/xlink/.

[XML-SCHEMA2]

XML Schema Part 2: Datatypes, Biron P., Malhotra A. (Editors), World Wide Web Consortium. 2 May 2001. This version is http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. The latest version is http://www.w3.org/TR/xmlschema-2/.

[XPACKAGE]

XML Package (XPackage) 1.0 , Wilson G., Editor's Working Draft, 6 March 2003. This version is http://www.xpackage.org/specification/xpackage-draft-20030306.html. The latest version is http://www.xpackage.org/specification/.