Compléments CKAN – GeoSource

Quelques messages reçus après mon précédent post présentant le portail OpenSource CKAN m’amènent à vous proposer quelques compléments d’explications sur les différences entre CKAN et GeoSource. J’ai en effet expliqué qu’on pouvait moissonner un catalogue GeoSource avec CKAN, ce qui a incité certains à se demander, à juste titre, si on pouvait remplacer GeoSource par CKAN.

Premièrement, pourquoi vouloir remplacer GeoSource ? On lui reproche d’être complexe, difficile d’accès et  fastidieux à utiliser. Mais il faut bien faire la part des choses. GeoSource permet de générer des métadonnées construites à partir de modèles XML et de valider la saisie réalisée selon les règles de contrôles inhérentes à chacun des modèles. Ce n’est donc pas GeoSource, dans son utilisation pour INSPIRE par exemple, qui est complexe, mais bien le modèle sous-jacent servant au renseignement de la métadonnée. Pour peu que vous construisiez un modèle XML ultre-simple uniquement composé d’un titre et d’une description, vous aurez une interface de saisie de votre fiche avec ces deux seuls champs à renseigner. Dans le contexte INSPIRE, c’est donc bien le modèle iso-19139 et les règles INSPIRE associées qui rend particulièrement difficile l’exercice de saisie de métadonnées.

Contrairement à GeoSource, CKAN n’utilise pas de modèle XML pour structurer ses métadonnées. Il y a un petit modèle interne constitué de quelques champs (titre, résumé, licence, date, format), qui peut être étendu librement par l’utilisation de simples paires clés-valeurs (par ex. : bbox, ou contact quand on injecte de la métadonnée INSPIRE). Mais la saisie reste totalement incontrôlée et générique, c’est-à-dire que pour y intégrer manuellement une fiche INSPIRE il va falloir nommer chacun des champs complémentaires au modèle de base et y indiquer la valeur appropriée. Lors de l’enregistrement, aucune vérification de validité ou de cohérence ne sera effectuée. Le module spatial qui permet de moissonner des catalogue CSW se contente ainsi de récupérer des fiches distantes, d’y retrouver les informations nécessaires pour CKAN (titre, résumé, licence, date, format) puis de générer les champs complémentaires. Certains de ces champs sont exploités par le module spatial pour réaliser des opérations spécifiques : le champ « spatial » doit ainsi contenir la bbox de la métadonnée (au format JSON, ce qui n’en fait par un modèle de simplicité à renseigner au clavier), et en sa présence, le widget « spatial-extent » s’active et affiche l’extent de la fiche sur une carte. Ce module reste donc très spécifique et n’est pas en mesure de traiter toutes les subtilités pouvant se rencontrer.

Deuxièmement, le profil des utilisateurs finaux, ceux qui vont faire des recherches dans le catalogue, est très différent. Pour un catalogue de métadonnées INSPIRE, on peut partir du principe que la personne réalisant la recherche connaît le domaine de l’information géographique et va être à même de construire une requête pertinente, éventuellement en utilisant des options de recherche avancées (type de représentation spatiale, échelle…). Disons surtout que les éléments du formulaires de recherche permettant de décrire précisément le type de donnée recherché DOIT être présent, car potentiellement utilisable par un grand nombre d’utilisateurs. Pour un catalogue CKAN, l’utilisateur lambda est n’importe qui et peut être amené à cherche n’importe quoi. Donc si des options de recherche POURRAIENT être présentes, ce n’est pas indispensable. Au contraire, des aides à la recherche, sous forme de tags cliquables et de recherche à facette, sont nécessaires. Ces dernières fonctionnalités sont récemment apparues dans GeoSource, illustrant bien que le périmètre utilisateur est en train de s’élargir.

Le même distinguo technicité/simplicité est également valide pour ce qui touche aux performances. Disposant d’un modèle de base restreint et unique, CKAN fait des recherches extrêmement rapides, puisqu’il s’agit de requêtes sur un contenu clé/valeur indexé. De même, l’affichage des fiches est rapide, puisqu’il ne s’agit que de templating HTML alimenté directement par le contenu de la base de données. Geosource a dans ce domaine des performances généralement moindre, mais dues au fait que la métadonnée est stockée dans la base au format XML (la fiche est intégralement stockée dans un champ unique) dont le rendu passe par un mécanisme de transformation XSLT. Mécanisme sans doute plus coûteux qu’un simple templating, mais extensible à volonté et permettant de différencier le rendu HTML selon le type de fiche de métadonnée et leur contenu.

In fine, le propos de cet article vise à faire la part des choses. D’un côté il y a un outil professionnel, capable d’ingérer des modèles complexes et d’en respecter les règles de composition, et dont la complexité apparente n’est jamais que l’expression de celle des modèles utilisées et de la réalité qu’ils décrivent. D’un autre, un outil ouvert à tous, générique et polyvalent, conçu pour répondre à des besoins très divers et donc faisant fi de la complexité associée à certains contenus, capable d’intégrer de l’iso-19139 grâce à un module conçu dans ce but, mais malgré tout incapable d’en conceptualiser le contenu. Reste qu’il peut tout à fait convenir à la publication de métadonnées INSPIRE à destination d’un public plus large et moins spécialiste que celui auquel GeoSource est cantonné par l’âpreté de l’ISO-19139, et qu’en cela il constitue une excellente passerelle entre la complexité de la donnée géographique et le nouveau monde de l’OpenData.

2 commentaires :

  1. Publié le 19 mai 2013, 17:41 par Jean-Roc

    Je pense pas que défendre l’utilisation de geosource/geonetwork en justifiant l’aridité et la lourdeur de son interface de saisie par son aspect normatif et professionel soit le meilleur arguement. Une appli pro dév. par des pros pour être utilisée par des pros peut aussi être agréable à utiliser, cf. isogeo et leur interface.

    • Publié le 20 mai 2013, 7:58 par Guillaume

      Bonjour,
      Si vous avez bien lu l’article, j’attribue l’aridité et la lourdeur à la norme ISO-19139 et non à GeoSource. Même avec ISOGEO, dont l’interface est assez proche de celle de CKAN, la saisie d’une fiche de métadonnées INSPIRE reste un travail un peu rébarbatif.

Publier un nouveau commentaire