1.1 Het Resource Description Framework (RDF)

Transcriptie

1 Het semantisch web 1 Het Semantisch Web is bedoeld om de opvolger te worden van het huidige World Wide Web. De voornaamste betrachting is om ervoor te zorgen dat er veel meer mogelijk wordt door een internet te bouwen dat niet langer uitsluitend voor mensenogen bedoeld is, maar waarop de informatie ook gemakkelijk door automatische tools verwerkt kan worden. Laten we deze noodzaak eens illustreren met een voorbeeldje. In de komische tv-serie The Big Bang Theory speelt het personage Sheldon een hoofdrol. In de serie is dit personage afkomstig uit Texas. Veronderstel nu dat we ons afvragen of de acteur die dit personage vertolkt misschien in het echt zelf ook uit Texas komt. Moesten we bijvoorbeeld beschikken over een relationele databank met daarin gegevens over acteurs (in de actor tabel) en de rollen die zij spelen in tv-series (in de cast tabel), dan zouden we onze nieuwsgierigheid kunnen bevredigen met een eenvoudige SQL-query: select birthplace from actor where actor_id = (select actor_id from cast where tvshow = "The Big Bang Theory" and role = "Sheldon Cooper"); Op het (huidige) WWW is het echter moeilijker om deze informatie terug te vinden. Dit komt doordat webpagina s vandaag de dag enkel maar bestaan uit tekst in een natuurlijke taal zoals Engels of Nederlands. Dit zorgt ervoor dat het overgrote deel van de informatie die in zo n webpagina vervat zit, niet begrepen kan worden door computerprogramma s. Het resultaat is dat het opvragen van informatie wel moet verlopen via de uiterst domme methode van de keyword search, waarbij enkel maar gekeken wordt of een bepaalde zoekterm zich toevallig letterlijk in een webpagina bevindt. Voor ons voorbeeld, zouden we bijvoorbeeld de zoekterm Big Bang Theory kunnen gebruiken. Dit zal ons een hoop pagina s opleveren, waarvan sommige over een natuurkundige theorie zullen gaan en andere over de tv-serie die we in gedachten hebben. We moeten dan handmatig één van de juiste pagina s kiezen, waarop we dan bijvoorbeeld volgende informatie aantreffen: Cast Johnny Galecki Jim Parsons Kaley Cuoco... Leonard Hofstadter Sheldon Cooper Penny Een computerprogramma ziet hier gewoon een <table> met daarin wat <tr>-en en <td>-en, maar wij kunnen uit deze tabel de informatie halen die we nodig hebben, namelijk dat de rol van Sheldon in The Big Bang Theory vertolkt wordt door ene Jim Parsons. Dit geeft ons dan een nieuwe zoekterm, die ons dan uiteindelijk in staat zal stellen om de informatie terug te vinden die we zoeken. 1

2 2 HOOFDSTUK 1. HET SEMANTISCH WEB De bedoeling van het Semantisch Web is nu om een nieuwe versie van het WWW te bouwen, waarin dit soort van opzoekwerk geautomatiseerd kan worden. Het mag uit dit voorbeeld duidelijk zijn dat eenvoudige keyword search hiervoor niet langer zal volstaan. In plaats daarvan zal de vraag van de gebruiker gesteld moeten worden in een vorm die meer lijkt op het SQL-statement van hierboven. Daarnaast zal er echter ook een inspanning nodig zijn van de content providers die webpagina s op het Semantisch Web zetten: zij zullen dit niet langer (enkel maar) in een formaat doen dat bedoeld is om door mensen gelezen te worden, maar ze zullen dit (ook) in een gestructureerd, computerleesbaar formaat moeten doen. Hierdoor zal dus bijvoorbeeld de informatie dat Jim Parsons de rol van Sheldon Cooper speelt ook toegankelijk worden voor een computeralgoritme, en zal het Semantisch Web dus een functionaliteit kunnen vervullen die gelijkaardig is aan die van een databank. Een belangrijk verschilpunt met een gewone databank is en blijft natuurlijk wel de gedistribueerde aard van het web: in het Semantisch Web zal informatie van op verschillende webpagina s, geschreven door verschillende personen, gecombineerd moeten worden. We kunnen vanzelfsprekend niet verwachten dat alle personen die, bijvoorbeeld, informatie over tv-series online willen zetten, op voorhand even met elkaar gaan overleggen om een gezamenlijke databank-structuur af te spreken. Er is dus, met andere woorden, nood aan een manier op gegevens op te slaan, die: flexibel is, zodat elke gebruiker zijn eigen voorstellingswijze kan kiezen; algemeen is, zodat gegevens over eender welk onderwerp kunnen worden opgeslagen. toelaat dat gegevens gemakkelijk uitgewisseld kunnen worden; toelaat dat gegevens uit verschillende bronnen eenvoudig met elkaar gecombineerd kunnen worden. Hiervoor wordt RDF gebruikt. 1.1 Het Resource Description Framework (RDF) Het RDF formaat tracht als volgt aan de hierboven aangehaalde vereisten tegemoet te komen: Het is een tekstgebaseerd formaat: een RDF bestand bevat enkel maar ASCII tekst. Dit betekent dat gegevens kunnen uitgewisseld en bekeken worden zonder dat men zich zorgen hoeft te maken over binaire encoderingen. Een RDF bestand bestaat uit een verzameling feiten. Dit betekent dat verschillende RDF bestanden zonder problemen samengevoegd kunnen worden, door ze gewoon achter elkaar te plakken. Zo n samengevoegd bestand bevat dan gewoon al de feiten die in beide afzonderlijke bestanden voorkwamen. RDF maakt gebruik van naamruimtes, zodat gegevens uit verschillende bronnen gecombineerd kunnen worden, zonder het risico op name clashes, waarbij dezelfde naam door verschillende bronnen in een andere betekenis gebruikt zou worden. Zoals al aangegeven door de naam van dit formaat (Resource Description Framework), dient RDF voor het beschrijven van resources. De volgende sectie gaat dieper in op wat deze resources juist zijn en hoe we ze kunnen identificeren.

3 1.1. HET RESOURCE DESCRIPTION FRAMEWORK (RDF) Resources en URIs Net zoals een databank, bevat een RDF bestand informatie over entiteiten. En, net zoals in een databank, wordt elke entiteit geïdentificeerd door een primaire sleutel. In RDF terminologie wordt een entiteit een resource genoemd en de primaire sleutel van zo n resource heet een URI (Uniform Resource Identifier). Een speciaal geval van zo n URI is de ons allemaal welbekende URL (Uniform Resource Locator). Een URL is niets anders dan de URI van een resource die toevallig een webpagina is. Aangezien een webpagina gedownload kan worden via het internet, volstaat het om diens primaire sleutel aan een webbrowser te geven, om de pagina te zien te krijgen. Andere resources, zoals bijvoorbeeld de actrice Kaley Cuoco, kunnen natuurlijk niet zomaar gedownload worden via het internet, maar we kunnen er wel informatie over opslaan. De URI die verwijst naar deze actrice is dus geen URL, aangezien deze URI een resource identificeert die zich buiten het internet bevindt. Net als primaire sleutels in een databank, moeten URIs natuurlijk uniek zijn. Met andere woorden, als we een URI gebruiken om te verwijzen naar de actrice Kaley Cuoco, dan moeten we er zeker van kunnen zijn dat er op het hele internet nergens iemand anders dezelfde URI gebruikt om naar een andere resource te verwijzen. Om dit te verzekeren, worden URIs geconstrueerd volgens hetzelfde stramien als URLs. Er is immers al een globale structuur opgezet, die verzekert dat de controle over elke bepaalde URL steeds bij slechts één instantie ligt. Bijvoorbeeld, de auteur van deze tekst heeft, als enige op de wereld, controle over deze URL: joost. Als ik zelf een URI wil verzinnen, kan ik deze dus best laten beginnen met deze URL, en dan ben ik zeker dat niemand anders ooit toevallig dezelfde URI zal gebruiken. Dit wordt dan bijvoorbeeld zoiets: Deze URI kan ik nu gebruiken om naar hartelust informatie over Kaley Cuoco op te slaan. Deze informatie zal echter alleen maar bruikbaar zijn voor mensen die deze URI ook kennen. Daarom doe ik er misschien beter aan om niet mijn eigen URI te verzinnen, maar om een bestaande URI te herbruiken. Als we even rondzoeken op het web, merken we immers dat er al een URI bestaat die naar precies deze actrice verwijst, namelijk deze: We zien hier meteen ook dat er dus toch een verschil is tussen primaire sleutels in een databank en URIs: hoewel elke URI steeds een naam is voor een unieke resource, kan dezelfde resource wel verschillende URIs hebben. Dit is ook logisch, aangezien het omgekeerde onmogelijk af te dwingen zou zijn doorheen het ganse internet. Software die gebruik maakt van RDF zal dus in staat moeten zijn om in bepaalde gevallen te concluderen dat twee verschillende URIs toch naar dezelfde resource verwijzen, net zoals wij bijvoorbeeld in een dagdagelijks gesprek plots tot de conclusie kunnen komen dat de actrice Kaley Cuoco en Penny uit de Big Bang Theory ook gewoon maar twee verschillende namen voor dezelfde vrouw zijn Drietallen De atomaire feiten in een RDF bestand zijn zogenaamde drietallen of RDF triples. Zo n drietal bestaat uit: 1. een entiteit waarover het feit gaat; deze wordt het subject of onderwerp van het feit genoemd. 2. een relatie die deze entiteit heeft met een andere entiteit; dit wordt de relatie of het predikaat van het feit genoemd.

4 4 HOOFDSTUK 1. HET SEMANTISCH WEB 3. de andere entiteit in kwestie; dit wordt het object of (lijdend) voorwerp genoemd. Merk op dat er in RDF dus enkel maar sprake is van binaire relaties. In een RDF bestand, gaan we alledrie deze componenten dus ook het predikaat! voorstellen door middel van een URI. Dit is geen toeval: het is immers zo dat RDF geen strikt onderscheid maakt tussen entiteiten en relaties. Predikaten worden dus ook gewoon gezien als een soort van resources en, meer nog, dezelfde URI kan in verschillende drietallen nu eens de rol van subject/object spelen en dan weer de rol van predikaat. Hier is een voorbeeld van een RDF drietal: Dit drietal vertelt ons dat Kaley Cuoco (onderwerp) de rol speelt van (predikaat) Penny uit The Big Bang Theory (voorwerp). Het valt hierbij op dat het gebruik van URIs zorgt voor een notatie die nogal veel schrijfwerk vereist. Om hier een mouw aan te passen, gebruiken we, net zoals in XML, een notatie waarbij naamruimtes kunnen afgekort worden door een prefix. Prefix dbpedia dbprop jve Naamruimte joost/resource Met deze prefixen, kunnen we ons drietal nu wat korter noteren: dbpedia:kaley_cuoco dbprop:portrayer dbpedia:penny_(the_big_bang_theory) RDF bestanden worden vaak visueel voorgesteld door een gelabelde grafe. Het bovenstaande drietal zou er dan bijvoorbeeld zo uitzien: dbpedia:kaley_cuoco dbprop:portrayer dbpedia:penny_(the_big_bang_theory) Het bovenstaande drietal is te vinden in de RDF databanken (triple store) van DBPedia. Het kan echter probleemloos gecombineerd worden met feiten uit een andere RDF databank, zoals bijvoorbeeld: jve:joost_vennekens jve:fan dbpedia:kaley_cuoco Deze nieuwe informatie kan nu gewoon bijgetekend worden bij de grafe die we al hadden. Op deze manier kan informatie uit verschillende bronnen en over URIs uit verschillende naamruimten probleemloos gecombineerd worden. dbpedia:kaley_cuoco dbprop:portrayer dbpedia:penny_(the_big_bang_theory) jve:fan jve:joost_vennekens

5 1.1. HET RESOURCE DESCRIPTION FRAMEWORK (RDF) Letterlijke waardes (literals) We hebben tot dusver al gezien hoe we RDF drietallen kunnen gebruiken om relaties tussen entiteiten te beschrijven. Daarnaast is het natuurlijk ook mogelijk om informatie bij te houden over de attributen van een entiteit. Ook dit kan met een drietal. Het verschil is dat het voorwerp van zo n drietal nu niet langer een naam voor een resource zal zijn, maar gewoon een letterlijke waarde, die enkel maar zichzelf voorstelt. In dit geval, noemen we het predikaat van het feit ook wel een eigenschap (property) en het voorwerp de waarde van deze eigenschap. We herkennen zo n letterlijke waarde aan het feit dat ze tussen aanhalingstekens staat. Zo bevat DBPedia bijvoorbeeld volgende informatie over een bijnaam van Penny uit The Big Bang Theory: dbpedia:penny_(the_big_bang_theory) dbpprop:nickname "Bestie" Merk op zo n letterlijke waarde natuurlijk niet in een naamruimte zit, aangezien ze geen naam is maar een waarde. In de grafische voorstelling van een RDF databank, worden letterlijke waardes in een rechthoek getekend. dbpedia:kaley_cuoco dbprop:portrayer dbpedia:penny_(the_big_bang_theory) jve:fan dbpprop:nickname jve:joost_vennekens Bestie Normaalgezien zijn letterlijke waardes gewoon strings. Het is echter ook mogelijk om een letterlijke waarde te annoteren met een bepaald datatype. Dit gebeurt door het datatype in kwestie er achter te schrijven, gescheiden door het verbindingsteken ^^. Bijvoorbeeld: dbpedia:kaley_cuoco dbprop:dataofbirth "1985"^^< Hier wordt gedeclareerd dat 1985 een letterlijke waarde is van het XSD datatype integer. Dit betekent bijvoorbeeld dat deze waarde hetzelfde is als deze letterlijke waarde: " "^^< Zonder het bijhorende datatype, zou dit niet het geval zijn. Naast annotaties die het datatype van een letterlijke waarde specifiëren, zijn er ook annotaties mogelijk die aangeven in welke taal een string geschreven is. Hiervoor wordt dan het gebruikt: jve:joost_vennekens dbpedia:teacher "industriele ingenieurswetenschappen"@nl Anonieme knopen Zoals we al gezien hebben, kunnen in RDF enkel maar binaire relaties voorgesteld worden. Dit is gelukkig geen echte beperking, aangezien we ook relaties met meer argumenten kunnen encoderen door het invoeren van bijkomende entiteiten. We hebben hier al een voorbeeld van gezien, namelijk met de relatie dat een acteur een rol speelt in een serie. In een relationele databank zouden we dit voorstellen door een drievoudige relatie:

6 6 HOOFDSTUK 1. HET SEMANTISCH WEB Acteur Serie Rol Jim Parsons The Big Bang Theory Sheldon Kaley Cuoco The Big Bang Theory Penny Kaley Cuoco 8 Simple Rules Karin In RDF gaan we dit oplossen door twee entiteiten samen te nemen tot een nieuwe entiteit, zoals we bijvoorbeeld The Big Bang Theory en Penny hebben samengenomen tot Penny_(The_Big_Bang_Theory). dbpedia:kaley_cuoco dbprop:portrayer dbprop:name dbpedia:penny_(the_big_bang_theory) dbpedia-owl:series Penny dbpedia:the_big_bang_theory In dit geval heeft deze nieuwe entiteit ook een eigen naam gekregen in de dbpedia naamruimte. Vaak is het echter niet nodig om zo n nieuwe entiteit ook een globale naam te geven. In dat geval kunnen we een anonieme knoop (of blank node) gebruiken. Zo n anonieme knoop zit in een namaak-naamruimte met als naam een enkele underscore _. Zo zegt volgende database dat Kaley Cuoco iemand speelt die als naam Penny heeft, zonder dat die iemand een eigen URI krijgt. dbpedia:kaley_cuoco dbprop:portrayer _:anon _:anon dbpprop:name "Penny" Zoals we in dit voorbeeld zien, kan de anonieme knoop _:anon wel herbruikt worden binnen hetzelfde RDF bestand, maar niet daarbuiten. Het is, met andere woorden, een lokale naam en geen globale Formaten voor RDF Als we een verzameling RDF drietallen willen neerschrijven voor gebruik door een computerprogramma, dan zullen we dit een bepaald formaat moeten doen. Er zijn hiervoor een aantal opties beschikbaar. Het N3 formaat. Dit is het meest mens-vriendelijke formaat. Een RDF drietal ziet er hier gewoon uit zoals in onze voorbeelden tot dusver, met dan dat verschil dat elk drietal beëindigd moet worden met een punt. Daarnaast is er ook de om de prefix van een naamruimte te definiëren. De bestandsextensie van het N3 formaat is dbpedia: rdf: foaf: < dbpedia:howard_wolowitz rdf:type foaf:person. dbpedia:howard_wolowitz dbpprop:religion dbpedia:judaism. dbpedia:howard_wolowitz dbpprop:occupation dbpedia:aerospace_engineer. dbpedia:howard_wolowitz dbpprop:nickname "Froot Loops"@en. dbpedia:howard_wolowitz dbpprop:nickname "Wolowizard"@en. Om schrijfwerk te besparen, zijn er nog twee afkortingen mogelijk: de puntkomma mag gebruikt worden om twee opeenvolgende drietallen met hetzelfde onderwerp te scheiden, en de komma mag gebruikt worden om twee opeenvolgende drietallen met hetzelfde onderwerp én dezelfde relatie te scheiden. Zo kan de bovenstaande verzameling drietallen herschreven worden tot:

7 1.1. HET RESOURCE DESCRIPTION FRAMEWORK (RDF) 7 dbpedia:howard_wolowitz rdf:type foaf:person; dbpprop:religion dbpedia:judaism; dbpprop:occupation dbpedia:aerospace_engineer; dbpprop:nickname "Froot Loops"@en, "Wolowizard"@en RDF/XML In de praktijk zijn de meeste RDF bestanden in de eerste plaats bedoeld om door computerprogramma s gelezen en verwerkt te worden. Hiervoor wordt dan meestal niet het bovenstaande N3 formaat gebruikt, maar wel een XML-gebaseerd formaat. In deze voorstelling, bestaat een RDF bestand uit een <RDF> wortelelement. Een drietal wordt dan voorgesteld door een <Description> element, dat een kind is van dit wortelelement. Het onderwerp van het drietal wordt gegeven als de waarde van het attribuut about van dit <Description> element. Het <Description> element zelf heeft precies één kind, namelijk een XML element dat de relatie van het drietal voorstelt. Het voorwerp, tot slot, wordt gegeven in het attribuut resource van dit element. Samengevat, ziet zo n bestand er dus als volgt uit: <RDF> <Description about="onderwerp"> <relatie resource="voorwerp" />... </RDF> In de praktijk is het natuurlijk nog net iets ingewikkelder dan dit, omdat zowel de RDFtags (RDF, Description,... ) zelf, als de URIs waarover de opgeslagen informatie gaat, in een bepaalde XML naamruimte moeten zitten. Een volledige voorbeeld zal er dus als volgt uitzien: <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns:foaf=" xmlns:dbpprop=" <rdf:description rdf:about=" <rdf:type rdf:resource=" /> <rdf:description rdf:about=" <dbpprop:religion rdf:resource=" /> <rdf:description rdf:about=" <dbpprop:occupation rdf:resource=" />... </rdf:rdf> De XML voorstelling van een letterlijke waarde ziet er een beetje anders uit. In plaats van een attribuut resource="uri" toe te voegen aan het XML-element dat de relatie voorstelt, komt een letterlijke waarde gewoon als inhoud van dit XML-element:

8 8 HOOFDSTUK 1. HET SEMANTISCH WEB <Description about="onderwerp"> <relatie>letterlijke waarde</relatie> Als de letterlijke waarde een type (^^type) of een taal heeft, kan dit worden opgenomen door een attribuut rdf:datatype of xml:lang bij het <relatie>-element. We kunnen de XML versie van ons voorbeeld dus vervolledigen met volgende twee drietallen: <rdf:description rdf:about=" <dbpprop:nickname xml:lang="en">froot Loops</dbpprop:nickname> <rdf:description rdf:about=" <dbpprop:nickname xml:lang="en">wolowizard</dbpprop:nickname> Het is opnieuw mogelijk om verschillende drietallen met hetzelfde onderwerp samen te nemen. <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns:foaf=" xmlns:dbpprop=" <rdf:description rdf:about=" <rdf:type rdf:resource=" /> <dbpprop:religion rdf:resource=" /> <dbpprop:occupation rdf:resource=" /> <dbpprop:nickname xml:lang="en">froot Loops</dbpprop:nickname> <dbpprop:nickname xml:lang="en">wolowizard</dbpprop:nickname> </rdf:rdf> Laten we nu nog wat extra informatie toevoegen, namelijk het feit dat de acteur Simon Helberg dit personage speelt. Dit kan natuurlijk door gewoon een tweede <Description> element toe te voegen. <rdf:rdf...> <rdf:description rdf:about=" <dbprop:portrayer rdf:resource=" /> <rdf:description rdf:about=" <dbpprop:occupation rdf:resource=" />... </rdf:rdf> Hier kunnen we dus zien dat Simon Helberg een personage speelt dat Lucht- en Ruimtevaart Ingenieur is, doordat de URI van Howard Wolowitz deze twee feiten met elkaar verbindt. Er is hiervoor ook een kortere notatie toegestaan, waarbij we de informatie over Howard Wolowitz rechtstreeks in de beschrijving van Simon Helberg plaatsen:

9 1.1. HET RESOURCE DESCRIPTION FRAMEWORK (RDF) 9 <rdf:rdf...> <rdf:description rdf:about=" <dbpprop:portrayer> <rdf:description rdf:about=" <dbpprop:occupation rdf:resource=" />... </dbpprop:portrayer> </rdf:rdf> Deze notatie wordt ook wel striped of gestreepte notatie genoemd, omdat er hier steeds een <Description> element wordt afgewisseld met een relatie. Deze notatie geeft aanleiding tot verschillende manieren om dezelfde grafe-structuur te serializeren. Veronderstel bijvoorbeeld dat het volgende seizoen van The Big Bang Theory een verhaallijn zou bevatten waarin Penny een doctoraat gaat maken met de auteur van deze tekst als promotor. dbpedia:kaley_cuoco jve:fan jve:joost_vennekens dbprop:portrayer jve:promotor dbpedia:penny_(the_big_bang_theory) We kunnen deze grafe nu op verschillende manieren serializeren in de streepjesnotatie, afhankelijk van welk startpunt we nemen. Twee voorbeelden (in afgekorte notatie): <Description about="joost"> <Description about="kaley"> <fan> <portrayer> <Description about="kaley"> <Description about="penny"> <portrayer> <promotor> <Description about="penny"> <Description about="joost"> <promotor resource="joost" /> <fan resource="kaley" /> </portrayer> </portrayer> </fan> </fan> Daarnaast blijft het natuurlijk ook nog steeds mogelijk om gewoon de drie drietallen naast elkaar te beschrijven. <Description about="kaley"> <portrayer resource="penny" /> <Description about="penny"> <promotor resource="joost"> <Description about="joost"> <fan resource="kaley" /> Laat ons deze twee opties ook eens naast elkaar zetten: <Description about="kaley"> <portrayer> <Description about="penny"> <promotor> <Description about="joost"> <fan resource="kaley" /> </portrayer> </fan>

10 10 HOOFDSTUK 1. HET SEMANTISCH WEB Een voordeel van de gestreepte notatie is dat we hierin gemakkelijk anonieme knopen kunnen gebruiken, door gewoon het attribuut rdf:about van een genest <description> element weg te laten. Vanzelfsprekend heeft deze manier om anonieme knopen te noteren wel haar beperkingen, aangezien we een anonieme knoop nu dus helemaal geen naam meer geven, zelfs geen lokale, en we er dus niet naar kunnen terugverwijzen. Dit zal een probleem zijn als dezelfde anonieme knoop bijvoorbeeld het voorwerp moet zijn van verschillende drietallen, of wanneer we zo n anonieme knoop zouden willen kiezen als startpunt voor het serialiseren van een lus in de grafe. Daarom bestaat er ook een manier om een anonieme knoop toch een lokale naam te geven. Dit gebeurt door het attribuut nodeid te gebruiken in plaats van het attribuut about of het attribuut resource. <rdf:description rdf:nodeid="blank1"> <dbpprop:portrayer> <rdf:description rdf:about=" <jve:promotor> <rdf:description rdf:about=" <jve:fan nodeid="blank1" /> </dbpprop:portrayer> </jve:fan> 1.2 Linked Data Tegenwoordig spreekt men vaak over Linked Data. Met dit modewoord wordt eigenlijk iets heel eenvoudigs bedoeld. We weten al dat in een normaal RDF bestand alle resources geïdentificeerd worden door een URI, die eruit ziet als een URL. In tegenstelling tot een URL, is een URI gewoon een naam en hoeft er op de overeenkomstige locatie niets te vinden te zijn. Linked Data houdt nu eenvoudigweg in dat we toch gaan zorgen dat alle URIs die we introduceren overeenkomen met een URL waarop er informatie te vinden is over de resource die door de URI geïdentificeerd wordt. Als je bijvoorbeeld de volgende URI intikt in een webbrowser: dan zal je effectief een webpagina zien verschijnen met daarop informatie over het personage in kwestie. Onderaan de pagina zal je ook een link terugvinden waarmee deze informatie o.a. in RDF/XML of N3 formaat gedownload kan worden. Deze bestanden bevinden zich op DBPedia altijd op een vaste locatie, die je kan afleiden uit de URI door resource te veranderen in data en een bestandsextensie naar keuze (.rdf of.n3) toe te voegen: Als je zo n bestand download, zal je daarin weer andere URIs terugvinden, en ook met deze URIs komen dan weer URLs overeen waarop je over die concepten dan weer informatie kan vinden. Op deze manier wordt het hele web dus een gedistribueerde databank, waarvan je deeltjes kan downloaden naar gelang je ze nodig hebt.

11 1.3. APACHE JENA Apache Jena Een standaard bibliotheek voor het werken met RDF bestanden in Java is het Jena pakket van Apache. Dit valt te downloaden van Compileren en uitvoeren van programma s die gebruik maken van dit pakket vereist simpelweg dat een aantal *.jar archieven worden toegevoegd aan het classpath waarin de java omgeving zijn pakketen gaat zoeken. Van op de commandline kan dit bijvoorbeeld zo: javac -cp ".:apache-jena /lib/*" Test.java java -cp ".:apache-jena /lib/*" Test Indien je gebruikmaakt van een IDE, moeten deze bibliotheken in de configuratie hiervan ook ergens worden toegevoegd. Deze bibliotheek bevat een klasse Model die RDF databank voorstelt. Een dergelijk model moet worden aangemaakt dmv. een ModelFactory en kan dan gevuld worden met de gegevens uit één of meerdere bestanden. Het volgend voorbeeld leest een RDF bestand in, en print dan het resulterende model naar standaard uitvoer. import com.hp. hpl. jena. rdf. model. * ; import java. u t i l. * ; import java. io. * ; public class Test { prviate static final String bestandsnaam = " test. rdf " ; public static void main ( String args [ ] ) { Model model = ModelFactory. createdefaultmodel ( ) ; model. read ( bestandsnaam ) ; // write i t t o standard out model. write ( System. out ) ; Een Model bevat een aantal Resources, die kunnen worden opgevraagd op basis van hun URI: Resource howard = model. getresource ( " http :// dbpedia. org/resource/howard_wolowitz " ) ; Naast Resources heeft een Model ook Properties (= predikaten), die eveneens op basis van URI worden opgevraagd: Property nickname = model. getproperty ( " http :// dbpedia. org/property/nickname" ) ; De verschillende eigenschappen van een Resource kunnen nu worden opgevraagd met zijn methode Statement getproperty ( Property p ) In tegenstelling tot wat je op basis van de naam van deze methode zou verwachten, geeft ze dus géén Property terug, maar wel een Statement waarmee de opgegeven eigenschap van de resource gedefinieerd wordt. Met andere woorden, het resultaat van r.getproperty(p) is een RDF drietal, waarvan r het onderwerp is en p de relatie.

12 12 HOOFDSTUK 1. HET SEMANTISCH WEB Resource howard = model. getresource ( " http :// dbpedia. org/resource/howard_wolowitz " ) ; Property nickname = model. getproperty ( " http :// dbpedia. org/property/nickname" ) ; Statement d r i e t a l = howard. getproperty ( nickname ) ; De drie onderdelen van een Statement kunnen worden opgevraagd met volgende methodes: Resource getsubject ( ) Property getpredicate ( ) RDFNode getobject ( ) De klasse RDFNode heeft natuurlijk twee subklassen, namelijk Resource en Literal. Een Literal stelt een letterlijke waarde voor, en heeft verschillende methodes om deze waarde te (proberen) op te vragen als een of ander Java datatype (getstring(), getint(), getfloat()). Statement d r i e t a l = howard. getproperty ( nickname ) ; RDFNode voorwerp = d r i e t a l. getobject ( ) ; String bijnaam = ( ( L i t e r a l ) voorwerp ). getstring ( ) ) ; De klasse Statement biedt ook een aantal convenience methods aan die ons toelaten deze expliciete typecast te vermijden. L i t e r a l l = d r i e t a l. g e t L i t e r a l ( ) ; String n = d r i e t a l. getstring ( ) ; Deze methodes proberen dus telkens het voorwerp van het RDF drietal op te vragen in een bepaald formaat. Het volgend voorbeeld laat zien hoe we kunnen omgaan met een voorwerp dat een Resource is in plaats van een letterlijke waarde. Resource simon = model. getresource ( " http :// dbpedia. org/resource/simon_helberg " ) ; Property portrayer = model. getproperty ( " http :// dbpedia. org/property/ portrayer " ) ; Resource howard = simon. getproperty ( portrayer ). getresource ( ) ; Property nickname = model. getproperty ( " http :// dbpedia. org/property/nickname" ) ; String bijnaam = howard. getproperty ( nickname ). getstring ( ) ; Tot dusver hebben we telkens maar één bijnaam opgevraagd, ook al zitten er in ons RDF bestand eigenlijk twee. Het effect is dat we willekeurig één van deze twee te zien krijgen. Als we alle bijnamen willen overlopen, moeten we in plaats van de methode getproperty gebruik maken van listproperties. Het resultaat hiervan is een iterator die ons toelaat om te itereren over alle Statements met het juiste onderwerp en predikaat. Resource howard = model. getresource ( " http :// dbpedia. org/resource/howard_wolowitz " ) ; Property nickname = model. getproperty ( " http :// dbpedia. org/property/nickname" ) ; Iterator <Statement> i t = howard. l i s t P r o p e r t i e s ( nickname ) ; while ( i t. hasnext ( ) ) { Statement d r i e t a l = ( Statement ) i t. next ( ) ; String bijnaam = d r i e t a l. getstring ( ) ; System. out. println ( "Een bijnaam : " + bijnaam ) ; Tot dusver hebben we het Model steeds gevuld met data uit één lokaal bestand. Het is echter ook mogelijk om een meerdere bestanden te laden in hetzelfde model, en deze hoeven zich ook niet lokaal te bevinden. In onderstaand voorbeeld combineren we gegevens uit twee verschillende RDF bestanden op het internet, om de Nederlandse naam voor het beroep van een persoon (bv. Leonard_Hofstadter) te ontdekken. We maken in dit voorbeeld ook gebruik van de methode getlanguage() uit de klasse Literal, waarmee de taal van een letterlijke waarde kan worden opgevraagd (zoals gegeven door het lang-attribuut in XML, of door de "string"@taal notatie in N3).

13 1.3. APACHE JENA 13 public class Test { private static String changeuri ( String o r i g ) { return orig. replace ( "/resource/", "/data/" ) + ". rdf " ; public static void main ( String args [ ] ) { Model model = ModelFactory. createdefaultmodel ( ) ; String URI = " http ://dbpedia. org/resource/" + args [ 0 ] ; model. read ( changeuri ( URI ) ) ; Resource persoon = model. getresource ( URI ) ; Property occupation = model. getproperty ( " http :// dbpedia. org/property/occupation " ) ; Resource beroep = persoon. getproperty ( occupation ). getresource ( ) ; model. read ( changeuri ( beroep. tostring ( ) ) ) ; Property label = model. getproperty ( " http :// org/2000/01/rdf schema#label " ) ; Iterator <Statement> i t = beroep. l i s t P r o p e r t i e s ( label ) ; Statement s ; String lang ; while ( i t. hasnext ( ) ) { s = i t. next ( ) ; lang = s. g e t L i t e r a l ( ). getlanguage ( ) ; i f ( lang. equals ( " nl " ) ) System. out. println ( s. getstring ( ) ) ;

14 14 HOOFDSTUK 1. HET SEMANTISCH WEB 1.4 Labo Info over jezelf Maak een RDF/XML bestand met daarin informatie over jezelf. Geef jezelf daarvoor een URI van volgende vorm: exxx We gebruiken een aantal relaties die allemaal in de naamruimte zitten: Relatie VCard fn adr locality streetaddress koppelt een persoon aan een naamkaartje geeft de naam van de persoon over wie het naamkaartje gaat geeft het adres dat bij een naamkaartje hoort geeft de gemeente die bij een adres hoort geeft de straatnaam en huisnummer die bij een adres hoort geeft het adres dat bij een naamkaartje hoort Om gemeentes voor te stellen, maken we geen gebruik van letterlijke waardes, maar wel van een dbpedia URI, zoals bijvoorbeeld: (Als er toevallig over jouw gemeente geen informatie op DBPedia staat, zoek dan een naburige gemeente waarvoor dit wel het geval is.) Je kan je resulterende RDF bestand laten controleren (en trouwens ook visualiseren) door: Als alles klopt, zet je bestand dan online op volgende locatie: exxx/data.rdf Info over je buurman Voeg aan het bestand een bijkomend drietal toe, dat aangeeft wie in dit labo jouw buurman is. Gebruik hiervoor de relatie: Schrijf nu een Apache Jerna programma dat uit jouw eigen RDF bestand en dat van je collega s volgende informatie ophaalt: De URI van je eigen gemeente. De URI van je buurman. De naam van je buurman. Schrijf tot slot een programma dat ook informatie van DBPedia kan combineren met jouw eigen RDF bestanden om volgende informatie op te vragen: De burgemeester van jouw eigen gemeente. De burgemeester van de gemeente van jouw buurman.

15 SPARQL 2 Zoals in het vorig hoofdstuk gezien, kunnen we gegevens opvragen uit een (combinatie van) RDF-bestand(en), door de bijhorende grafe te doorlopen met een Java programma. Dit is natuurlijk een repetitieve taak. Om niet voor elke vraag die we hebben een nieuwe Java programma te moeten schrijven, kunnen we gebruik maken van SPARQL. Deze afkorting is een recursief acroniem voor SPARQL Protocol and RDF Query Language. Het is essentieel een taal die toelaat om patronen te beschrijven, die dan kunnen opgezocht worden in RDF grafes. 2.1 De basis Eén van de eerste dingen die we ons in het hoofdstuk rond RDF hebben afgevraagd, was welke acteur de rol van Sheldon Cooper speelt. Hier waren we dus op zoek naar volgend patroon in een RDF grafe: dbprop:portrayer dbpedia:sheldon_cooper? Als we in een concrete RDF-grafe dit patroon kunnen terugvinden, dan vinden we het antwoord dat we zoeken op de plaats van het vraagteken. In SPARQL beschrijven we deze zoekopdracht als volgt: select?x where { dbpedia:sheldon_cooper dbpprop:portrayer?x. In het where-gedeelte beschrijven we het patroon dat we willen zoeken. Hierbij is?x een plaatshouder, die zal overeenkomen met eender welke knoop. In het select-stuk specifiëren we dan welke van plaatshouders in het patroon het antwoord bevat waarnaar we op zoek zijn. Normaalgezien begint een SPARQL query ook met het declareren van een aantal naamruimtes: prefix dbpedia: < prefix dbpprop: < select?x where { dbpedia:sheldon_cooper dbpprop:portrayer?x. Een SPARQL query ten opzichte van de DBPedia RDF-databank kan je bijvoorbeeld laten uitvoeren op deze locatie: 15

16 16 HOOFDSTUK 2. SPARQL Deze tool kent bovendien ook een heel aantal standaard naamruimtes met hun standaard prefixen, zodat we ook deze declaraties kunnen weglaten. Het resultaat van bovenstaand query is dan de volgende URI: Er kunnen natuurlijk meerdere knopen overeenkomen met hetzelfde patroon. Zo werd het personage van Sheldon bedacht door twee mensen, en zal het resultaat van deze query select?x where { dbpedia:sheldon_cooper dbpedia-owl:creator?x. bestaan uit twee URIs: Naast URIs, kunnen natuurlijk ook letterlijke waardes worden teruggegeven. Het vinden van het beroep van Sheldon kan bijvoorbeeld zo: select?x where { dbpedia:sheldon_cooper dbpprop:occupation?beroep.?beroep rdfs:label?x. Een greep uit het resultaat: "Theoretical physics"@en "Theoretische natuurkunde"@nl "Teoretisk fysikk"@no... Om enkel maar de Nederlandse versie over te houden, moeten we het resultaat dwz. de verzameling van alle knopen die matchen met ons patroon gaan uitdunnen met een filter(voowaarde) instructie. Om het taal-label van een knoop op te vragen, gebruiken we de functie lang. select?x where { dbpedia:sheldon_cooper dbpprop:occupation?beroep.?beroep rdfs:label?x. filter(lang(?x) = "nl"). Een mogelijk probleem met deze query is nog dat hij niet zal werken als men toevallig het taal-label als NL geschreven heeft ipv. als nl. Er bestaat een functie langmatches, die nagaat of twee taal-labels dezelfde taal voorstellen, onafhankelijk van dit soort details. Een laatse schoonheidsfoutje is dat we nu in ons resultaat de volledige literal, inclusief taal-label, terugkrijgen: "Theoretische natuurkunde"@nl Om enkel de string zelf over te houden, zonder taal-label, kunnen we de functie str gebruiken.

17 2.1. DE BASIS 17 select str(?x) where { dbpedia:sheldon_cooper dbpprop:occupation?beroep.?beroep rdfs:label?x. filter(langmatches(lang(?x),"nl")). Bovenstaande query bevat twee plaatshouders, waarvan er uiteindelijk maar eentje wordt opgevraagd in het select gedeelte. Het is natuurlijk ook mogelijk om er meerdere op te vragen. select * where {?personage dcterms:subject category:the_big_bang_theory_characters.?personage dbpprop:nickname?nick. Het resultaat van deze query is een overzicht van alle personages uit The Big Bang Theory die een bijnaam hebben, met deze bijnaam erbij. Om enkel maar de string waarde van de bijnaam literals over te houden, kan natuurlijk weer de functie str gebruikt worden. select?personage str(?nick) where {?personage dcterms:subject category:the_big_bang_theory_characters.?personage dbpprop:nickname?nick. personage callret-1 Moon Pie Shelly, Shelly Bean Smelly Shelly, Dr. Dumbass "Bestie" Fruit Loops Raj Omdat voor de tweede kolom de functie str wordt opgeroepen, krijgt deze kolom een titel die niet zo informatief is. Net zoals bij SQL kunnen we de as-instructie gebruiken om dit desgewenst aan te passen. Hierbij is wel een extra paar haakjes noodzakelijk. select?personage (str(?nick) as?bijnaam) where {... Als we hetzelfde where-patroon gebruiken, maar de bijnaam niet opvragen, krijgen we een overzicht van alle personages die een bijnaam hebben. Net zoals we dit kennen van SQL, zal een personage met meer dan één bijnaam meermaals voorkomen in deze lijst. En net zoals in SQL, kunnen we desgewenst een select distinct doen om dit te vermijden. Aangezien het patroon waarnaar we op zoek gaan in bovenstaande query vereist dat het personage in kwestie een bijnaam heeft, vindt deze query dus geen personages terug die geen bijnaam hebben. Soms is het echter wenselijk om net zoals met een outer join in een relationele databank dit toch te doen. Dit kan door een deel van het te zoeken patroon optioneel te maken: als het er is, zal het worden opgevraagd, maar als het er niet is, zal de rest van het patroon toch nog kunnen matchen. select?personage (str(?nick) as?bijnaam) where {?personage dcterms:subject category:the_big_bang_theory_characters. optional {?personage dbpprop:nickname?nick.

18 18 HOOFDSTUK 2. SPARQL personage bijnaam Moon Pie Shelly, Shelly Bean Smelly Shelly, Dr. Dumbass "Bestie" Fruit Loops Raj Deze optional instructie is natuurlijk vooral belangrijk omwille van de flexibiliteit van het RDF formaat, waardoor het perfect denkbaar is dat resources van dezelfde soort, in tegenstelling tot bijvoorbeeld entiteiten van dezelfde entiteitverzameling in een relationele databank, een verschillende verzameling attributen hebben. De flexibiliteit van het RDF formaat komt verder nog tot uiting in het feit dat plaatshouders niet alleen maar gebruikt kunnen worden om, zoals in een relationele databank, resources op te vragen, maar ook om relaties op te vragen. Moesten we bijvoorbeeld vergeten zijn wat Sheldon Cooper en Jim Parsons ook al weer met elkaar te maken hebben, dan kunnen we dit als volgt opvragen: select?relatie where { dbpedia:sheldon_cooper?relatie dbpedia:jim_parsons. En kunnen we nu intussen eigenlijk al opvragen of de acteur die Sheldon speelt zelf uit Texas komt? Jazeker: select?biggerplace where { dbpedia:sheldon_cooper dbpprop:portrayer?acteur.?acteur dbpedia-owl:birthplace?plaats.?plaats dbpedia-owl:ispartof?biggerplace. Het resultaat van deze query is een aantal geografische regio s die de stad Houston bevatten: Paden van eigenschappen In de queries die we tot dusver gebruikt hebben, zochten we steeds naar patronen die op basis van knopen die verbonden zijn door middel van één enkele relatie. Het is echter ook mogelijk om via ingewikkeldere paden van één knoop naar een andere te geraken. De algemene notatie is als volgt: startknoop pad eindknoop. Het eenvoudigste geval is dat het pad slechts uit één relatie bestaat, en dan zijn we natuurlijk gewoon terug in hetzelfde geval als voorheen. Meer complexe paden kunnen beschreven worden met een reguliere-expressie-achtige notatie:

19 2.3. IN JENA 19 Pad notatie ^pad (pad) pad1 / pad2 pad1 pad2 pad* pad+ pad? pad{n,m pad{n pad{n, pad{,n Betekenis het omgekeerde (= van achter naar voor) van pad haakjes dienen voor groeperen het pad bestaande uit pad1, gevolgd door pad2 ofwel pad1, ofwel pad2 een pad dat bestaat uit nul of meer keer pad na elkaar hetzelfde, maar dan één of meer keer hetzelfde, maar dan nul of één keer hetzelfde, maar dan tussen n en m keer hetzelfde, maar dan exact n keer hetzelfde, maar dan minimum n keer hetzelfde, maar dan maximum n keer Op deze manier kunnen we bijvoorbeeld opvragen wie er in dezelfde tv-serie speelt als Jim Parsons: select?acteur where { dbpedia:jim_parsons (^dbpedia-owl:starring / dbpedia-owl:starring)?acteur. Dit konden we natuurlijk voorheen ook al, maar toen nog met meer schrijfwerk: select?acteur where {?serie dbpedia-owl:starring dbpedia:jim_parsons.?serie dbpedia-owl:starring?acteur. DBPedia bevat ook gedeeltelijke informatie over welke Amerikaanse staten aan elkaar grenzen. select?van?naar where {?van dbpprop:borderingstates?naar. Met onderstaande query kunnen we dan berekenen welke staten we vanuit Texas kunnen bereiken met hoogstens 1 tussenliggende staat. select?state where { dbpedia:texas (^dbpprop:borderingstates dbpprop:borderingstates){,2?state Als we een arbitrair aantal tussenstappen willen toelaten, wordt dit: select?state where { dbpedia:texas (^dbpprop:borderingstates dbpprop:borderingstates)+?state 2.3 In Jena Naast de DBPedia website, bevat ook het Jena pakket een SPARQL engine. Deze kan gebruikt worden als alleenstaande command-line applicatie, maar ook via een Java API. De benodigde klassen zitten in het paket import com.hp.hpl.jena.query.*;

20 20 HOOFDSTUK 2. SPARQL Het stellen van een query aan een Model verloopt in drie stappen. De statische methode QueryFactory.create(String query) wordt gebruikt om een Query object aan te maken, gegeven een SPARQL String. Deze Query moet dan gekoppeld worden aan het Model waaraan de vraag in kwestie gesteld moet worden. Dit gebeurt met de statische methode QueryExecutionFactory.create(Query q, Model). Het resultaat is een QueryExecution object. Tot slot kan de query dan worden uitgevoerd met de methode execselect() van zo n QueryExecution object. Het resultaat is een Iterator die itereert over QuerySolution objecten.

21 2.4. LABO Labo DBPedia Zoals we al gezien hebben, wordt de relatie dbpprop:series wordt gebruikt om afleveringen (onderwerp) te verbinden met hun tv-serie (voorwerp). 1. Welke afleveringen bestaan er allemaal van de tv-serie dbpedia:game_of_thrones? 2. Hoeveel verschillende regisseurs hebben er een aflevering van deze tv-serie geregisseerd? (De regisseur van een aflevering wordt aangegeven met de relatie dbpedia-owl:director.) 3. Van welke tv-series heeft de regisseur van de aflevering dbpedia:you_win_or_you_die al allemaal afleveringen geregisseerd? 4. Is er een relatie tussen de resource dbpedia:you_win_or_you_die en de resource dbpedia:the_pointy_end? 5. Welke waren de drie volgende afleveringen na dbpedia:you_win_or_you_die? Jena Herschrijf je programma uit de vorige opgave zodat de URI van de gemeente van je buurman nu wordt opgevraagd dmv. een SPARQL query.

22 22 HOOFDSTUK 2. SPARQL

23 RDF Schema 3 Zoals we in het vorige hoofdstuk gezien hebben, kan iedereen die daar zin in heeft zijn eigen RDF naamruimte verzinnen en deze vullen met zijn eigen URIs. Informatie kan gedeeld worden tussen verschillende bronnen, maar enkel maar op basis van gemeenschappelijke URIs. Het is met andere woorden enkel maar indien verschillende bronnen informatie over dezelfde resource bevatten, die ze bovendien allemaal identificeren met dezelfde URI, dat ze iets aan elkaars informatie kunnen hebben. Deze situatie is natuurlijk niet ideaal. Er is nood aan een gemeenschappelijke kennisstructuur, die toelaat dat één bron toch iets van de informatie uit een andere bron kan begrijpen, ook als ze elkaars URIs niet kennen. Dit wordt verwezenlijkt door RDF Schema (RDFS), waarmee een bron de URIs die ze gebruikt kan beschrijven en kaderen ten opzichte van andere concepten. Dit zal bijvoorbeeld toelaten dat ook iemand die de specifieke URI niet kent, toch kan uitvissen dat het hier over een TV-serie gaat. De principes achter RDFS zijn eenvoudig: De flexibiliteit van RDF moet bewaard blijven, dwz. dat iedereen nog steeds vrij moet zijn om eender welke informatie in een RDF bestand te gieten en te combineren met bestaande RDF databanken, zonder dat hier allerlei beperkingen aan worden opgelegd. RDFS is zelf ook gewoon RDF. Net zoals bv. het XSD-formaat een XML-formaat is om XML-formaten in te beschrijven, is RDFS een RDF-formaat om RDF-formaten in te beschrijven. 3.1 Structuur van RDFS RDFS heeft een objectgeöriënteerd wereldbeeld: er zijn objecten, die behoren tot klassen. Wegens de vereiste flexibiliteit, is er geen limiet op het aantal klassen waartoe een object kan behoren. De klassen kunnen geördend worden in een overervingshiërarchie. Deze informatie wordt allemaal beschreven met URIs uit volgende naamruimte: 23

24 24 HOOFDSTUK 3. RDF SCHEMA URI rdf:type rdfs:label rdfs:resource rdfs:property rdf:class rdfs:domain rdfs:range rdfs:subclassof rdfs:subpropertyof Betekenis geeft aan tot welke klasse een object behoort een string die een object beschrijft de basisklasse, waartoe alle objecten behoren de klasse van alle resources die gebruikt kunnen worden als relaties de klasse waartoe alle klassen behoren verbindt een property met zijn domein, dwz., de klasse waartoe zijn onderwerpen behoren verbindt een property met zijn bereik, dwz., de klasse waartoe zijn voorwerpen behoren koppelt een klasse aan een superklasse koppelt een eigenschap aan een grotere eigenschap Als we zelf een eigen klasse van objecten willen aanmaken, volstaat het dus om de klasse zelf te declareren als iets van rdf:type rdfs:class en dan elk van de objecten deze nieuwe klasse als rdf:type te geven. Objecten van onze nieuwe klasse kunnen dan natuurlijk ook eigenschappen hebben, die we kunnen declareren als rdfs:property met een bepaalde rdf:domain en eventueel een bepaalde rdfs:range. Als we verschillende klassen of eigenschappen hebben, dan kunnen we bovendien het verband hiertussen aangeven met een rdfs:subclassof (voor klassen) of een rdfs:subpropertyof (voor eigenschappen). Hieronder declareren we twee nieuwe klassen, waarbij de ene de andere omvat. jve:denayerstudent rdf:type rdfs:class. jve:mijnstudent rdf:type rdfs:class. jve:mijnstudent rdfs:subclassof jve:denayerstudent. In RDFS bestanden zullen dergelijke declaraties natuurlijk vaak voorkomen. In XML/RDF formaat vereist zo n declaratie net zoals de meeste dingen aardig wat schrijfwerk: <rdf:description about=" <rdfs:type resource=" /> Dit mag echter ook afgekort worden als volgt: <rdfs:class about=" /> Het voorwerp van de type-relatie wordt hier dus als tag gebruikt, en het onderwerp komt in zijn about-attribuut. Nu voegen we een relatie toe, die als domain één van deze klassen heeft. jve:thesisonderwerp rdf:type rdfs:property; rdfs:domain jve:mijnstudent. We kunnen nu deze nieuwe klassen en eigenschappen gebruiken nu gebruiken om informatie over nieuwe objecten bij te houden, bijvoorbeeld: jve:dendinges jve:thesisonderwerp jve:semantischweb. Natuurlijk, dat hadden we even goed kunnen doen, zonder deze relatie op voorhand te beschrijven in RDFS. Wat schieten we er nu mee op dat we dit wel gedaan hebben?

25 3.2. GEBRUIK VAN RDFS Gebruik van RDFS Communicatie De eerste reden om een RDFS bestand op te stellen, is om ergens een verslag te hebben van de beslissingen die genomen zijn over hoe data zal worden voorgesteld, onafhankelijk van de voorgestelde data zelf. In dit opzicht manier speelt een RDFS bestand dezelfde rol als een ER-diagramma in een relationele databank. Dit RDFS bestand kan dan gebruikt worden om te communiceren met mensen die de gegevens zouden willen gebruiken of aanleveren in een compatibel formaat Inferentie Naast communicatie tussen mensen, kan RDFS natuurlijk ook gebruikt worden door computerprogramma s. De belangrijkste taak hier is inferentie. Hiermee bedoelen we dat, op een basis van RDFS-bestand, méér drietallen kunnen worden afgeleid dan er effectief in ons RDF bestand staan. Bijvoorbeeld, het RDFS schema zegt dat het domein van de relatie jve:thesisonderwerp de klasse jve:mijnstudent is, en bovendien dat deze klasse een subklasse is van jve:denayerstudent. Als volgend feit effectief in ons RDF-bestand staat: jve:dendinges jve:thesisonderwerp jve:semantischweb. kunnen we daar dankzij het RDFS schema ook volgende twee feiten uit afleiden: jve:dendinges rdf:type jve:mijnstudent. jve:dendinges rdf:type jve:denayerstudent. Deze feiten worden virtueel genoemd, omdat we weten dat ze waar moeten zijn, hoewel ze nergens effectief staan opgeschreven. Als we een RDFS schema hebben voor een RDF bestand, dan gaan we onze queries niet meer stellen aan dit bestand zelf, maar aan de zogenaamde afgeleide grafe (inferred graph) hiervan, die bestaat uit alle drietallen die effectief in het bestand staan plus alle virtuele drietallen die dankzij het RDFS schema kunnen worden afgeleid. Op deze manier kunnen we dankzij RDFS een complexe en grote gegevensstructuur vaak op een meer compacte manier beschrijven. Een implementatie kan dan natuurlijk kiezen of ze deze afgeleide grafe in zijn geheel gaat opstellen, of enkel maar gedeeltes ervan constueren op het moment dat een gebruiker er een query aan stelt Validatie Een tweede taak waarvoor RDFS gebruikt kan worden, is validatie. Hiermee wordt bedoeld dat we gaan nagaan of de afgeleide grafe van een RDF bestand wel op een correcte manier gemaakt kan worden. Het is bijvoorbeeld mogelijk dat een RDFS schema zegt dat een bepaalde letterlijke waarde het type xsd:integer moet hebben, terwijl er in het RDF bestand een kommagetal staat. In zo n geval bevat het RDF bestand dus een fout ten opzichte van het schema Integratie Het gebruik van RDFS kan ook helpen om informatie uit verschillende bronnen te integreren. Zoals we al gezien hebben, kan het integreren van informatie uit verschillende bronnen heel eenvoudig zijn, als die tenminste allemaal gebruik gemaakt hebben van dezelfde URIs. In zo n geval, volstaat het immers om gewoon de feiten uit verschillende bronnen samen te voegen tot één grote grafe.