De code is nog niet zo ver dat ik hem ook wil/kan beschikbaar stellen, maar de QTIv2.0-export uit Dokeos werkt. Zo’n eerste keer blijkt dat toch moeilijker dan je vooraf zou verwachten.
Stap 1) was het bestuderen van de Dokeos PHP-code, de achterliggende database en tabellen en proberen te achterhalen hoe die samenhingen.
Stap 2) was het bedenken van een vertaling van de per vraag beschikbare functionaliteit naar equivalente QTI-functionaliteiten.
Stap 3) was de realisatie van de daadwerkelijke code. Daar kwamen aardige uitdagingen bij om de hoek zoals het automatisch genereren van een zip-bestand vanuit PHP en het loslaten van een XSLT op een XML-bestand om de aanwezige metadata eruit te filteren.
Dit waren overigens natuurlijk allemaal dingen die voor het eerste vraagtype (Dokeos kent er vier) het meest complex waren en daarna een stuk eenvoudiger door te vertalen waren naar de rest.
Er waren ook zaken die vooral een investering in de toekomst zijn. Zo gebruik ik een template-systeem waarbij je de gebruikte XML-structuren voor de te genereren QTI relatief eenvoudig kunt wijzigen, zonder daarvoor de programmacode zelf te hoeven wijzigen.
Vraagtypes
QTIv2.0 kent geen ‘vraagtypes’. Je hebt het daar over interactietypes die gecombineerd kunnen worden in vragen (items). Dokeos (en veel andere ELO’s) kennen wel vragen met een vast type (multiple choice / multiple response / matchingsvraag / fill in the gap) en daarom was het gebruiken van templates waarin al veel delen vast ingevuld waren mogelijk.
Die vast vraagtypes maakten de export eenvoudiger, maar gaan bij het eventueel bouwen van een importfilter nog voor veel problemen zorgen.
Implementatie in Dokeos
Op dit moment vindt export nog per vraag plaats, maar ik heb er in de code rekening mee gehouden dat ik dat straks ook per test (toets) of questionpool (verzamelbak voor vragen) wil kunnen doen.
In de lijst met vragen binnen een test zie je hier een extra knop die een IMS Contentpackage met daarin een aantal bestanden genereert en beschikbaar stelt voor de download.
Laten we eens uitgaan van dit voorbeeld.
IMS Contentpackage
Het IMS Contentpackage (of IMS Materiaalpakket) bestaat uit een aantal bestanden die allemaal automatisch gegenereerd of aan het ZIP-bestand tegevoegd worden.
De bestanden die eindigen op XSD laten we even buiten beschouwing, die zullen we anders ook niet gebruiken.
Dan blijven er nog drie bestanden over:
item_x.xml
Het item-bestand is (uiteraard) het bestand waar alles om draait. Hier is bijvoorbeeld de vraag, de bijbehorende scores en feedback in opgenomen.
imsmanifest.xml
Dit is een belangrijk bestand in het materiaalpakket. In dit bestand is een overzicht opgenomen van de in het contentpackage opgenomen bestanden en is de metadata opgenomen.
item profile
Dit is een XML-bestand dat de benodigdheden van de vraag beschrijft. Het is geen verplicht of voorgeschreven onderdeel.
Overigens worden alle drie de bestanden volledig automatisch gegenereerd op basis van de in Dokeos beschikbare informatie, inclusief de opgenomen metadata.
Importeren
Ik had geen applicatie beschikbaar die al in staat is om QTIv2.0-bestanden te importeren. Wél maakt de wijze van gebruik van IMS Contentpackaging ook applicaties die niets van QTI weten met de packages om te gaan.
RELOAD laat het package netjes zien, waarbij duidelijk is welke delen het programma niet kan interpreteren.
Ook Intralibrary, een leerobjectrepository, ‘kent’ QTI niet, maar ook hier wordt gewoon netjes de standaard informatie (metadata) uit het package gelezen en wordt de rest genegeerd.
Wordt vervolgd.