Produire un standard open data en 2018

CharlesNepote · Juillet 11, 2018, 7:06

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

joel · Juillet 12, 2018, 4:09

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

joel · Juillet 12, 2018, 4:38

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.

lolobobo · Juillet 12, 2018, 5:27

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.

CharlesNepote · Juillet 12, 2018, 9:53

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 !

CharlesNepote · Juillet 12, 2018, 10:12

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.

johan · Octobre 4, 2018, 5:03

Je pense effectivement que le sujet des métadonnées et des schémas (et autres standards, spécifications…) crystallise beaucoup de problématiques dans l’open data actuellement et à ce titre il serait passionnant d’en discuter et partager les bonnes pratiques avec toutes les personnes intéressées ici.

Nous l’aborderons sous un angle technique et pratique lors d’un atelier mardi prochain au Square à Paris à l’occasion des Journées de l’Open Data par principe (2 ans de la loi Lemaire !).

Egalement lundi après-midi autour du projet Validata, cette fois plus en lien avec le travail d’Open Data France sur le Socle commun des données locales.

Des membres de l’équipe de Datagouv seront notamment présents.

col1m · Octobre 5, 2018, 1:58

Super ! Je serai à Validata lundi après-midi, ce sera l’occasion de discuter de tout ça. @loichay, y seras-tu ?

loichay · Octobre 5, 2018, 2:12

Oui je ne t’ai pas rappelé après la perte de ton fairphone … Ce sera donc l’occasion de reprendre la conversation et de répondre à tes questions concernant les schémas issus du SCDL. A lundi.

loichay · Janvier 11, 2019, 12:29

Je partage ici quelques ressources (rapports et guides) utiles et complémentaires pour alimenter la capitalisation des “bonnes pratiques” et recommandations pour la standardisation de l’open data :

From Development to Adoption: Lessons from Three Open Standards

OpenNorth (CA) a publié un rapport de documentation portant sur les standards ouverts pour les données qui a été réalisé dans le cadre d’un programme de R&D lancé par l’Open Data Institute (UK).

OpenNorth a documenté le processus de développement et d’adoption de 3 standards pour ce projet :

Open511 pour les données en temps réel relatives aux événements de perturbation du réseau routier (travaux, fermetures, manifestations, etc)
Popolo pour les données relatives à l’organisation de la vie politique telles que les représentants élus, les débats, les motions, les votes et les discours
Represent pour les données relatives aux représentants élus, comme le nom, le parti politique, l’adresse et autres coordonnées

Les principaux résultats et recommandations issus de ce rapport sont :

Créer des standards de données à partir de la demande
Spécifier des modèles de données simples et légers
Impliquer des collaborateurs officiels le plus tôt possible et maintenir leur engagement tout au long du projet
Impliquer des experts du domaine (métier) et des spécialistes de la donnée
Créer des outils logiciels pour faciliter l’adoption (édition, validation et conversion)
Rechercher le soutien des éditeurs de logiciels
Prendre en compte des coûts de sensibilisation, de facilitation et d’entretien

Voir la synthèse du rapport
Voir le rapport complet

Standards Lab Handbook: an open data standard toolkit

Ce guide donne un aperçu des différentes étapes de la conception, de l’élaboration, du maintien et de l’adoption d’un standard ouvert de données. Il fournit également une bibliothèque de composants et de modèles qui peuvent être intégrés dans ce processus.

Voir le guide

Réalisé par Open Data Services (UK) dans le cadre d’un programme de R&D lancé par l’Open Data Institute (UK), il s’appuie sur les enseignements tirés d’une étude portant sur les 6 standards suivants :

Voir le rapport

Creating and maintaining open standards

Créé par Porism (UK) à l’occasion d’un programme de R&D lancé par l’Open Data Institute (UK), ce guide fournit des orientations sur les processus et les techniques d’élaboration de standards ouverts pour les données.

Voir le guide

Open Standards for Data Guidebook

L’Open Data Institute (UK) propose un guide pratique en ligne pour aider les personnes et les organisations à créer, développer et adopter des standards ouverts pour les données. Ce guide est le résultat du projet “Documenting the development of open standards for data” intégré au programme d’innovation de l’ODI en 2017 et auquel 4 partenaires ont participé (Porism, OpenNorth, Open Data Services et W3C).

Voir le guide
Voir les sources sur Github

Exploring the development and impact of open standards for data

Ce rapport est le livrable de la recherche documentaire réalisée par l’ODI à propos du développement et de l’impact des standards ouverts pour les données.

Voir le rapport

Open standards for data - user experience

Ce rapport est le livrable de la recherche réalisée par l’ODI auprès des utilisateurs des standards ouverts pour les données.

Voir le rapport

Flacombe · Janvier 11, 2019, 9:14

En vous remerciant pour cet énorme travail de recensement et de capitalisation, je m’étonne beaucoup plus succintement de ne pas voir OpenStreetMap ou wikidata comme source de standard sémantique et attributaire.

Il y a une synergie à trouver, hors de l’activité purement cartographie et collecte de terrain, pour tirer partie de l’énorme travail de recoupement, consolidation et normalisation qui est fait par un petit nombre de personnes pour maintenir la cohérence de l’ensemble.

Ces pateformes étant ouvertes et mondiales, nous n’avons rien à gagner à réinventer la roue.
2019 sera surement l’année de la standardisation

loichay · Janvier 11, 2019, 9:20

Pourrais-tu répertorier et lister ici les ressources essentielles permettant de décrire les standards ouverts utilisés pour les données OSM et Wikidata ?

Flacombe · Janvier 11, 2019, 9:27

C’est un travail qui dure depuis de nombreuses années (et qui durera encore)
D’ailleurs certaines ressources sont toujours en construction pour augmenter leur cohérence.

Tout est sur le wiki de la communauté : https://wiki.openstreetmap.org/wiki/Map_Features

Je rédige pas mal de Requests for Comments, destinés à être votés et ensuite adoptés, pour l’industrie et l’infrastructure pour la plupart.
https://wiki.openstreetmap.org/wiki/User:Fanfouer

Autant que faire se peut, des correspondances sont établies entre les attributs OSM et la normalisation internationale (ISO, IEC, NF, EN, DIN…).
Et aussi entre les modèles OSM et des standards établis à l’exterieur.
C’est le cas de deux d’entre eux : les hydrants avec le standards d’échange de l’Afigéo et le modèle GraceTHD pour les télécoms
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Dfire_hydrant#Correspondance_avec_le_mod.C3.A8le_PEI_de_l.27Afigeo
https://wiki.openstreetmap.org/w/index.php?oldid=1686678#Correspondance_avec_GraceTHD

Avoir des standards opendata compatibles avec ce genre de plateforme augmente les chances de convergences et de nettoyage par le crowdsourcing. C’est encore plus facile pour réintégrer les résultats par la suite.

loichay · Janvier 13, 2019, 9:42

En février 2018, MISA Ontario et OpenNorth ont lancé un projet pilote consacré aux standards open data pour les municipalités canadiennes. Complémentaire des travaux qui ont permis d’élaborer le Do-it-Yourself Open Data Toolkit, ce projet a permis d’identifier des jeux de données prioritaires et de définir des conventions de nommage communes pour les acteurs publics locaux. Très proche de la démarche du Socle Commun des Données Locales (SCDL), il avait également comme objectif d’illustrer la valeur des standards et de favoriser leur adoption.

Publié en août 2018, le rapport final du projet explore deux aspects principaux :

La découvrabilité des données (conventions de nommage des jeux de données et fichiers, catégorisation, balisage par mots-clés, métadonnées)
L’interopérabilité des données et leur conformité aux standards (utilisation variable
de standards relatifs au contenu de certains jeux de données, de leurs métadonnées et de quelques attributs de base comme les dates)

Suite à une enquête par sondage, un référentiel de 10 jeux de données prioritaires a été défini :

Points d’adresse
Budget
Permis de construire
Répertoire des entreprises
Résultats des élections
Installations publiques
Construction de routes
Réseau routier
Transport public
Zonage d’occupation du sol

Une liste d’attributs pour chaque jeu de données est fourni en annexe.

4 éléments clés ont été identifiés pour cadrer la stratégie d’adoption de ces standards de données ouvertes :

Un processus simple
Pour simplifier et faciliter l’adoption des standards, les mesures suivantes sont proposées :
– S’appuyer sur des outils ETL (Extraction, Transformation, Loading)
– Prototyper le processus d’adoption dans deux environnements de portail importants
– Elaborer un guide pratique, étape par étape, pour l’adoption des standards
L’éducation
Pour faire connaître les ressources disponibles et socialiser les concepts, des présentations au cours d’événements et des webinaires sont recommandés.
Le soutien continu à la communauté des utilisateurs (organisation en communauté de pratique, boucle de retroaction avec les utilisateurs, appui sur la plateforme GCcollab, etc)
Le support des fournisseurs de logiciels pour promouvoir et intégrer les standards

Zitoun · Novembre 23, 2020, 3:01

Je m’intéresse en ce moment à conceptualiser le nœud producteur de données pour l’une des métropoles françaises, c’est à dire l’interface entre le producteur et l’API locale du portail.

Etant donné que les besoins des métropoles sont similaires, je suis étonné de ne pas trouver des standards validés par les métropoles, et des briques techniques comme les implémentations open source pour les formats de metadonnées des métropoles et plus particulièrement la mise en ligne de données au niveau producteur.

Nous sommes maintenant en 2020 : est-ce que l’histoire de la standardisation de l’Open Data est encore en cours d’écriture, ou bien ai-je omis un aspect important dans mes recherches ?