Bonnes Pratiques

1. Choix du vocabulaire

La notion de vocabulaire s’applique à plusieurs concepts xAPI : les verbes, les types d’activités et les extensions.

1. Utilisez en priorité le vocabulaire officiel, à condition toutefois que la signification des termes empruntés soit strictement identique à l’usage que vous souhaitez en faire.
2. Si le terme que vous cherchez n’existe pas dans le vocabulaire officiel, ou si vous avez un doute sur son sens, explorez les communautés de pratiques proches de votre domaine (par exemple, xAPI.fr).
3. Ne définissez vos propres termes qu'en dernier recours, en documentant vos choix et en les partageant le plus largement possible.

2. Identification des acteurs

L’identification des acteurs au sein des Statements relève des règles de gouvernance de chaque organisation. En d’autres termes, c’est à vous de fixer les règles et de vous y tenir.

1. N'utilisez l'identification par email que si elle peut être considérée comme stable et durable.
2. Si les utilisateurs sont déjà référencés dans un système de gestion d'identité (ex. annuaire LDAP, LMS, etc.), privilégiez le mode "account".
3. Avec le mode "account", la propriété "homePage" doit identifier le système de gestion des identités de manière durable. Utiliser une IRI, et non une URL susceptible de changer.
4. Avec le mode "account", la propriété "name" doit identifier l'acteur de manière durable.
5. Le choix du mode d'identification doit tenir compte de la politique de protection des données personnelles (cf ci-après).

3. Protection des données personnelles

Les traces xAPI, lorsqu'elles sont nominatives, sont à considérer comme des données personnelles à part entière. Un LRS est donc soumis aux règles de protection des données régies par la RGPD.

1. Envisagez sérieusement l'anonymisation des traces xAPI envoyées au LRS, ces traces étant théoriquement non modifiables et non supprimables.
2. Pour réaliser un reporting nominatif, envisagez le maintien d'une table de correspondance entre identifiants anonymes et identifiants nominatifs. Cette table pourra être stockée sur le LRS (Agent API), dans un système centralisé (ex. LDAP), ou dans un système émetteur (ex. LMS).
3. Le droit à l'oubli peut être exercé en supprimant l'utilisateur de la table de correspondance, les traces le concernant ne pouvant alors plus lui être attribuées.
4. Si les traces xAPI ne sont pas anonymisées, veillez à éviter les Statements qui impliquent plusieurs utilisateurs (ex. groupes dont les membres sont cités). Le droit d'accès aux données pour un utilisateur ne doit en effet pas entrainer la divulgation d'informations relatives à d'autre utilisateur.

4. Identification des activités

L’identification des activités au sein des Statements relève des règles de gouvernance de chaque organisation. En d’autres termes, c’est à vous de fixer les règles et de vous y tenir.

1. Ne confondez pas URL et IRI. Une URL permet de localiser une activité et d’y accéder, mais peut évoluer dans le temps. Une IRI peut être symbolique mais garantit une identification durable. Utilisez bien des IRI, et non des URL.
2. Etablissez une stratégie d’indexation claire de toutes les activités que vous gérez. Vous pouvez par exemple définir un schéma systématique pour la structuration des IRI. Assurez vous alors que les outils que vous utilisez (ex. LMS, LCMS) permettent de générer ou saisir ces IRI.

5. Définition des types d'activités

Les types d’activités font partie intégrante du vocabulaire xAPI. Ils sont théoriquement optionnels dans l’écriture des Statements. Mais ils jouent pourtant un rôle crucial dans le filtrage des données.

1. Attribuez un type à toutes les activités utilisées dans vos Statements.
2. Si le type d’activité que vous cherchez n’existe pas dans le vocabulaire officiel, explorez les communautés de pratiques proches de votre domaine (par exemple, xAPI.fr).
3. Si aucun type d’activité ne répond à vos besoins, créez-en un et documentez le dans un profil spécifique.
4. Un type d’activité doit caractériser l’activité sans tomber dans un usage trop spécifique. Gardez à l'esprit que les extensions d'activités peuvent permettre de préciser les choses.
5. Evitez d'utiliser des types d'activité trop spécifiques à un outil. Essayez de généraliser les concepts lorsque cela est possible.

6. Usage des activités contextuelles

Les activités contextuelles sont un élément crucial dans la structuration d’un Statement. Elles conditionnent la capacité à retrouver un Statement et à le relier aux autres. On distingue plusieurs types d’activités contextuelles : "parent" , "grouping", "category" et "other".

1. Définissez toujours une activité contextuelle "parent", sauf si l’activité concernée est une activité de plus haut niveau. Cette information permet au LRS de reconstituer la hiérarchie organisationnelle des activités.
2. Définissez toujours une activité "grouping" pour identifier le système dans lequel s’est déroulée l’activité (ex. le LMS).
3. Utilisez éventuellement d’autres activités "grouping" pour décrire la manière dont les activités sont organisées entre elles, regroupées, catégorisées.
4. Définissez toujours une activité "category" pour préciser le profil auquel est associé le Statement. Si vous n’obéissez à aucun profil officiel, définissez-en un qui vous est propre, documentez-le, et incluez-le à vos Statements.

7. Usage des éléments descriptifs

Les éléments descriptifs servent à décrire certains concepts dans un Statement : nom d’acteur, intitulé du verbe, nom et description d’activité, etc. Ces éléments sont facultatifs.

1. Ne renseignez pas le nom de l’acteur si vous souhaitez que vos traces gardent un caractère anonyme.
2. Ne renseignez pas les intitulés de verbes si vous souhaitez alléger les Statements. Ils n’apportent rien d'un point de vue informatique puisqu’ils peuvent généralement être retrouvés par le LRS.
3. Renseignez au moins une fois les noms et descriptions des activités de vos Statements pour que votre LRS puisse les stocker et en disposer (Activity API).
4. Renseignez les noms et descriptions des activités de vos Statements en cas de modification, pour que le LRS puisse mettre à jour ces données (Activity API).
5. En dehors de ces situations, il n’est à priori pas utile de renseigner les noms et descriptions des activités, qui peuvent alourdir rapidement la taille de vos Statements. C’est particulièrement le cas pour les activités contextuelles qui peuvent être nombreuses dans un Statement.