Mots-clés par organisation

[florimondmanca]

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

• Ne rien faire, car la situation actuelle est satisfaisante.
• Faire en sorte que chaque catalogue ait son propre jeu de tags possibles ? (Colonne Tag.organization_siret)
  • Le formulaire de contribution/édition n'afficherait alors que les tags propres au catalogue
  • La recherche avancée afficherait tous les tags, ou bien seuls ceux du catalogue sélectionné dans le filtre "Catalogue"
• Passer le champ en mode "saisie libre avec suggestion des tags existants", en s'inspirant de l'approche pour geographical_coverage ou license, cf Mots-clés par organisation #464 (comment)

[johanricher]

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 :

1. Permettre à un contributeur d'ajouter un nouveau mot-clé (c'est une erreur de ne pas l'avoir fait dès le départ, corrigée avec les champs qu'on a implémentés ensuite)
2. Autocomplétion lors de la saisie d'un mot-clé
3. Trier la liste par popularité des mots-clés dans le catalogue de l'organisation (celle à laquelle appartient le contributeur)
4. Différentes choses (qu'il faudrait distinguer) mentionnées sur Gestion de mot-clés semi-administrés #39

[florimondmanca]

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.

[johanricher]

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).

[florimondmanca]

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).

[DaFrenchFrog]

@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 :

• Selon le secteur d'activité de l'organisation, un mot-clé X pourra avoir une signification toute autre pour une autre organisation ("médecine" par exemple au ministrèe de la Santé, vs Ministère de la Culture). Et plus nous allons avoir d'organisation plus le problème va se faire ressentir
• Au fil des intégrations nous allons avoir une grande quantité de mot-clés, plus ou moins proches, et qui seront très difficiles à maintenir pour un responsable de données, ou à choisir pour un contributeur
• Je ne vois pas comment un responsable de données pourrait accepter dans son catalogue l'utilisation de mot-clés d'autres organisations. C'est je pense une condition critique pour intégrer son catalogue sur notre outil. A vérifier avec eux...

[johanricher]

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.

[DaFrenchFrog]

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.

[johanricher]

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.

[florimondmanca]

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 ?

[johanricher]

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.