Ce CR est en cours de réalisation et sera définitif à la fin du mois

Suite à la réunion du 08/01/2013 avec Stéphanie

1. poursuivre le développement du prototype de personnalisation
2. écrire une documentation sur le système de personnalisation mis en place (grammaire, fonctionnement)
3. se mettre d'accord sur le format pour les profils d'apprenant
4. ajouter une phase d'élaboration de graphes pédagogiques à partir des ressources et des profils (réalisation de graphes de référence) AVANT la phase d'adaptation

1. en cours;
2. en cours, premier jet pour la fin de semaine;
3. je termine le schéma que j'ai commencé à partir de la dtd fournie par Blandine (issue de celle de Carole), j epropose ensuite un autre schéma correspondant à ce qu'il me parait utile de conserver/modifier/supprimer/ajouter et je soumets alors aux personnes impliquées (Blandine, Marie, Stéphanie, Noa, Jérôme (dev. de Formagraph), Amélie?) les deux versions pour discussion;
4. en cours, première version testable pour vendredi

J'ai effectivement oublié que le fait de disposer d'un graphe de référence comme source de connaissance initiale était une hypothèse qui n'est pas forcément vraie dans la réalité. Il y a bien une phase d'élaboration qui peut être nécessaire avant d'adapter les graphes.

Je vais détailler l'architecture actuelle et visée du module de personnalisation dans son ensemble, j'essaie de faire ça vite sous forme de schéma (un dessin vaut mieux que patati patata…., [Cordier 201x]).

Dans une logique “RàPET”, il y a des similarités avec le “cycle”: élaboration de graphes suivant des contraintes sur ressources et sur profil (suivant les apprenants qu'on a, le contexte de l'élaboration change), ensuite (éventuellement) une phase de “recherche d'existant” parmi des cas “graphes-profils” existants, une première affectation de graphe (similarité, mais voir plus bas), une phase d'adaptation (la personnalisation telle que réalisée actuellement dans le proto) et une mémorisation du résultat à la fin.

Un premier niveau de “cas” serait donc un ensemble de sources de K (graphe personnalisé + le profil) + les contraintes qui ont été exprimées à la fois au niveau de l'élaboration et de l'adaptation.

Ca rejoint les discussions qui avaient été entamées avec Amélie du temps où je faisais un peu mieux de la recherche, avec l'idée qu'il n'y a pas de cycle à proprement parler, ou plus exactement que les K ne sont pas mobilisées linéairement dans un cycle mais qu'il y a des allez-retours entre chaque étape du cycle. Susan Craw proposait de l'agile CBR avec un cycle de CBR à chaque étape, mais elle ne remettait pas en cause l'application du cycle de manière linéaire.

Ce qu'on pourrait entrevoir comme contribution serait peut-être justement d'arriver à casser cette organisation en cycle, et à mobiliser génériquement les connaissances utiles au moment où on en a besoin (c'est à dire, pas forcément linéairement), d'observer les répercussions en live sur les résultats produits, etc.

Il y a aussi l'idée qu'il n'y a pas forcément un graphe candidat qu'on adapte (cf similarité plus haut), mais peut-être une collection de graphes à un instant T pour un profil, et que suivant les K utilisées le “meilleur” graphe puisse changer au cours du processus de personnalisation. D'où l'intérêt de retenir dès le départ non pas un graphe mais un jeu de graphe candidats.

Bon, c'est juste pour mettre ça quelque part pour l'instant. Ce n'est probablement pas clair, ce uqi est sûr:

1. on peut en discuter;
2. c'est pas la priorité pour l'instant mais on peut avoir ça en tête quand même;
3. c'est frais et ça a besoin d'être creusé en profondeur;
4. ça me ferait plaisir d'avoir votre point de vue dessus, même rapide; on peut voir ça pour l'instant comme une récréation intellectuelle entre deux morceaux de PHP qui plantent…

La liste suivante recense les développements qui pourraient être faits sur le prototype. J'ai essayé de les classer par ordre d'importance, et d'indiquer qui pouvait les faire (moi (M), stage m2 (S), Jérôme (J)):

1. modélisation complète de l'algo de personnalisation, version simple ET version complète (M)
2. ergonomie et représentation générale du processus de personnalisation (M)
3. interface permettant de faciliter la saisie d'expression XPATH pour les contraintes sur les profils (M, J)
4. généralisation effective de la grammaire de contrainte à l'ensemble des sources de K; l'objectif n'étant pas d'être exhaustif mais de fournir une preuve de concept (M)
5. développement de fonctions de transformation des graphes pour constituer une librairie de base (comme linéarise) (M, S); s'apparente à des connaissances de domaine; réutiliser des algo existants;
6. divers bidouillages esthétiques/fonctionnel, comme popup et autres dont nous avons discuté en réunion (M, J)
7. recherche pour la prise en compte d'échelles non-numériques (similarités) pour l'utilisation des sources de K (S2)