Cmi5
Cet article est en construction: un auteur est en train de le modifier.
En principe, le ou les auteurs en question devraient bientôt présenter une meilleure version.
La page suivante reprend le contenu de la page Cmi5 sur la version anglaise de EduTech Wiki
Introduction
Depuis 2018, cmi5 est la norme d'apprentissage en ligne la plus récente qui définit comment les cours empaquetés en tant qu'objets d'apprentissage et importés dans les systèmes de gestion d'apprentissage (LMS) peuvent interagir avec ces derniers afin de suivre les progrès des étudiants. Développée par ADL (Advanced Distributed Learning Initiative), la norme cmi5 clarifie l'utilisation de xAPI dans le domaine e-learning traditionnel.
cmi5 est probablement l'acronyme de "Computer Managed Instruction" (enseignement géré par ordinateur), cinquième tentative. "CMI" était le nom de la spécification AICC originale publiée en 1993 et qui fournissait le modèle de données adopté par SCORM 1.2.
cmi5 est un profil xAPI, initialement proposé par le groupe de travail AICC (l'un des premiers acteurs de la normalisation du e-learning) pour qui la création d'un profil spécifique a vu le jour car “Étant donné que la spécification xAPI est très généralisée pour prendre en charge de nombreux cas d'utilisation différents, un ensemble de "règles supplémentaires" (appelé "profil") est nécessaire pour garantir l'interopérabilité pour un cas d'utilisation donné. Le profil cmi5 garantit l'interopérabilité plug and play entre le contenu d'apprentissage et les systèmes LMS. Le cas d'utilisation pour lequel le profil cmi5 est spécifiquement conçu est celui où l'apprenant lance le contenu / l'activité d'apprentissage à partir de l'interface utilisateur LMS.”
La spécification cmi5 “décrit la communication d'exécution interopérable entre les systèmes de gestion de l'apprentissage (LMS) et les unités assignables (AU)” (Profil de spécification cmi5 pour xAPI, juillet 2018). Plus précisément, il définit comment utiliser la spécification xAPI pour les éléments suivants:
- Lancement d'AUs (unités assignables) par un LMS.
- Environnement de lancement et d'exécution utilisé par les LMS et les AUs (unités assignables).
- Données de communication lors de l'exécution et transport de données entre le LMS et les AUs (unités assignables).
- Définition du cours sur la plateforme LMS en ce qui concerne les données d'exécution utilisées par les AUs (unités assignables).
- Import / Export de structure de cours LMS
- Exigences de rapport pour le LMS.
Historique et versions
Selon la page du projet (en juillet 2018), le projet cmi5 a été lancé au sein de l'AICC (Aviation Industry Computer-Based Training Committee) en 2010 et devait remplacer les spécifications AICC et SCORM car elles ont toutes les deux des problèmes et des contraintes techniques tout en se chevauchant de manière significative. L'AICC était sur le point d'achever un mécanisme de communication basé sur SOAP 2012 à peu près au même moment où l'API xEST basée sur REST émergeait d'ADL. xAPI avait un objectif d'application plus large, mais le même objectif. Ainsi, ADL et AICC ont convenu de coopérer sur un profil cmi5 xAPI et en 2014, l'AICC a été dissoute (même le site Web a disparu) et a officiellement transféré le projet cmi5 à l'ADL.
Les versions principales ont des noms de pierre:
- Version basée sur SOAP (brouillon) en 2012
- Sanstone (Première version: 15 mai 2015)
- Quartz (Première version: 1 juin 2016)
Support
Depuis l'été 2018, cmi5 a été adopté par certaines plateformes. Cette norme est beaucoup plus simple que les normes plus anciennes et plus ambitieuses telles que le SCORM 2004 complet (qui comprend le IMS Simple Sequencing) ou le IMS Learning Design, qui étaient basés sur des langages de modélisation formels. Il simplifie également l'utilisation de xAPI en restreignant certaines fonctionnalités et en ajoutant des règles contraignantes.
Objectifs
La mission principale du projet cmi5 est de fournir une meilleure alternative aux spécifications AICC / SCORM actuelles avec quelque chose de beaucoup plus flexible, robuste et adaptable aux technologies d'aujourd'hui.
L'AICC définit les objectifs spécifiques du projet cmi5 suivants:
- Un modèle de données de suivi simplifié: Les modèles de données SCORM et AICC étaient trop compliqués et comportaient de nombreux éléments de données facultatifs qui n'étaient pas utilisés. Le but d'un modèle de données simple est de définir uniquement le strict minimum d'éléments de données requis qui fonctionneraient dans la plupart des domaines d'apprentissage (par exemple, score, statut et temps).
- La possibilité d'enregistrer et de rapporter / récupérer des données définies par le contenu: Restreindre la collecte de données à un petit ensemble d'éléments de données requis était trop limitatif. Dans la plupart des cas, ce qui était vraiment nécessaire était la seule possibilité d'enregistrer les données du contenu dans le LMS et de les récupérer plus tard pour analyse. L'objectif d'autoriser l'enregistrement / la récupération de données définies par le contenu permet aux concepteurs de contenu d'ajouter des fonctionnalités tout en étant interopérables. Les données définies par le contenu peuvent être du texte ou des données numériques.
- Modèle de données extensible (défini par les données de texte du contenu)
- Pièces jointes aux données numériques
- Prise en charge du modèle de prestation de contenu en tant que service (CaaS): Autoriser le stockage du contenu sur d'autres domaines (indépendamment du domaine du serveur LMS)
- Indépendance appareil / OS / navigateur: Permettre au contenu d'être indépendant du navigateur afin de communiquer ou d'être lancé.
- Partager des données entre les activités d'apprentissage: Autoriser le partage des données entre les activités d'apprentissage pour plusieurs apprenants inscrits au même cours
Fonctionnement basique
Cmi5 définit la façon dont le matériel d'apprentissage est défini pour inclure des commandes de monitoring pouvant interagir avec un système de gestion de l'apprentissage (LMS). Un cours est une sorte d'objet d'apprentissage (AU), très similaire à un IMS Content Packaging: techniquement parlant, il s'agit d'un fichier zip avec un fichier XML cmi5 spécifique qui est ensuite téléchargé sur un LMS prenant en charge le cmi5.
L'objet le plus important dans la spécification Cmi5 est l'unité assignable (AU), c'est-à-dire une sorte d'objet d'apprentissage. Les unités assignables sont définies comme “la présentation de contenu d'apprentissage lancée à partir d'un LMS. L'UA est l'unité de suivi et de gestion. L'UA recueille des données sur l'apprenant et les envoie au LMS”. (spécification cmi5, version Sandstone)
Un cours est ensuite défini comme une collection d'unités assignables (AUs). Par conséquent, la structure du cours est une “liste d'unités assignables et de paramètres de lancement, avec une séquence implicite”. (idem)
Le système de gestion de l'apprentissage (LMS) est défini comme “un système informatique qui peut inclure les possibilités d'enregistrer les apprenants, lancer des présentations d'apprentissage, analyser et rapporter les performances des apprenants et suivre leur progrès. Les rôles de lancement, de génération de rapports et de suivi LMS sont au cœur de la spécification cmi5. Le LMS doit avoir un Learning Record Store (LRS) dans le cadre de sa mise en œuvre”.
Le LMS importe une structure de cours qui contient au moins une AU. Le modèle cmi5 décrit ensuite les étapes suivantes d'une expérience d'apprentissage / suivi:
- Les UAs sont lancées par l'apprenant et le LMS écrit les données de lancement au LRS, c'est-à-dire l'identification de l'UA, la carte d'étudiant
- L'UA nécessite des données de lancement ainsi que des informations sur l'état antérieur du LMS, c'est-à-dire qu'elle contiendra des données sur l'apprenant, y compris un travail préalable avec cette unité.
- L'apprenant voit le contenu de l'UA et (espérons-le) s'engage dans l'apprentissage. Pendant ce temps, l'UA peut stocker des données et demander des données au LMS.
- Lorsque l'apprenant quitte l'UA, il communique les données de suivi finales au LMS.