Closed florimondmanca closed 1 year ago
Ce n'est pas un problème actuellement mais ça le deviendra davantage quand la liste des mots-clés (menu select) va s'allonger avec chaque nouveau catalogue (en particulier lors des imports successifs).
Pour moi les pistes d'améliorations des mots-clés seront plutôt dans cet ordre :
On partirait donc sur une approche similaire aux champs geographical_coverage
ou license
?
La différence technique importante serait qu'on est ici dans une relation "many to many" : un dataset ne peut avoir qu'une seule licence, mais plusieurs tags. Donc l'implémentation "suggestion des valeurs existantes + possibilités de définir une nouvelle valeur" serait possible mais pas un copie directe de l'implémentation pour license
par ex.
Oui ce serait une implémentation différente mais d'un point de vue utilisateurs l'idée est la même je pense (aide à la saisie avec un choix de valeurs existantes, triées par ordre de popularité, et si nécessaire possibilité de saisir une valeur nouvelle).
Tout-à-fait, c'est la même idée. À noter, ajd même pour license
etc on n'a pas de notion de popularité (on présente les choix par ordre alphabétique, il me semble).
@johanricher @florimondmanca Du point de vue des mot-clés il est à mon sens très problématique de mélanger l'ensemble des mot-clés pour les raisons suivantes :
Un mot-clé, par exemple "médecine", peut avoir une signification différente selon le contexte (et ce d'ailleurs y compris au sein d'une même organisation).
Un même mot-clé enregistré en base dans notre service, par exemple "médecine" avec l'id 42, peut être utilisé pas différentes organisations et c'est justement le contexte où le mot-clé est utilisé (d'une organisation à l'autre, voire d'un jeu de données à l'autre) qui en changera la signification.
Le fait d'avoir un mot-clé "médecine" (id 42) utilisé par l'organisation "Ministère de la Culture" et un mot-clé "médecine" (id 24) utilisé par l'organisation "Ministère de la Santé" ne résoudrait rien du point de vue utilisateur. Au contraire, cela pourrait poser différents problèmes. Par exemple : au moment de la recherche dans le filtre par mot-clé un utilisateur verrait 2 fois le mot-clé "médecine". A moins de filtrer par organisation, ce qu'il n'est pas obligé de faire pour utiliser ce filtre. Et encore une fois je ne vois pas bien ce que ça apporterait aux utilisateurs.
Je ne dis pas qu'un même mot-clé doit avoir un id différent, je dis que les mot-clés doivent être gérés distinctement pour chaque organisation. C'est surtout important lors de la contribution. Mais je ne suis pas fondamentalement contre l'idée de mélanger tous les mot-clés. Cet enjeu-là devrait discuté avec les responsables de données pour avoir leur point de vue, car ce sont eux qui ont la responsabilité de la gestion de leur catalogue, et ceux sont eux qui au final décideront si oui ou non ils cataloguent leurs données chez nous.
Je ne dis pas qu'un même mot-clé doit avoir un id différent, je dis que les mot-clés doivent être gérés distinctement pour chaque organisation.
Sauf erreur, ça revient au même. Avoir une liste de mots-clés spécifique à chaque organisation va forcément générer des doublons qui seront distingués en base mais qui seront impossibles à distinguer pour les utilisateurs (à ce stade de ma compréhension de ta proposition).
Lors de la contribution, le fait qu'un mot-clé soit spécifique à l'organisation ou le même pour toutes les organisations ne change, en soi, rien du point de vue utilisateur.
En revanche le problème c'est le volume de mots-clés proposés au contributeur, qui sera plus important. Il serait résolu par ce que je proposais ci-dessus (trier la liste par popularité des mots-clés dans le catalogue de l'organisation - celle à laquelle appartient le contributeur). Mais c'est bien un problème et une solution différents de ce que tu dis.
On pourrait aussi modéliser cela comme une notion de "mot-clé 'autorisé' par l'organisation" (d'un point de vue SQL, une relation many-to-many Tag -- OrganizationTag -- Organization
). On pourrait alors avoir un seul mot-clé "médecine (id 42)", mais qu'il ne soit "accepté" (ou au contraire "exclus" (?)) que pour certaines organisations. Une sorte de fonctionnalité include/exclude. Ce serait donc une propriété de l'organisation, et pas des tags.
De cette façon, lors de la recherche on charge tous les Tag
(qui sont distincts). Si un filtre catalogue est appliqué, on ne récupère que les tags correspondant à l'organisation. Dans la contribution on également ne récupérer que ce sous-ensemble.
Mais ça soulève bien des questions de design, je pense. Peut-on supprimer des tags ? Les modifier ? À quelle condition ? Faut-il une interface de configuration du lien OrganizationTag
? À quoi ressemblerait-elle ? Etc. N'est-ce pas plus "lourd" (configuration explicite) qu'un système plus "intelligent" telle que la "popularité au sein de l'organisation" proposée par Johan ci-dessus ?
Le champ mots--clés va être amélioré : #589
Le champ mot-clé fait partie du schéma commun. Les mots-clés ne sont pas spécifiques à chaque organisation. En base, tous les catalogues partagent les mêmes mots-clés.
cc @johanricher @DaFrenchFrog Pour réflexion / traçabilité de détails dans le cadre #122
Recouvre peut-être partiellement le vieux ticket #39
Problème
À ce stade, les mots-clés sont globaux et ne sont pas spécifiques à tel ou tel catalogue.
Tous les catalogues partagent donc les mêmes mots-clés.
Dit autrement, lors de l'import de >= 2 catalogues (#343), les mots-clés du catalogue de l'organisation A seront donc aussi utilisables par une autre organisation B.
Solutions possibles
Tag.organization_siret
)geographical_coverage
oulicense
, cf https://github.com/etalab/catalogage-donnees/issues/464#issuecomment-1267169055