Objectif :
Dans le cadre d’un projet d’innovation pédagogique (IDEA) mené à l’université Paris-Est, nous proposons de travailler à une évolution de WIMS, consistant à séparer la partie «moteur» (résolution d’exercice) de la partie «données» (les exercices, soit encore les «ressources pédagogiques»). Ces ressources seraient placées dans une base de données (BD) externe, à laquelle ferait appel le (futur) programme WIMS. Au choix, WIMS pourrait appeler les ressources une par une, à la demande, ou télécharger périodiquement une mise-à-jour complète de la BD. C’est une méthode classique en informatique qui aurait les avantages énumérés ci-dessous.
J’invite la communauté WIMS à commenter et proposer des idées pour enrichir cette initiative, discuter de sa faisabilité et des moyens d’y parvenir, et écrire un cahier des charges idéal.
Avantages :
– pouvoir modifier cette base de donnée indépendamment du code de WIMS, en particulier ajouter plus facilement de nouveaux exercices ou nouvelles variantes
– faciliter le travail collaboratif (et néanmoins contrôlé) sur les exercices grâce aux outils modernes de partage ; possibilité de proposer des exercices à la validation collective
– associer aux éléments de cette base de donnée des métadonnées, permettant une indexation automatique et une recherche facilitée (le moteur de recherche pourrait être indépendant de WIMS), voire le choix automatique d’exercices basé sur une ontologie et des métadonnées (mots-clefs) ; cela généralise considérablement le classement des exercices par feuilles thématiques, en autorisant beaucoup plus de souplesse
– afficher automatiquement l’énoncé via MathJax, insérer des commentaires et autres métadonnées, pour que l’enseignant puisse choisir facilement ses exercices (à comparer avec l’actuel moteur de recherche de WIMS, qui requiert une procédure longue pour voir l’exercice : champ de recherche > choix de la feuille > choix de l’exercice > se mettre au travail). Un exemple d’interface simple est celui d’exo7 ; chaque exercice est repéré par un identifiant numérique lisible (à défaut d’être parlant), l’énoncé est visible en ligne, et on peut facilement constituer des feuilles simplement en cochant ou en recopiant les identifiants.
– possibilité d’export de listes d’exercices vers des LMS utilisant WIMS (e.g. Moodle)
– possibilité de créer des sous-ensembles d’exercices adaptés à une communauté ou un usage donnés.
Contraintes :
– il faut exporter de WIMS les exercices actuels
– réécrire WIMS pour l’interfacer avec cette base de donnée, soit en la réimportant régulièrement, soit par des appels à la BD depuis WIMS (WIMS pourrait — ou non — garder son moteur de recherche interne)
– il faut (idéalement) définir une ontologie, et au minimum discuter des mots-clefs (taxonomie)
– il faut définir les attributions des éditeurs avec un compromis entre réactivité (avec beaucoup d’éditeurs) et contrôle ; cf. le modèle des wikis
Méthodes :
– métadonnées typiques : niveau scolaire, difficulté (potentiellement un système de vote, ou semi-automatisé), popularité (explicite/implicite), champs ontologiques (c-à-d notions nécessaires pour résoudre l’exercice), auteur(s)
– donner à chaque exercice un identifiant unique (à usage informatique, donc n’ayant pas forcément vocation à être lu par un humain, cf. exo7) ; cet identifiant est différent du titre (humainement compréhensible) ; à l’heure actuelle les exercices ont un code, retrouvé dans l’URL, e.g.
wims-prod.univ-mlv.fr/wims/wims.cgi?module=U1/algebra/oefvecspadef.fr
Travail :
– export de WIMS, réécriture du moteur
– décider des infos pertinentes
– décider (choix technique) du type de base de donnée et serveur
– saisir les métadonnées (peut se faire au préalable ou au fur et à mesure)
NB : (1) j’ignore dans quelle mesure cette séparation existe déjà dans le code de WIMS; (2) il existe un catalogue des exercices dans la wiki de wimsedu, qui est un bon premier pas dans la direction proposée ci-dessus.
Pascal Romon