Jeux de valeurs référentiels structurés

Veille
1

La diffusion des données en open data se fait majoritairement en CSV, avec quelques exceptions en XML. Les données sont parfois décrites, souvent mal. Qui plus est, il n’y a jamais de référence à des jeux de valeurs partageables entre les différents jeux de valeurs.
Si je prends 1 exemple concret : l’extraction des finess des établissements (hôpitaux par exemple) : https://www.data.gouv.fr/fr/datasets/finess-extraction-des-autorisations-dactivites-de-soins/

Les données sont exportées en CSV et font références à des jeux de valeurs, qui sont définis dans des pdf ! Nous avons même une liste de valeurs définie dans un fichier PDF, décrite via un schema XSD. Cette liste de valeurs est utilisée dans 1 CSV. Bref, cela n’a aucun sens.
Les nomenclatures utilisées sont définies sur le site de la DRESS : http://finess.sante.gouv.fr/fininter/jsp/nomenclatures.do

Mes interrogations :

  • pourquoi trouve-t-on majoritairement des données non structurées ? (CSV, versus XML, RDF, JSON-LD, etc.) ;
  • pourquoi n’utilise-t-on pas des jeux de valeurs définis une fois pour toute, et utilisés (et réutilisés) dans les données publiées : exemple : code APE/NAF, type d’activité des établissements de santé, nomenclature, etc. Il existe pour cela des standards internationaux (comme CTS2) permettant de publier ces terminologies ;
  • est-ce que cela poserait 1 problème aux datascientists de traiter autre chose que du CSV. Des données structurées se référant à des jeux de valeurs structurés ?

Merci pour votre avis
Frédéric

2

Bonjour,

Une réponse qui ne représente que ma propre expérience. Je suis moi-même curieux de lire ici d’autres avis.

pourquoi trouve-t-on majoritairement des données non structurées ? (CSV, versus XML, RDF, JSON-LD, etc.) ;

Facile à produire, facile à lire. De plus, il n’y a pas pour le producteur des données d’ambiguité sur le contenu de ses données (format, signification des valeurs, etc), donc pas de nécessité pour lui de la briser en sur-spécifiant le contenu.

Et puis les gens n’aiment pas manipuler des données complexes. Au début je publiais en XML, et j’ai recu des mails me disant qu’il y avait des problèmes pour les importer dans R afin de faire … des choses que je ferais en ligne de commande. Alors j’ai rajouté de l’export JSON --> même résultat. Alors j’ai rajouté de l’export TSV, mais Excel ne comprenait pas l’UTF8.
Alors j’ai rajouté un export sous format Excel.

Tous les formats sont utiles simultanément, à des publics différents. Il faut publier en CSV pour que les données soient vues, et il faut les publier dans des formats plus exigeants pour qu’elles soient fiables.

est-ce que cela poserait 1 problème aux datascientists de traiter autre chose que du CSV. Des données structurées se référant à des jeux de valeurs structurés ?

J’ai assisté à Nantes à une conférence surprenante qui expliquait les liens entre un “data scientist” et un “ingénieur logiciel”. C’était peut-être exagéré de leur part, mais dans leur explication le data scientist admettait son incapacité à “préparer” les données (son travail était la modélisation, l’expérimentation, l’amélioration du modèle de traitement) tandis que l’ingénieur logiciel était là pour manipuler les données d’entrée et de sortie.

Les journalistes savent manipuler du CSV/TSV avec des tableurs. Pour manipuler du JSON il faut déjà rentrer dans de la programmation dédiée (sauf à utiliser ‘jq’, un utilitaire fabuleux que je conseille à tout le monde) et c’est déjà hors de portée en général. Le reste (XML/RDF) c’est quand on fait de la donnée destinée à être réutilisée par d’autres producteurs de données.

C’est peut-être ca l’explication, d’ailleurs: la donnée destinée au public peut être publiée en CSV/TSV (ou directement sur des pages web), mais il tout format plus évolué est destiné exclusivement à des réutilisateurs.

Je suis curieux d’entendre d’autres expériences.

Nathann

2 « J'aime »
3

Bonjour,

Pour votre première interrogation je considère que le CSV est une donnée structurée : on peut y associer un schéma (voir la SCDL) et les fichiers se traitent très bien de manière informatique. Le cas des données Finess est particulier, c’est pour moi un des pires cas de diffusion de données que j’ai vu : on publie les données dans un format, mais on ne respecte pas l’esprit dans lequel il doit être utilisé. Les données Finess mentionnées n’ont pas d’entête de colonne, et les lignes n’ont pas toutes le même nombre de colonne. On peut effectivement parler ici de données non-structurées …

Mais de manière générale, je trouve que la plupart des données sont structurées (la majorité est en CSV est ils sont généralement utilisable directement). Par contre les métadonnées ne le sont pas et il y a énormément de documentation en PDF, ce qui complique grandement les traitements.

Pour la deuxième interrogation, je ne la comprend pas trop et il me semble que l’effort est fait, même si c’est perfectible. Beaucoup de jeux de données utilisent des codes postaux, code insee, code siren, … bien formatés et définis dans des jeux de référence comme par exemple hexaposte. On touche ici aussi à un problème de référentiel, et les données peuvent évoluer au cours du temps (exemple le codes insee avec les divisions administratives qui évoluent au cours du temps).

Pour la troisième interrogation, je ne pense pas, si cela permet d’avoir en entrée des traitements de la donnée de meilleure qualité. Mais il faut faire un effort en plus pour comprendre la structure de la donnée, et si elle change à chaque dataset, il faut à chaque fois réimplémenter la manière de la lire, alors que le CSV marche quasiment tout le temps pareil. Et on peut avoir des données en CSV qui font référence à des jeux de valeurs structurés si ils sont associés à un fichier de métadonnées qui décrit bien tout ça.

Pour conclure sur le CSV, je dirais que c’est un très bon compromis entre le “grand public” et les réutilisateurs avancés : le premier peut l’utiliser avec plusieurs outils accessibles comme les tableurs et les seconds peuvent l’utiliser dans leurs traitements (et d’autant plus facilement si il y a les métadonnées associées dans un bon format). C’est donc a priori le format qui va permettre de rendre la donnée accessible au plus large public possible.

1 « J'aime »
4

Bonjour,

Je ne suis malheureusement pas d’accord pour dire que les données CSV sont structurées. Il s’agit simplement d’une liste de valeurs, séparées par 1 caractère.

Il n’y a pas de schéma définissant formellement les types, les contraintes. Même si certaines initiatives sont intéressantes comme csvlint (1) ou CSV schema (2), il n’y a pas de spécifications officielles par le W3C, l’OMG, l’IETF… Et puis très peu utilisent les initiatives existantes.
Par ailleurs, il n’y a pas de structuration des données (sous forme hierarchique) possible, tout est à plat.

Dans SCDL (3), il y a des informations sur les données, comme des regex sur les prénoms, 1 json utilisable avec goodtables pour les subventions, 1 document pour les adresses locales, etc. Ces informations sur les données sont très intéressantes mais elles ne sont pas systématiques et utilisables par 1 programme informatique pour valider les données (à l’image d’1 schema XSD, ou relaxng ou autre).

Pour les données référentiels, il me semble qu’il y aurait 1 grand intérêt à avoir 1 serveur de terminologies national exposant de façon non ambigue les données.

Par exemple, un service qui exposerait les codes APE/NAF en données :

  • le code system (défini de façon univoque permettant de d’attacher les valeurs du jeu de valeurs à l’espace de noms NAFv2 de l’insee)
  • le code de la valeur
  • le libellé

Il s’agit là de la définition classique des code systems.
Ainsi le code 01.41Z associé à 1 OID ou 1 URL du jeu de valeurs est défini de façon non ambigue, fiable et sémantiquement solide.

Pour former un ensemble national de données qui peuvent se lier et donc avoir une valeur plus grande, tout le monde pointerait sur le ce jeu de valeurs et plus besoin de passer du temps à traiter 0141Z, 141Z, 1.41Z, 01.41Z, etc.

De même une valeur 04, ne veut rien dire toute seule, sortie de son contexte. En associant un espace de noms à cette valeur, elle a une signification non ambigue.

Si l’on prend 1 autre exemple avec le finess, il y a 1 jeu de valeurs activite/modalite/formes (4).
Dans un fichier CSV, la valeur 04 peut representer :

  • Psychiatrie pour l’activité
  • Réanimation néonatale pour la modalité
  • ou Hospitalisation à temps partiel de nuit pour la forme

Je pense qu’il serait bien plus solide d’avoir 3 jeux de valeurs avec 3 OID/URL différentes permettant de spécifier à quoi se rapporte cette valeur 04.

Le mouvement open data est formidable et nous allons avoir de plus en plus de données, mais n’allons nous pas être noyés dans ces données, qui sont redéféfinies sans cesse, qui n’ont pas de signification univoque ? Ne perd-t-on pas une valeur immense sous pretexte qu’il est plus facile de lire 1 CSV que des données structurées (et valides).

Ma question concernant les data scientists était de comprendre si cela ne pose pas question de faire parler des données faibles de sens/de structure, sans définition sémantique et d’en déduire des strategies ?

(1) https://csvlint.io/about
(2) http://digital-preservation.github.io/csv-schema/csv-schema-1.1.html
(3) https://git.opendatafrance.net/scdl
(4) http://finess.sante.gouv.fr/fininter/jsp/pdf.do?xsl=ActModFor.xsl
5

Bonjour,

En préalable, je précise que je ne suis ni datascientist, ni développeur, mais juste été un modeste apprenti producteur opérationnel en petite collectivité et depuis peu je m’amuse à la réutilisation des données relatives aux finances locales à travers la création d’un petit site perso (url en profil).
Mon avis ne vaut donc que ce qu’il vaut… probablement pas grand chose…

Je pense tout simplement que le format utilisé pour l’ouverture de la donnée doit être le plus simple et le plus accessible possible, tout en garantissant la fiabilité et la compréhension des données.

Toute utilisation d’un langage nécessitant des compétences spécifiques ne devrait être utilisé “par défaut” que lorsque la mise à disposition dans un format basique n’est pas possible ou n’a pas de sens (ce qui n’empêche pas le producteur de fournir en complément de la version “pour les nuls”, une version enrichie “pour les pros”).

Sauf bien sûr si l’objectif du producteur de la donnée est de la réserver à des professionnels et de ne pas chercher à faciliter son accès à une personne lambda…

L’esprit de l’open data n’est-il pas de favoriser la transparence, l’accessibilité et la ré-utilisation des données ?
Tout ce qui peut entraver, complexifier inutilement, ou réserver à des spécialistes la ré-utilisation de données ne va pas donc pas, pour moi, dans le bon sens.

Est-ce que je me serais lancé dans la ré-utilisation des données financières locales, des fichiers REI, de la BANATIC etc, … s’i elles avaient été mises à disposition dans un format XML, json ou autre ? Probablement pas…

Même s’il est probable qu’en m’y investissant un minimum j’aurais pû être en mesure de les traiter, je dois avouer que cela m’aurait demandé d’avantage d’efforts et d’investissement personnel que de simplement importer des fichiers CSV en base de donnée pour les traiter.

Et pour un simple projet sans business model économique qui ne reçoit que quelques centaines de visiteurs par jour, je n’aurais pas consenti ce supplément d’effort.

Voila, my 2cents…

3 « J'aime »
6

Plus on monte en qualité de structuration et de description sémantique de la données, mieux c’est sur un plan purement théorique, mais cela laisse aussi beaucoup de monde sur le bas côté du chemin, que ce soit tant côté producteurs que réutilisateurs.

Dans l’idéal il faudrait donc des deux.

Dans un premier temps, faire au plus simple pour le producteur… car tout démarre par lui.
Il peut sortir facilement des CSV, qu’il le fasse, c’est son MVP opendata :wink:
Il sort facilement du XML mais pas quelque chose de plus digeste pour beaucoup de réutilisateurs (exemple la DILA avec l’annuaire des services publics assez indigeste)… qu’il le fasse aussi !

Dans un deuxième temps, monter en gamme en proposant du CSV avec schéma, voir des formats plus sémantisés sera un progrès. De même dans l’autre sens où proposer une version plus accessible CSV de données XML permettra sûrement de démultiplier les réutilisateurs.

Cette montée en gamme ou version plus grand public peut même être faite par quelqu’un d’autre que le producteur.

2 « J'aime »
7

Au-delà du schéma et de la facilité le sujet est aussi celui des données normalisées vs dénormalisées. Un CSV contenant des données dénormalisées est une base de données “autonome”, sur laquelle on peut travailler directement (exemple pour se faire une idée sur des jeux de données utilisés pour des compétitions de data science : https://www.kaggle.com/datasets). En tant que réutilisateur, pour des projets “one shot” (ex. dataviz), ce type de structure est idéale.

8

Pour information, OpenData France mène actuellement un travail de développement d’un outil permettant la validation de ces schémas… ce qui implique de les formaliser de manière lisible machine :wink: : https://dev.validata.fr/

1 « J'aime »
9

Sinon pour en revenir au débat initial, je prends ici volontiers une position un peu caricaturale pour me faire l’avocat du diable.
D’abord pour rappeler le bilan pour le moins mitigé que les pros (enfin, ici, @lespetitescases) tirent de l’approche sémantique des données : Les Technologies du Web sémantique ont-elles tenu leurs promesses ?.
Ensuite je me permets de renvoyer à un thread que j’ai fait sur twitter dont l’argument est, si on veut, que même du CSV est déjà trop exigeant d’une certaine manière pour l’open data dans le monde réel. Position inspirée par notre expérience quotidienne chez Datactivist d’accompagnement d’organisations publiques à l’ouverture de leurs données…

1 « J'aime »