[module] Meta Data

[nimdanor]

Les méta données sont des données qui sont associées aux ressources avec un mode d'édition distincts. Nous distinguons deux type de méta données:

• les méta données qui sont construites automatiquement par le système
• les méta données qui sont ajoutées par les utilisateurs.

le document discriptif ce trouve la. https://github.com/PremierLangage/plconception/blob/master/conception/concept/metadonnees.md

[nimdanor]

Les méta données automatiques sont essentiellement statistiques, nombre d'utilisation, temps de réalisation, temps moyen, temps médian, nombre de success, nombre d'abandons, nombre d'intégration dans une activité, etc. (a compléter @magdalena-kobylanski ) Si la ressource est une évaluation (utilisation au moins une fois comme évaluation).

Les méta données ajoutées doivent être sous une forme distribuée, càd que les éditions des un n'ont pas d'effet sur les éditions des autres. Ainsi toutes les métas données de ce type sont de la forme:

• user X donne la propriété Y à la ressource. la propriété Y est soit un lien entre ressource,soit un json (ce qui permet d'ajouter de nouvelle propréitéé au fur et a mesure).

@qcoumes il faut une table spécifique pour les méta données ajoutées et un index ? ou bien les stocke t'on dans la même table que les méta données automatiques.

[nimdanor]

Les tests de la ressource ?? sont ils dans la ressource ou dans les métadonnées (ou les deux FIXME @nborie)

[nborie]

Pour le moment, je n'arriverai pas à formuler quoi que ce soit de consistant. Je suis persuadé que l'on aura besoin de Méta-données tôt ou tard (ce sera la solution...) mais cela permettra de résoudre des problèmes qui ne sont pas encore clairs pour le moment.

J'aurais moins de mal à donner un avis si on commence par s'accorder sur les besoins que ces méta-data devront permettre de réaliser :

• Extraire des données du type Karma sur les ressources disponibles (exercices aimés/détestés, utilisés/délaissés, rapides/longs, ...) --> On sent ici des méta données générés par les serveurs d'assets puis assemblés par le serveur central (faut-il mettre en cache ?).

• Recherches/sélections/tris sur les ressources disponibles (recherche par matière, par thèmes, par AAV, par difficulté) --> Ici, c'est plus des méta données plus en dures souvent écrite par des humains. Ces méta données seront ici en support de l'éditeur de ressources dans le serveur central.

• Monitoring des activités en cours d'utilisation (élèves en retard, en difficulté, réussite moyenne, etc...) --> Là, je vois plus des choses qui ne sortent pas des serveurs d'assets (ça concerne seulement les enseignants encadrant la matière).

• ...

Dans tous les cas, je plaiderai plutôt pour l'économie de programmation et la dépense massive en CPU. Pour le moment, je ne vois pas la nécessité de mettre en cache (coder des bases, enrichir régulièrement ces bases, assurer la cohérence des données et provoquer des recalculs quand le cache est trop vieux...).

Je pense qu'il est plus judiscieux d'optimiser les requêtes et de les éxécuter systématiquement à la volée (au moins les infos extraites sont toujours bonnes et up to date). Quand on aura un problème de charge, alors on se cassera la tête sur de la prog et du cache.

Les latences actuelles de PL pour les notes viennent de mauvaises requêtes. Corriger ces requêtes, c'est quelques heures de travail maxi. Mettre en place une stratégie de mise en cache partielle, ce sera tellement plus violent (et ça va nous enchaîner avec plus de maintenance...).

Actuellement, je ne vois pas de besoin dans PL qui nous contraigne à une telle techno. J'aurais tendance à reppousser cette décision au plus tard possible (parce que je suis aussi conscient qu'il existe un avenir dans lequel on ne pourra pas s'en passer).

Faire une liste exhaustive de "dynamic data" (j'entends par "dynamic data" des méta données extraites et pas écrite en dur par des humains...) nécessaires à la prochaine version me semble un bon point de départ, ça aidera à voir si une mise en cache est obligatoire/pratique/superflue... Je ne sens pas le besoin de cache pour le moment. Avec une bonne requête, on arrive à parser les plus de 200 kilo answers en moins d'un centième de seconde. (c'est mieux que (nb d'élèves)(nb d'exos)(200 k answers)... Sachant que l'on peut le faire en une seule passe, AP1 se prend un facteur 50 000 de ralentissement, sans ce facteur de latence facilement supprimable, les notes sont instantannées...)