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/.