Produire un standard open data en 2018

standards

(Charles Nepote) #1

Longtemps l’open data a été ce joyeux potlatch informationnel où chaque acteur produisant un jeu de données produisait son propre standard.
En 2018, ce temps est révolu.

Voilà je commence un peu crûment ce document dont j’avais évoqué l’idée ailleurs : Produire un standard open data en 2018 : grands principes et jalons.
Il fera 4 pages maximum pour être facile à communiquer et rester synthétique.

Après les travaux d’OpenDataFrance sur le SCDL et ceux d’Etalab sur divers standards open data je pense utile de prendre un peu de recul et capitaliser sur les bonnes pratiques.

Le document propose quelques grands principes et les explicite. Puis 7 étapes clés pour fabriquer un standard.

J’ai lancé un premier jet encore très brouillon. L’idée est notamment de le rédiger en travaillant sur celui des défibrillateurs cardiaques. J’aimerais bien ne pas être tout seul et sollicite l’aide de toutes les bonnes volontés d’ici et d’ailleurs, en écriture, commentaires, relectures, etc. Ça pourrait d’ailleurs être un beau projet d’Open Data impact : je passe la main à qui veut s’en saisir.


(Joël Gombin) #2

Merci @CharlesNepote, initiative intéressante et à laquelle je vais essayer d’apporter ma pierre.
Le fait de faire un pas de côté ou en arrière en partant de l’expérience française est intéressante, tout en ne perdant pas de vue qu’il y a sur le sujet un gros état de l’art international. @samgoeta s’en était fait pour partie l’écho, mais on trouve pas mal d’autres ressources en ligne. De ce que j’en vois, on peut distinguer deux séries de considérations qui sont traitées en parallèle dans ton document :

  • des considérations sur la gouvernance d’un standard - en gros, comment s’assurer que le standard lui-même est ouvert. La référence semble être https://open-stand.org/about-us/principles/
  • des considérations plus directement techniques/pratiques (“Éviter la redondance mais sans l’exclure absolument”, “utiliser des données pivots”). Paradoxalement, j’ai moins trouvé d’éléments de référence sur cette dimension, en tout cas pas rassemblées dans un endroit unique. Peut-être du côté du W3C ? Le projet Popolo semble aussi intéressant. Par contre, je pense que nos amis de Open Data Services ont une grande expérience sur ce sujet (c’est eux par exemple qui ont développé l’OCDS), et ils ont aussi créé et/ou maintiennent par mal de ressources utiles à cet égard (voir par exemple http://org-id.guide/ et http://docs.org-id.guide pour les identifiants uniques, et pivots, d’organisations au plan international).

Bref, merci @CharlesNepote d’avoir lancé ce chantier, et au travail pour ma part :wink:


(Joël Gombin) #3

Je le mets ici aussi faute de savoir où le mettre exactement dans ton doc, mais je pense qu’il manque une section (ou en tout cas des éléments) sur le “qui”. Tes verbes sont à l’infinitif et donc on ne sait pas clairement qui est responsable de chaque étape. Le cas de l’OCDS est sans doute overkill pour beaucoup d’usages mais a le mérite de poser explicitement toutes les instances et responsabilités. Ça a le mérite aussi d’expliciter l’implicite et donc d’éviter les asymétries d’information.

Au passage, d’ailleurs, c’est aussi une manière d’ouvrir un débat un peu politique autour du 5e principe d’open stand qui dit que les standards doivent faire l’objet d’une adoption volontaire et non contrainte – à mettre en parallèle avec notre tendance en France à valoriser les standards imposés par la norme juridique.


(Laurent B) #4

Je ne sais pas bien ou le noter non plus alors je le pose ici.
Je suis assez d’accord avec les idées exposées dans le projet de document.

Effectivement il est important de définir un standard facile a lire et a utiliser à la fois par une machine et par un humain ( l’exemple code insee + Commune exprime bien ce besoin.

Par contre dans le cadre de la conception du standard. Il serait intéressant de pouvoir réfléchir, si ce n’est deja fait à ine standardisation de “champs de données”.

Par exemple les champ latitude. Longitude, code INSEE date…possèdent des standards généralement utilisé.

Ça me semble moins évident pour d’autres. Je reprends l’exemple des défibrillateurs et des horaires d’accès que nous avions évoqué dans un autre fil : comment le définir
plusieurs champ ? Un champs avec unmarquage particulier ?
Ce qui pourrait être intéressant c’est de proposer les base d’un ”langage" de définition de la donnée qui pourrait être commun a tous les fichiers pour les champs nonn textuel:
Comment on écrit un oui ou un non par exemple (oui/non, 0/1,rien/oui…) Comment on écrit une date ? Est ce qu’on écrit les nom de communes en majuscule non accentués ou en minuscule.
Bref en plus de proposer une méthodologie pour in format de jeu de données. Mettre en commun une grammaire commune pour les créateurs de jeux de données.


(Charles Nepote) #5

J’entends et je connais un peu cette littérature mais je pense qu’elle est mal connue en France, la langue étant notamment une barrière. Elle est par ailleurs touffue et parfois verbeuse. Enfin elle n’est probablement par toujours adaptée au contexte français.

Mon intention est de vulgariser en français des bonnes pratiques issues des expériences internationales et nationales. Pour qu’il soit efficace, je pense utile de le faire court, pour donner les bases et donner envie d’aller plus loin.

Oui les principes d’open-stand.org donnent de bonnes choses mais peuvent être aussi un peu réinterrogés avec notre prisme local.

Les reco anglo-saxonnes sont plus diffuses peut-être parce qu’ils considèrent la qualité des données comme un sujet technique et moins organisationnel. Là encore la littérature anglo-saxonne est touffue et pas toujours adaptée. Commençons par vulgariser en français.

Merci pour ta participation !


(Charles Nepote) #6

Tu as raison. J’avais un peu de trop allonger le document en introduisant le qui mais c’est un tord. Il faudrait trouver un moyen de l’intégrer sans trop alourdir le doc.

Oui ce 5e principe me gêne aussi. Il ne faut pas en faire un dogme. Il y a d’ailleurs beaucoup de projets open source et non des moindres (Linux, etc.) qui sont pilotés par un dictateur bienveillant. Il faut accepter des formes de gouvernances variables mais probablement ne rien céder sur le fait d’associer toutes les parties prenantes.