Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:design:contexts [2019/01/31 08:13] – [Niveau 3 : Cohortes] admin
+++ boardz:design:contexts [2026/01/13 08:03] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
 ===== Contextes de données et de gestion, métadonnées de structure ======
 ===== BoardZ Version 2 =====
@@ Ligne 15: / Ligne 16: @@
 Un groupe d'hôtes est assimilable à un nom arbitraire.
+Le groupe d'hôtes intervient comme espace le plus large que lequel un indicateur peut être aggrégé pour fournir une valeur globale.
+=== Modèle de stockage ===
+^ Champ ^ Information ^
+| id | Identifiant primaire |
+| name | Nom du groupement |
 ==== Niveau 2 : Hôte moodle ====
@@ Ligne 20: / Ligne 29: @@
 Assimilable à une identité wwwroot unique.
+Un hôte définit un contexte d'extraction de métadonnées de structure et une source de logs à traiter dans un récepteur propre. Les paramètres techniques de ces fonctions d'obtention de données sont propres à chaque hôte.
+L'hôte constitue également une portée d'aggrégation pour obtenir des indicateurs globaux pour l'instance de moodle associée.
+=== Modèle ===
+^ Champ ^ Information ^
+| wwwroot | Identifiant primaire |
+| name | Nom affichable |
+| hostgroup | Référence au groupe d'hôtes |
 ==== Niveau 3 : Cohortes ====
 Assimilable à l'ID numérique de la cohorte ou à l'IDNumber de cohorte.
+=== Modèle ===
+^ Champ ^ Information ^
+| wwwroot | hôte |
+| id | identifiant primaire de cohorte |
+| idnumber | identifiant secondaire de cohorte |
 ==== Niveau 3 : Utilisateurs ====
+Assimilable à un id interne, l'IDNumber d'utilisateur ou son username.
+Il est défini essentiellement par une identité lisible associée à cet ID. La portée "utilisateur" doit pouvoir être désactivée si le contexte d'usage du serveur ne peut être résolu en termes du RGDP, laissant le serveur uniquement calculer des données statistiques aggrégées non nominatives.
+La conception des fonctionnalités contingentées à l'utilisateur devra prendre en compte des descripteurs RGDP capables de fournir toutes les indications sur le traitement nominatif tel que :
+- la liste des indicateurs individuels configurés et activés, renseigné par l'objectif d'utilisation de ces indicateurs (texte informatif).
+- un export des données calculées d'un utilisateur nominatif.
+Les principes d'effacement de l'ensemble des indicateurs individualisés d'un utilisateur particulier devront être proposés.
+Le username étant obligatoire, on le prendre de préférence comme identité primaire. Le cas des utilisateurs importés par réseau Moodle (MNET) nécessite que l'identité complètement qualifiée tienne compte de l'origine de l'utilisateur. Dans une constellation de moodles interconnectées, les identifiants internes d'hôtes MNET d'origine ne sont pas uniformes d'une plate-forme à l'autre. La mention du wwwroot dans l'identifiant complètement qualifié suffit cependant à résoudre cette question, car la valeur du wwwroot est par contre unique et uniforme pour une instance moodle donnée.
+Identité primaire : username / Identité accessoire : IDNumber / FQDN : wwwroot/username
+=== Modèle ===
+^ Champ ^ Information ^
+| wwwroot | hôte d'origine |
+| username | identifiant primaire |
+| firstname | Prénom |
+| lastname | Nom |
+| department | Département -division d'organisation) |
+| organisation | Organisation |
+| pays | Pays |
+| cust1 | champ qualifiant customisé 1 |
+| cust2 | champ qualifiant customisé 2 |
+| cust3 | champ qualifiant customisé 3 |
+| cust4 | champ qualifiant customisé 4 |
 ==== Niveau 3 : Catégories de cours ====
@@ Ligne 36: / Ligne 92: @@
 ==== Niveau 4 : Cours ====
+Assimilable à un id interne de cours, à un IDNumber ou au nom court du cours. L'IDNumber n'étant pas une information garantie, le 'shortname' (nom court) du cours sera l'identité primaire visible.
+Identité primaire : shortname / Identité accessoire : IDNumber / FQDN : wwwroot/shortname
 ==== Niveau 5 : Module d'activité ====
-==== Niveau 6 : blocs (optionnel, les données portant sur des identités de bloc sont peu nombreuses dans Moodle.
+Les modules d'activité sont assimilables à un id de "module de cours" ainsi qu'à un IDNumber, toujours sur le module de cours. Un des problèmes courants rencontrés dans les stratégies d'administration globales est la très faible mobilisation dans l'usage des IDNumber de modules. En effet, il existe très peu de cas où les modules de cours (activités et ressources) sont produits
+==== Niveau 6 : blocs (optionnel, les données portant sur des identités de bloc sont peu nombreuses dans Moodle. ====
+Cette portée d'administration est laissée à une évolution ultérieure.
 ==== Approche dimensionnelle ====
-Les dépendances entre données de contexte peuvent être comprises
+Les dépendances entre données de contexte peuvent être comprises comme des dimensions successives d'axes d'analyse qui permettent une exploration dans des niveaux de détail multiples.
+Les contextes de gestion ci-dessus peuvent être assemblés pour définir :
+   * Un axe organisationnel académique : réunissant les dimensions suivantes comme autant de niveaux d'imbrication de contextes :
+Groupes d'hôte >> hôte >> catégorie de cours >> Cours >> Section (ou page) >> Type de Module >> Instance
+   * Un axe organisationnel sur la population :
+Pays >> Organisation >> Département >> Fonction >> Utilisateur
+   * Un axe sur la segmentation pédagogique de la population :
+Hôte >> Cohorte >> Utilisateur
+et si l'analyse porte sur un cours ou un groupe de cours disposant d'une construction cohérente de groupes :
+Hôte >> Cohorte >> Groupe >> Utilisateur
+Les notions de groupes et de cohortes étant des relations NxN entre les utilisateurs et respectivement les groupes et les cohortes, les axes ci-dessus n'en proposent qu'une vision restreinte pour des usages où :
+      * Un étudiant appartient principalement à un groupe
+      * Un étudiant appartient principalement à un cohorte
+Pour permettre de réduire certains environnements à cette contrainte, et si nous prenons l'exemple particulier des cohortes, il faudra pouvoir exclure des définitions examinées celles qui font sortir les données de la restriction proposée. Dans cet exemple, s'il existait par exemple des cohortes basées sur les découpages de promotion ET des cohortes transverses, par exemple de groupes de langues, alors l'une de ces deux dimensions orthogonales devraient être exclues de l'analyse.
+----
+[[:boardz:design|Revenir au sommaire de la conception]] - [[:start|Revenir au sommaire général]]