#data.gouv.fr

ZDnet a publié ce jour une interview au sujet de l'architecture technique de la première plateforme d'open data de l'Etat, data.gouv.fr

Hébergement et infrastructure matérielle

Chez Atos, l'hébergement du portail data.gouv.fr (au budget de 2 millions d'euros) est mutualisé avec service-public.fr et legifrance.gouv.fr, les deux principaux sites de l’Etat en termes d’audience, édités par la DILA (Direction de l'information légale et administrative).

« Dès la création de la mission, nous avons choisi de travailler en collaboration avec la DILA que ce soit au niveau hébergement ou applicatif avec eZ Publish, Exalead et Mondeca. Cela permet,de manière générale, d’harmoniser les outils que nous déployons et donc de rationaliser les coûts, mais aussi de monter en compétences et de capitaliser au niveau du développement et de la maintenance » déclare le directeur technique d’Etalab, Charles Ruelle.

Très classiquement, le portail comprend trois environnements (qualification, pré-production et production), intégralement redondés, et une répartition sur deux datacenters distincts. Un  site de backup a été prévu et permet le téléchargement des jeux de données les plus demandés. Les différentes briques applicatives du site sont exécutées depuis une dizaine de serveurs virtuels en production (VMWare ESX).

Montée en charge et cache

La problématique de la montée en charge est gérée notamment grâce au recours à la virtualisation, qui permet en cas de pic de trafic, d’ajouter de nouveaux serveurs. La montée en charge a été anticipée au lancement afin de garantir la disponibilité du site lors de la mise en ligne et la capacité du back-office producteurs à accueillir un grand nombre d’utilisateurs (800 à 1000, contre 200 actuellement).

« C’est tout l’intérêt d’une architecture à base de machines virtuelles qui permet de s’adapter aux pics de trafic. Par ailleurs, l’architecture est très NoSQL en frontal. Par rapport au CMS, le fait de faire des modules d’extension qui ne s’appuient pas sur des modèles génériques de stockage mais plutôt des approches traditionnelles SGBD permet d’avoir un meilleur temps de réponse du CMS et plus globalement du système » détaille Jean-Christophe Renou, spécialiste de l’ECM chez Logica, prestataire technique de data.gouv.fr.

Pour le cache, Etalab a prévu une architecture asymétrique entre la contribution en « mode CMS » et une publication en cache avec pré-génération d’un certain nombre de pages (référencées par le moteur de recherche).  

CMS : eZ Publish

Le choix d’un socle CMS eZ Publish est dicté par une volonté de mutualisation avec la DILA.

« Tous les aspects transactionnels sont construits au-dessus du CMF - Content Management Framework – et toutes les interactions comme le forum sont le plus souvent des extensions greffées à l’intérieur d’eZ Publish […] Les contributions peuvent rapidement devenir nombreuses et afin de maintenir de bonnes performances, nous avons créé pour cela des extensions spécifiques » précise Jean-Christophe Renou.

Back-office producteurs et description des jeux de données

Pour publier leurs jeux de données, les administrations disposent de leur propre outil de publication, accessible en mode Web.

« On retrouve les concepts d’un CMS. Nous avons créé un modèle d’organisation générique à l’ensemble des producteurs de données, et souple, à travers lequel il est possible de définir les workflows. Les fonctions d’administration sont elles déportées vers les coordinateurs » décrit le responsable de Logica.

La description des jeux de données est gérée quant à elle par l’intermédiaire de l’outil de gestion de base de connaissances sémantiques de la société Mondeca. « Chaque descriptif d’un jeu de données est harmonisé avec des thésaurus […] Cela permet déjà d’apporter une première étape de qualification harmonisée au niveau de l’Etat » commente Charles Ruelle.

Plate-forme d’échange de données

Chacun des 200 contributeurs de la plateforme peut recenser, qualifier et diffuser des données publiques depuis son interface. 

La publication automatisée des jeux de données sur data.gouv.fr s’effectue quant à elle grâce à une plate-forme d’échanges (des échanges FTP sécurisés). Celle-ci supporte les flux automatiques entre les bases de données des SI de l’Etat et la plate-forme.

« Nous avons tiré des liens permanents entre les bases de données des administrations et Etalab pour que la mise à jour de centaine de milliers de jeux de données puisse se faire dans un souci de productivité » détaille Jean-Christophe Renou.

« Nous envisageons un mode en pull basé sur le moissonnage. Nous avons mis en place un prototype avec une syntaxe XML/RDF avec l’Insee et le MEDETEL [Ndlr : ministère de l’écologie]. Pour nous c’est un enjeu extrêmement fort puisque cela permet de mettre à disposition toujours plus de données, mieux qualifiées et mieux mises à jour et d’industrialiser cette étape de diffusion » ajoute Charles Ruelle.

Moteur de recherche : Exalead

Le moteur interne du portail est basé sur la technologie d’Exalead - propriété désormais de Dassault Systèmes. La démarche itérative est également appliquée au moteur afin donc d’améliorer la pertinence des résultats et de proposer de nouvelles fonctionnalités de recherche.

(Sorry, in french)

Un modèle de catalogue créé sur mesure à partir de l’état de l’art :

Ce modèle a été initié en 2011, lors de la création de la plateforme data.gouv.fr, en prenant en compte l’état de l’art du marché, les retours d’expériences et les outils disponibles. Il s’est enrichi au fur et à mesure pour assurer la couverture de l’ensemble des besoins identifiés et faciliter le référencement et la réutilisation des données.

Les grands principes qui ont dirigé la conception du catalogue des données publiques de la plate-forme data.gouv.fr (DGFR), sont :

Faciliter la réutilisation des données :

Maximiser la documentation associée aux jeux de données : en permettant la description selon des vocabulaires contrôlés, complétée par des descriptions aux formats libres.

Maximiser l’efficacité de la recherche des jeux de données dans le catalogue :  

Adoption d’une normalisation de la description des jeux de données ;

Sémantisation forte de l’indexation : structuration fine, sélection de vocabulaires riches ;

Optimiser le rapprochement des jeux de données au travers de leur description : normalisation des vocabulaires ;

Conception en vue de modes de potentiels recherche alternatifs, par exemple : une recherche historique par producteur,  

S’inscrire dans une démarche de long terme :  

Adopter des référentiels et vocabulaires pérennes et internationaux.

Adopter l’état de l’art des technologies relatives au Linked Open Data : utilisation de technologies sémantiques de gestion de connaissances, adoption d’url permanentes « URI » pour la publication des jeux de données, déréférencement des « URI » pour atteindre une page descriptive du jeu de données au format HTML ou RDF;

Le déploiement de flux automatisés de publication des données a également été un facteur déterminant dans l’approche de la conception du catalogue. Ainsi le modèle a été conçu de manière a minimiser à la fois le délai et les coûts de mise a disposition des données tout en maximisant la finesse de description des jeux de données (descriptions contrôlées complétées par des descriptions libres). 

L’architecture de la plateforme data.gouv.fr a été conçue sur une approche orientée services, pour être fortement évolutive, dans les principes du modèle d’architecture technique Open Data tel que le présentait le projet européen HOMER en Février 2013 (http://www.homerproject.eu/)

L’architecture intégralement basée sur les technologies RDF, tant en interne que pour les interfaces d’échange.

Plusieurs modes de recherches sont déjà proposés et on vocation a être enrichis.

Source : www.homerproject.eu  

Conformité aux standards DCAT

Le modèle DCat du W3C (http://www.w3.org/TR/vocab-dcat/) a été initié à l’occasion du lancement des plateformes nationales et territoriales d’open data, dont data.gouv.fr. DCAT est un vocabulaire RDF construit pour faciliter l’interopérabilité entre les catalogues de données publiés sur le web. Ce modèle est issu notamment des travaux et des retours d’expériences de la modélisation du catalogue de données publiques de la plateforme data.gouv.fr.

Le profil d’implémentation de DCAT pour les portails européens (https://joinup.ec.europa.eu/asset/dcat_application_profile/home ) qui a été mené par la Commission Européenne a également bénéficié des retours d’expériences de la plateforme française

Le modèle qui en résulte n’est pas strictement aligné techniquement sur le modèle DCat mais l’essentiel des concepts apparaissent sous une forme ou une autre dans le modèle résultant. Ainsi, le catalogue pourrait à l’avenir être publié au format DCat.

  Espaces de nommage

Le  namespace pour le vocabulaire du catalogue de la plate-forme www.data.gouv.fr est http://www.data.gouv.fr/ressource/dgfr#. Il convient de considérer que l’ontologie du catalogue DGFR fait usage de plusieurs vocabulaires publics :

PrefixNamespacedcathttp://www.w3.org/TR/vocab-dcat/ dctermshttp://dublincore.org/documents/dcmi-terms/ dchttp://purl.org/dc/elements/1.1/contributorfoafhttp://xmlns.com/foaf/0.1/

  Un choix de référentiel d’indexation optimisé pour le contexte de l’open data national :

Ainsi la conception du catalogue s’est accompagnée du choix de plusieurs référentiels d’indexation structurant les capacités d’indexation et de recherche de la plate-forme.

Ces référentiels sont :

Le référentiel des producteurs de l’administration : Ce référentiel catalogue l’ensemble des entités de l’administration française, leur organisation hiérarchique en organigramme, y compris les relations de tutelle existant entre certaines entités juridiques (EPA, EPIC…etc.) et l’administration centrale. Ce référentiel est mis a jour au fil de l’eau des réorganisations au sein de l’administration. L’historique de l’organisation des producteurs au fil du temps est conservé au sein du référentiel.

A ce référentiel permettant d’identifier sans ambiguité la source des données publiées soit l’entité au sein de l’administration ayant publié l’information, s’ajoutent deux autres référentiels permettant de décrire les facettes spatiales et temporelles des jeux de données. Il s’agit : 

Du thesaurus multilingue de l’Union Européenne « EUROVOC » http://eurovoc.europa.eu/: EuroVoc est un thésaurus multidisciplinaire couvrant la terminologie des domaines d'activité de l'Union européenne, avec un accent sur l'activité parlementaire. EuroVoc est disponible dans 22 langues officielles de l'Union européenne. Il est utilisé entre autres par le Parlement européen, l'Office des publications, des parlements nationaux et régionaux en Europe, ainsi que par des administrations nationales et des utilisateurs privés des États membres et non membres de l'Union européenne. La pertinence de choix de ce référentiel  repose sur plusieurs critères : sa vocation qui lui assure une bonne adéquation pour la description thématique des jeux de données produits par l’administration française, notamment l’administration centrale, sa pérennité et son actualité garantie par l'Office des publications qui en assure la maintenance et enfin par la forte interopérabilité sémantique qu’il assure de par son caractère multilingue, sa vocation européenne et sa compatibilité avec les technologie du web sémantique.

Du Code Officiel Géographique de l’INSEE « COG » http://insee.fr/fr/methodes/nomenclatures/cog/ : Le COG est depuis soixante ans « le » code géographique de référence, au plan administratif comme au plan statistique. La reconnaissance explicite de son caractère officiel n’est toutefois intervenue que tout récemment, par la grâce d’un arrêté ministériel en date du 28 novembre 2003. La pertinence de ce choix de référentiel repose donc sur plusieurs critères : sa vocation et son caractère officiel à l’échelon national, sa pérennité et son actualité garantie par l’INSEE qui en assure la maintenance et enfin par la forte interopérabilité sémantique qu’il assure avec la nomenclature européenne des unités territoriales statistiques (NUTS) http://europa.eu/legislation_summaries/regional_policy/management/g24218_fr.htm dont les niveaux 1 et 2 correspondent respectivement à nos ZEAT et à nos régions et sa compatibilité avec les technologie du web sémantique.

Un choix de référentiel d’indexation assurant une forte interopérabilité sémantique : A noter que ces trois principaux référentiels d’indexation, font eux-mêmes l’objet d’une gestion ontologique et s’appuie donc tout comme le modèle de métadonnées du catalogue DGFR les technologies du web sémantique, conformément aux recommandations du W3C et aux dernières tendances en ce qui concerne les normes relatives aux thésaurus.

Descriptions détaillées

Vous pouvez naviguer dans le modèle du catalogue data.gouv.fr à l'aide des liens dans la colonne de droite.

A l’instar du vocabulaire DCAT, le modèle de description du catalogue DGFR définit trois classes principales:

dgfr:Catalog représente le catalogue

dgfr:Dataset représente un dataset dans le catalogue

dgfr:Distribution représente un moyen d'accès aux données d'un dataset

Au sein du vocabulaire DCat l’usage du concept de CatalogRecord est considéré come optionnel. De fait, le vocabulaire du catalogue DGFR n’en fait pas usage. A contrario plusieurs métadonnées complémentaires ont été ajoutées à la classe DataSet elle-même, permettant de tracer certaines informations telles que le status de publication, la date de création, la date de mise a jour…etc.