Ajouter plusieurs schémas pour référencer un même type de donnée

geoffreyaldebert commented 2 years ago

Contexte

Plusieurs acteurs de la communauté nous ont remonté certaines difficultés pour référencer un même type de donnée via plusieurs fichiers csv. C'est le cas par exemple du schéma des comptage des mobilités qui comprend trois schémas distincts :

Ce qui n'est pas des plus ergonomiques pour visualiser la documentation sur schema.data.gouv.fr car 3 "cartes" schémas sont présentes dans la liste des schémas : https://schema.data.gouv.fr/schemas.html

Nous rencontrons également le même type de cas pour des schémas en cours de réalisation comme celui des tiers lieux ou lieux d'insertion professionnel.

Il y a toujours la possibilité de décrire ce type de données via un schéma jsonschema mais cela nuit à l'accessibilité des données et leur facilité de production pour certains cas.

De plus, il y a aussi souvent la possibilité de réunir l'ensemble des différents fichiers en un seul mais cela entraîne un dédoublement des données important dans le fichier et n'est donc pas toujours optimisé. Nous ne traitons donc pas de ce cas dans cette issue.

Solutions envisagées

Pour résoudre ce problème, nous réfléchissons à utiliser un formalisme particulier pour traiter ce type de cas. Plusieurs solutions sont envisagées à ce jour, n'hésitez pas à réagir à cette issue pour proposer / amender ces idées :

Utilisation d'un fichier schemas.yml

Création d'un fichier schemas.yml à la racine d'un repo github (de la même façon que ce qui est demandé pour les schémas jsonschema). Ce fichier yml pourrait avoir un formalisme de ce type (en reprenant l'example des comptages de mobilité) :

title: "Comptage des mobilités"
description : "Spécification des comptage de mobilité"
homepage: "https://github.com/XXX/schema-comptage-mobilite"

schemas:
  -
    path: "comptage_mobilite_channel.json"
    title: "Channel comptage de mobilité"
  -
    path: "comptage_mobilite_measure.json"
    title: "Measure comptage de mobilité"
  -
    path: "comptage_mobilite_site.json"
    title: "Site comptage de mobilité"

Cette option a l'avantage :

de garder un url unique pour chacun des schémas
de déporter l'intelligence sur un fichier pivot qui pourra être interprété par schema.data.gouv.fr et d'autres outils tiers (par exemple publier.etalab.studio)
de limiter les développements sur l'écosystème d'outils déjà existants (validata, publier, schema...)

Cette option a le désavantage :

de ne pas pouvoir associer de foreign key d'un fichier à l'autre et donc de ne pas être en mesure de valider un ensemble de trois fichiers produits sur ces spécifications

Utilisation de la spécification `data package` de frictionless

Le framework frictionlessdata propose la notion de data package, permettant de regrouper un ensemble de resources en un seul package.

Nous pourrions alors représenter cette spécification de la manière suivante :

{
  "profile": "tabular-data-package",
  "name": "Comptage Mobilité",
  "resources": [
    {
      "path": "comptage-channel.csv",
      "profile": "tabular-data-resource",
      "schema": {
        "fields": [
          {
            "name": "var1",
            "type": "string"
          },
          ...
        ]
      },
    {
      "path": "comptage-site.csv",
      "profile": "tabular-data-resource",
      "schema": {
        "fields": [
          {
            "name": "var2",
            "type": "integer"
          },
          ...
        ]
      },
    {
      "path": "comptage-measure.csv",
      "profile": "tabular-data-resource",
      "schema": {
        "fields": [
          {
            "name": "var3",
            "type": "number"
          },
          ...
        ],
        "foreignKeys": [
          {
            "fields": "var3"
            "reference": {
              "resource": "comptage-site.csv",
              "fields": "var2"
            }
          }
        ]
      }
    }
  ]
}

Cette option a l'avantage :

de regrouper en un seul fichier les spécifications de plusieurs fichiers de sortie csv
de garder le lien entre fichier via l'utilisation de clé étrangères

Cette option a le désavantage :

de ne pas entrer complètement dans la philosophie frictionless qui utilise principalement les data package pour décrire des données et non uniquement des schémas (j'ai demandé à frictionless confirmation sur ce point).
de n'être pas encore compatible avec l'ensemble des outils construits autour des schémas (schema.data.gouv.fr, publier.etalab.studio, validata etc.)

Je suis donc preneur de vos retours, suggestions, idées. Avant de nous lancer sur ce chantier qui est je pense assez important mais indispensable si nous voulons passer à l'échelle sur le référencement de schémas plus complexes sur schema.data.gouv.fr

Cc @johanricher @NicolasBerthelot @AntoineAugusti @thbar @pierredittgen @agarrone

geoffreyaldebert commented 2 years ago

Après quelques informations prises auprès de frictionless, il est possible de partir sur un format de type datapackage en gardant un fichier unique par table et en étant capable de référencer des clés étrangères.

Exemple : https://github.com/tdwg/camtrap-dp/

qui contient des schémas à la racine du repo. Par exemple : observations-table-schema.json
et un fichier datapackage.json qui contient la référence à l'ensemble de ces schémas : https://github.com/tdwg/camtrap-dp/blob/main/example/datapackage.json

Le fichier datapackage.json peut être validée avec frictionless validate https://raw.githubusercontent.com/tdwg/camtrap-dp/main/example/datapackage.json et la validation valide également les schémas sous-jacents référencés dans la propriété resources du fichier.

Je pense que c'est la solution la plus adaptée, à voir après comment nos applicatifs interprètent ce fichier pour les mettre dans un catalogue de schémas.

johanricher commented 2 years ago

Je suis favorable à cette option, qui a l'avantage de s'appuyer sur des specs solides et pérennes dans le temps qui sont déjà alignées avec le fonctionnement actuel de data.gouv.fr : Un datapackage ("jeu de données" sur data.gouv.fr) contient des ressources et chaque ressource peut-être associée à un schéma. Dans un datapackage, les ressources et schémas peuvent aussi être référencés par URL.

datagistips commented 2 years ago

Je suis aussi partisan de l'option Data Package. Il est important de pouvoir mentionner les clés étrangères, et il vaut mieux partir sur une méthode commune plutôt qu'une alternative individuelle.

Aussi, pour une raison de cohérence : il serait étrange de passer du YAML au json : autant garder une certaine constance dans le mode de faire.

thbar commented 2 years ago

Ca me paraît une option raisonnable à première vue.

Au pire, si l'aspect data-package est non supporté quelque part, peut-être pourrait-on extraire automatiquement les schémas séparés par re-traitement, mais en conservant le data package comme "version originale" (ou l'inverse).

En tout cas je vous remercie de considérer cette évolution, car regrouper tout dans un repository permet de simplifier le cycle de vie et les releases sur un schéma comme celui que tu as cité.

thbar commented 2 years ago

Côté "transport", on a un nouveau cas qui pourrait s'appuyer sur ce qui est discuté ici.

Le schéma concernant les "Infrastructures de recharge pour véhicules électriques" (https://schema.data.gouv.fr/etalab/schema-irve) dispose déjà d'une partie dite statique (position des points de recharge etc), et nous sommes en train de commencer à poser les premiers éléments d'une partie dynamique (disponibilité d'un point de charge etc), avec un format complémentaire à l'existant et capacité à jointurer sur les identifiants.

@geoffreyaldebert si ça te paraît un bon moment pour tenter quelque chose là dessus (je ne sais pas où vous en êtes potentiellement là dessus), fais-moi signe (sinon je ferai un repo par schéma, pas de souci).

thbar commented 2 years ago

@geoffreyaldebert on continue de préparer nos ateliers sur le format IRVE dynamique, et une réflexion vient s'ajouter : comment différencier les ressources qui seront du "irve statique" de l'"irve dynamique" ?

Existera-t-il la possibilité, dans les méta-données, d'utiliser un descripteur de schéma qui soit plus fin que "juste irve" ?

Le besoin de pouvoir différencier les ressources d'une sous-partie d'un schéma va être important, notamment pour faciliter la mise en place de consolidations nationales (déjà existante sur le statique, et en projet probable sur le dynamique).

geoffreyaldebert commented 2 years ago

Salut @thbar,

Pour avancer sur ce sujet. J'ai préparé un exemple de repo comprenant un data package IRVE avec deux schémas irve-statique et irve-dynamique. Je pense que tu peux t'inspirer de cette structure pour l'intégration de l'IRVE dynamique. Faire un sous-dossier par schéma me semble être assez clair et pratique. Qu'en penses-tu ?

Avec cette structuration, nous sommes capables de correctement intégré ce data package au sein de schema.data.gouv.fr. Voici une proposition d'interface, attention, le lien ne sera peut-être plus actif dans quelques semaines

N'hésitez pas à nous faire des retours dans ce fil !

Geoffrey

thbar commented 2 years ago

Hello @geoffreyaldebert ! Merci, parfait, je vais plancher dessus jeudi matin !

thbar commented 2 years ago

@geoffreyaldebert un point auquel je pense est le suivant (mais tu as peut-être déjà intégré ça) : comment l'introduction du data package va-t-elle influencer la consultation des versions précédentes du schéma statique ? Ca fonctionne bien en l'état ? (ex: je peux aller sur la proposition d'interface, et les anciennes versions vont fonctionner, alors qu'elles ne sont pas au même niveau structurellement qu'avant etc ?)

geoffreyaldebert commented 2 years ago

Alors oui c'est un problème à aborder pendant notre point demain.

Le fait que le repo passe d'un repo "tableschema" à "datapackage" casse le lien avec l'historique que l'on va avoir sur les IRVE. Donc les versions antérieures ne seront pas visibles (soit dit en passant, c'est déjà le cas car depuis l'évolution de frictionless au niveau de la contrainte des champs "exemples", il n'y a que la dernière version, soit la 2.0.3 des IRVE qui est valide et donc visible sur schema.data.gouv.fr).

Mais effectivement cela va modifier les URLs de consultation des schémas. Dans l'exemple que j'ai mis ci-dessus, l'url historique : https://schema.data.gouv.fr/etalab/schema-irve/ contenant la description du tableschema sera alors celle qui portera la description du data package. Et celle qui portera le tableschema sera du genre https://schema.data.gouv.fr/etalab/schema-irve-statique (à voir). NB : Ca pourrait se changer et se gérer si on décidait de changer le nom du repo ;)

La version des différents schémas d'un data package doit être la même pour tous (ça implique une montée de version pour un schéma même si celui-ci n'est pas modifié et que c'est un autre du data package qui l'est). Mais de cette manière, on pourra suivre l'évolution pour chacun des schémas. C'est le cas pour la proposition d'interface où j'ai simulé deux versions : 2.0.3 et 2.0.4. Et tu peux voir l'historique des modifications.

thbar commented 2 years ago

Point en vrac à discuter cet après-midi: il pourrait être pratique d'avoir un readme général (pour réduire la duplication des informations), quitte peut-être à ce qu'il ne soit pas affiché dès le top-level en terme de navigation, mais sur chaque page.

À cogiter, je pense en particulier au schéma comptage mobilités qui comprend 3 sous-schémas, ça fait beaucoup de duplication etc.

(idée pas encore claire, je la note pour ne pas l'oublier).

Pierlou commented 8 months ago

Sujet bien connu maintenant avec la création de multiples datapackages :

datagouv / schema.data.gouv.fr