search

etalab / catalogage-donnees

Outil de catalogage de données développé par Etalab (service en production sur catalogue.data.gouv.fr)
https://catalogue.data.gouv.fr
GNU Affero General Public License v3.0
14 stars 3 forks source link

Implémenter les métadonnées d'une fiche jeu de données #166

Closed johanricher closed 2 years ago

johanricher commented 2 years ago

Contexte

Champs à implémenter

Design

Maquette fiche jeu de données : https://www.figma.com/file/42KOPuvkD1jpubEe2mMtXr/DATALOGUE-maquettes?node-id=843%3A22296

Critères d'acceptation

Implémenter seulement les champs nécessaires pour le cas d'usage du MC.

Tâches

johanricher commented 2 years ago

Quelle est la source de vérité pour déterminer la liste des champs des métadonnées d'une fiche jeu de données ? (pour l'instant seulement ceux dont on a besoin pour le cas d'usage MC) Est-ce que les maquettes suffisent pour savoir ce qu'il faut implémenter ou il faut détailler davantage ? @DaFrenchFrog @florimondmanca @Volubyl

DaFrenchFrog commented 2 years ago

Si je me place du point de vue utilisateur, il n'y a pour l'instant pas eu de besoin remonté de faire cette distinction côté front donc pour l'instant cette problématique reste technique. Je laisse donc les spécialiste s'exprimer sur le sujet.

johanricher commented 2 years ago

Ma question peut être reformulée de la sorte : quelles sont les informations dont on a besoin et qui ont traits aux métadonnées d'une fiche de jeu de données ?

La première utilisation de ces métadonnées est évidemment de les afficher dans l'UI (i.e. si elles ne sont pas utiles aux utilisateurs, peut-être qu'on a tout simplement pas besoin d'avoir ces métadonnées, de les créer, collecter, stocker) mais ça peut être des usages plus indirects.

Exemple : si on veut pouvoir ordonner dans l'UI du catalogue les jeux de données par date de création ou date de dernière mise à jour de la fiche (on n'utilisera pas la date de dernière mise à jour du jeu de données lui-même car souvent on ne l'aura pas ou elle ne sera pas fiable) auquel cas on devra avoir cette métadonnée

C'est la liste de ces champs qu'il faut fixer ici.

florimondmanca commented 2 years ago

Je vais essayer de répondre en éclairant diverses pistes. Ce sont des notes rapides pour alimenter la réflexion, j'espère être clair.

TL;PL (trop long; pas lu) :

Etat des lieux

Actuellement on a les métadonnées de fiche suivantes :

Dataset vs Datasheet

On a évoqué jeudi dernier une "séparation technique" de cette séparation logique entre métadonnées du jeu de données (la fiche elle-même) et métadonnées à propos de la fiche.

Actuellement, tout est stocké dans une entité Dataset. On y trouve donc par exemple title (titre du jeu de données) et created_at (date de création de la fiche).

On pourrait donc procéder à la séparation suivante : Dataset vs Datasheet (ou DatasetMeta ? disons Datasheet pour l'exposé).

Modèle logique : Dataset 1:1 --- 1:1 Datasheet. Lecture : un jeu de données a exactement une fiche correspondante.

Modèle physique (non-formalisé) :

Nouvelles métadonnées

Je vais ici essayer de réfléchir "fonctionnellement". En effet il semble inutile de stocker des données dont on ne ferait rien.

La priorité est donc de questionner les différents besoins, ce qui rejoint aussi une démarche d'écoconception : que stocker, qu'afficher, pour quoi faire ? Là-dessus on semble en phase et c'est heureux.

Ouverture

visibility - "open", "shared", "internal" - Définit l'ouverture de la fiche au sein de l'outil de Catalogage.

Il y a une ambigüité sur la signification de ce champ je trouve.

À l'inverse license me semble clairement être un champ de la fiche puisque la licence concerne le jeu de données.

Je crois que la question clé est : comment envisageait-on de représenter "l'ouverture" d'un jeu de données dans le schema.json ? La licence y était marquée comme required: true. Mais quid d'un jeu de données "partagé" (entre organisations), qui n'est donc pas encore en Open Data ?

@DaFrenchFrog @johanricher Je me fais peut-être trop de noeuds au cerveau mais je serais intéressé de votre avis.

Historique des modifications

Ici je vais explorer l'idée d'un historique, car les infos 'date de dernière mise à jour' et 'contributeurs' cités par @johanricher nous y amènent assez vite.

Version minimale

En version minimale, on afficherait la dernière modification, soit :

Version "liste de contributeurs"

Dans cette approche, on stockerait la liste des personnes ayant contribué à la fiche au cours du temps -- sans stocker le détail des modifications.

Techniquement, on aurait donc la relation logique de contribution suivante : User 0:n --(contributes_to)-- 1:n Datasheet. Lecture : un utilisateur peut contribuer à des fiches de données, et une fiche de données a au moins un contributeur (la personne qui a initialement créé la fiche, puis les personnes qui ont successivement mis à jour la fiche).

La relation physique (tables en BDD) serait : Datasheet -> DatasheetContributor <- User. L'enregistrement d'un contributeur se ferait en ajoutant un couple (datasheet_id, user_id) à DatasheetContributor.

Niveau UI, ça permettrait de faire qqc comme la section "Contributors" de GitHub sur l'accueil d'un repo -- mais pas plus, car on ne stockerait pas le contenu des modifications.

La question centrale restant : pour quoi faire, pour répondre à quel besoin ? Pour la contribution comme la contribution, ne serait-ce pas une information "doublon" avec les contacts ? À mon humble avis, si un besoin émerge, ce sera celui d'une simple traçabilité.

Version "full Wikipedia"

Ici on passerait en mode Wikipedia : history + compare). ll faudrait :

Il va sans dire que cette fonctionnalité en version "complète" serait un gros morceau.

johanricher commented 2 years ago

Merci pour ton commentaire Florimond. Il contient beaucoup de choses, j'espère que je ne loupe rien.

D'abord je reformulerais la différence entre les métadonnées d'un jeu de données et celle d'une fiche d'une autre façon, afin de peut-être donner un autre angle d'éclairage sur ces notions. Les métadonnées d'une fiche sont strictement propres à notre outil, elles ne sont utiles qu'à nous, utilisables que par nous, et pour nos besoins spécifiques. En revanche les métadonnées d'un jeu de données sont génériques, elles peuvent être utiles et utilisées par d'autres et même chargées et affichées dans d'autres outils interopérables avec notre schéma catalogue (basé sur DCAT-AP) comme par exemple les portails data.gouv.fr et OpenDataSoft. Inversement, nous pourrions moissonner ces catalogues publics pour intégrer les métadonnées des jeux de données qu'ils contiennent dans un catalogue de notre outil.

Sur l' "ouverture"

En gros tes remarques et questions me semblent non seulement pertinentes mais toutes valides. En détaillant un peu plus :

Le besoin sera à un moment de savoir par quels utilisateurs peut être lue une fiche d'un catalogue. On avait initialement parlé de 3 niveaux d'accès pour une fiche donnée dans une instance de l'outil :

  1. Membres de l'organisation à laquelle appartient le catalogue (accès "interne")
  2. Membres d'autres organisations (accès "inter-ministériel"). Etant donné que le multi-catalogue n'est pas encore implémenté, ce niveau n'a pour l'instant pas de sens.
  3. Tout le monde (accès "public" sans authentification nécessaire). Etant donné (en plus de la remarque au point 2) que l'outil est pour l'instant accessible uniquement en étant authentifié, que ce niveau de "catalogue public" a vocation à être sur data.gouv.fr et qu'on ne sait pas comment on va gérer ça, ce niveau n'a pour l'instant pas de sens.

:warning: A ne pas confondre en effet avec la notion d' "ouverture" attachée au jeu de données lui-même, qui correspond en fait à la notion de licence open data (ou son absence) et qui a son propre champ dans le schéma du catalogue.

Quid d'un jeu de données "partagé" (entre organisations), qui n'est donc pas encore en Open Data ?

Dans un tel cas, le champ "licence" peut contenir la valeur "None" ou "Aucune". Sinon on peut aussi rendre ce champ optionnel (il est "recommandé" dans la spec DCAT-AP).

Sur l'historique des contributions et des contributeurs

On en aura besoin tôt ou tard c'est certain. Si ça ne rajoute pas trop de complexité (au chantier du mois) de faire en sorte de collecter ces métadonnées dès maintenant, j'y suis favorable. Sinon, je préfère qu'on s'y attaque plus tard.

La relation physique (tables en BDD) serait : Dataset -> DatasetContributor <- User

On parle ici de contributions à une fiche donc c'est plutôt des notions de "Datasheet" et "DatasheetContributor" qu'il s'agirait selon moi d'utiliser ici.

Le reste de la description technique que tu fais me paraît correct.

La question centrale restant : pour quoi faire, pour répondre à quel besoin ? Pour la contribution comme la contribution, ne serait-ce pas une information "doublon" avec les contacts ? À mon humble avis, si un besoin émerge, ce sera celui d'une simple traçabilité.

C'est vrai que sans l'historique des contributions elles-mêmes (stocker chaque version des métadonnée d'un jeu de données à chaque nouvelle contribution), la liste des contributeurs a un moindre intérêt. Cependant il faut considérer que les personnes qui contribuent à une fiche et les personnes qui sont mises comme "contacts" sur un jeu de données ne sont pas forcément les mêmes. Les premières peuvent être par exemple des personnes en responsabilité qui contribuent beaucoup au catalogue et à la description de beaucoup de jeu de données, les deuxièmes peuvent être par exemple des agents métiers qui ont une connaissance importante sur le jeu de données voire qui l'ont même produit, sans pour autant contribuer directement au catalogue (idéalement il le faudrait mais ça sera pas toujours le cas et notamment dans le cas d'usage MC par lequel on commence).

Aller vers une fonctionnalité similaire à celle de Wikipedia (savoir qui a modifié une fiche et quand, pouvoir annuler une contribution, revenir en arrière) serait un en garde-fou essentiel pour rendre efficace la modération à posteriori. J'ai conscience que c'est une fonctionnalité qui nécessiterait un gros chantier, et entrainerait une augmentation substantielle du volume de métadonnées stockées.

Pour l'instant garder seulement la liste des contributions et leur timestamp est suffisant

florimondmanca commented 2 years ago

A ne pas confondre en effet avec la notion d' "ouverture" attachée au jeu de données lui-même, qui correspond en fait à la notion de licence open data (ou son absence) et qui a son propre champ dans le schéma du catalogue.

En effet, donc on a bien l'ouverture du jeu de données et la "visibilité" (portée ? - scope) de la fiche au sein de l'outil.

J'ai vu que @DaFrenchFrog avait mis à jour la partie "Ouverture" de la maquette. Il ne reste plus qu'un switch "Disponible en open data" et un champ texte conditionnel pour une URL. En revanche l'idée initiale d'une "visibilité" (open data / restreint / ...) était bien présente sur la maquette intiale et persiste sur la page "Validation" présente sur la maquette à ce jour.

En bref, si jamais une telle "visibilité" est ajoutée à l'outil plus tard (ça a l'air probable), je conclus donc que c'est une information qui rentrera dans les métadonnées de fiche, car elle est spécifique à notre outil.

On parle ici de contributions à une fiche donc c'est plutôt des notions de "Datasheet" et "DatasheetContributor" qu'il s'agirait selon moi d'utiliser ici.

Bien vu merci, je vais modifier.

Pour l'instant garder seulement la liste des contributions et leur timestamp est suffisant

Qu'entend-on par "contributions", donc ? La description technique de Revision que j'ai faite te semble correspondre ? Si oui, je suis un petit peu confus car alors le "est suffisant" se rapporterait à la version maximaliste de la feature, qui permettrait de faire toutes ces fonctionnalités de retour arrière, annulation, etc. :sweat_smile: Si non, est-ce que ce serait plutôt qqc du type : qui a fait une modification et quand, avec une description libre (mais obligatoire) du changement effectué ?

DaFrenchFrog commented 2 years ago

J'ai vu que @DaFrenchFrog avait mis à jour la partie "Ouverture" de la maquette. Il ne reste plus qu'un switch "Disponible en open data" et un champ texte conditionnel pour une URL. En revanche l'idée initiale d'une "visibilité" (open data / restreint / ...) était bien présente sur la maquette intiale et persiste sur la page "Validation" présente sur la maquette à ce jour.

Attention il n'a pas disparu c'est juste que c'est la version cochée qui est sur la maquette. Mais si tu testes le prototype ici ou que tu regarde le composant dans la librairie tu auras accès à toutes les étapes. J'en profite aussi pour dire que cette section va évoluer en terme de design car les utilisateur ne voient/comprennent pas bien le switch. Donc je vais passer à un modèle plus direct où l'on pose une question oui/non. Cela ne change rien au niveau du principe mais c'est juste plus clair.

johanricher commented 2 years ago

Qu'entend-on par "contributions", donc ? La description technique de Revision que j'ai faite te semble correspondre ?

On est bien d'accord : on veut tendre vers une fonctionnalité "à la Wikipedia" maximaliste, mais je sais même pas si ça sera une fonctionnalité au lancement ou plus tard donc on parle de quelque chose de lointain et hypothétique. Il s'agira le moment venu de définir ça plus en détail du point de vue utilisateur. Mon "pour l'instant" revient (je crois) à ta première fonctionnalité "liste de contributeurs" : on ne garde en base qu'un timestamp de chaque contribution et le user associé ("datasheet contributor"). Je pense que le simple fait de pouvoir afficher cet historique sera utile comme fonctionnalité minimaliste, mais à définir plus tard.

johanricher commented 2 years ago

@DaFrenchFrog Après avoir regardé une nouvelle fois les maquettes de contribution sur la partie ouverture je pense qu'elles font perdurer la confusion entre 1) l'ouverture de la fiche et 2) l'ouverture du jeu de données. La maquette pose des questions qui vont plutôt servir à répondre au point 1) or comme je disais ci-dessus seul l'accès "interne" est pour l'instant possible donc on ne peut pas implémenter ça pour l'instant. Pour le point 2) si le jeu de données est déjà "disponible en open data" ça veut dire que dans les faits il est sur un portail open data donc un simple lien répond à la question. En revanche s'il n'a pas été publié ce n'est pas forcément qu'il y a une raison qui s'y oppose ! dans 90 % des cas c'est juste qu'ils ne l'ont pas encore fait, même si la loi les y oblige..

DaFrenchFrog commented 2 years ago

Je n'ai pas eu de remontées jusqu'ici sur cette confusion mais dans la mesure où les testeurs étaient plutôt experts il est possible qu'il y en ait une...

On peut peut-être séparer en deux parties avec un titre comme "Accès aux données" et "Visibilité de cette fiche de données". Les termes accès et visibilité permettent de bien faire la distinction entre ce qui est "là-bas" et dont on souhaite obtenir "l'accès", et ce qui est "dans l'outil" et qui peut être visible ou pas. Qu'en pensez-vous ?

DaFrenchFrog commented 2 years ago

Autre option changer les questions pour avoir :

Et ensuite

johanricher commented 2 years ago

Ok pour "Visibilité (ou Partage ?) de cette fiche : interne / inter-ministériel / public". Et utiliser le terme d'ouverture (plutôt que "open" et "open data") uniquement pour parler du jeu de données.

Les données sont-elles accessibles en open data ?

Je reformulerais en "Les données sont elles ouvertes ?" (si oui quel est lien pour y accéder etc.)

Cette fiche de données est-elle visible par les autres organisations ?

Il faudrait reformuler en partant du principe qu'une fiche est en accès public par défaut et permettre à l'utilisateur de définir un accès plus restreint si ça se vérifie par ses réponses à des questions. Mais encore une fois je pense qu'il est trop tôt pour designer ça car 1. le multi-catalogue n'est pas encore implémenté, donc le niveau "inter-ministériel" n'a pour l'instant pas de sens. et 2 l'outil est accessible uniquement en étant authentifié, le niveau "public" a vocation à être sur data.gouv.fr et on ne sait pas encore comment on va gérer ça.

florimondmanca commented 2 years ago

@johanricher Pour info, pour l'instant j'ai ouvert une PR pour déplacer created_at vers un "namespace séparé", sous la forme d'une table séparée que j'ai appelée catalog_record plutôt que datasheet. (Si je ne m'abuse c'est le vocabulaire DCAT-AP et je trouve ça plus facile à distinguer visuellement que dataset / datasheet.)

Cette étape correspond à la section "Dataset vs Datasheet" dans un de mes précédents messages.

C'est dans ce "namespace" qu'on pourra donc stocker les métadonnées de fiche prorpes à l'outil.

johanricher commented 2 years ago

une table séparée que j'ai appelée catalog_record plutôt que datasheet. (Si je ne m'abuse c'est le vocabulaire DCAT-AP et je trouve ça plus facile à distinguer visuellement que dataset / datasheet.)

En effet, bien vu ! (pour le contexte : DCAT-AP est un "profil" une extension à DCAT)

De manière générale ça peut être pas mal de reprendre les noms des propriétés / champs dans DCAT, quand elles existent et qu'elles ne sont pas contradictoires avec nos besoins et méthodes.

florimondmanca commented 2 years ago

Suite à réunion du 21/04 :

Pour le cas d'usage MC, ce qui est à faire :

florimondmanca commented 2 years ago

La séparation technique #189 a été faite, je vais fermer ce ticket pour l'instant, étant entendu qu'on pourra suite au cas d'usage MC regarder les évolutions futures évoquées dans les messages précédents.