Représentation du contenu SCORM
Le cœur de la spécification de packaging du contenu SCORM est le fichier manifeste du cours. Le manifeste est un fichier XML qui décrit complètement le contenu. Il contient plusieurs pièces essentielles :
Ressources
Les ressources sont une liste de « pièces » qui composent le cours. Il existe deux types de ressources, les SCO et les actifs.
- Un actif est une collection d’un ou plusieurs fichiers qui constitue une unité logique. Les actifs peuvent être soit des unités d’enseignement autonomes ( » parties » du cours), soit des collections logiques de fichiers qui sont réutilisées dans d’autres parties du cours (un ensemble commun d’images de marque, par exemple).
- Les SCO sont des unités d’enseignement qui sont également composées d’un ou plusieurs fichiers. Les SCO sont presque toujours des parties pédagogiques d’un cours.
La différence essentielle entre un SCO et un actif est qu’un SCO peut communiquer avec le LMS, alors qu’un actif est simplement un contenu statique qui est présenté à l’utilisateur. Toute ressource qui peut être lancée par l’apprenant contient un pointeur vers la page vers laquelle le LMS doit rediriger l’apprenant afin de lancer la ressource. Les ressources doivent également contenir une liste complète de tous les fichiers nécessaires à la bonne fonctionnalité de la ressource afin qu’elles puissent être portées vers de nouveaux environnements et continuer à fonctionner.
Organisations
Les organisations sont des regroupements logiques des parties d’un cours (ressources) dans une structure hiérarchique. Un même manifeste peut contenir plus d’une organisation du même contenu (par exemple, pour permettre de présenter le contenu différemment selon les publics), mais il n’y a généralement qu’une seule organisation, l’organisation par défaut. Les organisations sont toujours structurées de manière hiérarchique, sous forme d’arbre. Les nœuds de cette arborescence sont appelés « activités » (lorsqu’on y fait référence dans le contexte du séquençage) ou « éléments » (lorsqu’on y fait référence dans le contexte du conditionnement du contenu). Tout élément peut avoir des éléments enfants imbriqués sous lui. Lorsqu’un élément a des enfants, on parle d’une « agrégation » ou d’un « cluster ». Les éléments qui n’ont pas d’enfants doivent faire référence à une ressource. Cette ressource est ce qui est fourni au leaner lorsque l’élément est sélectionné. Les éléments qui ont des enfants ne sont pas autorisés à faire référence à des ressources, ils sont uniquement des conteneurs pour d’autres éléments. (On peut comparer cette structure à celle des fichiers d’un ordinateur… les éléments sont soit des dossiers, soit des fichiers, mais pas les deux. Les dossiers peuvent contenir d’autres dossiers ou fichiers, mais les « dossiers vides » ne sont pas autorisés.)
Plus d’informations:Le format XML du manifeste SCORM 2004.
Métadonnées
Chaque élément du manifeste peut être décrit en détail en lui associant des métadonnées. Les métadonnées SCORM sont enregistrées dans un format bien défini appelé « métadonnées d’objet d’apprentissage », ou « LOM ». LOM contient de nombreux champs prédéfinis pour décrire le contenu d’apprentissage. SCORM permet également l’extension de LOM pour permettre aux organisations de spécifier des métadonnées supplémentaires. Les métadonnées peuvent être appliquées à pratiquement n’importe quelle section du manifeste, par exemple au cours dans son ensemble, à des éléments individuels ou même à des ressources et des fichiers individuels afin d’améliorer leur réutilisation. Dans le fichier du manifeste, les métadonnées peuvent être spécifiées en ligne dans le XML (recommandé pour les petites quantités de métadonnées, en particulier au niveau du cours), ou elles peuvent être spécifiées par un lien vers un fichier de métadonnées externe (recommandé pour les grandes quantités de métadonnées détaillées). Les métadonnées sont généralement facultatives, mais SCORM 1.2 impose certaines restrictions sur le sous-ensemble minimal de données qui doit être spécifié si des données sont spécifiées. La quantité appropriée de métadonnées SCORM à utiliser variera largement en fonction de l’utilisation prévue du contenu, de sa longévité anticipée et de la probabilité que le contenu soit réutilisé.
Plus d’informations : Le format XML des métadonnées de SCORM 2004.
Séquencement
Dans SCORM 2004, chaque activité peut se voir attribuer un ensemble de règles de séquencement. Ces règles sont encodées en XML dans le manifeste du cours. SCORM a été conçu de telle sorte qu’un cours simple ne comprenant que des actifs ne devrait pas avoir besoin de spécifier de règles de séquençage, à l’exception des valeurs par défaut. Cependant, dans la pratique, il existe des valeurs par défaut qui doivent être remplacées pour tous les cours, sauf les plus simples.
Plus d’informations : Le binding XML de séquençage SCORM 2004.
Emballage du contenu
Une fois que le contenu a été représenté en XML, il est enregistré dans un fichier appelé « imsmanifest.xml ». Le fichier manifest doit toujours exister à la racine du contenu. Pour être totalement conforme, le contenu doit également inclure un ensemble de fichiers de définition de schéma XML (fichiers .xsd et .dtd) qui décrivent formellement la grammaire XML contenue dans le manifeste, y compris les extensions éventuellement utilisées. (Téléchargez les fichiers de définition de schéma du manifeste SCORM). Le contenu peut ensuite être livré soit dans un simple répertoire (par exemple sur un CD), soit dans un fichier ZIP. Lorsque le contenu est placé dans un fichier ZIP, il est connu sous le nom de « package interchange file » ou « PIF ». Les PIF sont de loin le format de livraison SCORM le plus courant.
Un principe important du packaging de contenu est qu’idéalement, tout ce qui est nécessaire pour délivrer le cours doit être contenu de manière autonome dans le fichier PIF. SCORM encourage fortement la portabilité et la réutilisation. Pour maximiser ces objectifs, chaque fichier nécessaire à la diffusion du cours doit être contenu dans le PIF et répertorié dans le manifeste. En outre, les développeurs de contenu doivent éviter d’utiliser du code côté serveur et d’autres dépendances comme les bases de données. L’utilisation de ces outils, ainsi que des dépendances externes, est autorisée par SCORM, cependant la norme de l’industrie est de les éviter lorsque cela est possible.