Based on indicators and monitoring dashboards for the observed phenomena, the decision support tools provide documents taking different forms (summaries, websites, fact sheets), easy to use by players in the field. To allow users to correctly interpret the synthesized information, description of the underlying data sets and processing is an undeniable contribution. We propose an innovative approach, which, in the context of the construction of dashboards designed around data warehouses, such as online atlas allows the establishment of a system integrating the generation, management and publication of metadata. We illustrate this point by the experience of an online atlas for the sustainable management of fisheries and the environment in Mauritania.
Copyright © by the paper’s authors. Copying permitted for private and academic purposes. Proceedings of the Spatial Analysis and GEOmatics conference, SAGEO 2015.
L’accès transparent à l’information constitue, à la fois, un défi persistant pour la
communauté des informaticiens, et une condition pour que, globalement, la science
soit pleinement reproductible
Le terme de métadonnées signifie « données sur les données ou données qui
renseignent sur certaines données et qui permettent ainsi leur utilisation pertinente »
Pour implémenter les métadonnées, deux approches coexistent. La première,
qu’on peut qualifier de méthode ad hoc, consiste à ce que le développeur définisse
avec le producteur des ressources des éléments de métadonnées propres à leurs
besoins, ceux qu’il juge importants pour mieux décrire les ressources qu’ils gèrent
ou plus simplement ceux pour lesquels ils disposent de l’information, et qui seront
utilisés pour générer les métadonnées. Cette méthode non standardisée est
généralement mise en oeuvre pour répondre à des besoins spécifiques : nous pouvons
citer par exemple le cas d’entrepôts de données dédiés à la pêche, comme
l’application StatBase
Dans ces contextes particuliers, les métadonnées restent accessibles uniquement au sein de l’application mère, ce qui pose le problème de leur exploitation par des agents logiciels externes et celui de leur interopérabilité avec d’autres applications.
La seconde approche consiste à utiliser des solutions de catalogage génériques et
standardisées. En effet, vu le caractère transversal des métadonnées et leur
importance pour faciliter l’accès à l’information, des groupes de travail ont proposé
des normes (W3C & RDF, Dublin Core / ISO 15836:2009, FGDC, ISO TC 2011,
etc.). Celles-ci définissent un cadre structuré et standardisé pour décrire les
ressources (données, informations, connaissances, traitements). Dans ce cas, deux
solutions se présentent :
1. les solutions qui se restreignent au catalogage, comme GeoNetwork
(http://geonetwork-opensource.org) et MdWeb (http://www.mdweb-project.org),
pour publier les métadonnées et en assurer l’accès indépendamment de leur
contexte de localisation et de gestion. Cette approche, si le catalogue est mal
intégré aux applications, peut présenter divers inconvénients : double saisie
(saisie dans l’application mère et saisie dans les plates formes externes) et défaut
de mise à jour (si les métadonnées sont indépendantes des données sources et
gérées dans des contextes séparés et différents).
2. les solutions qui permettent d'intégrer les métadonnées au sein d'une démarche
plus globale de gestion et diffusion de l'information spatiale, comme Geotoolkit
(www.geotoolkit.org), Geotools (www.geotools.org) ou d’autres API. Ces
solutions plus génériques permettent de décrire en RDF tous types de ressources
et de les rendre accessibles avec des SPARQL endpoint (par exemple l'API Java
JENA et le serveur Joseki)
Nous proposons de développer une solution normalisée, respectant les standards de génération de métadonnées directement au sein de l’application mère et du coup assurant l’interopérabilité avec les agents logiciels qui voudront venir moissonner les métadonnées, les acquérir ou les partager. Après cette introduction, nous étayons, en section 2, la problématique de recherche. En section 3, nous présentons un aperçu historique des travaux portants sur le catalogage et un panorama des outils de catalogage existants. Notre proposition est présentée en section 4 et les conclusions et perspectives sont données en section 5.
Le service de catalogage, dans les approches non modulaires de conception des systèmes d’information est perçu au mieux2 comme une fonction externe. Ce qui fait 1 Improve Scientific and Technical Advice for Management 2 trés souvent ce service est omis et rajouté au système a posteriori.
Copyright © by the paper’s authors. Copying permitted for private and academic purposes. Proceedings of the Spatial Analysis and GEOmatics conference, SAGEO 2015. que les concepteurs n’accordent pas suffisamment de temps à son développement et s’adossent généralement à des solutions ad hoc ou génériques mais sans lien direct entre les métadonnées et les ressources qu'elles décrivent. Cette approche a le mérite de simplifier la vie des développeurs en leur permettant de passer outre le développement d’un nouvel outil, qui peut être remplacé par un équivalent existant et testé. Elle permet également de gagner du temps et économiser les ressources (matérielles et humaines).
Cependant, cette approche présente certains inconvénients sur les plans technique et fonctionnel. Sur le plan technique, les choix opérés par un développeur peuvent souvent s’avérer différents de ceux utilisés dans le cadre des solutions génériques qui sont souvent plus lourdes à prendre en main. Ce qui peut compromettre la compatibilité et l’interopérabilité entre celles-ci et l’application mère. Sur le plan fonctionnel, les solutions génériques essayent généralement de couvrir les fonctionnalités jugées essentielles et du coup, on ne trouve pas forcément certaines fonctions « métier » qu’on aimerait utiliser, dans des cas particuliers d'implémentation liés à des thématiques particulières. Créer des métadonnées est bien pris en compte mais automatiser une partie de la saisie des contenus de celles-ci reste en général complexe. Il est toutefois possible de profiler les standards (schémas XML) et d'adapter les codes sources des applications qui les implémentent. On peut ainsi hériter d'un noyau d'éléments de métadonnées et de fonctionnalités communes sur la base duquel on peut s'adapter au contexte métier en ajoutant des éléments plus spécifiques.
Développant une application dénommée « atlas en ligne », dédiée à la mise en oeuvre d’indicateurs et de tableaux de bord relatifs à des ressources halieutiques, nous sommes confrontés à la gestion de métadonnées directement au sein de cet observatoire « virtuel » qui repose sur un entrepôt de données issues de sources réparties et hétérogènes. Les extractions de données contenues dans cet entrepôt servent de paramètres d'entrée aux traitements qui produisent les indicateurs du tableau de bord. Le verrou essentiel est donc de produire de manière la plus automatisée possible les métadonnées pour faciliter la découverte et l’accès des ressources par divers utilisateurs et diverses applications.
Les premiers catalogues de métadonnées informatisés remontent aux années 70 où, ils trouvent leur origine dans les tables d’allocation de fichiers maintenues par les systèmes d’exploitation et qui, sauvegardant le nom logique du fichier et son adresse physique sur disque (métadonnées), permettaient de localiser les fichiers et d’y accéder ultérieurement.
Pour le Web, on peut distinguer deux grands types de catalogues qui sont les annuaires et les catalogues basés sur les normes descriptives.
Dans le contexte du Web, les premiers outils et travaux utilisant les métadonnées, ont été les annuaires (Yahoo) et les moteurs de recherche (AltaVista, Google, Inktomi, Northern Light). Initialement, les premiers annuaires accessibles sur Internet demandaient au gestionnaire de l’annuaire de définir les métadonnées qui restaient à l’état de mots-clés, voire de description textuelle plus ou moins structurée et conforme à des modèles propriétaires. Remarquons que l’ère des services Web a aussi introduit de nouveaux types d’annuaires (UDDI Universal Description Discovery and Integration), mais celui-ci aussi demande une opération de publication du service concerné, c’est-à-dire une description de ce que l’on peut considérer comme des métadonnées conformes au modèle de données propre et défini par l’UDDI (Cf. Figure 1).
Figure 1 : Modèle général pour une architecture web service, exemple de combinaison (SOAP+WSDL+UDDI), utilisés dans le cadre de l’atlas géomatique (Beibou et al., 2014)
Une deuxième étape est franchie dans le contexte du catalogage et s’appuie sur
l’adoption des normes descriptives standardisées définies par divers organismes ou
groupes de travail qui ont analysé et répondu aux besoins métiers de différentes
communautés d'utilisateurs : Dublin Core
Indépendamment de leurs différences, l’objectif de ces normes est de structurer et de donner un sens aux éléments de métadonnées ainsi qu'à leurs valeurs pour permettre ainsi une interopérabilité syntaxique et sémantique. Il s’agit d’uniformiser la manière d’effectuer la description/indexation des ressources et par voie de conséquence d’améliorer les échanges et le partage a posteriori en dehors du contexte de production. De manière générale, les normes proposent un guide de structuration des métadonnées nécessaires à la description d’une ressource. Les métadonnées sont présentées sous forme d’éléments (sections ou rubriques) lesquels peuvent, selon leur sémantique, être regroupés en catégories. Par exemple, la norme Dublin Core, dans sa version la plus légère, propose 15 éléments de description relatifs au contenu d’une ressource classifiés en trois catégories concernant : • • •
Le contenu de la ressource : titre, sujet ou codes de classement, description, source, langue, lien vers une autre ressource, couverture spatiale et temporelle. La propriété intellectuelle : créateur, éditeur, collaborateur, droits d’utilisation. La matérialisation de la ressource : cycle de vie, type, format, identificateur.
Ce noyau d'éléments génériques peut être appliqué à n'importe quelle ressource et se retrouve donc dans les normes métiers qui le complètent par des éléments plus spécifiques au domaine d'application. Par exemple, la norme ISO19115/19139 dédiée aux métadonnées pour l’information géographique, tout comme le standard FGDC, complète la proposition du Dublin Core pour prendre en compte les spécificités des ressources concernées dans des packages de métadonnées plus spécifiques : système de référence spatial, étendue spatiale et temporelle de la ressource, modalités de distribution (résolution, mode raster ou vecteur...).
La norme ISO 19115 incite explicitement à produire des métadonnées de qualité (mise à jour et traçabilité / généalogie / historique) et révèle plusieurs problèmes d'adaptation au contexte d'implémentation qui sont :
• la connexion avec la sémantique du domaine concerné, comment aider le producteur de métadonnée à décrire la thématique de la ressource. Pour éviter les difficultés d’interprétation des valeurs saisies pour renseigner ces divers éléments, les guides associés aux normes recommandent l’utilisation de formats prédéfinis. Ces formats relèvent de notations, contraintes ou de structures plus ou moins élaborées comme les Code Listes ou autres vocabulaires contrôlés (pour les mots clés en particulier). En effet, une recherche de ressource sera d’autant plus pertinente et complète pour l’utilisateur s’il s’appuie sur des vocabulaires contrôlés (des glossaires voire des thésaurus ou des ontologies).
• l’extensibilité. De nombreux travaux actuels tendent à définir, au-delà du guide préconisé, des ensembles personnalisés d’éléments de métadonnées (il s’agit de définir des sous-ensembles judicieux d’éléments regroupés en ce que l’on dénomme « profils »). Cette démarche est adoptée au niveau européen dans le cadre de la directive INSPIRE Infrastructure for Spatial Information in Europe pour profiler la norme ISO 19115 (http://www.ec-gis.org/inspire/) et l'adapter aux besoins des états membres et de l'UE.
Au-delà du choix des normes, le producteur de métadonnées doit décider de la forme qu’il souhaite donner à son catalogue. Les métadonnées peuvent être directement décrites et intégrées dans la ressource (par exemple dans un fichier de séquence génomique ou dans un fichier netCDF, où métadonnée et donnée sont regroupées), ou elles peuvent être dissociées des ressources et simplement les référencer depuis un système extérieur. La frontière reste souvent complexe à définir. Dans le cas où métadonnées et ressources sont disjointes la localisation de la ressource devient plus rapide (indexation) et assure, de plus, un niveau de protection exigé par les communautés scientifiques. Mais on court alors le risque, d’une part, de dissocier les cycles de vie de la ressource et de ses métadonnées (problème de maintenance des mises à jour) et, d’autre part, de complexifier l’accès direct à la ressource elle-même. Si les métadonnées et les ressources décrites sont entreposées dans un système de gestion de base de données, le service de catalogage bénéficie alors de la puissance d’interrogation du SGBD sous-jacent. Cette solution est retenue par de nombreux services de catalogage constituant l’ossature essentielle de portails dédiés.
Nous allons analyser les outils de catalogage existant en considérant les normes
utilisées, l’architecture (web ou stand-alone), la couverture de la sémantique,
l’utilisation d’interface cartographique, les licences associées, l’architecture de
stockage, l’interopérabilité. Dans notre analyse, nous serons guidées par la nature
spatiale des données à traiter, tout en tenant compte du besoin de normalisation
(standards ISO TC 211 produits par l’OGC, notamment le CSW : OGC Catalog
services for the web). Les principaux standards pour les Web Services de l'OGC sont
répertoriés et détaillés dans
Dans le monde open source, le service de catalogage est aujourd’hui souvent basé sur différentes solutions comme GeoNetwork (http://geonetworkopensource.org/) et MdWeb (http://www.mdweb-project.org/). Ces outils sont performants et largement utilisés dans les domaines de l’agriculture, au sens large du terme, et de l’environnement. Ils sont des catalogues de métadonnées liées à des ressources à composantes géographiques qui permettent la recherche et l'accès aux catalogues géospatiaux locaux ou distribués. Ils permettent de télécharger non seulement les données spatiales mais tout type de données et disposent d’interfaces web interactives pour dialoguer avec les services CSW de serveurs distribués.
Après l’étude de ces outils, et au regard de précédentes expériences (prototype ISTAM) nous avons vérifié que les fonctions d’interrogation des métadonnées (la partie cliente) souhaitée pour notre application sont prises en charge par ces outils et permettent de proposer des front-end faciles à mettre en place et accessibles sur le Web.
En réponse à la problématique présentée dans la section 2, nous proposons une démarche modulaire intégrant la question des métadonnées et considérant le catalogage comme composant ou service accessible au sein de l’application mère, mais moissonnable à partir d’agents externes.
Notre proposition consiste donc, à concevoir un système d’information pour assurer un accès transparent aux données, issues de sources diverses, hétérogènes et distribuées, aux traitements et aux indicateurs produits à partir des ces données et qui alimentent un tableau de bord pour la gestion durable des pêches et la préservation de l’environnement. Ce système est basé sur différents composants incluant des services pour i) la recherche dans un catalogue de métadonnées, ii) l’accès aux données iii) la construction des indicateurs du tableaux de bord, et iv) l’interaction entre acteurs et utilisateurs dudit tableau de bord. Nous présentons dans ce qui suit le schéma conceptuel d’un tel système.
Figure 2 : Modèle conceptuel du Système SICP
Selon ce modèle, plusieurs modules rentrent en jeux (Catalogage, Extraction,
Traitement & Indicateur, Commentaire). Le module qui nous intéresse est celui du
catalogage (ici, 1). Celui-ci, permet d’effectuer la recherche et la localisation de
l’information pertinente en prenant en compte les différents niveaux de granularité
(indicateur ou fiche thématique composée de plusieurs indicateurs et de leur
analyse). En effet, l’atlas produit des fiches thématiques composées de différentes
ressources : des indicateurs (résultats de traitements appliqués à des jeux de
données) et des commentaires d’experts
Les entrepôts de données sont devenus incontournables pour intégrer des sources
d’informations hétérogènes et permettre le traitement analytique en ligne
Etant donné qu’un entrepôt de données reflète le modèle de l’organisation, un
élément essentiel d'une architecture de stockage est la gestion des métadonnées
Par contre, suivant notre conception (figure 2), nous proposons d’en faire un module indépendant mais intégré au système et, du coup, notre entrepôt prend en charge la production, la génération, la gestion et la publication au sein d’un serveur dédié, des métadonnées associées aux sources de données, traitements, indicateurs et commentaires associés à ces différents éléments.
Copyright © by the paper’s authors. Copying permitted for private and academic purposes. Proceedings of the Spatial Analysis and GEOmatics conference, SAGEO 2015. Figure 3 : Architecture générale d'entrepôt de données d'après (Surajit and
D’une part, l’atlas en ligne génère automatiquement un certain nombre de
métadonnées sur les indicateurs au fur et à mesure que ces derniers sont créés et
intégrés
Pour l’opérationnalisation du moissonnage, le service web qui nous intéresse est
le CS-W, parce qu’il permet la publication de catalogues de métadonnées (relatives
à des données, des traitements ou des services) exploitables par des clients extérieurs
au système pour rechercher parmi les entrées de catalogues
Copyright © by the paper’s authors. Copying permitted for private and academic purposes. Proceedings of the Spatial Analysis and GEOmatics conference, SAGEO 2015.
Pour l’implémentation de ce service au sein de l’atlas, notre choix s’est arrêté sur
PyCSW (www.pycsw.org ), basé sur Python et qui correspond à une bibliothèque sur
laquelle on peut s'appuyer pour exécuter des opérations de recherche, de production,
de visualisation et d’interrogation de métadonnées
- Interopérabilité et normalisation. PyCSW est une implantation du serveur OGC CSW en Python, qui met en oeuvre la clause 10 (liaison protocole HTTP, Catalogue Services pour le Web, CSW) de la spécification d'implémentation OpenGIS catalogue de services, la version 2.0.2.
- Possibilité d’intégration du service à l’atlas en ligne. PyCSW permet de publier des métadonnées soit à partir de son propre modèle intégré de métadonnées, ou à travers la configuration d’une liaison à un modèle existant de métadonnées.
- Indépendance par rapport aux plateformes systèmes. PyCSW est Open Source, publié sous licence MIT, et fonctionne sur toutes les grandes plates-formes (Windows, Linux, Mac OS X).
- Compatibilité des environnements de développement. En effet, PyCSW fonctionne grâce à une simple table Postgres et l’Atlas est lui-même développé sur ce SGBD. Cette table peut alors être intégrée directement à l’atlas et alimentée par ses métadonnées.
Dans l’atlas en ligne, les métadonnées sont présentes à différents endroits (Cf. Figure 4) :
Au sein des fiches XML qui permettent la génération des fiches de synthèses et qui contiennent un ensemble de sous éléments (indicateurs, expertises) Au sein de la table de description des entrées thématiques où, sont stockées des informations transversales, valables pour toutes les fiches de la même thématique.
Au sein de la table de description des bases de données ressources utilisées pour créer les indicateurs.
La proposition que nous avons mise en place consiste à créer pour les 3 types (Source, Fiche et Indicateurs) des métadonnées (correspondant à un profil ISO 19115), générées à partir des 3 types d’information décrits ci-dessus (grâce au composant 1 Catalog (moteur de catalogage) de la figure 2 qui les extrait des sources et les sauvegarde dans la table RECORD utilisée par PyCSW (Cf. Figure 4 et 5). Par la suite PyCSW permet à n’importe quel client (et ici à Geonetwork) de publier ces métadonnées.
Copyright © by the paper’s authors. Copying permitted for private and academic purposes. Proceedings of the Spatial Analysis and GEOmatics conference, SAGEO 2015.
Les résultats obtenus sont donnés dans la figure 5 qui suit. Copyright © by the paper’s authors. Copying permitted for private and academic purposes. Proceedings of the Spatial Analysis and GEOmatics conference, SAGEO 2015.
L’atlas en ligne tel que nous le proposons apporte, nous le pensons, une réponse à la problématique soulevée qui consiste à mieux documenter les indicateurs des observatoires pour en faciliter l'interprétation par les acteurs des domaines, de l’environnement et de l'halieutique dans notre cas. Le fait que les métadonnées soient globalement générées par le composant Catalog de l’atlas en coopération avec le client catalogue Geonetwork permet de gérer les problèmes récurrents de mise à jour des métadonnées. En effet, si le producteur d’une source alimentant l’entrepôt, modifie les métadonnées de celle-ci, l’atlas donnera pour les indicateurs et les fiches, des métadonnées actualisées. Le service web CSW quant à lui permet le moissonnage par d’autres applications (autres moteurs de catalogage, clients ou serveurs CSW).
Restent encore cependant quelques problèmes : la mise à jour des métadonnées se fait en continu ce qui ne permet pas de vérifier l’historique des mises à jour, pour cela il faudrait avoir recours à des liens de filiation (Généalogie ou Lineage dans 19115). D’autre part, l’approche privilégie le calcul au stockage ce qui évidemment entraîne une surcharge du fonctionnement de l’atlas (notamment lorsqu’il est accédé par de multi utilisateurs) mais nous sommes dans l’éternel dilemme temps/espace. Il faut aussi considérer les problèmes posés par le calcul d'indicateurs complexes qui nécessitent idéalement d'exécuter directement les codes dans les langages de programmation utilisés par les chercheurs (R, Python, Java..). Cela pousse à l'intégration de composants dédiés aux traitements de données, idéalement en Web Service tel que le standard WPS (Web Processing Service) proposé par l'OGC. Ce standard implémenté par différentes applications Open Source comporte un modèle utile à la description des traitements et à la gestion des codes sources. Ainsi l'approche que nous proposons pour notre système gagnerait à implémenter ce standard pour fournir des métadonnées plus riches et des informations plus transparentes et totalement reproductibles.