Gestion du cycle de vie des cours en ligne basé sur l

Université de Genève 1 Switch-AAA

Annexe 2 : Descriptif du projet 2 Date: 26/03/08

Chefs de projet

Projet Institution

Pierre-Yves Burgi et Patrick Roth

Gestion du cycle de vie des cours en ligne basé sur l'environnement Fedora

Université de Genève

Auteurs: Patrick Roth et Georges Lavoisier

Dates début/fin du projet: 15 avril 2008 au 30 octobre 2009

Titre du projet: Gestion du cycle de vie des cours en ligne basé sur l'environnement Fedora

Responsable du projet à l'université (Mandant, sponsor): Alain Jacot-Descombes

Chefs de projet à l'université: Pierre-Yves Burgi et Patrick Roth

Autres collaborateurs au projet à l'université: Olivier Jeannin, Jan Melichar

Autres université participantes et leurs collaborateurs au projet: Université Suisse Italienne

Objectifs/utilité: L'objectif du projet que nous nous proposons de réaliser est double. Tout d'abord mettre en place une infrastructure transparente d'échange d'objets pédagogiques inter-LMS. Cette infrastructure devra permettre aux enseignants d'un LMS de pouvoir accéder aux objets pédagogiques élémentaires stockés sur un des LMS des Universités et Ecoles Polytechniques suisses. Il est à noter que ce projet sera directement en lien avec le Learning Object Repository1 (Switch-LOR) initié en 2006 par SWITCH. Le second objectif que nous proposons de réaliser est une solution d'archivage. Dans un premier temps il s’agira d’un archivage court terme permettant de sauvegarder une leçon, un cours, etc. d'un LMS spécifique. Dans un deuxième temps, une solution plus universelle d'archivage long terme de ces objets pédagogiques sera proposée. Cette solution nécessitera l'utilisation d'un langage "pivot", par exemple SCORM (Sharable Content Object Reference Model) ou/et Common Cartridge [9]. En outre, il sera possible d'accéder en lecture et/ou en écriture aux objets pédagogiques archivés en tout temps, ceci pour une période pouvant aller de quelques mois à plusieurs années. Ceci nécessitera de tenir compte de la compatibilité des objets pédagogiques pour une période de temps relativement longue et donc de mécanismes permettant le recyclage des cours (au travers du langage pivot). Du fait de l'ampleur de la problématique, ces aspects d'archivage ne seront pas traités dans ce projet, mais feront l'objet d'un futur projet qui s’appuiera sur les solutions proposées dans ce présent projet (et d’une analyse préliminaire).

Nombre d'utilisateurs attendus:

Enseignants : plusieurs centaines

Etudiants : 15'000 + triangles Azur (Universités de Neuchâtel, Lausanne, et Genève) + communauté Switch-AAI

1 http://www.switch.ch/de/els/LOR


1. Description technique 1.1 Situation actuelle Avec la démocratisation du WEB, les LMS (Learning Management System) ou plateformes d'enseignement intégré, sont devenus une brique essentielle de l'enseignement dans l'ensemble des universités suisses. En effet, la possibilité d'accéder à distance au contenu pédagogique de leurs cours représente un confort dont les étudiants ont de plus en plus du mal à se passer.

Actuellement, l'Université de Genève met à disposition de sa communauté deux LMS: Dokeos2 et Moodle3. Ces deux LMS permettent aux enseignants de créer des espaces de cours et de mettre des objets d'apprentissage (ou pédagogiques) à disposition de leurs étudiants. Ces objets sont donc stockés dans les LMS eux mêmes qui font de ce fait office de repository4. Le gros désavantage est qu'il n'existe pas de moyen transparent pour les enseignants de réutiliser un objet pédagogique d'une plateforme LMS à l'autre, ceci tant au niveau institutionnel qu’inter-institutionnel (i.e., entre les LMS des hautes écoles suisses).

Outre le problème de la transparence entre les LMS, certains objets d'apprentissages sont tout simplement incompatibles entre LMS. C'est le cas des archives, puisqu'une archive produite sur Dokeos ne peut pas être lue par Moodle. Cette incompatibilité a pour conséquence de compliquer la mise en place d'une structure d'archivage d'objets pédagogiques universelle et utilisable sur le long terme.

1.2 Solution conceptuelle Pour pouvoir répondre aux objectifs que nous nous sommes fixés, il nous faut approfondir notre connaissance relative aux objets pédagogiques ainsi qu'à leur cycle de vie.

Notion d'objet pédagogique

Un objet pédagogique ou objet d’apprentissage, peut être défini dans sa forme la plus générale comme « Entité digitale ou non digitale, pouvant être utilisée, réutilisée ou référencée durant le processus d'apprentissage assisté par la technologie » [1].

Ici, l'apprentissage assisté par la technologie inclut les systèmes d'entraînement basés sur les ordinateurs, les environnements d'apprentissages interactifs, les systèmes d'apprentissages à distance ou les environnements d'apprentissages collaboratifs. Des éléments concrets d'objet pédagogique seraient par exemple typiquement du contenu multimédia ou du contenu pédagogique (voir Figure 1).

L’idée principale sous-jacente au concept d’objet d’apprentissage est la structuration du contenu éducatif en différentes briques distinctes, qui pourront par la suite être utilisées de manière modulaire dans des environnements d’apprentissage hétérogènes. En effet, la plupart du temps, lorsqu'un professeur accède pour la première fois à un matériel pédagogique nouveau, il le séquence en différents blocs élémentaires, pour ensuite le réassembler comme il le souhaite et parvenir à sa finalité, remplir son objectif d'apprentissage.

2 http://dokeos.unige.ch

3 http://moodle.unige.ch

4 Qui peut être défini en Français comme un « dépôt de stockage centralisé ».


Fig.1: Différents éléments possibles d’un contenu pédagogique

La conception d'objets pédagogiques se caractérise donc par deux principes intimement liés qui sont la granularité et la combinaison [2]. La granularité se réfère à la « taille » d'un objet pédagogique (OP) tandis que la combinaison définit la manière dont ce dernier est assemblé avec d'autres objets pour former un nouvel OP. Il existe plusieurs manières de caractériser la granularité d'un OP [3,4]. Parmi elles, la caractérisation d'un objet par sa complexité introduite par le groupes de travail IEEE LTSC (Learning Technology Standards Committee) et son standard IEEE 1484.12.1-200 [1] est sans doute la caractérisation plus souvent utilisée. Dans ce cas, il existe 4 niveaux distincts de granularité :

Niveau 1: Fragment de donnée ou donnée atomique, comme par exemple un document, une présentation, une vidéo, un test d'auto-évaluation, etc. (voir figure 1).

Niveau 2: Combinaison d'OP de niveau 1 formant par exemple une leçon.

Niveau 3: Combinaison d'OP de niveau 2 dont le résultat forme un cours.

Niveau 4: Combinaison d'OP de niveau 3 pouvant former, par exemple, un certificat. Outre la granularité et la combinaison, le groupe LTSC et le centre des Ressources on-line du Wisconsin [4] proposent d'ajouter la notion d'indexation des objets d'apprentissage par le biais de métadonnées pédagogiques. Ces métadonnées ont pour but de décrire sémantiquement un OP. Elles permettent de ce fait de faciliter sa recherche, le référencement et le transport d'un OP. La Figure 2 suivante représente quelques propriétés possibles d'un OP en termes de données et de métadonnées.


Fichier vidéo

Page HTML

Document PDFFichier audio

QuizDocument Word

Objet d’apprentissage

ContenuPédagogique

Identifiant

Date decréation

Description

Langue

Mots clés

Durée

Version

Statut

Titre

Matière

MétaDonnées

Fig.2: Quelques propriétés courantes d'un OP

Il existe plusieurs standards décrivant les métadonnées des objets d'apprentissage dont les plus connus sont le LOM5 [1] et DublinCore6 [6]. Ces différents standards sont généralement construits

5 Learning Object Metadata est un modèle de données, habituellement encodé en XML, et utilisé pour décrire les

objets d’apprentissages ou autres ressources digitales utilisés pour supporter le processus d’apprentissage.


selon une hiérarchie de propriétés, possédant chacune une description, un type de donnée et un espace de valeurs (souvent défini par une norme ISO). Notons à ce propos qu'il existe souvent des analogies entre les propriétés de ces standards, comme nous le verrons dans la section suivante.

Intéressons-nous à présent aux propriétés du standard LOM et plus particulièrement à celle qui caractérise le cycle de vie d'un objet pédagogique (OP). Ce dernier détermine l'historique ainsi que l'état actuel d'un objet pédagogique. Selon Catteau et Al. [7], le cycle de vie d'un objet pédagogique comprend 9 phases comme nous le montre la Figure 3.

Fig.3: Représentation du cycle de vie d'un OP

Le cycle de vie commence par une phase d’initiation pendant laquelle l'OP ne contient que la description de ses intentions. Puis vient ensuite la phase de conception, dans laquelle on détermine ses caractéristiques spécifiques. Ensuite vient la phase de réalisation où l'on concrétise l'OP dans le but de le rendre exploitable. Ensuite la phase de classification, qui comme son nom l'indique, classe l'OP selon des standards comme CDD7 ou CDU8. Puis vient la phase de validation où les avis de différents experts (du domaine, pédagogues) sont nécessaires pour assurer la qualité du fond et de la forme de l’OP. Selon l'avis des experts, l'objet devra revenir dans une des 3 étapes précédentes, ou passer en phase de diffusion. Lors de cette phase, l'OP sera intégré dans un dispositif d'enseignement (e.g, un LMS, voir ci-dessous) permettant ainsi son utilisation au sein d'un cursus

6 Le DublinCore fournit un ensemble de métadonnées pluridisciplinaires (bibliométriques, pédagogiques, etc.)

utilisé pour décrire des ressources informationnelles.

7 La Classification Décimal de Dewey (CDD) est un système ayant pour but de classer l'ensemble du savoir humain à l'intérieur d'une bibliothèque.

8 La Classification Décimal Universelle (CDU) est une classification perfectionnée de la CDD.


de formation d’un apprenant. Ce dernier va ensuite tirer profit de l'objet pendant la phase d'utilisation. Suite à cette phase, l'apprenant donne ses avis sur le cours et donc sur l'objet pédagogique lors de la phase retour d'expérience. Finalement, en fonction du retour d'expérience, l'objet sera soit modifié, et donc retournera en phase de conception, soit archivé.

Création et diffusion d'objets pédagogiques par les LMS

Comme nous venons de le voir dans la section précédente, le cycle de vie d'un objet pédagogique s'effectue selon 9 phases successives. Parmi elles, certaines pour exister ont besoin de supports informatiques spécialisés. C'est le cas des phases 3, 6, 7 et 9 qui nécessitent l'utilisation de système d'enseignement intégré, comme le sont par exemple Dokeos et Moodle. Grâce à ces systèmes, les enseignants en combinant des OP de niveau 1 construisent des objets de niveau 2, donc des cours. Ces cours sont ensuite diffusés (généralement en utilisant le même support) puis utilisés par les apprenants. Finalement, ces cours sont dans la plupart du cas archivés au sein de la même plate-forme.

Le problème majeur des LMS actuels est que les objets pédagogiques atomiques et ceux de niveau 2 sont uniquement stockés dans leurs plateformes respectives et qu'il n'existe aucune transparence. Il n'est donc pas possible en phase de réalisation de combiner des objets d'apprentissages provenant d'autres LMS 1) au sein de la même institution et 2) entre les institutions suisses (voir Figure 4 ci-dessous).

Fig.4: Situation actuelle des objets d'apprentissage dans les LMS

Un moyen efficace de répondre à ce problème est d'utiliser un repository comme « pont » entre les LMS. Aussi, une solution qui se base sur l'utilisation de la plateforme Fedora comme repository


nous amène à faire appel à trois notions distinctes : l'objet numérique, le harvesting et l’ingest. C'est ce que nous allons préciser dans la section suivante.

Mutation d'un objet pédagogique niveau 1 en un objet numérique

En opposition aux systèmes de gestion de bases de données « traditionnelles », basés sur le concept d’entités relations, Fedora propose une structure de données particulière, fondée sur le concept d’objets digitaux. Les objets digitaux fournissent un support pour le stockage d’informations binaires et textuelles de tous types, mais également un support dédié au stockage des métadonnées (basé sur les 15 propriétés du DublinCore). Ces deux composantes sont suffisantes pour percevoir l’adéquation de la structure de données de Fedora avec celle des OP.

La spécification du modèle objet de Fedora met en évidence plusieurs composantes élémentaires d’un objet digital :

• Un identifiant persistant unique (PID) • Un ou plusieurs flux de données typés relatifs au contenu de l’objet en termes de données

numériques (images, textes, vidéos, flux XML, etc.). A noter qu'un flux de données peut également être une référence vers un contenu distant identifié par une URL, géré ou non par Fedora.

• Un flux de donnée spécifique, pouvant stocker les 15 propriétés suivantes du DublinCore : title, creator, subject, description, publisher, contributor, date, type, format, identifier, source, language, relation, coverage, rights.

• Eventuellement un «disseminator», composant associant un ensemble de comportements à un objet. Un disseminator a pour but de transformer le contenu ou de le préparer pour une mise en forme. Il est assuré par une servlet, dont les méthodes implémentent l’action à effectuer sur le contenu de l’objet. Le comportement dynamique d’un objet est donc assuré par le processus de dissémination.

La Figure 5 suivante schématise quelques propriétés possibles d’un objet digital.

Fig.5: Exemple de propriétés d'un objet digital sous Fedora

Parallèlement, des relations entre les objets gérés par Fedora peuvent être mises en place, à l’aide de représentations basées sur RDF [8].


Fedora permet également l’agrégation de contenu local et de contenu distribué (distant) dans un même objet digital. Cette caractéristique occupe une place prépondérante en ce sens que Fedora peut agir comme passerelle pour des données et n'oblige pas à les stocker en interne. L'agrégation de sources de données hétérogènes est donc possible, sans remettre en question le modèle initial.

Le stockage et la récupération des données au sein de Fedora sont effectués par deux processus spécifiques qui sont l’ingest et l’harvest. L’ingest tout d'abord est le processus responsable de l'enregistrement des objets digitaux dans Fedora. Ce processus comporte deux phases manuelles qui sont :

• La création du flux ou d’un fichier formalisé comportant un certain nombre de propriétés comme les métadonnées et/ou les références sur la ressource.

• L'enregistrement de ce fichier ou de ce flux dans Fedora.

A la suite de ces deux étapes, Fedora prend en charge le stockage et l'indexation de l'objet et de ses métadonnées associées, respectivement dans le système de fichier et dans le registre interne.

S'agissant du processus d'harvesting, il est responsable de la récupération des métadonnées. Ce processus permet de centraliser les métadonnées et par conséquent d’effectuer des recherches globales sur un grand nombre d’objets. L’utilisation d’un repository Fedora comme pont pour l'échange d'objet pédagogique entre les LMS est illustré dans la Figure 6.

Fig.6: Utilisation de Fedora pour le transfert d'objets pédagogiques inter-LMS


Ainsi, pour qu'un OP soit visible par un autre LMS, il se doit d'être au préalable ingested dans Fedora. Comme nous l'avons décrit plus haut, ce processus d’ingest demande tout d'abord la création d'un flux/fichier normalisé contenant dans notre cas entre les métadonnées ainsi qu'une série de références relatives aux objets pédagogiques ingestés. Les métadonnées que nous retiendrons (métadonnées qui restent à être définies) seront de deux natures : (1) spécifiques au projet Switch-LOR et (2) spécifiques à notre université. Pour les métadonnées spécifiques au projet LOR, les membres du projet, dont l'Université de Genève fait partie, ont retenu les propriétés suivantes afin de faciliter le processus de Harvesting :

• Identifiant de la ressource

• Titre de la ressource

• Langage du contenu de la ressource • Droits d’accès associés à la ressource

• URL de la ressource • Créateur de la ressource

Quant aux métadonnées retenues par notre institution, elles sont à ce jour au nombre de 4, à savoir :

• Type de la ressource • Description de la ressource

• Date de création de la ressource • Code du cours auquel est associée la ressource

Ces propriétés représenteront un ensemble d’éléments sémantiques invariablement présent dans tous les objets d’apprentissages gérés par le système. On remarque un nombre relativement restreint de propriétés, 9 pour être précis. Deux avantages peuvent être perçus à ce faible nombre. Cela permet tout d’abord de ne pas axer le processus de standardisation sur des propriétés peu utilisées qui alourdiraient le modèle de données. De plus, les propriétés que nous avons retenues permettent une extraction automatique de ces dernières par le LMS en évitant un processus manuel effectué par l'enseignant. Ces propriétés de bases pourront par la suite être étendues selon le contexte et les besoins. Ensuite, dans une optique d’interopérabilité avec un LMS préexistant, un nombre de propriétés restreint offre une plus grande flexibilité, le processus de transfert des objets n’exigeant du système tiers que le minimum de métadonnées sur les objets qu’il transmet. En effet, les systèmes préexistants peuvent être disparates en terme de métadonnées qu’ils maintiennent en relation avec leurs objets d’apprentissages, on ne peut donc pas en attendre un ensemble exhaustif de métadonnées.

Déterminons maintenant la correspondance entre ces métadonnées de l’OP et un objet digital dans Fedora. Ceci est fait par étape en transposant ces métadonnées en DublinCore, à savoir en utilisant les champs pid, title, type, language, rights, creator, description et date. Cette transposition est visible dans le Tableau 1.

Dans le cas où la propriété n'est pas définie dans le DublinCore, nous ajouterons cette dernière dans un flux de données que nous appellerons "extra-metadata". Cela sera le cas pour les propriétés « code du cours » rattaché et l’URL de la ressource. Au final, la Figure 7 schématise le modèle de métadonnée représentant l'objet digital dans Fedora, qui décrit les propriétés des OP accessibles entre LMS.


Tab.1: Correspondance des métadonnées selon différents standards [10]

Fig.7: Propriétés de l'objet digital correspondant aux OP

1.3 Solution technique Comme précisé au début de ce document, l'objectif du projet que nous nous proposons de réaliser est double et consiste

• A la mise en place d’une infrastructure transparente d'échange d'objets pédagogiques élémentaires (niveau 1) inter-LMS et inter-institutionnelle

• A l’analyse préliminaire d'une solution d'archivage d'objets pédagogiques de niveau > 1.

Mise en place d'une infrastructure transparente d'échange d'objets pédagogique

Les 2 briques principales apparaissant ici sont les LMS utilisés à l'Université de Genève (Dokeos et Moodle) ainsi que le repository choisi, à savoir Fedora. Il convient donc ici, d'exposer brièvement l'architecture des LMS, puisque ceux-ci devront être modifiés afin de fournir l'interface nécessaire au renseignement ainsi qu'à la récupération des objets d'apprentissages. Dans un deuxième temps nous éclaircirons les mécanismes mis en œuvre pour le renseignement et la consultation de Fedora. Ces deux étapes nous permettront d'exposer une solution conduisant à la publication et la récupération d'objets pédagogiques entre différents LMS.


Architecture des LMS

Les environnements de Dokeos et Moodle sont, comme indiqué dans le schéma de la Figure 8, de type AMP (Apache, MySql, PHP). Cela amène naturellement à des développements de modules en PHP pour ce qui concerne la publication et la récupération des objets sur Fedora.

Fig.8: Composants logiciels de Dokeos

Renseignement et consultation de Fedora

Pour injecter un objet digital dans Fedora, on doit passer par une API, l'API-M, dédiée à cet effet. Fedora expose ses fonctionnalités à travers des Web services, comme visible sur le schéma ci-après (Figure 9):

Fig.9: Web services de Fedora

Comme on le voit, l'API-M reçoit du FOXML, qui est ensuite stocké par Fedora. Le FOXML est un format XML simple qui exprime directement le modèle des objets digitaux sous Fedora. On observe aussi les éléments search et RISearch qui seront utilisés pour la récupération d'objets digitaux.


Publication des métadonnées de l'OP depuis le LMS sur Fedora (one click plublishing button)

La démarche qui sera suivie pour l'injection d'un OP dans Fedora passe par une transcription des caractéristiques de l'objet en FOXML. Ainsi, schématiquement, ce passage se traduit ainsi (Figure 10):

Extraction des métadonnées

Enregistrement du flux dans Fedora

Conversion au format FOXML

Vérification des métadonnées

Fig.10: Etapes d'enregistrement d'un objet digital

L'enregistrement du flux dans Fedora se fait via SOAP (Simple Object Access Protocol) en invoquant une API-M de Fedora dédiée à l'ingest (injection). De manière schématisée, le résultat de cette application peut être représenté comme suit (Figure 11) :

Fig.11: Publications d'objets pédagogiques sous Fedora


La solution qui consisterait à développer des modules PHP dans chaque application LMS permettrait d'injecter les OP directement dans le repository. Cependant, de telles solutions seraient trop fortement couplées aux LMS concernés et ne permettraient pas (ou peu) la réutilisation du code lors de l'apparition de nouvelles applications ayant aussi besoin d'injecter des objets d'apprentissages dans Fedora. C'est pourquoi la publication de l'OP sera assurée par une couche intermédiaire qui se voudra extensible à d'autres applications à venir (ayant la même vocation de création et de publication d'objets d'apprentissage). Cette couche, dite de "communication", est illustrée dans le schéma suivant (Figure 12):

Fig.12: Transformation d'objets pédagogiques et ingestion sous forme d'objets digitaux dans Fedora

Dans ce cas de figure, des modules en PHP seront toujours nécessaires dans chaque LMS, mais les fonctionnalités leur incombant sont réduites car la transcription des objets d'apprentissage en FOXML, ainsi que leur injection via SOAP dans Fedora, sont déléguées à cette couche intermédiaire. Les propriétés d'un OP créé dans un LMS, ainsi que les propriétés d'un objet digital tel que stocké dans Fedora, devront être mises en rapport, ceci afin d'assurer une bonne conversion des objets comme montré dans le Tableau 1 ci-dessus.

Récupération transparente d'un OP

Par récupération transparente d'objets d'apprentissage nous entendons la récupération sur la base des métadonnées fournies par Fedora. Aussi, deux cas se présentent: (1) l'objet élémentaire (niveau 1) récupéré a été conçu sur le même LMS (et est donc déjà stocké sur ce LMS); (2) l'objet élémentaire (niveau 1) récupéré a été conçu sur un autre LMS et n'est donc pas encore stocké sur ce LMS. Pour traiter ces deux cas, nous développerons toute la logique dans des modules PHP. La


récupération des objets s'opérera donc sans intermédiaire, comme illustré ci-après (Figure 13) :

Fig.13: Recherche et acquisition d'objets pédagogiques par le biais de Fedora

Une requête sera construite et envoyée sur Fedora par le module PHP (étape 1). Puis le résultat (étape 2) de cette requête sera traité afin de le présenter à l'utilisateur. Puisque le contenu de l'objet encapsulera toutes les données relatives à sa plateforme d'origine (y compris son emplacement sous la forme d'une URN), cela nous permettra de déterminer sa compatibilité avec la plateforme locale et de l'afficher ou non comme téléchargeable. Subséquemment, l'utilisateur aura la possibilité de choisir certains objets pour les télécharger sur le LMS (étape 3). Indépendamment des contraintes liées à l'accès aux objets, le téléchargement se produira directement entre les LMS (étape 4), par exemple de Dokeos à Moodle. La stratégie pressentie lorsqu'un objet n'est pas compatible avec la plateforme locale sera d'en permettre dans tous les cas un téléchargement sur la machine de l'utilisateur.

Droits d'accès

Les droits d'accès aux OP nécessiteront une étude particulière afin de définir une stratégie d'autorisation/refus d'accès au sein de l'institution. Cette stratégie devra tenir compte des solutions proposées par les membres du projet LOR [10]. Des mécanismes utilisant les propriétés d'objet de Fedora seront mis en œuvre afin de garantir que le niveau de sécurité exigé par l'auteur des OP soit respecté. Il faudra également prévoir lors du stockage des OP la possibilité de spécifier ce niveau de sécurité.

Perspective de collaboration inter-institutionnelle au travers d'OAI-PMH

Les développements effectués dans ce projet poursuivent aussi les objectifs décrits dans le workshop Switch d'octobre 2007, à savoir la mise en place d'une architecture globale permettant de mettre en commun des objets d'apprentissages créés par diverses universités ou institutions suisses (Switch étant chargé de la mise à disposition d'un réseau pour la fédération des objets). La mise en place d'une telle architecture est dictée par un besoin de normalisation et de collaboration du matériel pédagogique. Les avantages perçus sont évidents: réutilisation du matériel pédagogique, amélioration de la collaboration intra et inter institutionnel, archivage et distribution des objets d'apprentissage de manière persistante via des URL stables (par exemple des URN). Fedora met à disposition le processus de Harvesting (via un module batch tool) qui consiste en la récupération des métadonnées dans de multiples repository. Ce processus permet de centraliser les métadonnées et par conséquent d'effectuer des recherches globales sur un grand nombre d'objets.


D'autre part, via un protocole spécifique OAI-PMH (Open Archives Initiative Protocole for Metadata Harvesting), des repository hétérogènes peuvent servir de fournisseur de métadonnées. Le protocole OAI-PMH, se base sur des requêtes POST ou GET du protocole HTTP. Il est donc envisageable techniquement d'établir une communication des métadonnées inter-repository, et donc de rejoindre un LOR fédérant plusieurs Universités et Hautes Ecoles. Dans ce sens, nous pouvons imaginer une collaboration entre universités, dans laquelle chaque partie pourrait harvester l'autre (voir Figure 14).

Fig.14: Harvesting inter-institutionnel simple

Cependant, la mise en application d'une telle mise en œuvre du protocole OAI-PMH engendrait à une échelle nationale une explosion combinatoire d'échange de données qui occasionnerait des tâches d'administration prohibitives (cf. Figure 15). De plus, l'unicité des objets serait plus difficile à maintenir.

Fig.15: Harvesting inter-institutionnel combinatoire

Par conséquent, il serait plus judicieux d'avoir une solution dans laquelle SWITCH mettrait à disposition un Repository central qui s'occuperait de harvester tous les repositories fédérés. Le repository de chaque institution n'aurait besoin d'accéder et d'être accédé qu'avec un repository central, qui lui s'occuperait de harvester les autres repositories et aussi de garantir l'unicité des données. Cette solution est illustrée dans la Figure 16.


Fig.16: Harvesting inter-institutionnel simplifié

Création d'une solution d'archivage des cours

Comme indiqué au début de ce document, un deuxième objectif du projet est l'archivage d’OP de niveau > 1. L'idée est la suivante: les LOA (Learning Objects Archives) sont une façon de stocker un cours. L'Université a en effet l'obligation de conserver les cours et de les mettre à disposition des élèves un certain temps après la fin de leurs études. Les archives de cours nécessitent donc un traitement particulier, afin de rester lisibles dans le temps. On a déjà constaté des problèmes lors de la sortie d'une release de Dokeos. En effet, pour certains cours ayant été créés sur une des versions antérieures de Dokeos, la lisibilité n'était plus garantie. Des solutions doivent être trouvées afin d'éviter l'obsolescence des archives.

Un autre objectif plus lointain dans le traitement des archives est d'offrir un point d'entrée unique permettant des les récupérer et de les lire. La technologie toute pressentie pour servir à la fois d'espace de stockage et d'indexeur de métadonnées à l'Université de Genève est la plateforme Fedora sur laquelle pourraient être archivées toutes les archives de cours produites par nos LMS.

Une première stratégie pour éviter qu'une archive ne devienne illisible dans le temps serait de conserver des releases des plateformes en ligne afin de pouvoir en tout temps déployer ces archives. Deux problématiques majeures seraient cependant à résoudre :

• La multiplicité des versions des logiciels ne fait que de s'accroître d'année en année. • Les failles de sécurité dans certaines plateformes ne sont parfois corrigées que dans une

version suivante, ce qui impliquerait de garder en ligne des plateformes dont les failles sont déjà connues.

Une deuxième stratégie serait d'appliquer un traitement aux archives au moment de leur création afin d'en faire le stockage sous une forme normalisée (langage pivot). Cela nous permettrait ensuite de les lire au moyen de lecteurs d'archives de la bonne norme (SCORM ou Common Cartridge pour les citer).


On pourrait penser ici que la solution est toute trouvée, étant donné que de plus en plus de LMS proposent la création d'archivage dans ces formats normalisés. Cependant, et ce malgré un certain respect des normes de création des archives, ces dernières restent tout de même dépendantes de leur plateforme de création pour deux raisons essentielles :

• L'insertion de données trop fortement couplées au LMS dans l'archive, ce qui peut interférer à sa visualisation dans un lecteur de la norme.

• L'existence de certains objets non prévus par une norme. Par exemple, les tests d'évaluations ne sont pas prévus par la norme SCORM.

La norme la plus complète semble être à ce jour la norme Common Cartridge définie par IMS. Cependant, une liste exhaustive des objets concaténés dans un cours devra être faite pour s'assurer d'un stockage optimal des objets selon le langage pivot choisi. Le cas échéant, il faudrait procéder à un filtrage des objets non prévus par le langage pivot et assurer une veille technologique afin de rester à jour avec les possibilités qu'offrent ces normes.

Dans ce projet nous nous limiterons à une analyse préliminaire de la problématique d'archivage d'un OP niveau > 1, limitée dans un premier temps à une plateforme spécifique. Dans un deuxième temps, nous traiterons plus spécifiquement de l'archivage universel basé sur un langage pivot. Le développement des solutions se fera dans le cadre d’un nouveau projet.

1.4 Bibliographie [1] IEEE Learning Technology Standards Committee (2002), Draft Standard for Learning Object Metadata, IEEE 1484.12.1-2002. Retrieved March, 2008, from the World Wide Web: http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf. [2] Wiley, D. A. (2000), Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy. in D. A. Wiley, ed., The Instructional Use of Learning Objects: Online Version. Retrieved March, 2008, from the World Wide Web: http://reusability.org/read/chapters/wiley.doc. [3] K. Thompson and Fr. Yonekura (2005), Practical Guidelines for Learning Object Granularity from One Higher Education Setting , in Interdisciplinary Journal of Knowledge and Learning Objects, Volume 1. [4] Wiley, D. et al. (2004), A reformulation of the issue of learning object granularity and its implications for the design of learning objects. Retrieved March, 2008, from the World Wide Web: http://reusability.org/granularity.pdf [5] «Wisconsin Online Resource Center». Retrieved March, 2008, from the World Wide Web: http://www.wisc-online.com [6] Dublin Core MetaData, Retrieved March, 2008, from the World Wide Web: http://dublincore.org/ [7] Catteau O., Vidal P., Broisin J., 2006, “A Generic Representation Allowing for Expression of Learning Object and Metadata Lifecycle”, IEEE International Conference on Advanced Learning Technologies (ICALT’06), pp. 30-33. [8] Typical components of a learning object, Retrieved March, 2008, from the World Wide Web: http://en.wikipedia.org/wiki/Learning_object [9] Common Cartridge Working Group, Retrieved March, 2008, from the World Wide Web: http://www.imsglobal.org/commoncartridge.html [10] Brugger, R, Rohrer, Ch., Presentation for the Workshop "National Learning Object Repository" @ SVC Days 2007, Retrieved March, 2008, from the World Wide Web: http://www.switch.ch/export/sites/default/services/els/LOR/documents/2007-10-LOR-Workshop-presentation.pdf


Plan du projet/Deliverables/étapes: (cf. également le Gantt complet pour ce projet)

Étape Titre Prévu Commentaire 1 Préétude 27.05.08 Confirmation des concepts 2 Dokeos 30.10.08 Dokeos connecté au LOR 3 Moodle 15.04.09 Moodle connecté au LOR 4 Tests et production 14.08.09 Mise en marche effective 5 Promotion et clôture 28.09.09 Produit fini 6 Analyse archivage 30.10.09 Préparation de la suite du projet

Manpower/autre coûts:

Main-d’œuvre : 27 HM sur une durée totale de 18.5 mois

Budget (salaires + matériel) 2008

(15.04-31.12)

2009

(01.01-31.12)

Total

Aide fédérale escomptée au titre de contributions liées à des projets

45’000 84’000 129’000

Participation propre (matching funds) 78’000 58’000 136’000

Risques, sources de problèmes possibles:

Aucun majeur

Délimitations éventuelles par rapport à d'autres projets ou activités:

Liens avec le projet 1 (« Enregistrement et diffusion des cours en format audio-visuel enrichi »), puisque les documents multimedia constituent des éléments pédagogiques contenus dans les plateformes LMS.

Conditions préalables du succès du projet:

Une bonne coordination avec le projet LOR de Switch devra se faire.

Remarques:

Signature du responsable du projet à l'université __________________________

Documents

Gestion du cycle de vie des cours en ligne basé sur l