NieuwsMagazine

Het testen van RDF: geen dagelijkse kost!

Auteur: Faisel Isenia ● faisel.isenia@viqit.nl
Faisel Isenia
Digitale informatie is niet meer weg te denken uit onze samenleving. In het huidige leven kun je niet meer zonder. Je hebt vast wel eens zoekmachines als Google, Yahoo, Ilse en Vinden.nl gebruikt om informatie te vinden op het internet. Ik neem je mee bij het testen van een metadatamodel dat gebruikt wordt bij het modelleren van zo’n zoekmachine: RDF. Tegenwoordig zijn veel organisaties bezig met Semantisch web, Linked Open Data en RDF. Het is dan ook logisch dat testers in hun opdrachten vaker met het testen van RDF of vergelijkbare technieken in aanraking zullen komen. Dit artikel biedt wat handvatten bij zo’n testopdracht. Ik geef je daarbij inzicht in de functionaliteit achter zoekmachines en sluit af met een paar praktische aanbevelingen. 
Wat is RDF?
RDF staat voor Resource Description Framework. Dit is het metadatamodel van het Semantische Web. Het Semantische Web is het raamwerk voor het efficiënt delen van data en ligt ten grondslag aan de technologie van Linked Open Data. Linked Open Data koppelt informatie door middel van standaarden die gebruikt worden voor de inhoud van de data.
Met het RDF-metadatamodel kunnen uitspraken gedaan worden over de kenmerken van bronnen op het web (resources) in de vorm van een drieledige subject-predicaat-object-structuur (in RDF-termen een triple). Het subject is in essentie de resource die beschreven wordt. Het predicaat is welk kenmerk of aspect van die bron beschreven wordt. Het object ten slotte is wat de waarde van dat kenmerk is. Als voorbeeld: het object ‘Dit artikel’, het predicaat heeft als titel’ en het object dat daarbij hoort ‘Het testen van RDF: geen dagelijkse kost!’.
RDF is een standaard die sterk in opkomst is. Het leuke aan RDF is dat de data zonder complicaties kunnen worden uitgebreid met nieuwe feiten, maar ook met links naar andere bronnen! RDF data is dus dynamisch en zeer geschikt om te combineren op het internet met ander informatiebronnen. Denk aan Wikipedia en dan speciaal de RDF-versie daarvan: Dbpedia.
Het mooie van RDF is dat je van tevoren niet al alle mogelijke relaties hoeft te kennen. Het is niet nodig om bij het ontwerp van het systeem een volledig datamodel van de betrokken informatie te hebben. Vanwege de ’triples’-structuur van RDF is het mogelijk om op een later moment een systeem uit te breiden met eerder onvoorziene informatie. Als voorbeeld: het object ‘Faisel Isenia’ is dan een subject met het predicaat heeft werkgever‘ en het bijbehorende object ‘ViQiT’. Aan de hand van bovenstaande voorbeeld wordt het RDF-metadatamodel en data in een RDF-graaf weergegeven (zie figuur 1).

Figuur 1. Een schematische weergave van het RDF-metadatamodel met data (RDF-graaf)

Voor meer informatie over RDF: zie Wikipedia en W3C.

RDF in de praktijk
Tijdens het uitvoeren van een testopdracht bij een opdrachtgever kwam ik in aanraking met het testen van RDF. De opdrachtgever wilde een zoekmachine ontwikkelen om haar klanten betere zoekmogelijkheden te bieden. De opdracht voor de zoekmachine luidde als volgt: bouw een connector/opnamestraat die ervoor zorgt dat de metadata van verscheidene bronnen (collecties) wordt opgehaald of ontvangen, omgevormd naar het RDF-formaat. Het RDF als eindproduct vormt de input voor het zoekplatform (zoekmachine) en dient voor het beantwoorden van zoekacties vanuit de opdrachtgever.
De verwerking van één broncollectie gebeurt via een aantal stappen. Deze stappen zijn: ophalen bij de bronleverancier, uitpakken, formaat omzetten naar XML, XML valideren, aanvullen, inhoudelijk controleren, converteren naar RDF, RDF valideren voor één broncollectie. Deze stappen plus de bijbehorende brondefinitie (de bron mapping rules), vormt een connector (zie figuur 2).

Figuur 2. Schematische weergave van de connector

De opnamestraat is de totale applicatie en is opgebouwd uit meerdere connectoren die ieder de totale verwerking van één broncollectie voor zijn rekening neemt (zie figuur 3).
Figuur 3. Schematische weergave van de connectoren in opnamestraat

Bronnen
Bronnen zijn verzamelingen van digitaal opgeslagen informatie die beschikbaar worden gesteld door bijvoorbeeld ketenpartners van de opdrachtgever. Bronnen bestaan uit één of meer collecties met documenten: de broncollecties. Een document representeert alle entiteiten die in de bronnen gecatalogiseerd zijn, bijvoorbeeld boeken en cd’s. De bronnen en de documenten in die bronnen worden beschreven aan de hand van metadata. De systematiek voor het gebruik van deze metadata voor de specifieke bron wordt benoemd als onderdeel van de brondefinitie van die bron.
Bronnen kunnen zich van elkaar onderscheiden op de volgende eigenschappen:

  • Content type (boeken, muziek, nieuws, enzovoort);
  • Formaat (XML, relationele database, enzovoort);
  • Structuur (samenhang van records, velden, enzovoort);
  • Protocol (FTP, OAI-PMH, enzovoort).

Wat is er bijzonder aan het testen van RDF?
Het bijzondere aan het RDF-testen zit in het feit dat er geen vaste verhouding is tussen het aantal ingelezen records van een bron en het aantal omgevormde RDF-records van de bron. Dit kan één op één zijn maar is meestal één op n. Dus honderd records uit een bron leveren niet altijd honderd sets gelijke RDF-triples.
Testen van RDF in de praktijk
In het Mastertestplan werden onder andere de testdoelen, de teststrategie en de planning vastgelegd. De SysteemTest (ST) en de Functionele AcceptatieTest (FAT) waren de twee testsoorten die gepland waren voor dit testtraject. De teststrategie zorgde voor een duidelijke taakverdeling tussen beide testsoorten.
De gedetailleerde uitwerking van de testdoelen en de testaanpak werd vastgelegd in de Detailtestplannen. De ST was een verantwoordelijkheid van het testteam van de leverancier. De FAT was een verantwoordelijkheid van het testteam van de opdrachtgever. In de volgende alinea wordt per testsoort aangegeven welke testactiviteiten hebben plaatsgevonden.
Systeemtest (ST)
De ST richtte zich op het testen van de functies die in de connectoren en de opnamestraat werden ingebouwd, de generieke functies van de connector en de opnamestraat. De functies die werden getest waren beschreven in het Functioneel Ontwerp. Conform de teststrategie waren de Functionele Compleetheid en Toepasselijkheid (Geschiktheid) de belangrijkste kwaliteitsattributen die tijdens de ST werden afgedekt.
De volgende testactiviteiten hebben plaatsgevonden:

  1. Bronanalyse
    De bronanalyse richtte zich op het analyseren van één broncollectie. Daarbij werd een dataset van ongeveer tien tot twintig records uit de broncollectie geselecteerd. De geselecteerde records moesten van bijzonder karakter te zijn. Bijvoorbeeld records met leestekens, aanwezige links, verwijzingen, grafische karakters, vreemde karakters en subscript tags. Deze beperkte dataset werd gebruikt in plaats van de gehele broncollectie om in een vroeg stadium fouten te constateren met een beperkte inspanning.
  2. Testen van de getransformeerde RDF via een RDF graaf check programma
    Het programma controleerde de RDF-syntax voor één specifieke bron. Bij een correcte syntax produceerde het programma een graaf die eenvoudig te controleren is (zie figuur 1).
  3. Testen van de connectoren en de opnamestraat
    Het testen van de connectoren en de opnamestraat richtte zich op de mate waarin de set van functies alle gespecificeerde taken ondersteunde. Tijdens het testen werd de geselecteerde testdataset gebruikt.
  4. Het testen van de beheerfunctionaliteit
    Testen van de beheerfunctie van de connectoren en de opnamestraat richtte zich op het starten en stoppen van de connectoren, de monitoring van de connectoren en de opnamestraat, en de bruikbaarheid van de geproduceerde logfiles.

Functionele acceptatietest (FAT)
De functionele acceptatietest richtte zich op het testen van de functies van een connector binnen de specifieke context van een bron. De specifieke functie van de connector waarop de conversie van data werd uitgevoerd, staat centraal in deze test. Conform de teststrategie was de Functionele Correctheid (Geschiktheid) het belangrijkste kwaliteitsattribuut die tijdens de FAT werd afgedekt.
Tijdens de functionele acceptatie test vonden de volgende testactiviteiten plaats:

  1. Inhoudelijke datatest
    Tijdens de FAT werd er een representatieve subset van de betreffende broncollectie als dataset geselecteerd. Er vond een inhoudelijke vergelijking plaats tussen bron- en doelsysteem aan de hand van deze dataset.
    Tijdens de inhoudelijke test werd de getransformeerde RDF getest via het RDF graaf checkprogramma. Het programma controleert de RDF-syntax voor één specifiek bron en bij een correct syntax produceert het programma een graaf (zie figuur 1). Waar de ST alleen aandacht had voor de basis-graaf, had de FAT meer aandacht voor de verschillende variaties in grafen.
    Het testen van de RDF-structuur geschiedde aan de hand van de bron mapping rules (brondefinities) en de geselecteerde dataset voor een specifiek bron. Er werd gecontroleerd of de getransformeerde RDF voldeed aan de bron mapping rules voor de specifieke bron.
  2. Volume datatest
    Deze test is gericht op het verwerken van een grote hoeveelheid data ter validatie van de effectiviteit van de connector. Er vond een vergelijking plaats tussen bron- en doelsysteem aan de hand van tellingen en toetsen van conversieverslagen.

Mijn aanbevelingen
Tijdens deze testopdracht zijn we op enkele punten gestuit die van belang zijn tijdens het uitvoeren van een project waarbij RDF-technologie wordt toegepast.
De twee belangrijkste zijn:

  1. Zorg dat RDF-kennis binnen het project aanwezig is
    Tijdens het uitvoeren van een project waarbij RDF toegepast gaat worden is het van belang er voldoende kennis van RDF in huis is. In ieder geval bij de leverancier, maar bij voorkeur ook aan de opdrachtgeverszijde. Aangezien RDF vrij abstract en technisch van aard is, is het noodzakelijk dat enkele projectteamleden RDF-kennis hebben. Dat bevordert de communicatie en het nemen van beslissingen omtrent RDF-richtlijnen en mapping rules. Deze opdrachtgever had speciaal RDF-experts ingehuurd om het project uit te voeren.
  2. Het testen van de RDF-structuur is monnikenwerk
    Het aantal records, de soort bron en de lengte van een bronrecord zorgt ervoor dat de testuitvoering juist veel of weinig tijd in beslag neemt. Hoe langer de beschrijving van een bronrecord, des te meer tijd er nodig is om de getransformeerde RDF regel voor regel te controleren. Planning en beheer hiervan verdient daarom tijdens de testopdracht zeker extra aandacht. Immers, je weet aan het begin van het project tijdens de eerste inschattingen nog niet alle details van de bronrecords.

Belangrijke ontwikkeling: Web 3.0
We zien dat Web 3.0 de volgende stap is in de ontwikkeling van het internet. Web 3.0 wordt het Semantisch Web genoemd en RDF een van de technologieën waar het op is gebaseerd. RDF is verder aan het ontwikkelen en uitbreiden in de vorm van RDFS ( de S staat voor Schema) en met OWL (Ontology Web Language). Vooral de laatste biedt uitgebreid mogelijkheden om een semantisch model te beschrijven.

De sites van tegenwoordig worden steeds vaker ontwikkeld volgens bepaalde protocollen of standaarden, waardoor het uitwisselen van gegevens gemakkelijker gaat. Vooral bij zoekmachines kunnen deze technologieën nuttig zijn. In plaats van zoekmachines te hebben die gericht zijn op zoekwoorden (kernwoorden), zouden de zoekmachines zich kunnen aanpassen aan de gebruiker. De zoekmachines zullen woorden kunnen zoeken die gebaseerd zijn op je cultuur, regio en het jargon dat je gebruikt. Een voorbeeld: als je anno 2013 op vakantie gaat, moet je verschillende zoekopdrachten uitvoeren om je vliegtuig te boeken, je hotel te boeken en een auto te huren. Door semantisch te zoeken op een combinatie van deze drie zal een RDF-zoekmachine de resultaten tegelijkertijd en op een overzichtelijke manier presenteren aan de gebruiker. Je ziet dan in één oogopslag welk hotel het meest geschikt is, welke vlucht je daarbij moet boeken en welke auto je kunt huren. Eén druk op de knop en je volledige vakantie is geregeld!

één reactie

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *