Décrire un jeu de données

Ouverture des données publiques
#1

Quelles informations vous semblent nécessaire pour décrire un jeu de données ? Comment savoir ce qu’il y a dans une base sans l’avoir ?

On peut penser au format, à la fréquence de mise-à-jour, le contenu, le producteur. Quoi d’autre ?

Cette discussion alimentera un projet de cartographie des données.

1 J'aime
#2

S’il s’agit de données tabulaires:

  • Nombre de colonnes et de lignes
  • En-têtes de colonnes
  • Caractère de séparation des colonnes(; , tab, etc.)

L’objectif étant de pouvoir consommer le jeu de données de façon quasiment automatique.

Plus généralement, pour les fichiers en texte brut, l’encodage est important (UTF8, ASCII, etc).

Et enfin, pour tous les fichiers:

  • taille (en octets)
  • URL
  • la méthode de production ou de collecte des données (s’inspirer du standard PROV)
  • et toutes celles déjà mentionnées ci-dessus
1 J'aime
#3

Il y a les données et il y a le mode de représentation de ces données.
Le format CSV consistant à représenter les données sous forme de valeurs séparées par des points-virgules ou des tabulation n’est pas suffisamment complet pour fournir les méta-données nécessaires à la mutualisation des sources d’information.
De quelles données s’agit-il (un lieu, une personne, etc)? Quel est leur type (nombre, date, etc)? Le fichier est-il encodé en UTF-8 ou en ASCII?

Pour faciliter la consommation de ces jeux de données, des formats sémantiques seront plus indiqués. Et généralement de ce côté là, c’est XML qui est le plus complet et le plus répandu.

La difficulté cependant, est de s’accorder sur des « vocabulaires » adaptés à chaque domaine.

1 J'aime
#4

il serait pour moi nécessaires de décrire plusieurs caractéristiques de chaque donnée contenu dans le jeu de donnée

  • leur sens : la sémantique des données.
    il faut être précis sur cette sémantique car elle est trop souvent source d’erreur d’interprétation, même dans les cas jugés simples. Idéalement un modèle de données (vision sémantique) serait le top, et c’est le moyen le plus efficace. Mais du texte peut faire l’affaire.
    Exemple. si l’on a une donnée « adresse ». On parle de quelle adresse ? l’adresse postale de contact ? l’adresse de résidence ? l’adresse de livraison ? l’adresse de localisation ? comment est sémantiquement structurée cette adresse ?
  • l’encodage utilisé (UTF8 est recommandé dans le RGI), mais aussi la norme de codification quand elle existe. par exemple la norme ISO 8601 pour les dates)
  • le format retenu pour le jeu de donnée (JSON est a privilégié même si dans le RGI, les formats XML, JSON, OData, et d’autres sont recommandés. CSV est considéré comme en fin de vie donc à éviter).
  • enfin, il faudrait également décrire comment les données sont collectées / mises à jour / et publiées : cycle de vie et rythme.
#5

Il faut globalement s’appuyer sur un système de métadonnées plus ou moins générique.

Vous trouverez ci-dessous quelques éléments utiles additionnels pour décrire un jeu de données

  • La granularité (fiabilité à quelle unité/précision)
  • Les occurrences les plus fréquentes (souvent le nom de champ n’est pas suffisant)

Par ailleurs, différentes projets « pêle-mêle » pour décrire, qualifier les données et gérer les métadonnées:

  • L’initiative Dublin Core qui est à priori ce qu’il y a de plus générique sur les métadonnées
  • une introduction aux métadonnées
  • les datapackages pour décrire les données
  • le JSON-LD pour « sémantiser » des données
  • le géocatalogue pour appliquer la directive européenne INSPIRE qui nécessite de mettre à disposition des métadonnées. Certains points sont spécifiques à la cartographie. Le mieux est de consulter une fiche.
  • Le format de métadonnées METS de la BNF
2 J'aime
#6

Le format choisi par la mission Etalab est JSON-LD, avec l’utilisation du vocabulaire standard CSVW (du W3C).

Les avantages de cette approche sont multiples :

  • Pour un CSV donné, l’accès à ses métadonnées est bien décrit dans la spec CSVW
  • le vocabulaire CSVW s’appuie sur des vocabulaires bien établies, tels que Dublin Core, DCAT et Schema.org.
  • JSON-LD, c’est du JSON, donc les développeurs peuvent l’exploiter facilement…
  • …mais c’est du JSON-LD avec ancrage dans le Web, où les propriétés comme les objets sont identifiés par une URI, selon les principes du Linked data.
#7

Vous pouvez voir des exemples sur le projet Github d’annotation des jeux de données de référence.