Guide MOOC – Partie 2 – API MOOC, le SCORM 1.2

Authors : Alterway

Dans notre précédent article, nous vous présentions quelques éditeurs permettant de concevoir et de packager un cours Mooc. Un point important est à prendre en compte dans cette étape, l'API / standard utilisé pour le package final. Si le format SCORM semble un incontournable, il se décline en de nombreuses versions et sous-versions, et n'est plus un standard en devenir comme pourrait l'être TinCan.

Dans cet article nous proposons un article centré sur l'API SCORM, avec un rappel des différents niveaux d'API et les requis pour se mettre en conformité avec sa sous-version la plus utilisée : SCORM 1.2.

Pourquoi le SCORM ?

Comme nous l'apprend la page Wikipedia dédiée, le SCORM ou Sharable Content Object Reference Model est un standard développé principalement par l'agence américaine ADL (Advanced distributed learning) en vue de respecter les exigences suivantes : Accessibilité, adaptabilité, durabilité, interopérabilité et réusabilité. Pour simplifier, la définition d'un standard de package autonome, respectant les contraintes d'accessibilité numérique modernes et, à travers une API standard, compatible avec les plateformes d'édition et de présentation (LMS).

Pour résumer : SCORM 1.0 : draft du standard SCORM 1.1 : première implémentation SCORM 1.2 : première version adoptée massivement et ayant fait connaître le format SCORM. C'est toujours aujourd'hui un des formats les plus utilisés, y compris par les industriels du Mooc. SCORM 2004 “1st Edition” : ni publiée ni utilisable SCORM 2004 "2nd Edition" : réponse rapide d'ADL aux problèmes de la première édition SCORM 2004 "3rd Edition" : sous-version la plus utilisée parmi les versions 2004

Aujourd'hui c'est la version 1.2 qui est la plus utilisée parmi toutes ces éditions du standard SCORM.

Concrètement, le SCORM v1.2 est composé de deux parties : L'environnement d’exécution (Run-Time Environment) définit comment le contenu devrait se comporter une fois qu'il a été exécuté dans le LMS. Le modèle d'agrégation de données (Content Aggregation Model) définit comment vous devriez packager votre contenu de sorte à ce qu'il puisse être importé dans un LMS. Ceci implique la création de fichiers XML qu'un LMS peut lire pour détecter la configuration nécessaire à la présentation de votre contenu.

L'environnement d’exécution (Run-Time Environment)

Requis pour implémenter un connecteur d'API. Le connecteur d'API doit se présenter sous la forme d'un object ECMAScript (Javascript) nommé "API" xqui est accessible à travers le DOM. L'adaptateur doit implémenter les 8 fonctions suivantes :

LMSInitialize() LMSFinish() LMSGetValue() LMSSetValue() LMSCommit() LMSGetLastError() LMSGetErrorString() LMSGetDiagnostic()

Pour un niveau minimal de conformité SCORM, la seule chose dont un morceau de contenu a besoin est d'appeler LMSInitialize() quand il démarre et ensuite appeler LMSFinish() quand il en sort. C'est possiblement aussi simple, dans les cas d'usage réels cependant, les utilisateurs souhaitent une interaction beaucoup plus riche.

Le modèle d'agrégation de données (Content Aggregation Model)

Il se divise en trois parties : Package du contenu (Content Packaging) Modèle de contenu (Content Model) Méta-données (Meta-data)

La spécification du package de contenu (Content Packaging) définit comment le modèle de contenu (Content Model) et les méta-données (Meta-data) sont implémentées. Elle requiert tout le contenu à transférer dans un dossier ou un fichier ZIP appelé un PIF. À la racine de ce dossier doit se trouver un fichier XML appelé "imsmanifest.xml" contenant les informations de spécification du modèle de contenu et des méta-données dans un format bien définit.

Le modèle de contenu définit un puissant modèle pour distinguer le contenu en des unités réutilisables de taille arbitraire. Ces unités sont appelées Objets de Contenu Partageables (Sharable Content Objects ou SCO) et "Assets". Un "asset" est simplement une "représentation électronique d'un média, texte, images, sons, pages web, ou tout autre format de données". Par exemple, les "assets" incluent des photos, des extraits vidéo ou audio, etc... Un SCO est donc une collection d'"assets" représentant une unité logique d'apprentissage.

La spécification de méta-données procure un mécanisme pour décrire le contenu utilisant un vocabulaire commun pré-défini. Ce vocabulaire a 9 catégories, générale, cycle de vie, meta- metadata, technique, éducation, droits, relation, annotation, et classification. La spécification des méta-données indique un modèle de données très riche. Cependant, seule un sous jeu d'éléments de données sont requis pour atteindre la conformité SCORM.

L'exemple d'un fichier "imsmanifest.xml"

{{< highlight bash >}}

ADL SCORM 1.2

  <item identifier="item_1" identifierref="resource_1">

  </item>
</organization>

{{< /highlight >}}

Si le SCORM 1.2 semble le standard incontournable du packaging de cours MOOC, il faut prendre en compte deux axes de pondération : 1. votre capacité à packager votre contenu dans une archive, ce qui peut-être limitant si vous comptez par exemple faire appel à un webservice pour dynamiser le contenu de vos slides de cours, 2. la compatibilité avec le LMS distant, les plateformes de présentation MOOC celles-ci ne supportant pas toutes les APIs voire proposent des hybridations propriétaires.

Pour ces deux points, rendez-vous pour les parties « 3 – MOOC APis, suite et fin » et « 4 – LMS et support API » de notre guide MOOC.

Sources : - ADL SCORM http://www.adlnet.org/scorm.html - SCORM 1.2 Overview for developers : http://scorm.com/scorm-explained/technical-scorm/scorm-12-overview-for-developers/ - SCORM 1.2 Specification – zip http://www.adlnet.org/wp-content/uploads/2011/07/SCORM_1_2_pdf.zip - SCORM 1.2 Test Suite Readme http://www.adlnet.org/wp-content/uploads/2011/07/SCORM1_2_TestSuite1_2_7ST_ReadMe.htm