Outils pour utilisateurs

Outils du site


rech:these:prive:cr2012101

CR octobre 2012

Nouvelles du projet IMAGO/Formagraph

Le projet a été financé et accepté. Formagraph a recruté une partie des ressources humaines nécessaires (côté développement: 1 chef de projet + 1 développeur, 1 autre développeur est prévu).

Mon rôle qui semblait au départ limité (à l'aspect personnalisation) risque d'être plus important que prévu car:

  1. le chef de projet n'est pas techniquement apte à rédiger le chier des charges sur les problématiques concernant la personnalisation et le portefeuille de compétence: ce seront très probablement Noa et moi qui le feront;
  2. il faut convaincre Claroline, ce qui peut prendre du temps et nécessiter de l'investissement humain; l'avantage, c'est que ça m'oblige à présenter mes idées et à les défendre;
  3. Formagraph sera le maître d'oeuvre de la prochaine version de Claroline

Point très positif: le développeur recruté est a priori bon.

Noa me demande donc de continuer mes spécifications, et d'identifier ce que je peux faire développeur par d'autres que moi (le développeur de Formagraph pour l'instant).

A priori, ça sera essentiellement tout ce qui concerne les interfaces graphiques hormis le module d'élaboration.

Je réalise donc les maquettes pour les interfaces

Je poursuis le développement et les spécifications de l'API de personnalisation

Je réalise des interfaces très (très) basiques : pas de contraintes esthétiques, pas d'implémentation dans claroline⇒ ce sera le développeur qui le fera

API

Le développement se passe bien, même si j'ai toujours du retard sur ce que j'avais prévu.

Développement/technique/modèles

Toute la partie “sources de connaissance” est traitée. Ci-joint les derniers modèles établis: Diagramme général sans les comportements  Détails des packages profils, ressources, sources de connaissances

Lien vers la documentation (en anglais) de l'API: http://bruno.mascret.fr/tests/apiPerso/doc/index.html

Lien vers le benchmark de l'API sur ce serveur (tout ne marche pas pour des raisons de droits que je ne vais pas régler tout de suite, ce n'est pas prioritaire): http://bruno.mascret.fr/tests/apiPerso/Test.php

Snapshots du benchmark complet réalisé sur mon instance locale (ma machine):

J'en suis à l'implémentation de la grammaire de contraintes (qui inclus cPMDLe, mais qui sera plus générique). J'ai choisi d'utiliser un moteur d'interprétation de règles en xsl qui facilitera les opérations de transformation (personnalisation) des structures arborescentes.

Je n'ai plus de grosses difficultés techniques avec le langage (PHP), ce qui fait que j'avance vite.

Je n'ai pas non plus de blocage particulier pour le moment.

J'ai montré ce que j'ai fait à Noa qui est satisfait et m'encourage à continuer.

Je fournirai des interfaces très basiques qui seront améliorées et/ou intégrées dans claroline par le développeur rrecruté chez Formagraph.

Une de ces interface permettra notamment à Formagraph de créer/saisir des profils implémentant IPACOME dont j'ai fourni l'implémentation (voir instance d'example sur les snapshots ci-dessus).

Modèle pour PMDLe et les échelles

Après avoir discuté avec Blandine, il apparaît fondamental de mettre très au clair le schéma/dtd de PMDLe: Blandine l'utilise à sa sauce en fonction de ses besoins, elle l'a augmenté de différents éléments dont certain sont redondants (après coup) avec des propriétés que Carole n'avait pas très bien (ou du tout) documentées. Je pense que lorsque Carole a implémenté son modèle, elle a du faire face à des contraintes techniques qu'elle a évacué de manière adhoc (ce n'est pas une critique), car son objectif n'était pas de fournir à ce moment-là un modèle partageable mais de valider ses travaux.

La conséquence est que le modèle ainsi obtenu n'est pas un modèle dont on peut se servir comme référence pour une utilisation générique avec d'autres applications que celles utilisées jusqu'à présent.

Il est indispensable de se mettre d'accord sur ce schéma.

De même, il m'apparaît de plus en plus évident que les échelles doivent être modélisées dans un autre schéma, et référencées au bon niveau dans le schéma de PMDLe (i.e.: propriété ou attribut de l'évaluation, pas de la composante) ET de manière optionnelle.

J'ai besoin de pouvoir présenter un modèle générique et représentatif à Claroline, “nettoyé” de tout ce qui a été rajouté pour faciliter l'exploitation dans un contexte très particulier (bâtisseur).

Ce modèle doit également être utilisable en français ET en anglais. C'est techniquement réalisable et prévu avex xml schema.

Pour l'instant, voici où j'en suis: PMDLe XML schema

Blandine m'a envoyé ses fichiers XML pour les échelles, je vais faire un schéma séparé pour modéliser ces échelles (c'est rapide et simple, moins complexe que pour PMDLe).

Si ce travail n'est pas fait (rapidement), PMDLe restera un modèle utilisé uniquement dans les applis SILEX et ne sera pas diffusé… C'est quand même dommage!

Publications

J'ai passé beaucoup de temps sur l'article TICE. Ce n'était pas forcément ce que vous m'aviez demandé mais:

  1. je ne sais pas bâcler, et je n'aime pas le faire surtout quand je suis en premier nom;
  2. quoiqu'on puisse dire sur l'impact de cette conférence, la moindre des politesses est de fournir un travail qui rend honneur à la qualité des reviews dont nous avons bénéficié.

Pour éviter des incompréhensions/problèmes lors de nos prochaines collaborations, je vous propose d'adopter systématiquement la démarche suivante:

  1. prévenir tout le monde (Stéphanie, Noa, Amélie, Bruno) lorsqu'on a l'intention de publier quelquechose qui concerne de près ou de loin ma thèse;
  2. définir à l'avance qui écrit, qui ne souhaite pas participer, qui est le corresponding author, le premier auteur, etc.
  3. faire un plan de publication avec ceux qui participent.
  4. prévenir systématiquement les auteurs lorsqu'on modifie ne serait-ce qu'une virgule du texte soumis, suffisamment tôt pour permettre une relecture si nécessaire.

Cette organisation correspond à ce que nous avons décidé à l'oral.

Travail pour novembre/dates

  1. demonstrateur pour la grammaire
  2. interfaces basiques pour Formagraph
  3. RDV avec Claroline à Lyon, du 12/11 au 14/11, pour plus de précisions, demander à Noa
  4. présentation pour TICE (slides)
  5. étude pour une première expérimentation du module de personnalisation “à la main” des graphes/parcours pédagogiques:
    1. soit en interne chez Formagraph (contact pris avec les formateurs)
    2. soit plus modestement sur mes propres étudiants
    3. soit d'autres idées…

Vos remarques/Commentaires

Noa:

  1. Concernant l'acceptation du projet IMAGO, à mon avis on doit profiter des ressources humaines disponibles pour pouvoir développement un prototype plus élaboré. Formagraph a demandé à Bruno de s'impliquer plus sur la partie spécification au debut et après Formagraph a embauché 3 développeurs informatiques pour assurer la mise en œuvre technique. Certaines applications seront développer par Claroline (je vous tiens au courant lesquelles ?).
  2. Concernant les développement des interfaces, elles seront développées par l’équipe de développeurs de Formagraph.
  3. Concernant le schéma XML du MODÈLE IPACOME, je suis d'accord avec Bruno, il faut absolument qu'on se met d'accord sur la structure de ce schéma XML en plus Bruno a déjà travaillé dans ce sens avec l’intégration des facettes, la validation de ce schéma XML permettra à l’équipe de Formagraph de développer les interfaces rapidement par exemple (créer/saisir des profils, etc…)
  4. Concernant le sujet de thèse et les travaux réalisés actuellement, à mon sens le lien entre le modèle de ressource de Bruno et les méta-donnés comme SCORM par exemple n'est pas encore très clair ( à discuter) ou Bruno propose une autre mode de description de ressources ? (à discuter) BM: Je ferai également un DAO sur les ressources pour faciliter les évolutions + un modèle simple de représentation des métadonnées des ressources pour Claroline
  5. Concernant la thèse toujours, je pense aussi qu'il faut expliciter plus les notions suivants : règles, conséquences, peut être que nous avons un modèle de règles finalement (à discuter) BM: Proposition sur le CR novembre/décembre
  6. Concernant les publications je suis d'accord d'adopter la démarche proposée par Bruno, dans ce sens justement j'ai une proposition à vous soumettre, il me semble intéressant que Bruno publie à EIAH'13 vu l'avancement de son travail, je pense qu'il a de la matière pour écrire en plus cet article EIAH sera publier en anglais à ICALT'13. Comme je vous ai dit la dernière fois, actuellement, nous sommes dans une obligation de publier.

Amélie:

  1. Je n'ai pas les droits d'édition sur la page.BM: c'est fait
  2. Ce compte-rendu est satisfaisant, même si je préférerais que tu passes plus de temps à raconter ce que tu as FAIT (de sorte à ce que je puisse comprendre) plutôt qu'à expliquer ce qui ne te concerne qu'indirectement ou que d'expliquer pourquoi tu n'as pas FAIT les choses que tu devais faire. BM: ok pour les prochains CR
  3. Par ailleurs, pour moi qui n'ai qu'un tiers des informations, c'est difficile à suivre. Je voudrais que tu commence le compte rendu par exposer les objectifs et ensuite, que tu expliques en quoi le travail que tu as fait répond (ou pas) à ces objectifs. BM:ok
  4. J'ai regardé les benchmarks et la doc. Ok, c'est propre, mais pour moi ça ne démontre rien. Quelles étaient tes ambitions, pourquoi avoir fait ces benchmarks et qu'est-ce que tu testes ??? BM:Je teste l'API de manière exhaustive; cette API a pour objectif de manipuler tous les objets identifiés sur le modèles proposé plus haut, et de s'abstraire de Claroline dans la partie personnalisation. Le lien avec Claroline (ou tout autre système) en intégrant tout ou une partie de cette API dans le noyau et/ou en réalisant des modules externes pour Claroline

Stéphanie:

  1. J’ai pu travailler avec Bruno qui a avancé. Par contre, la mise en place du nouveau projet de Formagraph lui prend beaucoup de temps au détriment de sa thèse. Je comprends que ce soit nécessaire pendant la phase de mise en place du projet, mais il va falloir qu’il se recentre sur sa thèse pour pouvoir avancer significativement.
  2. En ce qui concerne les publications, nous avons bien compris la nécessité de Formagraph de publier et nous en tenons compte, toutefois ta proposition ne me convient pas tout à fait, comme je te l’avais dit par téléphone.
  3. Ok pour EIAH (un article dans lequel Bruno pourra vraiment expliquer son approche), mais ICALT ne me semble pas être une bonne cible pour cette année, je propose de travailler sur une version en anglais à soumettre dans UMAP.voir CR novembre/décembre
  4. Export en pdf des CR BM: fait, utiliser le dernier bouton (crayon) de l'onglet latéral
rech/these/prive/cr2012101.txt · Dernière modification : 2012/12/21 17:06 de bruno