Skip to content

Publier des stats en RDF (1) : ébauche et errances

22/10/2012

Comme annoncer dans un précédent billet, je compte exploiter le cas des données PAPESR (statistiques sur les Universités) pour voir comment publier des données statistiques en RDF.

Pour commencer, je suis passé par le SCOVO (mentionné comme deprecated) pour arriver au RDF Data Cube Vocabulary.

J’y reviendrai, mais d’emblée j’ai dans l’idée que le graphe produit pourrait ressembler vaguement à ça :

Explications et remarques

  • En rouge, le « noeud » Université, qui sert de point de départ. Déjà dans PAPESR, les Universités ont un ID qui peut servir à les désigner (sauf que cet ID ne peut pas être exprimé sous forme d’URI déréférençable).
    Mais en réalité il faudrait ajouter un niveau supérieur « Jeu de données » (Data set) qui permettrait de relier les universités au même ensemble « Statistiques des universités françaises »
  • En bleu, des ressources exprimables par des URI.
    Typiquement, en indiquant « Autre ID », je pensais à l’identifiant DBPedia.
    Par exemple pour l’Université d’Amiens (id PAPESR : 707), associer http://fr.dbpedia.org/resource/Université_de_Picardie
    A quoi ça sert ? A exploiter ce que je peux trouver derrière la fiche DBPedia, par exemple des informations géolocalisées, donc un affichage de résultats de mes statistiques PAPESR sur une carte.
  • La classe« NbEtudiants » doit être définie quelque part. Donc si j’ai bien tout compris, il faut
    • soit que je rédige une ontologie qui définisse ce concept
    • soit que je trouve quelqu’un d’autre qui l’ait fait
    • soit que je dise : c’est une dimension, et elle a pour label « Nombre d’étudiants » (où la bulle « Label »)
      Mais justement, je ne suis pas sûr d’avoir tout compris
  • Les bulles blanches contiennent des littéraux : chaînes de caractères, nombres bruts
  • Les flèches :
    • en gras, celles qui correspondent à des propriétés standard de RDF
      Dire que « Université de Picardie Jules-Verne » (plutôt que « Amiens ») est le nom de l’ID PAPESR 707 pourrait se dire :
      papesr:707 rdfs:label "Université de Picardie Jules-Verne"
      De même, dire que l’ID 707 correspond à la ressource DBPedia ci-dessus s’écrirait :
      papesr:707 owl:sameAs http://fr.dbpedia.org/resource/Université_de_Picardie
    • En non gras (la flèche « a pour dimension »), une propriété dont je suis sûr qu’elle a déjà été définie, mais que j’ignore encore comment il faudrait l’exprimer

Ne prenez pas le schéma pour argent comptant : comme je le disais, je tâtonne et je n’ai pas lu le quart de ce que j’aurais dû lire pour me lancer là-dedans. Mais j’aime bien avancer en tâtonnant : il vous faudra aimer avancer dans le noir pour me suivre.

Ce qui me gêne, après avoir lu le début du RDF Data Cube Vocabulary (mais pas encore terminé, ni encore moins assimilé), c’est qu’avec le graphe ci-dessus je restitue surtout l’arborescence d’un fichier XML, qui suit en cascade le chemin : Universités françaises > Université N > Nb d’étudiants > XXX.

Or j’ai l’impression que le modèle proposé est centré, non sur l’établissement, mais sur la donnée elle-même. Après tout, pourquoi ne pas considérer que ce qui compte, c’est le nombre d’étudiants : l’Université n’est qu’une dimension de ce nombre (dimension géographique) de même que l’année est la dimension chronologique.

Donc si ça se trouve, j’ai tout fait à l’envers.

Au fait, pourquoi tout ce travail ?

La question devrait en fait plutôt être : j’ai un ensemble de statistiques sous la main, comment je les publie.

Là, je les ai déposées dans un tableur Google. J’aurais aussi bien pu proposer du CSV (Excel est propriétaire). Mais un fichier CSV n’est pas vraiment structuré : une machine ne peut rien en faire directement. Et donc je ne peux pas brancher un logiciel qui m’exploiterait directement ce CSV pour me permettre de naviguer dans ces données.

En outre, pour fournir une donnée, du genre :

Nombre d’étudiants
Université Lyon 2 28309

un tableau suffit. Mais quand on a 3 dimensions, c’est-à-dire les stats de 83 universités, pour 61 catégories d’informations, sur 5 années différentes, ça nous donne plutôt un cube :

D’où le Data Cube

Et je ne vais pas monter une base de données juste pour ça. D’ailleurs, elle existe, elle s’appelle PAPESR, et dans une base de données celles-ci sont fermées : c’est justement pour ça qu’on a inventé le linked data.

Second point, j’y ai fait allusion plus haut : avec la mise en graphe de ces données, je peux les lier à d’autres. Par exemple :

et quand des correspondances auront été établies entre les identifiants de ces différentes bases, naturellement.

Vous commencez à voir l’intérêt de la chose ?

%d blogueurs aiment cette page :