Lexique

[johanricher]

Contexte

Dans le cadre d'une investigation en cours pour enrichir les schémas et améliorer leur articulation avec des "données pivot", les parties prenantes (Etalab, OpenDataFrance / multi, Données et territoires) ont besoin de s'accorder sur un vocabulaire commun.

Il s'agit de définir ensemble au sein d'un lexique les notions communément employées par les parties prenantes. Ce lexique a notamment vocation à être ajouté dans le guide Etalab sur les schémas et à être référencé sur schema.data.gouv.fr.

Critères d'acceptation

• Le lexique définit un vocabulaire commun qui permet aux parties prenantes de se comprendre et de mieux coordonner leurs travaux.
• Les parties prenantes sont d'accord avec la liste des notions à définir et les définitions données.
• Les parties prenantes se réfèrent au lexique comme cadre commun aux travaux qu'elles mènent indépendamment.

Tâches

• [ ] Créer et itérer le lexique sur un pad dédié
• Quand les parties prenantes sont satisfaites :
  • [ ] Ajouter le lexique sur guides.etalab.gouv.fr (améliorer la documentation par la même occasion)
  • [ ] Référencer le lexique sur schema.data.gouv.fr

[l-vincent-l]

Dans le pad il y a une confusion entre format et columnType.

Le format est quelque chose de très technique, typiquement ça va être une regex, alors que columnTtype est là pour donner de la sémantique sur la colonne, on pourra dire ceci est un code INSEE d’une commune, ceci est un code INSEE d’un département…

[johanricher]

columnType est spécifique au profil Fiscal de Data Package et n'existe pas dans la spec Table Schema, qui est l'objet de notre focus dans le contexte qui est le nôtre actuellement. Cependant, une piste serait de s'inspirer de ce système d'"extension" en proposant un profil FR à Table Schema, où on pourrait ajouter des "formats" français qui s'appuieraient sur des "référentiels" (voir là aussi le lexique pour les définitions qu'on donne à ces notions dans notre contexte).

[ronnix]

Je pense aussi que surcharger la clé format ne serait pas la meilleure approche, dans le sens où elle décrit plutôt "à quoi la chaîne doit ressembler", ce qui est orthogonal à la question de la sémantique et du référentiel, qui demanderait plutôt une clé distincte, qui serait donc une extension (un peu comme fiscal data package).

Par exemple pour un code INSEE de commune, on pourrait à la fois avoir :

• un type string
• un format qui nous dit que ça fait 5 caractères (et qui peut être validé par tout outil frictionless standard)
• un truc en plus (propre à notre profil) qui nous dit que sémantiquement c'est un code INSEE de commune dans le COG 2022

[ColinMaudry]

Je vois que Fichier est présenté comme synonyme de "table" : pas vraiment puisqu'un fichier au format tableur (ODS, XLSX) peut contenir plusieurs tables hétérogènes.

[pierrecamilleri]

Dans tous les cas, il ne s'agit pas de surcharger la clé format, ce qui n'est pas permis par la spécification Table Schema (c'est cependant permis par JSON Schema).

Les regex ne vont pas être spécifiées dans la clé format, mais dans la clé pattern pour Table Schema et pour JSON Schema. Les règles de validation des formats sont d'ailleurs parfois (souvent ?) plus riches que ce qui est possible de faire sans, en s'appuyant sur des spécifications séparées.

Le lexique proposé n'attache pas un sens sémantique fort au mot "format", mais un "formalisme métier" (formalisme: respect scrupuleux des formes), ce qui à mon sens est assez juste.

La distinction sémantique / validation n'est selon moi pas aussi simple que vous la présentez. Si l'on prend l'exemple de {"type": "string", "format": "email"}, le format va donner à la fois de l'information sur ce que c'est et sur à quoi ça ressemble. On ne serait pas très loin avec un {"type": "string", "format": "code_commune:COG2022"} où on retrouve la même ambiguité (mais à nouveau, ce n'est pas permis par la spec).

(Pour rajouter un peu à la confusion, JSON Schema définit la clé format comme "the format keyword allows for basic semantic identification of certain kinds of string values that are commonly used." La clé format n'a pas d'autre définition que "A field’s format property is a string, indicating a format for the field type" dans Table Schema.)