[CdC] → v1 Cahier des carges
- Fermer #30 (closed)
-
Lex:gaMe. J'ai retouché un peu le texte.
- Relire
-
Il faudrait clarifier un peu "les informations de groupes, absentes des autres bases".
- Est-ce qu'il ne s'agit pas de groupes propres à BaLex dont il est du coup assez clair qu'ils ne sont pas forcément utilisables dans les autres applications ?
- Est-ce que certaines informations de groupes ne sont pas accessibles via BaBaLex ?
NB : J'ai bien réfléchi et je pense que c'est moins complexe que l'API BaBaLex traite aussi les traces mutualisées (c'est-à-dire que je ne pense pas qu'elles aillent dans la BD BaBaLex, mais que l'API BaBaLex puisse gérer les traces externes pour BaLex). En effet, pour gérer une API avec des données perso, il faut des mécanismes d'authentification. Si crée une API par système ça veut dire un mécanisme d'authentification par système. Alors que si BaBaLex centralise les infos mutualisées ET l'authentification, on n'a qu'un seul système d'authentification à gérer, c'est beaucoup plus léger à développer.
- À partir du moment où on mutualise des traces, il faut définir un format d'échange. J'ai commencé un article d'après une présentation qu'Élise pourra partager avec toi. En l'occurrence, comme on va définir un format d'échange, il va falloir en faire un truc un peu plus formel que du csv → JSON ou XML. Je pense que ça reste plus simple de faire un format ad hoc que d'utiliser xAPI, qui veut permettre de faire bien plus que nos objectifs et créent du coup de la complexité.
-
BaLex. J'ai pas mal reformulé pour essayer de clarifier un peu et limiter un peu la redondance d'information
- Relire
-
Ajouter ta figure avec les calques en l'expliquant bien. Même si la boite n'a pas à gérer la représentation graphique de tout ça, elle devra gérer le modèle de données associé.
- Retirer le lexique de classe de la figure, c'est finalement un lexique de groupe (ou alors expliquer comment s'articule la visibilité de données entre les deux : qui peut voir quel lexique de groupe au-dessus du précédent)
- Il faut associer du texte à la figure pour expliquer ce que ça veut dire ces calques…
-
Groupes, les rôles/droits ne sont pas clairs : on a l'impression qu'on peut soit fixer des rôles sur le lexique (avec à chaque rôle des droits associés, cf. administrateurs), mais qu'il y a aussi des modes sur les quels on peut switcher, passer du mode collaboratif pendant un cours au mode lecteur (je trouve mieux que “spectateur”) entre deux cours, p. ex. C'est des fonctionnalités intéressantes, mais il faut préciser un peu ce fonctionnement :
- et une section droits pour indiquer tout ce que les utilisateurs peuvent avoir droit ou non de faire selon leur rôle et le mode
- Créer une section rôle avec tous les rôles
- Si nécessaire une section modes avec tous les modes
- Lier vers la page Profils utilisateur
- BaBaTracIEN : suite à ce que je te disais au dessus peut être qu'il faut unifier l'API vers les 2 bases de données
- image des uses cases : est-elle toujours à jour ? Il y avait un lien vers MoLiLex, qui s'appelle maintenant MoLex
- Relire l'article BaBaLex, je n'y ai quasiment pas touché (juste créé un ou deux titres pour la lisibilité), mais tenir compte des remarques ci-dessus (authentification, BaBaTracIEN).
-
Compte
- Question du transfert d'informations entre applications qui sera gérée par le module OAuth, mais aussi par des dumps pour nous (là il y a une question d'éthique, à discuter avec Élise aussi)
- Pour les différents jeu et même pour nos données, il sera utile de connaitre le niveau de l'utilisateur dans chaque langue, ce serait intéressant de le centraliser (ça veut dire qu'il faudra pouvoir le faire remonter → requête possible dans l'API)
-
Graphie et entrée lexicale
- j'ai essayé de proposer une définition plus formelle de graphie vs entrée lexicale, à valider…
-
l'exemple de structure est intéressant, parce qu'il rend plus clair les choses, mais il va falloir commencer un travail d'affinement de la structure qui liste :
- le champs qui peuvent exister ;
- où il peuvent apparaître (cf. étymologie ne peut-il pas être lié à l'acception, phonétique on sait que oui) ;
- pour quelles langues est-ce qu'ils peuvent être affecté.
-
Profils Utilisateurs
- Rédiger une petite intro sur la distinction entre profil et rôle…
- Lister les paramètres concernés
- Pour moi, il manque des informations sur les fonctionnalités sociales qui sont dans les cas d'utilisation de l'article Groupe ainsi que sur les droits associés à chaque entité. Il faudrait clarifier tout cela. Peut être que pour ça il faudrait restructurer les articles Groupe et Profils utilisateurs en un terme plus générique (ex : rôles et droits) et lister tout ces droits entité par entité. À partir de cela, il sera plus facile de définir les profils utilisateurs.
-
Liste
- Relire pour valider mes modifications
- La note 2 est problématique : la transcription phonétique est habituellement une information en API, le cas du japonais est spécifique, est-ce à dire que cette information complémentaire ne sera disponible qu'en japonais (et chinois ?) ou est-ce que pour chaque liste, on peut décider d'une représentation complémentaire de la graphie ? Est-ce qu'en japonais et chinois, c'est réellement une transcription phonétique ou est-ce qu'il s'agit d'une autre graphie ?
- Ce serait bien de renvoyer aux besoins associés à la liste personnelle et à la liste collaborative.
-
Lexique. Globalement, cet article est compliqué parce qu'il regroupe beaucoup d'informations dont on n'est pas sûr qu'elles soient à leur place (je vais lire l'article label pour mieux pouvoir me positionner… mais au minimum, il faudrait y renvoyer) :
-
La notion de “distinction” des entrées lexicales n'est pas claire pour plusieurs raisons
- La première est que c'est abordé trop tôt, il faut d'abord parler des 3 types de lexiques (j'ai déplacé)
- La seconde est que dans ces trois types de lexiques, il n'est pas fait mention des différents niveaux d'information (finalement la page BaLex explique plus le fonctionnement des lexiques que la page lexique) ;
- Je reste convaincu qu'il serai plus pertinent de décomposer chaque entrée d'après les informations auxquelles elle est associée, et que ce soit ces informations qui soit individuellement propres à un lexique, permettant ainsi de regrouper les informations de tous les lexiques sur la même page (sans dépendre de la capacité de comparaison — asynchrone en plus— de l'utilisateur). Après, il y a peut être des raisons à ce choix, je suis prêt à les entendre, mais il faudrait justifier.
- Le statut du mot est-il une information propre au lexique ou est-ce plus un label ou autre ?
-
La notion de “distinction” des entrées lexicales n'est pas claire pour plusieurs raisons
-
Label :
- Relire l'article (j'ai un peu formalisé certaines choses)
- Maintenant que j'ai relu tout le reste, je ne comprends plus bien la notion de label grammatical. Pourquoi est-ce un label ? Est-ce parce que les labels ont une fonction de filtrage ? Sinon, on ne comprend pas pourquoi le part of speech est une information différente de la transcription phonétique…
- J'ai considéré que les labels personnels étaient des labels thématiques ;
- Label thématique public : que se passe-t-il si un utilisateur a créé un label public repris et étendu par d'autres et qu'il le transforme en label privé ? (l'utilisateur choisit lors de la création du label et peut ensuite en modifier le statut quand il le souhaite)
- Est-ce qu'un label privé peut être restreint à un groupe ? (je suis parti du principe que oui) Si oui, est-ce qu'il peuvent être importés dans un lexique perso ? (je suis parti du principe que non)
-
Label de graphie :
- que se passe-t-il si un utilisateur a ajouté chien dans son lexique, supprimé le sens "percuteur" d'un révolver, mis le label « connu », puis dans un lexique de groupe, remis chien, mais conservé le sens "percuteur" ?
- ne faudrait-il pas fixer un comportement par défaut pour tout ces labels ? Je pense que le comportement par défaut est qu'ils ne sont pas apposés…
-
je pense que c'est délicat de parler de "liste exhaustive de labels de graphie" parce que cela suppose qu'on peut anticiper toutes les applications qui peuvent interagir avec BaBaLex. Peut être qu'il faut définir plutôt un appel à l'API
declare-label
qui spécifie l'intitulée, le type de l'information complémentaire et la valeur par défaut de celle-ci et que l'API renvoie unundeclared-label
comme erreur si le label avec lequel interagir n'a pas été déclaré au préalable.
- Labels et applis externes : ce serait bien de pouvoir renvoyer aux issues concernés et/ou aux specs de l'API
-
API : j'ai commencé à la formuler sous forme de besoins :
- search
- il manque le format pour décrire la langue (cf. ISO 639-1 ?)
- souligne le besoin de définir la structure d'une entrée lexicale
-
est-ce que
target_lex
est un tableau d'identifiants ou un tableau d'objets complexes jsons ? -
il faut indiquer si c'est une recherche ouverte (n'importe qui ayant accès à internet), si c'est une requête authentifiée, qui peut y avoir accès, et quel est l'effet de l'utilisateur (ici, on a tous ses points de vue sur le mot, j'imagine = son lexique et ses lexiques partagés en plus de la couche de base) ?
- → message/code d'erreur quand non authentifié/non autorisé (choisir entre 401 et 403)
- déclenchement système : c'est les applis externes, non ? Du coup, c'est un exemple les flashcards… si oui il faut l'indiquer.
-
completeShare, renommé
transferEntry
:- Est-ce que les graphies doivent être des gros objets json ou juste un identifiant ? Est-ce que le lexique source est nécessaire ? (l'entrée doit être liée au lexique et on doit l'avoir avec l'id, non ?)
- J'ai rajouté le cas où l'utilisateur n'est pas authentifié et/ou où il n'a pas droit d'accéder à la ressource
-
createEntry :
- Est-ce que c'est pas cet appel qui va récupérer les information dans une source externe (wiktionnaire)? Si oui, il faut le dire explicitement et renvoyer vers le besoin correspondant.
- Au final, il s'agit de restructurer d'après ce qu'on a définit à l'oral de la structure de BaBaLex en tenant compte de la ressource cible de la requête
- Je dois encore lire les use cases et l'API…