Tous les articles par Léon Robichaud

À la recherche de données SIGH canadiennes

Avancement du projet, Outils SIGH en ligne

Depuis plusieurs années, des quantités appréciables de données géohistoriques ont été créées par les chercheurs qui s’intéressent au Canada. Alors que l’on réfléchit à la création d’une infrastructure géohistorique nationale, il est pertinent d’identifier les jeux de données à différentes échelles qui pourront nourrir un tel portail. La démarche actuelle vise donc à faire connaître les jeux de données existants et disponibles. Si, à terme, il serait préférable d’énumérer et de décrire chaque couche et chaque table de données attributaires, il n’est pas nécessaire, en ce moment, d’aller à un niveau de granularité aussi fin. Nous espérons plutôt, à cette étape, identifier les collections découlant de différents projets de recherches ou de mise en ligne des données numériques déjà géoréférencées comme celles-ci :

  • cartes géographiques matricielles
  • photographies aériennes
  • couches vectorielles
  • données attributaires liées à des couches vectorielles

Nous avons déjà identifié une série de données offertes par différents types de créateurs, question de présenter une diversité dans la nature et les types de données qui peuvent intéresser les chercheurs. Ainsi, on y retrouve :

  • des données internationales de qualité (FAO)
  • des données issues de projets de cartographie collaborative (Open Street Map, Natural Earth)
  • des données disponibles sur les sites d’entreprises en SIG (ESRI)
  • des données nationales (gouvernement du Canada, Géogratis)
  • des données provinciales ou territoriales (Colombie-Britannique, Yukon, Québec, Nouvelle-Écosse, Île-du-Prince-Édouard, Nouveau-Brunswick)
  • des données municipales (Toronto, Montréal, Sherbrooke)
  • des données d’équipes de recherche (CIEQ, NICHE, LHPM, MAP, VIHistory)
  • des données de cartothèques et de centres d’archives (Scholars’ Geoportal, MADGIC, GéoIndex+)
  • des données d’initiatives personnelles (lignes de chemins de fer historiques)

Le choix des métadonnées à associer à chaque jeu de données nous amène à faire des compromis. Un niveau de détail insuffisant ne permettrait pas de faire des recherches efficaces alors qu’un niveau de détail trop grand pourrait décourager les créatrices et les créateurs de données qui ne sont pas formés pour créer des métadonnées qui répondent aux standards internationaux. Selon Rodolphe Devillers, six caractéristiques sont nécessaires pour définir la qualité d’un jeu de données géospatiales1.

i. Définition : Permet d’évaluer si la nature exacte d’une donnée et de l’objet qu’elle décrit, c.à.d. le « quoi », correspond aux besoins (définitions sémantique, spatiale et temporelle);

ii. Couverture : Permet d’évaluer si le territoire et la période pour lesquels la donnée existe, c.à.d. le « où » et le « quand », correspondent aux besoins ;

iii. Généalogie : Permet de connaître d’où provient une donnée, ses objectifs d’acquisition, les méthodes utilisées pour l’obtenir, c.à.d. le « comment » et le « pourquoi », et de voir si cela correspond aux besoins;

iv. Précision : Permet d’évaluer ce que vaut une donnée et si elle est acceptable pour le besoin exprimé (précision sémantique, temporelle et spatiale de l’objet et ses attributs);

v. Légitimité : Permet d’évaluer la reconnaissance officielle et la portée légale d’une donnée et si elles rencontrent les besoins (standards de facto, respect de normes reconnues, reconnaissance légale ou administrative par un organisme officiel, garantie légale par un fournisseur, etc.);

vi. Accessibilité : Permet d’évaluer la facilité avec laquelle l’usager peut obtenir la donnée analysée (coût, délai, format, confidentialité, respect des normes reconnues, droits d’auteur, etc.).

Un standard de métadonnées permettant de répondre à tous ces critères risquerait de rebuter plusieurs personnes qui souhaiteraient rendre leurs données accessibles. Nous proposons donc d’utiliser le format prescrit par le Dublin Core Metadata Initiative, un standard international dont les types de champs sont plus compréhensibles pour les personnes moins familières avec les métadonnées. Nous appliquons et interprétons le DCMI en nous inspirant de la définition générale disponible sur Wikipédia2 et des interprétations de certains champs proposés par la Bibliothèque nationale de France3. L’approche utilisée peut certainement être critiquée, car elle vise une application simple plutôt que la perfection. À la lumière de leur utilisation dans cette liste, nous pourrons évaluer comment revoir ces principes afin d’en arriver au meilleur compromis possible. Les champs n’apparaissent pas dans l’ordre prescrit par le DCMI et certains sont subdivisés afin d’apporter certaines précisions et d’en arriver à un niveau de granularité un peu plus fin.

Tableau 1. Liste des champs utilisés pour décrire les jeux de données

Élément Élément (anglais) Commentaire
Créateur Creator L’entité principalement responsable de la création du contenu de la ressource. Il s’agit du nom d’une ou de plusieurs personnes, d’une organisation ou d’un service.
Format : Nom, Prénom.
Séparer par des points-virgules les multiples entités.

Optionnel
Contributeur Contributor Entité responsable de contributions au contenu de la ressource.
Les exemples de contributeur comprennent une ou plusieurs personnes, une organisation ou un service.
Format : Nom, Prénom.
Séparer par des points-virgules les multiples entités.

Optionnel
Titre Title Nom donné à la ressource.
Le titre est généralement le nom formel sous lequel la ressource est connue.
Utiliser le titre tel qu’indiqué dans la langue d’origine de la ressource.
Si la ressource ne porte pas de titre formel et que le titre inscrit est dérivé du contenu, inscrire le titre entre crochets.

Obligatoire
Description.Générale Description.General Une présentation du contenu de la ressource.
Les exemples de description comprennent, notamment un exposé du contenu en texte libre.
Privilégier la description prévue par les créatrices ou les créateurs de la ressource.

Optionnel
Description.Nature-du-projet Description.Project-type Un mot-clé qui permet de classer les projets selon la typologie suivante :

– gouvernementale
– ONG
– universitaire
– individuelle
– commerciale
– collaborative

Obligatoire
Description.Méthodologie Description.Methodology Un texte suivi décrivant la démarche suivie pour créer la ressource. Optionnel
Description.Sources Description.Sources Énumération des documents qui ont servi à créer la ressource. Ce champ est distinct du champ Source, lequel sert à identifier l’endroit où on peut se procurer la ressource. Optionnel
Description.Champs Description.Fields Liste des champs utilisés dans le tableau ou la base de données, si possible avec description.

Optionnel
Date.Publication Date.Published Date de la création initiale de la ressource. Il ne s’agit pas nécessairement de la date représentée par la ressource.

Obligatoire
Date.Mise-à-jour Date.Updated Date d’un événement de mise à jour dans le cycle de vie de la ressource.

Optionnel
Couverture.Temps Coverage.Time Périmètre ou domaine d’application du contenu de la ressource, dans ce cas-ci, la date, l’année ou la période représentée par la ressource.

Obligatoire
Couverture.Espace Coverage.Space Périmètre ou domaine d’application du contenu de la ressource, dans ce cas-ci le territoire. intervalle de temps) ou une autorité (comme le nom d’une entité administrative). Il est recommandé de sélectionner une valeur dans un vocabulaire contrôlé.

Obligatoire
Couverture.Niveau Coverage.Level Un mot-clé qui permet d’identifier le niveau de couverture spatiale de la ressource :

– international
– national
– provincial
– régional
– municipal
– local

Obligatoire
Sujet.ISO Subject.ISO Un mot-clé permettant d’associer la ressource à une des catégories de classement ISO des données géospatiales.

– agriculture / farming
– biota / biota
– limites administratives / boundaries
– climatologie / climatology
– économie / economy
– élévation / elevation
– environnement / environment
– information géoscientifique / geoscientific information
– santé / health
– imagerie / imagery
– intelligence / intelligence (militaire)
– eaux intérieures / inland waters
– localisation / location
– océans / oceans
– urbanisme / planning
– société / society
– structure / structure
– transport / transportation
– services publics / utilities

Voir : https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Topic_Categories

Obligatoire
Sujet Sujet Un ou des mot-clés permettant de classer la ressource. Optionnel
Format Format La manifestation (ou matérialisation) physique ou numérique de la ressource. Type MIME du document :

– shp
– kml
– kmz
– zip
– csv
– autres formats de données utilisés en SIG

Obligatoire.
Langue Language La langue du contenu intellectuel de la ressource.
Il est recommandé d’utiliser une des valeurs définies dans la RFC 3066 [RFC3066] qui, avec la norme ISO 639 [ISO639], définit des codes de langues primaires à deux, ainsi que des sous-codes facultatifs.
Exemples :- en
– fr

Obligatoire
Type de ressource Type Genre de contenu.
Par défaut, les ressources identifiées dans le cadre de ce projet font partie du type dataset (jeu de données).

Obligatoire
Droits.Licence Rights.License Identification brève du type de licence qui s’applique aux données :

– copyright
– CC (ou une ses variantes)
– domaine public
– ouverte

Obligatoire
Droits.Accessibilité Rights.Access Un des termes suivants permettant d’identifier la nature de l’accès aux données.

– gratuit
– payant
– abonnement gratuit
– abonnement payant

Obligatoire
Droits.Conditions d’utilisation Rights.Terms of use Texte copié et collé du site même pour préciser les conditions d’utilisation prescrites par l’équipe de création. Optionnel
Source Source Emplacement à partir duquel on peut obtenir la ressource. La source sera généralement un URL.
Un champ Source.URI pourra être ajouté si cela s’avère pertinent.

Obligatoire
Relation Relation Lien avec d’autres ressources. Une ressource peut être dérivée d’une autre ou être associée à une autre dans le cadre d’un projet.
Exemples : isPartOf [numéro de l’autre ressource]
isChildOf [numéro de l’autre ressource]
isDerivedFrom [numéro de l’autre ressource]

Optionnel
Éditeur Publisher Nom de la personne, de l’organisation ou du service à l’origine de la publication du document.

Optionnel
Commentaire Comment Tout information complémentaire qui permet de mieux comprendre la ressource.

Optionnel

Une liste de ressources déjà identifiées est disponible ici : http://bit.ly/2rlIkRC.
Certaines notices sont incomplètes et nous travaillerons à les compléter. Si vous désirez proposer un jeu de données, vous pourrez le faire en remplissant le formulaire suivant disponible ici : http://geohist.ca/donnees-sigh-hgis-data-form

1  DEVILLERS, Rodolphe (2004). « Conception d’un système multidimensionnel d’information sur la qualité des données géospatiales », [En ligne], Ph. D., Université Laval <http://theses.ulaval.ca/archimede/fichiers/22242/22242.html>.

2  Collaborateurs de Wikipédia (2016). « Dublin Core » <https://fr.wikipedia.org/wiki/Dublin_Core#Liste_des_.C3.A9l.C3.A9ments_et_raffinements>.

3  Bibliothèque nationale de France, Direction des Services et des Réseaux, Département de l’Information bibliographique et numérique (2008). « Guide d’utilisation du Dublin Core (DC) à la BnF : Dublin Core simple et Dublin Core qualifié, avec indications pour utiliser le profil d’application de TEL », version 2.0 <http://www.bnf.fr/documents/guide_dublin_core_bnf_2008.pdf>.

Comment retrouver et relier toute cette information géohistorique?

Outils SIGH en ligne, Projets SIGH

Le volume de données géohistoriques disponible sur le web et entreposé dans différentes bases de données augmente rapidement alors que le tournant géospatial prend de l’ampleur et que les outils de cartographie en ligne devienne plus accessibles. Les cartes historiques peuvent être localisées avec un bounding box ou géoréférencées avec précision. Les photographies aériennes sont assemblées et géoréférencées pour permettre l’analyse d’une région ou la localisation d’une planche particulière. Les cartes statiques, interactives ou animées sont de plus en plus utilisées pour visualiser des phénomènes qui ont eu un impact sur l’histoire à différentes échelles : locale (Don Valley Historical Mapping Project), régionale (Carte de l’impact de la peste noire sur l’Angleterre médiévale), nationale (American Panorama. An Atlas of United States History), continentale (Mapping the Republic of Letters), trans-atlantique (The Trans-Atlantic Slave Trade Database) ou mondiale (Time-Lapse Map of Every Nuclear Explosion, 1945-1998).

Face à ces masses de données, les chercheurs ne tente pas seulement de trouver une aiguille dans une botte de foin. Ils doivent retrouver plusieurs aiguilles réparties à travers plusieurs bottes de foin. Plusieurs initiatives ont été lancées, incluant par cette équipe, pour développer des solutions qui amélioreraient l’accessibilité aux données géohistoriques. Les portails sont généralement perçus comme une solution qui permet de rassembler les données relatives à un lieu ou aux intérêts d’un groupe ou d’une institution. Consciemment ou non, ces portails sont aussi conçus pour mettre en valeur le travail d’une groupe ou d’une institution. Nous aurons besoin de portails comme infrastructure permettant d’héberger et de distribuer les données géospatiales. Mais ils ne peuvent pas, seuls, résoudre les problèmes de découverte de données, d’ouverture et d’interopérabilité.

Selon les compétences des développeurs en optimisation du portail pour les moteurs de recherche, un portail sera plus ou moins facile à retrouver sur le web. L’usager aboutira généralement sur la page d’accueil du portail de devra ensuite utiliser les outils spécifiques au portail pour retrouver le ou les items pertinents pour sa recherche. Certains systèmes, tels que GeoIndex+, associent la recherche par facettes à une vue cartographique pour faciliter la découverte de données. D’autres s’en remettent encore à des outils de recherche découlant d’anciens catalogues.

Que les données souhaitées puissent être retracées ou non, elles ne seront peut-être pas disponible pour le téléchargement. Hormis les enjeux de licences commerciales, plusieurs chercheurs sont encore réticents à rendre leurs données disponibles pour téléchargement, un enjeu pour un autre billet. Les différents paliers de gouvernement rendent graduellement leurs données disponibles gratuitement, mais il est encore possible qu’un chercheur finisse par numériser et géoréférencer des données qui existent déjà en ce format. L’utilisation d’un format de fichier incompatible avec le logiciel préféré du chercheur devient alors un inconvénient mineur.

Même lorsque les développeurs d’un portail ont les meilleurs intentions pour rendre les données disponibles et téléchargeables, le manque d’interopérabilité des systèmes rend les recherches trans-portail difficiles à moins d’ouvrir des API ou de rendre les données disponibles dans un format ouvert et lié. Bien que les API pourraient résoudre les problèmes immédiats, il resterait à résoudre des problèmes à plus long terme de sécurité, d’entretien et de renouvellement des systèmes. Je mettrai donc l’accent sur les données ouvertes et liées en tant que solution à long terme pour ce problème.

Les données liées, ou le web des données « est une initiative du W3C (Consortium World Wide Web) visant à favoriser la publication de données structurées sur le Web, non pas sous la forme de silos de données isolés les uns des autres, mais en les reliant entre elles pour constituer un réseau global d’informations. Il s’appuie sur les standards du Web, tels que HTTP et URI – mais plutôt qu’utiliser ces standards uniquement pour faciliter la navigation par les êtres humains, le Web des données les étend pour partager l’information également entre machines. Cela permet d’interroger automatiquement les données, quels que soient leurs lieux de stockage, et sans avoir à les dupliquer. » [Source] Ce standard du W3C est à la base du web sémantique tel que défini par Tim Berners-Lee.

Les données liées reposent sur le Resource Description Framework (RDF), lequel utilise une grammaire sujet → prédicat → objet pour définir des déclarations à propos des ressources. Ces triplets, qui peuvent aussi être conçus comme des structure entité → attribut → valeur (le document X → est une → carte) peuvent être lus par les machines et utilisent des Uniform Resource Identifiers (URIs) pour relier les différents éléments. Les données liées sont déjà utilisées pour rendre l’information disponible et connectée dans des projets tels que DBpedia.

Les structures de données présentées en tant que déclarations rdf sont définies par des ontologies. Le Spatial Data on the Web Working Group a été mis sur pied par le W3C afin de

  • to determine how spatial information can best be integrated with other data on the Web;
  • to determine how machines and people can discover that different facts in different datasets relate to the same place, especially when ‘place’ is expressed in different ways and at different levels of granularity;
  • to identify and assess existing methods and tools and then create a set of best practices for their use;
    where desirable, to complete the standardization of informal technologies already in widespread use.
    [SDWWG Mission Statement]

Une telle initiative offrira les outils et l’infrastructure à partir de laquelle nous pourront rendre les données géohistoriques découvrables et accessibles.

Malheureusement, les données liées et ouvertes ne sont pas simple à mettre sur pied. Des ontologies concurrentes pourraient émerger, ce qui limiterait l’interopérabilité à moins de définir des équivalences. Certaines institutions insisteront pour définir leurs propres URIs, pour les toponymes par exemple, sans les reliées à d’autres listes d’autorité, recréant ainsi les silos que nous souhaitons éviter. Plusieurs parties prenantes devront ouvrir et offrir leurs données de recherche en triplets rdf pour que le web de données géohistoriques puisse émerger, comme c’est déjà le cas avec DBpedia, Geonames et le World Factbook. Conçu comme une infrastructure, les données ouvertes et liées n’ont pas un très grand effet « wow » qui apporterait de la visibilité et des investissements. Un projet pilote avec une vitrine sophistiquée sera nécessaire pour que les gens comprennent le potentiel des données ouvertes et liées et investissent les ressources nécessaires pour publier les données géohistoriques en triplets rdf.

Certains enjeux devront être résolus, dont l’approbation d’une ontologie standard ou d’un ensemble d’ontologies compatibles. Le SDWWG met de l’avant la compatibilité avec les ontologies supérieures plutôt que la dépendance sur une approche particulière des données liées. [SDWWG Best Practices Statement]. Nous devons aussi nous attendre à ce que différentes équipes publient leurs données à divers niveaux de granularité. Certains fourniront au minimum les métadonnées qui permettront d’indiquer qu’un jeu de données comprend de l’information sociale et économique à propos de Montréal en 1825 alors qu’un autre pourrait publier chaque donnée individuelle des maisonnées. Si on se penche sur les enjeux de la carrière des chercheurs, comment ce type de publication sera-t-il reconnu pour l’embauche, la promotion ou l’obtention de subventions? Le Collaborative for Historical Information and Analysis  a étudié les pratiques des dépôts de données qui pourraient être utiles alors que nous avançons vers les données ouvertes et liées. Enfin, comment signalerons-nous des données qui sont peu recommandables pour la recherche académique? Nous aurons à définir un mécanisme d’évaluation par les pairs pour un monde de données ouvertes et liées.

En ce moment, les questions sont plus nombreuses que les réponses, mais les données ouvertes et liées offrent une solution à long terme pour la découverte et l’accès. Une telle solution devrait être intégrée dans la conception de portails à l’avenir.

Pour aller plus loin, le SDWWG énumère quelques publications et présentations sur le sujet. L’ouvrage de Catherine Dolbear et Glen Hart, Linked Data: A Geographic Perspective (CRC Press, 2013) offre aussi une approche pour l’utilisation des données liées dans une perspective géographique. Toute recherche sur les données liées ou le web sémantique donnera aussi plusieurs résultats de lectures utiles pour se lancer dans l’aventure. Pour les historiens, le mémoire de maîtrise de Philippe Michon, « Vers une nouvelle architecture de l’information historique : L’impact du Web sémantique sur l’organisation du Répertoire du patrimoine culturel du Québec », est fortement recommandé.

Léon Robichaud
Professeur agrégé
Département d’histoire
Université de Sherbrooke