QTI 2.1 in Nederland – hoe verder?

by Wouter HuijninkOctober 29, 2010

Vrijdag 22 oktober organiseerde SURF Foundation een bijeenkomst over de stand van zaken met betrekking tot IMS QTI 2.1 in Nederland. Namens JTeam heb ik in een presentatie uiteengezet hoe naar ons idee de toepassing van deze prachtige onderwijsstandaard vlot kan worden getrokken.

Huidige problemen

Op dit moment ondervinden partijen die gebruik willen maken van de standaard grote problemen bij het maken en uitwisselen van content. Dat is erg jammer, want in principe biedt deze standaard zeer veel mogelijkheden tot het eenduidig vastleggen van toestmateriaal op een leveranciersonafhankelijke manier. Belangrijke struikelblokken zijn:

  • gebrek aan goede auteursomgevingen
  • duidelijke handleidingen voor auteurs (hoe vertaal je een vraag op papier naar een interactietype van QTI?)
  • niemand implementeert alle features (de specificatie is te groot), laat staan dezelfde features
  • de specificaties laten ruimte voor interpretatie, en die interpretatie is zelden gelijkluidend

En natuurlijk spelen de onvermijdelijke bomen, bossen, klokken en klepels nog een rol.

De specificaties bieden ruimte om vast te leggen in hoeverre je de standaard implementeert: in de vorm van een zogenaamd conformance profile. Dit is alleen een veel te restrictief formaat – je kunt feedback wel of niet; je kunt responseRules wel of niet interpreteren; etc. Voor de meeste implementaties gaat dit helemaal niet op, die kunnen bijvoorbeeld een beetje feedback, of een bescheiden deel van responseprocessing.

Wat hebben we nodig?

Allereerst moet de content op orde komen. Door eenduidige richtlijnen op te stellen waar iedereen die binnen Nederland gebruik wil maken van QTI op kan terugvallen, worden veel onduidelijkheden weggenomen. Denk aan richtlijnen met betrekking tot:

  • items – bijvoorbeeld: het attribuut normalMaximum gebruiken we alleen voor het vastleggen van de maximumscore van een open vraag
  • auteurs – voor elk interactietype worden enkele voorbeelden uitgewerkt
  • assessmentTests (gebruikt iemand die in Nederland? Of zou de aanbeveling moeten zijn: gebruik enkel assessmentItems?)
  • responseProcessing: gebruik altijd variabelenaam X; beperk je tot een “if, else, else” op 1 niveau; etc
  • feedback: gebruik vaste identifiers als “firstAttemptSuccess”, “firstAttemptFailure” – zo kunnen implementatiepartijen wat hoekjes afsnijden door af te gaan op naamgeving ipv volwaardige xml-interpretatie
  • content packaging: welke versie? XSD’s wel/niet verplicht in het content package? welke metadata is verplicht? etc
  • de uitlevering van resultaten

Nederlandse toepassingsprofielen

Op basis van bovenstaande richtlijnen kunnen vervolgens toepassingsprofielen worden geformuleerd die uitwisseling een heel stuk eenvoudiger gaan maken en het idee van een keer schrijven, overal afspelen wat dichterbij zullen brengen. Dit kan vervolgens een grote impuls betekenen voor de Educatieve Content Keten.

Edustandaard, SURF en Kennisnet kunnen hopelijk een belangrijke rol spelen bij het opstellen en evangeliseren van deze toepassingsprofielen.