Archives de l’auteur : Jean-Baptiste Pressac

Mémento de requêtes SQL pour Omeka Classic

Omeka Classic, la plateforme de publication de collection numérisées, repose sur le logiciel de base de données relationnelle MySQL (ou sa version entièrement GPL, MariaDB). Aussi, des connaissances de base en SQL et des droits d’accès à cette base de données vous permettront d’obtenir des informations sur les documents déposées sur votre bibliothèque numérique que l’interface d’administration de Omeka ne pourra vous fournir. Par exemple, afficher le nombre de fichiers associés aux documents des collections ou trouver des documents en doublons.

Ce document constitue un mémento de requêtes SQL utilisées pour interroger la bibliothèque numérique du Centre de recherche bretonne et celtique dont vous pouvez vous inspirer pour interroger votre instance de Omeka. Il présuppose une connaissance des concepts de Omeka (fichiers, contenus ou items, collections) et des connaissances de base en SQL1.

Si vous êtes intéressé par la même démarche avec Omeka S, vous pouvez consulter l’article de Pierre Couchet : Quelques requêtes MySql avec Omeka S. Continuer la lecture

  1. Pour une introduction au SQL, voir Des fichiers Excel au SQL, introduction aux bases de données relationnelles et Administrez vos bases de données avec MySQL []

Découverte de CRBC Dataset (1)

Depuis le 16 avril 2020, une sélection de données produites sous la direction de chercheurs du Centre de recherche bretonne et celtique (CRBC) sont mises à la disposition de tous sur la nouvelle plateforme de données, CRBC Dataset.

Au 26 mai 2020, deux jeux de données sont disponibles selon la Licence Ouverte version 2.0 d’Etalab : Une première extraction d’une base de données des forçats du bagne de Brest et la base de données PRELIB (Projet de recherche en littérature de langue bretonne).

Découvrons dans ce premier billet le jeu de données des registres du bagne de Brest.

Les 988 premiers forçats arrivés au bagne de Brest, en mai 1749

La base de données des forçats du bagne de Brest est un projet de l’historien Philippe Jarnoux1. Elle est constituée à partir des registres conservés à la Division Nord-Ouest du Service historique de la Défense2.

Cette première mise en ligne de la base sur CRBC Dataset concerne les 988 forçats arrivés à l’ouverture du bagne, en mai 1749. Les données suivantes (actuellement sous la forme d’un fichier Microsoft Excel) seront mises en ligne progressivement. En attendant, vous pouvez consulter l’intégralité des registres de matricules des bagnards emprisonnés au bagne de Brest de son ouverture en 1749 à sa fermeture en 1858 sur la bibliothèque numérique du CRBC3.

Que contient ce jeu de données ?

Au 26 mai 2020, donc, le jeu de données des bagnards est un tableau de 95 colonnes et 988 lignes dans lequel chaque ligne correspond à une entrée du registre 2 O 7, comme indiqué dans la colonne “Registre”.

Par exemple, la toute première ligne correspond au matricule de Jean Gatté, que l’on peut trouver dans les premières pages du registre 2 O 7.

Enregistrement de Jean Gatté au bagne de Brest

Matricule du bagnard Jean Gatté dans le registre 2 O 7 du bagne de Brest

Un bagnard ayant pu s’évader puis être repris, il pourra apparaitre plusieurs fois dans le jeu de données complet (de 1749 à la fermeture du bagne en 1858).

Les informations saisies ont été commentées colonne par colonne par Philippe Jarnoux. Vous y trouvez par exemple la raison pour laquelle les numéros de matricules attribués à chaque condamné à son arrivée ne se suivent pas forcément ou pourquoi un bagnard a pu avoir plusieurs  numéros de matricules durant son séjour au bagne.

Pour les informations recodées, telles que la situation familiale, le code a été explicité (c = célibataire, m = marié , v = veuf).

Rechercher un bagnard par son nom

Le formulaire “Search” affiché au dessus du tableau permet de rechercher les bagnards par leur nom ou celui de leurs parents. Par exemple, la recherche sur “pierre audié” ou “Pierre Audié” ou “audie” affiche la ligne correspondant à Pierre Audié, n° de matricule 340, condamné à vie pour désertion le 3 aout 1723.

Recherche de Pierre Audié

Recherche de Pierre Audié

Filtres multicritères, les forgerons ayant commis des vols

Sous le moteur de recherche par nom de bagnards, un formulaire permet de filtrer les colonnes selon le critère de votre choix.

Par exemple pour trouver les forçats ayant exercé le métier de forgeron condamnés pour vol, vous pouvez chercher la chaine de caractère “forge” dans la colonne “Métier” et “vol” dans la colonne “crime”.

On obtient trois forçats : Pierre Guinet (originaire de Barjac), François Matthieu (originaire de Fréjus) et Antoine Salarvrier (originaire de Aumignac).

Les forgerons ayant commis des vols

Les forgerons ayant commis des vols

Le critère utilisé est “contains” au lieu de “=” auquel cas, vous n’obtiendrez que les lignes pour lesquelles la valeur saisie correspond exactement au critère. Or le mot “vol” est contenu dans des mentions telles que “les cas résultant du procès et suivant le rôle du Procureur Général pour vol” pour Antoine Salarvrier. De même si nous avions lancé une recherche selon le critère “= forgeron” au lieu de ” contains forge”, nous n’aurions pas trouvé François Matthieu dont le métier a été saisi dans le registre comme “maréchal à forge”.

Les critères supérieur >, inférieur <, supérieur ou égal à ⩾, inférieur ou égal à ⩽ permettent de filtrer les données numériques. Par exemple le filtre “> 1789” appliqué à la colonne “année_mort” permet l’affichage des bagnards décédés après la Révolution.

Bagnards décédés après la Révolution

Bagnards décédés après la Révolution

Les lieux

La plateforme permet d’afficher des cartes si le jeu de données contient des latitudes et des longitudes4 mais les noms des communes d’origine ou de résidence des bagnards étant parfois difficiles à identifier, cette information ne figure pas dans les données.

Portraits robots

L’appareil photographique n’existant pas encore, les registres contiennent des informations sur  des signes distinctifs permettant de dresser le portrait-robot du bagnard en cas d’évasion, en particulier dans les colonnes “cicatrice”, “lieu_cicatrice” et “signes_particuliers” : cicatrices, couleur des sourcils, des cheveux, de la barbe, tâches de rousseur, verrues, infirmités…

Trier le contenu des colonnes

Pour trier le contenu des colonnes, cliquez sur leur titre.

Explorer, trier les données des colonnes avec les facettes

Pour visualiser toutes les informations saisies dans une colonne et leurs nombres d’occurrences, vous pouvez utiliser les facettes dont vous trouverez des suggestions au dessus des titres de colonnes.

Les suggestions de facettes

Les suggestions de facettes

Si vous cliquez par exemple sur la facette Prénom_2, la liste de tous les deuxièmes prénoms et de leur nombre d’occurrences est affichée.

Facette de la colonne Prénom_2

Facette de la colonne Prénom_2

Ce qui permet de constater que sur les 988 bagnards arrivés en mai 1749, 32 ont pour deuxième prénom “François”. Cliquer sur le prénom, affiche toutes les lignes correspondantes du tableau.

Les facettes sont cumulables. En cliquant sur la facette “situation-famille”, puis sur le prénom François, vous obtenez parmi les 32 personnes ayant pour deuxième prénom François : 16 célibataires, 8 mariés et 8 pour lesquels l’information ne figure pas dans le registre.

Facette de la situation familiale des individus ayant pour deuxième prénom "François"

Facette de la situation familiale des individus ayant pour deuxième prénom “François”

Étant donné que le tableau comprend 95 colonnes, les 95 facettes correspondantes ne sont pas suggérées. Mais vous pouvez modifier l’URL (l’adresse web) qui s’affiche dans la barre d’adresse de votre navigateur pour afficher une facette absente des suggestions.  Par exemple, pour afficher la facette de la colonne “signes_particuliers”, il faut modifier l’URL comme suit : http://crbc-dataset.huma-num.fr/bagnards/matricules?_facet=signes_particuliers. Pour rajouter une deuxième facette, il faut la séparer de la première par un & : http://crbc-dataset.huma-num.fr/bagnards/matricules?_facet=signes_particuliers&_facet=Emplacement_cicatrice.

Notez que ces paramètres d’URL, comme on les appelle, sont automatiquement renseignés lorsque vous modifiez l’affichage de la page en faisant une recherche, en cliquant sur une facette suggérée, en triant les colonnes, etc.

Les filtres et les facettes peuvent être cumulés. Afficher la facette de l’année de décès permet d’afficher les années de décès des bagnards décédés après la Révolution.

Années de décès des bagnards morts après la Révolution

Années de décès des bagnards morts après la Révolution

Graphiques

Sous les suggestions de facettes, le bouton “Show charting options” permet de choisir deux colonnes pour l’affichage d’un graphique. Vous avez le choix entre des diagrammes à barres (Bar), des lignes (Line) ou des nuages de points (Scatter).

Vos choix sont conservés dans nos fameux paramètres d’URL, ce qui vous permet de communiquer vos réglages à d’autres personnes. Par exemple en suivant ce lien vous pouvez consulter le nuage de points des prénoms en fonction du lieu d’origine.

Diagramme den barres des prénoms en fonction de la commune d'origine

Nuage de points des prénoms en fonction de la commune d’origine

Le bouton “Swap W and Y”, sous le choix “Y column”, permet d’inverser l’axe des abscisses avec celui des ordonnées.

“Color” permet de coloriser les barres, les lignes ou les points en fonction d’une colonne et “Size” d’afficher le diamètre des points d’un nuage de points en fonction d’une colonne contenant une valeur numérique. Ce qui permet, à titre d’exemple, de coloriser les points du graphique des prénoms avec le pays d’origine et d’afficher leur taille en fonction de l’âge du bagnard (voir le résultat sur CRBC Dataset).

Nuage de points des prénoms en fonction de la commune d'origine

Nuage de points des prénoms en fonction de la commune d’origine avec la couleur des points en fonction du pays d’origine et le diamètre des points en fonction de l’âge

La palette de couleurs étant limitée, il ne vaut mieux pas choisir une colonne avec un nombre élevé d’occurrences.

Pour enregistrer le graphique sous forme de fichier SVG (image vectorielle) ou PNG (image matricielle), déplacez votre souris en haut à droite du graphique pour faire apparaitre le menu correspondant.

Sauvegarder le graphique au format PNG ou SVG

Sauvegarder le graphique au format PNG ou SVG

Vous avez bien entendu la possibilité de représenter graphiquement le résultat d’un filtre multicritère ou d’une recherche.

Télécharger les données

Vous pouvez télécharger l’intégralité des données ou le résultat de vos filtrages ou de vos recherches en utilisant la fonction “This data as json, CSV” affiché au dessus des facettes.

Exporter les données

Exporter les données

Deux formats possibles : le CSV (comma-separated values), qui peut être exploité avec Microsoft Excel ou LibreOffice Calc ou le format JSON, qui conviendra plus à des informaticiens.

 

  1. https://www.univ-brest.fr/crbc/menu/Lab-members/Enseignants-chercheurs/Philippe_Jarnoux []
  2. Division Nord-Ouest du Service historique de la Défense – 4, rue du Commandant Malbert 29240 Brest []
  3. Les registres cotés de 2 O 1 à 2 O 39 ont été numérisés par la Division Nord-Ouest du Service historique de la Défense de 2015 à 2016 puis mis en ligne sur la bibliothèque numérique du CRBC. []
  4. L’affichage des cartes sera abordée dans un prochain billet sur le jeu de données du projet de recherche en littérature de langue bretonne []

Créer une carte avec Wikidata, OpenRefine et uMap

A l’occasion de la Méridienne du CRBC du 13 décembre 2018, une carte des communes de Bretagne liées aux cylindres phonographiques conservés au CRBC a été créée sur uMap.

Les données nécessaires à la carte ont été construites en alignant avec Wikidata les noms des communes saisies dans l’inventaire Excel de Blanca Pérez González, stagiaire à la bibliothèque Yves-Le-Gallo, puis en récupérant sur Wikidata leurs coordonnées géographiques. Pour cela nous avons utilisé le logiciel libre OpenRefine (version 3.1). Dans ce tutoriel, nous détaillons toutes les opérations à effectuer pour créer la carte à partir de l’inventaire. Nous avons délibérément utilisé une version de l’inventaire où subsistent quelques erreurs pour montrer les capacités de OpenRefine en matière de nettoyage des données.

Qu’est ce que Wikidata ?

Mais avant toute chose, qu’est ce que Wikidata ? Wikidata est un projet de base de connaissances libre lancé en 2012 par la Wikimedia Foundation, l’organisme qui héberge Wikipédia. Les informations saisies dans Wikidata sont des données “brutes”. C’est à dire que l’on y saisi non pas des phrases telle que “Quimperlé [kɛ̃pɛʁle] est une commune française, située dans le département du Finistère en région Bretagne. ”1 mais des déclarations ou statements.

On trouve par exemple sur la page Wikidata de la ville de Quimperlé, ou plus précisément sur la page de l’élément Wikidata correspondant à Quimperlé, les déclarations comme quoi Quimperlé est une “commune of France”, que sa population était de 11.978 habitants en 2013 et pour ce qui nous concerne aujourd’hui, que ses coordonnées géographiques sont 47°52’22″N, 3°32’59″W.

Si l’affichage de l’interface par défaut en anglais vous dérange, vous pouvez ouvrir une session sur Wikidata avec votre compte Wikipédia (en haut à droite, lien Log in) soit en créer un en déclarant le français comme langue par défaut.

Il existe plusieurs manières pour récupérer ces informations. L’une d’entre elle est le point d’accès SPARQL Wikidata Query Service (WQS) qui suppose d’avoir des notions élémentaires du langage SPARQL2. Mais WQS ne vous permettra pas de récupérer les coordonnées géographiques à partir de votre propre liste de noms de communes. Il faut un outil qui vous permettre de faire correspondre le nom d’une commune avec un élément Wikidata (“Quimperlé avec Q235382) puis d’interroger Wikidata pour récupérer la valeur de la propriété coordinate location de chaque élément. C’est exactement ce que permet le logiciel libre OpenRefine.

Le fichier Excel utilisé dans la suite de ce tutoriel nécessite un nettoyage préalable. Pour aller directement à l’étape de réconciliation des données, vous pouvez télécharger et importer le projet OpenRefine nettoyé, puis consultez le chapitre Réconciliation des données avec Wikidata.

Création d’un nouveau projet dans OpenRefine

Commençons par créer un nouveau projet dans OpenRefine à partir du fichier Excel Inventaire des cylindres phonographiques du CRBC de Blanca et la commande Create Project > This computer.

La colonne Dublin Core Spatial Coverage des noms des communes est dans la feuille Catalogue du fichier Excel où chaque ligne correspond à un cylindre (la deuxième feuille, Inventaire, contient la liste des contenus intellectuels : chansons, interprétations musicales). Dans les paramètres d’importation du fichier Excel, cochons la case correspondant à la feuille Catalogue et cochons la case permettant de considérer la première ligne comme contenant les titres des colonnes (Parse next 1 line(s) as column headers).

Préparation des données à réconcilier

Appliquons une facette textuelle sur la colonne Dublin Core Spatial Coverage (Depuis le menu de la colonne, commande Facet > Text facet).

La facette nous permet de constater qu’une des cellules du tableau contient deux noms de communes séparées par un point-virgule (Saint Avé et Morlaix).

Pour séparer ces deux communes sur deux lignes distinctes utilisons la commande Edit cells > Split multi-valued cells

… en précisant le point-virgule comme séparateur de valeur.

La facette est automatiquement mise à jour et on voit apparaitre de manière distincte Saint-Avé et Morlaix .

Par contre, petit problème, Saint-Avé (56206) apparait deux fois et Morlaix  (29151) apparait en premier dans la liste classée alphabétiquement. Le premier problème est dû au fait que Saint-Avé a été saisi une fois “Saint Avé” (sans tiret) et cinq fois “Saint-Avé” (avec un tiret). On corrige le problème en éditant directement le nom de la commune dans la facette.

Morlaix apparaît en début de liste car lors de l’étape de séparation de « Saint Avé (56206); Morlaix (29151) » sur deux lignes, nous aurions dû utiliser comme séparateur un point-virgule suivit d’un espace au lieu du point-virgule seul. Ce qui fait que nous avons laissé un espace avant “Morlaix (29151)”. Rien de bien grave. Nous pouvons supprimer l’espace en éditant la valeur dans la facette ou utiliser la commande Edit cells > Common transforms > Trim leading and trailling whitespace.

Dans cette colonne, Goelo correspond à une aire géographique et non pas à une commune. OpenRefine ne permet pas de supprimer des lignes mais cela n’a pas d’importance pour la suite des opérations.

Notez au passage que toutes les opérations que vous effectuez dans OpenRefine sont sauvegardées automatiquement. Vous pouvez également revenir aux étapes précédentes dans l’onglet Undo/Redo. Bon à savoir également : Le fichier Excel original reste intact puisque ses données ont été importées dans OpenRefine.

Le nom de la commune est suivit de son code commune entre parenthèses. Par exemple, Quiberon (56186). Nous pourrions lancer l’alignement avec Wikidata en utilisant les données telles quelles mais nous allons améliorer la réconciliation en répartissant ces deux informations dans des colonnes distinctes.

Une des manières de procéder est d’utiliser Edit column > Split into several columns en choisissant la parenthèse ouvrante précédée d’un espace comme séparateur.

On se retrouve avec une deuxième colonne Dublin Core Spatial Coverage 2 qui contient le code commune et la parenthèse fermante.

Pour supprimer la parenthèse fermante, on utilise la même commande que précédemment en choisissant cette fois la parenthèse fermante comme séparateur.

Réconciliation des données avec Wikidata

On lance la réconciliation avec Wikidata par la commande Reconcile > Start reconciliation sur la colonne Dublin Core Spatial Coverage 1 et on choisi la réconciliation avec Wikidata.

Le service de réconciliation devine que les données sont du type commune of France. Il aurait également été possible de préciser le type dans Reconcile against type. Pour renforcer la réconciliation, on précise que la colonne Dublin Core Spatial Coverage 2 contient des codes INSEE. Il suffit de commencer à taper “INSEE” pour afficher une liste de suggestions. On choisit INSEE municipality code.

Une fois la réconciliation terminée, deux nouvelles facettes sont affichées dont une qui permet d’afficher les lignes où l’alignement n’a pas pu se faire automatiquement.

Quand on clique sur none dans la facette,  les lignes correspondant à Landerneau et Goëlo s’affichent. Goëlo, comme nous l’avons vu n’est pas une commune mais un ancien pays de Bretagne. Nous n’allons donc pas l’afficher sur la carte. En ce qui concerne Landerneau (écrit Landernau dans l’inventaire), une lettre “e” a été omise mais cela n’aurait pas posé de problème au service de réconciliation de Wikidata si ce n’est que c’est le code postal qui a été saisi dans l’inventaire (29800) et non le code commune (29103).

Pour aligner à la main la commune avec Wikidata, on clique sur Search for match sous Landernau et dans le formulaire qui s’affiche on rajoute le e de Landerneau et on valide la commune proposée par Wikidata.

Pour récupérer les coordonnées géographiques de la commune, on commence par réinitialiser la facette de la réconciliation en cliquant sur reset.

On choisit ensuite depuis la colonne Dublin Core Spatial Coverage 1 la commande Edit Column > Add columns from reconcilied values.

On choisit dans le formulaire suivant la propriété Wikidata coordinate location.

Une fois la récupération des coordonnées géographiques terminée, on se retrouve avec une nouvelle colonne coordinate location contenant la latitude et la longitude de la commune séparées par une virgule. uMap a besoin de ces données séparément. On ventile la latitude et la longitude dans des colonnes distinctes avec la commande déjà utilisée Edit column > Split into several columns appliquée à la colonne coordinate location.

Préparation de l’export des données pour uMap

On se retrouve maintenant avec un tableau de données où l’on a bien une ligne par commune (après la séparation de Saint-Avé et Morlaix qui se trouvaient dans la même cellule), où les erreurs ont été corrigées (Saint-Avé orthographié de deux manières différentes, Landerneau écrit Landernau), où l’on a récupéré la latitude et la longitude des communes dans des colonnes séparées. Comment extraire de ce tableau uniquement les communes et les coordonnées spatiales, sans doublons ?

Pour supprimer les doublons, il faut commencer par les rassembler. Nous pourrions pour cela appliquer un tri alphabétique sur le nom des communes. Mais bien que cet inventaire soit exempt de communes portant le même nom, il vaut mieux trier les lignes par codes communes par la commande Sort….

Pour rendre le tri permanent, on va dans Sort > Reorder rows permanently.

Assurez-vous ensuite que vous êtes bien dans le mode d’affichage des lignes (rows) et non pas des entrées (records).

On vide ensuite les noms des communes consécutives en utilisant dans le menu de la colonne des noms de communes, la commande Edit cells > Blank down (Editer les cellules > Vider des valeurs répétées dans des cellules consécutives).

Toujours sur la colonne des noms des communes, on applique une facette par ligne vide : Facet > Customized facets > Facet by blank (null or empty string).

On clique ensuite sur false dans la facette pour n’afficher que les lignes non-vides.

On obtient un tableau où ne figure plus que la liste des communes sans doublons :

Subsistent néanmoins les lignes correspondant à Goëlo qui peuvent être masquées par une deuxième facette “by blank”. Mais étant donné qu’elles sont à la fin de la liste, nous les supprimerons une fois les données exportées.

Export des données pour uMap

Dans le menu Export en haut à droite, il faut choisir Custom tabular exporter.

Dans l’onglet Content, on ne coche que les trois colonnes contenant le nom des communes, les latitudes et les longitudes. Notez que Matched entity’s name permet d’exporter les noms des communes tel qu’il ont été saisi dans Wikidata et non pas tels que saisis dans l’inventaire.

Dans l’onglet Download, on sélectionne le format CSV et on clique sur Download.

Le fichier CSV doit contenir les lignes suivantes :

Dublin Core Spatial Coverage 1,coordinate location 1,coordinate location 2
Morlaix,48.5775,-3.8277777777778
Plonévez-du-Faou,48.252222222222,-3.8247222222222
Trégourez,48.106111111111,-3.8630555555556
Landerneau,48.450833333333,-4.2494444444444
Arzon,47.548055555556,-2.8913888888889
Belz,47.675833333333,-3.17
Melrand,47.980277777778,-3.1116666666667
Plumergat,47.741944444444,-2.9172222222222
Quiberon,47.483333333333,-3.1205555555556
Saint-Avé,47.686666666667,-2.7344444444444
Saint-Nolff,47.703611111111,-2.6516666666667
Sainte-Anne-d'Auray,47.703611111111,-2.9538888888889
Goëlo,,
Goëlo,,
Goëlo,,
Goëlo [Q3112879],,

On supprime à la main les dernières lignes concernant Goëlo. On renomme les titres des colonnes correspondant à la latitude (à renommer lat) et à la longitude (à renommer lon), faute de quoi l’import dans uMap ne fonctionnera pas. On renomme également la colonne des noms de communes en name. Ce qui donne :

name,lat,lon
Morlaix,48.5775,-3.8277777777778
Plonévez-du-Faou,48.252222222222,-3.8247222222222
Trégourez,48.106111111111,-3.8630555555556
Landerneau,48.450833333333,-4.2494444444444
Arzon,47.548055555556,-2.8913888888889
Belz,47.675833333333,-3.17
Melrand,47.980277777778,-3.1116666666667
Plumergat,47.741944444444,-2.9172222222222
Quiberon,47.483333333333,-3.1205555555556
Saint-Avé,47.686666666667,-2.7344444444444
Saint-Nolff,47.703611111111,-2.6516666666667
Sainte-Anne-d'Auray,47.703611111111,-2.9538888888889

Création de la carte avec uMap

uMap est un service de création de cartes personnalisées du projet OpenStreetMap, concurrent libre de Google Maps. Vous pouvez utiliser uMap sans vous créer de compte. Mais créer un compte vous permettra de gérer vos cartes plus facilement et vous évitera de perdre vos cartes.

Pour importer les données dans uMap, on clique sur le lien Créer une carte en haut à gauche de la page d’accueil de uMap. Puis on clique sur l’outil rond avec une flèche vers le haut dans la barre d’outils, à droite de la carte.

Je vous conseille d’importer les données dans un nouveau calque. Si uMap ne vous permet de cliquer sur le bouton Importer, c’est que vous n’avez pas renommé les colonnes des cordonnées géographies en lat et lon.

Les points correspondants aux communes apparait sur la carte. uMp appelle ces points des marqueurs.

Pour afficher les noms des communes et modifier l’aspect des marqueurs, vous pouvez éditer les propriétés du calque en cliquant sur l’icône en forme de cylindre (Gérer les calques) puis sur l’icône en forme de crayon à côté du nom du calque.

La forme des marqueurs se paramètre dans Propriété de la forme.et l’affichage des étiquettes dans Options d’interaction > Afficher une étiquette. Si vous avez bien renommé la colonne du nom des communes en name, avant d’importer le fichier CSV, vous devez voir apparaitre le nom des communes.

Pour partager votre carte ou l’intégrer dans une page web, utilisez le bouton Exporter et partager la carte dans la barre d’outils en haut à gauche de la carte.

Déposer les données absentes sur Wikidata

Dans le cas où les coordonnées spatiales de certaines communes étaient introuvables sur Wikidata (comme le soulève Brian Chauvel dans les commentaires), vous pouvez contribuer au projet en les saisissant directement sur Wikidata ou en utilisant la fonctionnalité de dépôt en masse de OpenRefine en partant de l’exemple du tutoriel Dépôt de données sur Wikidata avec OpenRefine des Ateliers du Web sémantique.

Pour en savoir plus sur OpenRefine

Pour en savoir plus sur OpenRefine, voir le cours et le TP de l’atelier OpenRefine de l’ANF « Sciences des données : un nouveau challenge pour les métiers liés aux bases de données » (5 au 7 novembre 2018, Sète). Ces documents sont inspirés de Nettoyer et préparer des données avec OpenRefine : atelier pour les journées du consortium MASA de Mathieu Saby. 

Pour les anglophiles, la documentation de OpenRefine, bien qu’un peu fouillis, reste la référence, notamment la page concernant la réconciliation des données.

Pour en savoir plus sur Wikidata

Pour en savoir plus sur Wikidata, lire les publications de Markus Krötzsch, un chercheur de l’Université de Dresde qui a contribué à la conception de Wikidata. Notamment la publication Denny Vrandečić, Markus Krötzsch. Wikidata: A Free Collaborative Knowledgebase. In Communications of the ACM 57:10, pp. 78–85. ACM 2014

  1. source : la page Wikipédia en français de Quimperlé []
  2. Lecture conseillée pour s’initier au langage SPARQL : Wikidata:SPARQL tutorial. []

La collection de cylindres phonographiques du CRBC

Les méridiennes du CRBC

Le CRBC organise régulièrement dans ses locaux des rencontres ouvertes à tous à l’heure de la pause déjeuner pour faire découvrir les projets menés par les membres du laboratoire et de la bibliothèque de recherche.

Ce jeudi 13 décembre 2018 entre 12h30 et 13h30, Blanca Pérez González, stagiaire au CRBC et étudiante en master à l’Université d’Estrémadure (Espagne) présente son travail d’inventaire et de documentation de la collection de 178 cylindres phonographiques conservée au CRBC ainsi que notre phonographe, en état de fonctionner.

La carte ci-dessous permet de visualiser les communes bretonnes où les cylindres ont été probablement été enregistrés.


Cylindre cote CRBC 75 : Comin’ thro’ the rye  by the 48th Highlanders Band (The Kilties), Edison Gold Moulded Record: 12879
Cylindre cote CRBC 68 : The campbells are coming by Pipe major H. Forsyth, Edison Gold Moulded Record: 13648, édité en 1907
Cylindre cote CRBC 23 : Cylindre de la Maison de la Bonne Presse, contenu inconnu
Cylindre cote CRBC 30 :  Cylindre de la Maison de la Bonne Presse, contenu inconnu

Sémantiser une base de données relationnelle (4e épisode) : Nettoyage d’été de la base de données des acteurs de la littérature en breton

La base de données prosopographique des acteurs de la littérature en langue bretonne (projet PRELIB) est renseignée depuis trois ans par des étudiants vacataires de la Faculté des lettres et sciences humaines de Brest. Après nous être attelés en début d’année à un travail de nettoyage des informations géographiques (villes, départements, pays) et d’alignement des lieux et des individus avec les référentiels Wikidata1 et IdRef2, le nettoyage des “professions” est le gros chantier en cours depuis le début de l’été. Ce nettoyage est l’occasion de revoir la structure de la base de données et de se poser des questions sur le sens des informations saisies.

Pour cette opération, nous ne passons pas en revue une à une toutes les fiches des individus mais nous avons exporté en bloc les données de table “profession” et les avons importées dans le logiciel de nettoyage de données OpenRefine3. C’est beaucoup plus simple pour avoir une vue d’ensemble des données.

Les informations sur les “professions” sont stockées dans une table dont la structure était la suivante :

Schéma de la table profession de la base de données PRELIB

Schéma simplifié de la table profession. Cette table est liée aux tables des personnes (seule table liée représentée ici), des villes, des départements, des pays et des aires géographiques. Seuls quelques champs de la table personne ont été représentés afin de ne pas alourdir le schéma.

La notion floue d’employeur

Je ne sais plus trop pourquoi nous n’avions pas choisi de saisir les “employeurs” dans une table séparée comme nous l’avions fait pour les villes ou les pays4. Et comme il fallait s’y attendre, les données saisies étaient très hétérogènes…

Le champ “employeur”, contenait des noms d’institutions5, des types d’institutions (clinique privée, collège privé), des noms d’individus (Charles Dullin, Alan Stivell, Louis Jouvet, Louis XIV). Certains étudiants avaient cru bon de saisir “église catholique”, “diocèse de Vannes”, comme employeur de certains prêtres ou “Ministère de l’éducation nationale” pour les enseignants alors que d’autres avaient précisé le nom de l’établissement (Lycée Chaptal, Petit séminaire de Ploërmel).

Outre le farfelu de certaines saisies (Louis XIV pour l’aumônier de la Dauphine, Napoléon III pour un consul), on se retrouvait dans de nombreux cas avec des employeurs différents pour le même type d’occupation. Un peu comme si les étudiants avaient cherché à remplir cette case avec ce qui leur avait semblé être l’employeur et non pas avec des informations trouvées dans les sources (Cela dit, je doute que Napoléon III rémunérait ses consuls sur ses propres deniers).

Cependant, si la notion d’employeur peut être sans ambiguïté pour des professions contemporaines (employé chez Air France ou au Commissariat à l’énergie atomique), il est en réalité plus difficile de savoir exactement qui verse le salaire de l’individu, quand bien même il en perçoit un. Ce champ a donc été ventilé dans d’autres champs dont le nouveau champ “collectif” lié à la table du même nom. Le collectif correspondant à l’entreprise, institution, association, congrégation religieuse, etc. dans laquelle s’est exercée la profession.

Après tout, le fait que l’institution en question ait versé ou non le salaire de l’individu n’a pas d’importance. L’essentiel étant pour nous de lier des individus entre eux.

Le siège de la banque ou l’agence locale ?

La base de données a été modifiée pour faire disparaître la notion d’employeur au profit de l’association avec la table “collectif”. Mais au cours du remplissage de cette table avec les employeurs, un nouveau questionnement est apparu.

Yvonne Martin avait été indiquée comme employée de la Société générale dans la ville de Morlaix. Il suffisait donc en apparence de créer une nouvelle entrée “Société générale” dans la table “collectif” et d’y associer l’identifiant Wikidata de la banque française6. Mais si l’on faisait alors une requête dans la base pour obtenir la liste de tous les individus ayant travaillé à Société générale (la banque française dont le siège est à Paris et dont les agences sont réparties sur tout le territoire français) et à Morlaix, on n’aurait pas eu pour autant la certitude que ces individus aient travaillé au même endroit, car même à l’époque (de 1941 à 1942), il y avait peut-être plusieurs agences de la Société générale à Morlaix. Faute de ne savoir pour l’instant s’il existait Nous avons donc rattaché cette activité au collectif “Société générale (agence de Morlaix)”, elle même rattachée au collectif “Société générale” (identifiant Wikidata Q270363).

De même pour Hervé Mazé qui est noté comme ayant exercé le métier d’ingénieur à Rouen pour Shell (non pas “Shell à Rouen” mais “Shell” pris au sens de la compagnie pétrolière multi-nationale dont le siège est à La Haye en Hollande) . Rouen étant une grande ville, cela ne nous permet pas d’affiner le lieu d’exercice d’Hervé Mazé qui est très probablement la raffinerie de Petit-Couronne exploitée par Shell jusqu’en 2008. Il vaudrait donc mieux lier cette activité au collectif “Raffinerie de Petit-Couronne”, lui même lié au collectif “Shell”.

Dans la mesure du possible, il vaut donc mieux privilégier l’association avec le collectif liant l’individu avec le groupe d’individus le plus restreint possible.

Églises et paroisses

Je ne sais également plus pourquoi nous avions aussi ajouté un champ “lieu”. Peut-être pour distinguer l’employeur (celui qui verse le salaire) de l’institution dans laquelle s’exerce l’activité. Toujours est-il que l’on s’est retrouvé comme pour les employeurs avec des informations très disparates : des noms d’institutions (collège de Dinan, Fédération régionaliste de Bretagne), des noms de lieux géographiques (Finistère, Morlaix, Nantes), des types d’institutions (collège, évêché, prison, port, cathédrale), des noms d’individus (“chez F. Guilmer”), des informations du type “étude de son père” ou “ferme familiale” ou “village minier au sud du Pays de Galles”.

La question du “lieu” a été particulièrement épineuse pour les prêtres. Pour certains, c’est le nom de l’église ou de la cathédrale qui était saisi (cathédrale Saint-Corentin de Quimper), pour d’autres l’évêché (évêché de Quimper et Léon) ou le nom de la paroisse ou du diocèse (diocèse de Quimper et Léon). Le tout avec des intitulés plus ou moins officiels. Pour éviter que la même information ne puisse être désignée de plusieurs manières, c’est le nom du diocèse ou de la paroisse qui a été préférée à l’église ou à l’évêché.

En effet, les églises sont plutôt à considérer comme des bâtiments et non pas des lieux géographiques (voir plus loin Un bâtiment n’est pas un lieu) et il n’y pas de sens à considérer l’activité d’un prêtre comme circonscrite à la surface terrestre sur laquelle repose son église. Cette activité s’étend plutôt à celle de sa paroisse que l’on a finalement considéré comme un territoire (une aire géographique) plutôt que comme l’ensemble des paroissiens (qui serait considéré dans la base comme un collectif).

J’avais d’ailleurs des notions assez floues sur les notions d’évêché et de diocèse. Notions éclaircies par Yvon Tranvouez, notre spécialiste de l’histoire du catholicisme au CRBC lors d’un échange de mails :

1) Diocèse et évêché peuvent être synonymes mais mieux vaut employer diocèse, parce que évêché peut signifier à la fois le diocèse (comme territoire) et le bâtiment qui abrite l’évêque et ses services.

2) La paroisse est l’unité de base de l’organisation territoriale de l’Église catholique. Un diocèse comprend un nombre X de paroisses (nombre qui varie avec le temps et les restructurations du dispositif : le diocèse de Quimper va passer l’an prochain [en 2017] de plus de 300 paroisses à une vingtaine !)

3) Un édifice religieux n’est pas forcément rattaché à une paroisse : les chapelles d’ordres religieux ou de congrégations, et aussi les chapelles privées (dans un château par exemple), échappent à la juridiction paroissiale. Exemple : l’abbaye de Landévennec ne dépend absolument pas de la paroisse de Landévennec, laquelle a son église paroissiale, au bourg et non dans le domaine monastique.

4) La cathédrale est un cas particulier : église de l’évêque, elle est aussi celle de la paroisse où elle est implantée. Saint-Corentin, à Quimper, a un curé, distinct de l’évêque, mais l’évêque a sa cathèdre épiscopale (ornée de ses armes) dans le chœur de la cathédrale.

Yann Celton, bibliothécaire diocésain à l’évêché de Quimper7, nous a également livré des informations intéressantes au sujet des paroisses du Finistère et de leur évolution :

Depuis 1801, le diocèse est le même, Quimper et Léon, qui correspond au Finistère ; ses frontières n’ont pas changé : c’est déjà bien. Avant, il faut parler de Cornouaille, de Léon ou de Trégor et il faut regarder sur une carte, nous n’avons pas de listes de ce genre. Ensuite, le curé est curé d’une paroisse (Saint-Mathieu de Morlaix, par exemple) et donne le culte dans son église, qui porte le même nom que la paroisse. A Brest, l’église Saint-Laurent est celle de la paroisse Saint-Laurent, qui correspond au civil à Lambézellec. […] La forme géographique des paroisses ne varie que très peu. Dans les villes en extension, (Brest) furent créées des paroisses nouvelles dans les années 50 (Le Bouguen…) mais c’est une exception. Je vous conseille de consulter les annuaires diocésains en cas de doute, numérisés jusqu’en 1980. Dans les années 1990, il fut procédé à des regroupements de paroisses ; ces ensembles paroissiaux prenant parfois des noms étranges. L’ensemble paroissial des “Rives de l’Aulne” regroupe les paroisses de Châteaulin, Dinéault, Port-Launay, Saint-Coulitz et Trégarvan. Mais en définitive, ce sont ces paroisses ancestrales qui comptent, et non le regroupement artificiel et ponctuel (qui correspondrait à un canton dans le civil). Vous pouvez à mon avis vous baser uniquement sur le nom des paroisses anciennes.

Nous avons donc suivi ses conseils pour le choix des noms de paroisses et nous nous sommes servis d’un référentiel de noms qu’utilise en interne la bibliothèque diocésaine de Quimper.

Pour les activités autres que la prêtrise, il a fallu ventiler à la main les saisies entre le nouveau champ “Collectif” et les champs relatifs à des informations géographiques (ville, pays, département, aire géographique).

Un bâtiment n’est ni un lieu ni un collectif

Pour les bâtiments saisis comme des lieux (des localisations géographiques) et qui ne sont ni des églises ni des cathédrales (remplacés par la paroisse), un champ supplémentaire “bâtiment” a été créé. Pour m’aider dans cette décision, je me suis aidé de l’ontologie CIDOC CRM8 où les bâtiments sont considérés comme des E22 Man-Made Object9 et non pas comme des E53 Place.

Étant donné que E22 Man-Made Object est une sous-classe de E18 Physical Thing qui peut être composée de plusieurs E18 Physical Thing10, j’ai également considéré que l’abbaye Saint-Guénolé de Landévennec était aussi un E22 Man-Made Object bien que l’abbaye soit composée de plusieurs bâtiments distincts.

On pourrait aussi être tenté de considérer l’abbaye comme un collectif mais il vaut mieux distinguer les bâtiments des éventuels groupes d’individus qui les occupent. En effet, un même lieu peut servir successivement de couvent, de salle de réunion, de prison, d’école publique, de site industriel, de supermarché pour finir comme musée, comme c’est le cas du couvent des Capucins à Landerneau.

Faut-il rattacher les informations géographiques et les bâtiments au collectif ou à la profession ?

Table profession

Table profession

Concernant les informations géographiques (ville, département, pays, aire géographique) et les bâtiments, vous remarquerez dans le schéma ci-dessus qu’ils ont été directement associés aux professions. Mais peut-on circonscrire l’exercice d’une profession à une zone géographique ou à l’occupation de bâtiments ? Cela peut sembler utile lorsque les sources indiquent “vicaire et enseignant dans le Tregor” ou “chargé de recueillir les chants et mystères de Basse-Bretagne”. Mais si l’on interroge la base de données pour savoir qui était présent en Basse-Bretagne en 1845 au même moment que François-Marie Luzel (1821-1895), cela ne nous apprendra pas grand-chose sur les probabilités de rencontre entre ces individus.

Dans la plupart des cas, les informations saisies concernent plutôt le lieu d’implantation du collectif lié à l’activité. La base de données permettant la saisie des lieux d’implantation des collectifs, cette information devrait suffire.

Histoire des individus, histoire des collectifs

La saisie des parcours de vie d’individus revient tout autant à s’intéresser à l’histoire des collectifs. En effet, ceux-ci peuvent changer de nom, de lieu ou de statut au cours du temps.

C’est le cas par exemple de l’École des frères à Brest devenue “La Croix-Rouge La Salle” après s’être appelée “École de Bonne-Nouvelle” d’après la page “Notre histoire” de l’établissement brestois. Ou de l’École du calvaire à Pontchâteau où Jean-Louis Rozec (1898-1946) a été professeur et qui s’avère être le Petit séminaire de Guérande, transféré à Pontchâteau de 1912 à 1922 d’après un répertoire d’archives diocésaines réalisé par Jean Bouteiller et Claire Gurvil.

Si l’on se contente de créer trois “collectifs” distincts pour tous ces intitulés sans faire des recherches approfondies pour savoir s’ils ne sont pas liés entre eux, on passe à côté de la mise en relation des individus ayant fréquenté le même collectif ou des collectifs ayant le même héritage. Mais la question n’est pas aisée. S’agit-il du même collectif qui aurait juste changé de nom au cours de l’histoire ou ce changement de nom ne s’accompagne-t-il pas également d’un changement de statuts ou de lieux qui en fait un nouveau collectif ?

Il faut donc prévoir dans la base de saisir des informations dépendant du temps pour les collectifs et trouver des sources dédiées à leur histoire n’est pas toujours chose aisée. Mais nous avons des pistes, puisque c’est en interrogeant des collègues sur ces problématiques que nous avons appris que certains d’entre eux participaient à un dictionnaire des établissements de l’enseignement catholique du second degré. Et Sébastien Carney, maître de conférences en histoire contemporaine va apporter sa contribution à PRELIB avec des données sur les militants bretons.

Désambiguïser les collectifs

La saisie des lieux géographiques étant rattachée à la profession et non pas au collectif, nous nous sommes retrouvés avec des collectifs tels que “Petit séminaire”. Or il a existé au moins un séminaire par département breton. Quand on consulte donc la table des collectifs en dehors du contexte des professions (la table collectifs est liée à d’autres tables que celle des professions), rien ne permet de savoir de quel petit séminaire il s’agit. Celui de Pont-Croix ? Tréguier ? Quimper ? La précision “Petit séminaire de Point-Croix” ou “Faculté des lettres de Poitiers” dans l’intitulé du collectif n’est donc pas superflue.

Afin de lever complètement les ambiguïtés, nous avons ajouté depuis le début de l’année la saisie des identifiant Wikidata et des identifiants IdRef (les PPN). Mais les collectifs n’étant pas tous présents dans ces référentiels, il faudra leur créer une notice si nécessaire.

Cas des activités directement liées à un autre individu

Ce nettoyage a aussi permis de mettre en évidence certaines limites. La base permet actuellement de lier une profession à un collectif mais pas à un autre individu. Le cas se pose par exemple pour saisir que Erwan Kervella a été le chauffeur d’Alan Stivell. On peut toujours contourner le problème en trouvant le nom de la structure qui rémunérait Erwan Kervella, par exemple, la maison de production d’Alan Stivell et déclarer conjointement qu’Alan Stivell était un artiste de cette maison de production. Mais cela ne permet pas de lier directement les deux individus (ce n’est pas parce que deux individus travaillent dans la même entreprise qu’ils travaillent l’un pour l’autre). La base permet de lier directement deux individus par la table “relationinterpersonnelle” mais on perd alors le contexte de la structure dans laquelle s’exerce cette relation. A revoir, donc.

Évolutions de la table “profession”

Le schéma de la table professions après le nettoyage de la base de données PRELIB

Le schéma de la table “professions” après le nettoyage de la base de données PRELIB

Suite au nettoyage des professions, la table éponyme a été modifiée selon le schéma ci-dessus. Le champ “lieu” a été remplacé par la référence à une nouvelle table “bâtiment” (non représentée ici). Le champ “employeur” a été remplacé par une référence à la table “collectif”. Soit dit en passant, il aurait été plus judicieux de lier non pas un seul mais plusieurs collectifs à la même profession. Il est toujours possible d’associer des informations géographiques à la profession au cas où elle s’exercerait en dehors de la collectivité (qui possède ses propres informations géographiques). Mais la pertinence de cette information est discutable.

En guise de conclusion

Nettoyer les données ou ne serait-ce qu’y jeter un œil de temps en temps, c’est comme la vaisselle ou faire le ménage chez soi, on considère ça comme une corvée que l’on a toujours envie de remettre à plus tard. Pourtant, c’est l’occasion de revenir sur des concepts qui nous avaient semblé évidents au départ et de les affiner.

Laisser des champs de saisie assez flous ou d’une acception assez large n’est pas forcément un problème. Cela permet aux opérateurs de saisie de ne pas devoir toujours “rentrer dans les cases” et de saisir des informations que l’on n’avait pas envisagées lors des premières versions de la base de données (les bâtiments, par exemple).

Une base de données n’est pas figée. Sa structure n’est pas gravée dans le marbre et peut évoluer avec le temps. Mais ce n’est pas une opération anodine car un changement de structure entraîne une redistribution des données selon le nouveau schéma de la base et un recodage de l’interface de consultation des données.

La base de données PRELIB couvre tellement de champs connexes (histoire des institutions scolaires et religieuses, histoire du militantisme breton, histoire de l’imprimerie en Bretagne, etc.) liés tant par la nature que par la structure des informations saisies que l’on peut se demander s’il ne vaudrait pas mieux rassembler toutes les données produites au sein d’un même laboratoire dans une seule et unique base de données, les informations saisies par les uns bénéficiant aux autres.

On peut s’aider d’ontologies pour penser ses données. Dans notre cas, nous nous aidons du CIDOC CRM. C’est notamment ce qui nous a permis de distinguer les lieux des bâtiments.

Merci à Florence Daniel, secrétaire d’édition de la Revue Natures Sciences Sociétés au Ladyss et à Philippe Jarnoux, directeur du CRBC, pour leurs remarques et corrections.

  1. Pour en savoir plus sur Wikidata : https://fr.wikipedia.org/wiki/Wikidata. Nous avons choisit Wikidata car cette base pourrait être le socle du web des données (Open data). []
  2. Pour en savoir plus sur IdRef : http://www.abes.fr/IdRef/IdRef-Referentiel-d-autorites. []
  3. Voir aussi : OpenRefine, mes données à la machine. []
  4. Les villes et les pays correspondant aux attributs ville_id et pays_id de la table “profession” qui contiennent non pas le nom de la ville ou du pays mais un nombre entier correspondant à l’identifiant de la ville ou du pays dans leurs tables respectives “ville” et “pays”. Par exemple, l’identifiant interne à PRELIB de Brest est le chiffre 40. Cet identifiant s’appelle une clé primaire en SQL. []
  5. Par institution, j’entends tout type de groupe d’individus : entreprises, associations, structures gouvernementales, établissement d’enseignement, congrégations religieuses, etc. []
  6. Nous saisissons l’identifiant Wikidata et le PPN de IdRef pour les collectifs, les individus et les lieux afin de désambiguïser les données saisies. L’utilisation de ces référentiels nous permettra également de récupérer des informations, telles que les coordonnées géospatiales des villes. []
  7. La bibliothèque diocésaine de Quimper met à disposition une partie des documents issus de son fonds dans une bibliothèque numérique. []
  8. CIDOC Conceptual Reference Model []
  9. La classe E22 Man-Made Object du CIDOC-CRM est une sous-classe de E24 Physical Man-Made Thing qui englobe tous les “objets physiques persistants” créés par l’activité humaine qui comprend le Tunnel sous la Manche ou le Canal de Suez (deux E25 Man-Made Feature) ou la collection des oeuvres du musée du Louvre (E78 Collection). Les exemples donnés de E22 Man-Made Object sont la locomotive à vapeur “Mallard” détentrice du record de vitesse des locomotives à vapeur, le vase Portland conservé au British Museum, le Colisée à Rome (donc un bâtiment). Un E22 Man-Made Object peut-être lié à une E53 Place par P53 has former or current location. []
  10. A travers la propriété P46 is composed of (forms part of). []

Première séance du cycle de rencontres et d’échanges autour du traitement et de l’analyse de données quantitatives en Sciences Humaines et Sociales à Brest

Le cycle de rencontres et d’échanges autour du traitement et de l’analyse de données quantitatives en SHS à l’UBO reprend pour la saison 2015-2016.

Dans la continuité des précédentes années, ces rencontres s’inscrivent dans une démarche pluridisciplinaire (démographes, sociologues, psychologues, géographes, gestionnaires, économistes, etc.) et transversale car selon la discipline, les chercheurs ne traitent pas de la même manière leurs données quantitatives. Ils ont des approches différentes et utilisent des traitements et des logiciels spécifiques qui peuvent être complémentaires. L’objectif est de créer un espace d’analyses et de discussions scientifiques sur nos pratiques. Ce cycle d’échanges prendra en compte autant les dimensions épistémologiques que méthodologiques en partant de nos pratiques et usages mais aussi de nos outils.

La première séance « L’analyse de réseaux sociaux avec le logiciel QCA. Le conformisme dans le choix des téléphones portables chez des jeunes français » par Germain Barré, docteur en sociologie et membre du LABERS aura lieu le mardi 3 novembre 2015 de 14h à 16h salle C219 à l’UFR des Lettres et Sciences Humaines à Brest.

Cette séance sera suivie d’un temps de discussion collective autour des prochaines rencontres (dates, propositions, contenu…).

Contacts et inscription : laurent.mell@univ-brest.fr

Ce cycle est organisé en collaboration avec l’ IBSHS (Institut Brestois des Science de l’Homme et de la Société), le LABERS (LABoratoire d’Études et de Recherche en Sociologie), le CRBC (Centre de recherche bretonne et celtique) et l’école doctorale SHS (Sciences Humaines et Sociales) de l’UBO (Université de Bretagne Occidentale)

Sémantiser une base de données relationnelle (3ème épisode)

Ce billet est le troisième épisode d’une série de billets sur la sémantisation d’une base de données relationnelle des auteurs de langue bretonne issue du projet PRELIB.

Je posterai dorénavant la dernière version de la totalité des triplets RDF sur mon compte personnel sur le site de partage de code informatique GitHub Gist. Je commençai en effet à être un peu perdu avec mes petits bout de triplets dispersés d’un billet à l’autre. Pour l’instant, les triplets déclarés avec le vocabulaire BIO et le vocabulaire FRBRoo sont dans des fichiers prelib.ttl séparés, mais cela n’exclut pas par la suite l’utilisation combinée des deux vocabulaires.

Dans les fichiers prelib.ttl publiés sur GitHub Gist des codes de langue (language tags) ont été rajoutés sur tous les littéraux en se servant du formulaire de recherche de la page de l’ISO 639-6 sur geolang.org (champ de recherche Language Reference Name).

Saisie du décès de Théodore et de ses années collège avec BIO

Dans la version BIO de prelib.ttl, les triplets de la date et du lieu de décès de Théodore ont été rajoutés ainsi que ses études au collège des Jésuites de Keranna à Quimper entre 1825 et 1826.

BIO permet de déclarer des bio:Interval (les années d’études de Théodore au collège des Jésuites de Keranna correspondent à la ressource http://prelib.huma-num.fr/interval/1) bornées par des bio:Event (les ressources http://prelib.huma-num.fr/event/3 et http://prelib.huma-num.fr/event/4 correspondant à sont entrée en 1825 et à sa sortie en 1826 du collège). Les informations spatio-temporelles sont rattachées aux bio:Event.

Si une autre personne rentre au même moment au collège des jésuites de Keranna, faut-il créer une nouvelle ressource de type bio:Enrolment ou rattacher la personne au même événement ? Vous ne trouverez pas la réponse dans la documentation du vocabulaire BIO mais dans le schéma du vocabulaire1 où il est indiqué que la propriété bio:principal liant la personne à l’événement a une cardinalité de 1 pour les ressources de type bio:IndividualEvent (dont bio:Enrolment est une sous-classe). En d’autres termes, il ne peut y avoir qu’une seule personne liée par la propriété bio:principal à un événement de type bio:Enrolment. Il faut donc bien créer autant d’événements de type bio:Enrolment que de personnes qui seraient rentrées au collège des Jésuites de Quimperlé la même année que Théodore.

Le collège des Jésuites correspond à la ressource http://prelib.huma-num.fr/organization/1 de type foaf:Organization où le nom de l’établissement a été saisi avec dc:title et foaf:name. Mais cette saisie ne permet pas de tenir compte des éventuels changement de nom ni de statut de l’établissement ni de ses divers lieux d’enseignement. Comment modéliser par exemple l’histoire mouvementée des Écoles normales supérieures ? L’École normale supérieure de l’enseignement primaire de Fontenay-aux-Roses créée par Jules Ferry en 1880 et École normale supérieure de Fontenay-Saint-Cloud doivent-elle être représentées par la même ressource ou par des ressources différentes mais liées entre elles (de quelle manière) ?

Petite remarque en aparté : L’idée sous-jacente à la saisie des études est de savoir si des personnes ont fréquenté les mêmes lieux de sociabilité. Mais une proximité spatio-temporelle n’est pas suffisante pour attester d’une relation. Dans le cas d’études, des documents tels qu’une thèse ou des devoirs en groupe seraient des preuves plus tangibles d’une relation (de professeur à étudiant ou entre étudiants).

Les multiples implémentations de FRBR pour le web sémantique

Plus j’explore l’utilisation de FRBR pour la base de donnée, plus je m’aperçois qu’il en existe de multiples implémentations en RDFS ou dans les différentes versions de OWL2. Voici celles que j’ai trouvées jusqu’à présent :

Implémentations de FRBRER (entité-relation)

– La version de l’IFLA : http://iflastandards.info/ns/fr/frbr/frbrer/
– La version RDFS de Ian Davis (auteur également du vocabulaire BIO) : http://purl.org/vocab/frbr/core et http://purl.org/vocab/frbr/extended
– La version OWL 2 DL de Paolo Ciccarese et Silvio Peroni3 qui fait référence à la version de Ian Davis : http://purl.org/spar/frbr

Implémentations de FRBRoo (orienté objet, version dérivée de CIDOC-CRM)

– La version RDFS de la dernière version de FRBRoo (version 2.1 du modèle) édité par le groupe de travail du groupe de travail CRM-FRBR : voir en haut de la page http://www.cidoc-crm.org/frbr_drafts.html
– La version de l’IFLA : http://iflastandards.info/ns/fr/frbr/frbroo/
– La version OWL DL de l’Université d’Erlangen (version 1.0.2 du modèle) : http://erlangen-crm.org/efrbroo

Sur la page Vocabulaires du web sémantique sur le site de la BnF on trouve également un lien vers la page The FRBR Vocabularies de l’IFLA. Pas facile de s’y retrouver dans tout ça…

  1. Je mets en lien la version du schéma publié par Ian Davis sur GitHub pour faciliter sa lecture. []
  2. Pour tenter d’y voir clair dans les différentes versions de OWL, lire Difference between OWL Lite, DL, and Full. []
  3. Silvio Peroni a également développé le web service LODE permettant de créer une documentation web d’une ontologie OWL. []

Sémantiser une base de données relationnelle (2ème épisode)

Ce billet est le deuxième épisode d’une série de billets sur la sémantisation d’une base de données relationnelle des auteurs de langue bretonne issue du projet PRELIB.

Corrections et améliorations

Depuis le dernier billet, Patrick Le Boeuf de la BnF m’a apporté quelques précisions sur le modèle CIDOC-CRM et Gabriel Kepeklian d’Atos m’a aidé à connecter une copie locale de ma base de données à DataLift1. Je vous conseille à ce propos la lecture de How to import an SQL database? Si vous avez des difficultés pour utiliser DataLift ou si vous voulez signaler votre utilisation de l’outil, n’hésitez pas à le faire sur la liste de diffusion du projet DataLift. J’ai également réalisé en discutant avec mon collègue Fañch Postic qui connait très bien Théodore, que je n’avais pas très bien interprété l’écriture manuscrite de l’acte de naissance de ce dernier puisque le nom de famille de la mère de Théodore Hersart de la Villemarqué est Feydeau et non pas Kerjean, plus précisément Feydeau de Vaugien2.

Pour revenir aux exemples précédents de triplets en Turtle, j’ai un doute sur la validité des URI des classes et des propriétés du CIDOC CRM. J’avais supposé que l’URI de P96 by mother par exemple, était http://www.cidoc-crm.org/cidoc-crm/by_mother mais il s’avère que c’est plutôt http://www.cidoc-crm.org/cidoc-crm/P96_by_mother. Je modifie les triplets de l’accouchement http://prelib.huma-num.fr/event/1 en conséquence. J’en profite également pour corriger les URI préfixées. En effet, les URI prelib:event/1 ou prelib:person/1115 ne sont pas valides : Le / n’est pas reconnu après les préfixes. J’ai donc remplacé le préfixe prelib: par les préfixes event: et person:

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

event:1 a cidoc:E67_Birth ;
cidoc:P98_brought_into_life person:80 ;
cidoc:P96_by_mother person:1115 ;
cidoc:P97_from_father person:1114 ;
cidoc:P1_is_identified_by _:date1 .

_:date1 a cidoc:E50_Date ;
rdfs:label “1815-07-07″^^xsd:date .

J’ai rajouté un triplet concernant le père de Théodore, Pierre Hersart de la Villemarqué (person:1114) car j’avais mal interprété l’utilisation de P97 from father. Comme me l’a expliqué Patrick Le Boeuf, cette propriété sert à désigner le père biologique et peut être utilisée même si celui-ci n’a pas assisté à l’accouchement.

Saisie du lieu de naissance

Modélisation des informations sur une personne aec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.

Modélisation des informations sur une personne aec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.

Comment saisir le lieu de naissance, c’est à dire la ville de Quimperlé ? D’après le schéma publié sur le site du CIDOC CRM et reproduit ci-dessus, il faut créer une ressource E53 Place que l’on lie à l’accouchement par la propriété P7 took place at. On crée donc une nouvelle ressource http://prelib.huma-num.fr/place/1 et on déclare à cette URI les triplets suivants :

@prefix place: <http://prelib.huma-num.fr/place/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

place:1 a cidoc:E53_Place ;
rdfs:label “Quimperlé″ .

Cependant, le CIDOC-CRM incite à saisir les dénominations dans des classes dédiées afin de relater leur évolution dans le temps (par exemple, Lutèce qui devient Paris). E48 Place Name, sous-classe de E44 Place Appellation, semble la mieux indiquée dans notre cas3. Je pourrai créer une nouvelle ressource http://prelib.huma-num.fr/appellation/1 de type E48 Place Name mais je ne sais pas si celle-ci sera utilisée pour un autre usage que l’appellation de http://prelib.huma-num.fr/place/1, je me contente donc pour l’instant d’une ressource anonyme (ou blank node en anglais).

@prefix place: <http://prelib.huma-num.fr/place/> .
 @prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

place:1 a cidoc:E53_Place ;
cidoc:E87_is_identified_by _place_name .

_place_name a cidoc:E48_Place_Name ;
rdfs:label “Quimperlé″ .

On peut maintenant compléter les triplets de l’accouchement avec une référence à Quimperlé :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

event:1 a cidoc:E67_Birth ;
cidoc:P98_brought_into_life person:80 ;
cidoc:P96_by_mother person:1115 ;
cidoc:P97_from_father person:1114 ;
cidoc:P1_is_identified_by _:date1 ;
cidoc:P7_took_place_at place:1 .

_:date1 a cidoc:E50_Date ;
rdfs:label “1815-07-07″^^xsd:date .

Retour sur la date de l’accouchement

Je ne suis toujours pas convaincu de cette saisie de la date de l’accouchement. Or, on trouve l’information suivante dans le commentaire au début du fichier http://www.cidoc-crm.org/rdfs/cidoc_crm_v6.0-draft-2015January.rdfs :

8. CRM time extension 1.0 Encoded in RDFS
Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension of 4 properties replacing P81 and P82 adequately using xsd:dateTime.
Property P81 is dedicated for modeling the Time-Span’s maximum known temporal extent i.e. ongoing_throughout. Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.

Visiblement, cette implémentation en RDFS par le FORTH-ICS4 a nécessité la création de quatre propriétés RDF P81a_end_of_the_begin, P81b_begin_of_the_end, P82a_begin_of_the_begin et P82b_end_of_the_end qui sont les seules propriétés permettant explicitement la saisie de dates au format ISO 6801 (elles ont toutes les quatre pour portée (range en anglais) http://www.w3.org/2001/XMLSchema#dateTime) .

A y regarder de prêt, il semblerait que toute information temporelle est de facto une durée dont il faut saisir la date de début et la date de fin. Cela vient du fait que les concepteurs du modèle considèrent que les données temporelles sont forcément floues (fuzzy en anglais)5 et qu’ils ont voulu introduire la possibilité d’utiliser l’algèbre des intervalles d’Allen pour déduire la chronologie d’événements6.

Cela dit, dire que Théodore est né le 7 juillet 1815 signifie qu’il est né entre le 7 juillet à 0 heure et le 7 juillet à minuit… Toute “date” est en soit une durée. Mais il faut tout de même avouer que cela complique un peu la saisie.

Expression des données avec le vocabulaire BIO

Comment les mêmes informations pourraient-elles être exprimées avec le vocabulaire BIO du développeur anglais Ian Davis suggéré par Gautier Poupeau ? A la fin de la documentation de BIO, Ian Davis a illustré le vocabulaire par des données biographiques sur le roi d’Angleterre Henry VIII exprimées en RDF dont voici un extrait :

@prefix bio: <http://purl.org/vocab/bio/0.1/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

_:henryviii
  a foaf:Person
  ; foaf:name "Henry VIII, King of England"
  ; bio:father _:henryvii
  ; bio:mother _:elizplantagenet
  ; bio:child _:child1, _:child2, _:child3, _:child4, _:child5, _:child6, _:child7, _:child8
  ; bio:birth _:birth
  ; bio:death _:death
  ; bio:event _:burial, _:accession, _:coronation, _:marriage1
            , _:marriage2, _:marriage3, _:marriage4, _:marriage5, _:marriage6
  .

_:henryvii
  a foaf:Person
  ; foaf:name "Henry VII Tudor, King of England"
  ; bio:child _:henryviii
  .

_:elizplantagenet
  a foaf:Person
  ; foaf:name "Elizabeth of York"
  ; bio:child _:henryviii
  .
  
_:birth
  a bio:Birth
  ; rdfs:label "The birth of Henry VIII to Henry VII and Elizabeth Plantagenet on 28 June 1491"
  ; bio:date "1491-06-28"
  ; bio:place <http://dbpedia.org/resource/Palace_of_Placentia>
  ; bio:parent _:henryvii, _:elizplantagenet
  ; bio:principal _:henryviii
  .

_:death
  a bio:Death
  ; rdfs:label "The death of Henry VIII on 28 January 1547"
  ; bio:date "1547-01-28"
  ; bio:place <http://dbpedia.org/resource/Palace_of_Whitehall>
  ; bio:principal _:henryviii
  .

Je me suis largement inspiré de cet exemple à la seule différence que j’ai évité l’utilisation de ressources anonymes.

Les triplets associés à Théodore pourraient devenir :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix bio: <http://purl.org/vocab/bio/0.1/> .

person:80 a cidoc:Person, foaf:Person ;
dc:title "Théodore-Claude-Henri Hersart de la Villemarqué (1815-1895)"@fr ;
foaf:name "Théodore-Claude-Henri Hersart de la Villemarqué"@fr ;
foaf:givenName "Théodore Claude Henri" ;
foaf:familyName "Hersart de la Villemarqué" ;
foaf:nickname "Barz Nizon", "Kervarker";
foaf:gender "male"@en, "homme"@fr ;
bio:birth  event:1 .

Et les triplets de l’accouchement deviennent :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dbpedia: <http://dbpedia.org/resource/> .

event:1 a bio:Birth ;
rdfs:label "Naissance de Théodore-Claude-Henri Hersart de la Villemarqué le 7 juillet 1815 à Quimperlé"@fr ;
bio:date "1815-07-07"^^xsd:date ;
bio:place dbpedia:Quimperl%C3%A9 ; # Voir http://www.dbpedia.org/resource/Quimperl%C3%A9
bio:parent person:1115 , person:1114 ;
bio:principal person:1 .

On perd la distinction du père et de la mère du CIDOC CRM mais les informations sur la date et le lieu sont plus faciles à saisir. Notamment pour le lieu, il est possible de ne saisir non pas une valeur littérale mais l’URI d’une ressource qui permette de désambiguïser l’information et de récupérer des informations saisies par ailleurs7. Après, je ne dis pas que cela n’est pas possible avec le CIDOC CRM, je n’ai peut-être pas encore compris comment procéder. Toujours est-il que la propriété bio:place n’a pas de portée (range) et n’impose donc pas de valeur particulière à l’objet d’un triplet dans lequel la propriété est utilisée.

Pour signifier Quimperlé, j’ai suivit l’exemple de la biographie d’Henry VIII et j’ai utilisé DBpedia en anglais, mais j’aurais tout aussi bien pu utiliser DBpedia en français, voire un référentiel géographique (gazetteer en anglais) tel que Getty Thesaurus of Geographic Names et faire la déclaration suivante :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix tgn: <http://vocab.getty.edu/tgn/> .

event:1 a bio:Birth ;
rdfs:label "Naissance de Théodore-Claude-Henri Hersart de la Villemarqué le 7 juillet 1815 à Quimperlé"@fr ;
bio:date "1815-07-07"^^xsd:date ;
bio:place tgn:7009459 ; # Voir http://vocab.getty.edu/tgn/7009459
bio:parent person:1115 , person:1114 ;
bio:principal person:1 .

Bon, ce n’est pas tout de faire des tests de vocabulaires, mais il faudrait faire quelques premières requêtes en SPARQL pour les évaluer. Pour cela rien de tel qu’un triple store tel que Sesame RDF que vous pouvez installer en suivant les instructions de Thomas Francart. La suite au prochain épisode…

  1. Par copie locale, j’entends une copie de ma base de données installée sur mon ordinateur avec la plateforme de développement web EasyPHP. []
  2. Source : Ces Quimperlois(es) qui ont fait l’histoire (Jacques Gouriou, Alain Pennec, Fañch Postic), Amis de l’abbaye Sainte-Croix de Quimperlé / Société d’Histoire de Kemperle, décembre 2007. []
  3. Notez que la notion de sous-classe est indiquée dans le graphique ci-dessus par des doubles flèches. []
  4. Le FORTH Institute of Computer Science est un institut d’informatique grec où travaille Martin Doerr, un des co-rédacteurs du manuel de référence du CIDOC CRM []
  5. Voir à ce sujet la discussion Start/End vs Period of Existence sur le site officiel du CIDOC CRM. []
  6. Voir le chapitre 6 “Example” de Deducing Event Chronology in a Cultural Heritage Documentation System où l’on trouve un exemple de déduction de la date de construction d’une église à partir de la date à laquelle ont été approuvés les plans et la date d’un mariage célébré dans cette église. []
  7. L’intérêt de passer par des ressources externes sera plus évidente quand on fera des requêtes en SPARQL. []

Sémantiser une base de données relationnelle (1er épisode)

Dans un billet précédent, j’avais commencé à envisager l’évolution de la base de données relationnelle des auteurs de langue bretonne du projet PRELIB afin de mieux gérer la saisie des données temporelles. Mais au delà de ce problème, ce pose la question du stockage dans une base de donnée relationnelle et le passage au web sémantique.

Je m’intéresse depuis 2012 au web sémantique mais j’avais du mal à passer à la pratique faute d’avoir trouvé un outil de publication en RDF bien documenté et des vocabulaires ou des ontologies permettant d’exprimer nos données biographiques en RDF.

Concernant les outils, j’avais découvert en 2013 le logiciel Open source Callimachus en lisant le livre Linked Data co-écrit par David Wood (livre dont je vous recommande la lecture que je trouve plus digeste que celle du livre en français Le web sémantique), mais la documentation de Callimachus n’était pas assez aboutie à l’époque et je n’ai pas su comment l’utiliser pour mes besoins. J’avais aussi repéré CubicWeb un outil en Python sur lequel repose data.bnf.fr. Mais son installation s’est avérée trop compliquée sous Windows et je n’ai pas pu le tester. Sans compter là encore sur une documentation peu aboutie.

D’un autre côté, la plateforme DataLift, que j’ai rapidement testée la semaine dernière, permettrait dans un premier temps de transformer les données relationnelles en RDF. Je conserverai le stockage des données dans la base de données relationnelle mySQL, mais elles seraient “libérées” de la base sous la forme d’un export en RDF (et interrogeables à travers un SPARQL Endpoint ou REST + RESTdesc ? A voir).

Pour découvrir DataLift, je vous conseille de visionner la vidéo de démonstration de Gabriel Kepeklian où il se sert de DataLift pour sémantiser en quelques clics un fichier CSV des emplacements des kiosques à journaux mis à disposition sur ParisData. C’est plutôt convaincant.

Du côté des vocabulaires, j’avais identifié FRBR pour la saisie des œuvres littéraires mais j’avais du mal à en trouver une pour exprimer les données biographiques jusqu’à ce que j’entende parler fin 2014 de CIDOC1 CRM2 grâce au projet Biblissima.

Une lecture récente de documents sur le CIDOC CRM m’a également permit de comprendre que FRBRoo (FRBR object oriented) était une extension du modèle du CIDOC et que je devais plutôt m’intéresser à FRBRoo qu’à FRBR pour exprimer en RDF les données de ma base concernant la production littéraire.

L’objectif, au printemps 2015 est donc d’essayer de voir comment exprimer les données avec le CIDOC CRM et FRBRoo puis de convertir les données de la base de données relationnelles avec DataLift afin de comparer les requêtes SPARQL avec des requêtes SQL, de faire des essais d’analyse de réseau à partir de ces données RDF et de vérifier si le web sémantique permet réellement d’inférer de nouvelles connaissances (peut-être l’aspect le plus intéressant du web sémantique) en mettant en pratique l’article Bringing reasoning to the Web de Ruben Verborgh.

Vous pouvez télécharger le PDF du Schéma conceptuel de la base de données PRELIB au 23 octobre 2014. Ce n’est certainement pas un modèle à suivre pour la conception d’une base de données relationnelle mais il me servira de référence pour RDFiser la base de données par étapes successives.

Pour commencer, où peut-on trouver des informations sur le CIDOC CRM ?

Le site officiel du CIDOC CRM (version du 17 avril 2015) est la source de référence mais est un peu fouillis. L’information est dispersée dans de multiples sous-rubriques où l’on a un peu de mal à se retrouver. Mais j’ai découvert un peu par hasard qu’une nouvelle version du site est en chantier à cette adresse http://139.91.183.82:8888/drupal/ où l’excellent CIDOC-CRM Tutorial et la version HTML du manuel de référence de la version 6.0 du CRM (sortie en février 2015) sont mieux mis en avant.

SI vous êtes intéressés par la version PDF du manuel de référence (200 pages) de la version 6.0, il est disponible depuis la page Official Release of the CIDOC CRM où vous trouverez également un lien vers l’expression en RDF Schema du modèle (à consulter aussi sur LOV, Linked Open Vocabulary3).

Le manuel faisant 200 pages, vous aurez une meilleure introduction au CRM en lisant le document d’introduction (les anglophones appellent ce type de document des “primer”) ou si vous avez du temps devant vous, en visionnant les vidéos du CIDOC-CRM Tutorial.

Pour vous y retrouver dans les multiples entités et propriétés du modèle, vous pouvez aussi consulter des représentations graphiques de la version 5.0.4 du modèle : La version complète et la version réduite.

Toutes ces ressources sont en anglais. Le seul document de référence en français sur le CIDOC CRM est la traduction de la norme ISO 21127 (la normalisation ISO du CIDOC CRM) dont la lecture vous coutera 198 francs suisses sur le site de l’ISO ou 157 euros sur la boutique en ligne de l’Afnor.

Il faut noter au passage que le CIDOC CRM est un modèle et qu’il n’impose pas de langage pour exprimer les données. Je pourrai donc tout aussi bien adapter ma base de données relationnelle pour qu’elle repose sur le modèle, rien ne m’oblige à utiliser le RDF sinon mon intérêt pour ce format et le web sémantique. Il est néanmoins dommage que l’on ne trouve pas d’exemples de données exprimées en RDF sur le site officiel du CIDOC CRM alors que le Dublin Core Metadata Initiative l’a fait pour le Dublin Core dans deux guides utilisateurs publiés sur son wiki4.

Table "Personne" de la base de données relationnelle PRELIB

Table “Personne” de la base de données relationnelle PRELIB

Essayons d’appliquer le modèle CIDOC CRM à la base de données en commençant par la table “Personne” qui stocke des informations sur des individus. L’entité qui correspond le mieux à cette table est E21 Person. Dans le futur site du projet, chaque individu va devenir une ressource RDF de type E21 Person accessible à partir d’une URI construite à partir de la clé primaire de la table “Personne”. Par exemple, les informations sur Théodore Hersart de la Villemarqué, qui a pour clé primaire id_personne = 80 dans la table “Personne” pourra être accessible à l’URI http://prelib.huma-num.fr/person/80. Notez que vous pourrez récupérer depuis cette URI, soit du contenu en HTML sur Théodore si vous la consultez avec votre navigateur web, soit du RDF si vous vous connectez avec une application telle ARQ pour faire des requêtes SPARQL5.

Une première lecture de la référence à E21 Person dans le manuel de référence peut donner l’impression que l’entité n’a qu’une seule propriété P152 has parent. Ne peut-on que donner des informations sur les parents d’un individu avec CIDOC-CRM ?

Que neni.

En effet, en consultant la représentation graphique des entités et des modules disponibles pour signifier l’existence d’un objet ou d’une personne (reproduite ci-dessous), on se rend compte qu’il existe une propriété P98 brought into life qui permet de lier la personne à une ressource de type E67 Birth. Notez au passage que le sens de la flèche entre E67 Birth et E21 Person indique que P98 brought into life est une propriété de E67 Birth et non pas de E21 Person.

Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/existence.html

Source :http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/existence.html

Le diagramme indique aussi les cardinalités. Ces couples (0,n) ou (1,n) ou (0,1) qui indiquent le nombre d’entités minimales et maximales impliquées dans la relation. Notamment le (0,n) indiqué du côté de E67 Birth pour la propriété  P98 brought into life indique qu’un accouchement (il s’agit plus d’un accouchement que d’une naissance si je ne m’abuse) peut donner naissance à zéro (!?) ou plusieurs enfants (dans le cas de jumeaux, triplés, etc.). Le (1,1) du côté de E21 Person précise comme on pourrait s’y attendre qu’une personne ne peut naitre qu’une seule fois lors du même accouchement et qu’un individu est forcément né une fois (donc Dieu ne peut être une E21 Person si on considère qu’il a toujours existé). On voit que E67 Birth nous permet aussi de déclarer le père et la mère des enfants et il y a fort à parier que l’on puisse aussi déclarer le lieu de la naissance.

A creuser : Les cardinalités fonctionnent-elles pour toutes les instances de l’entité ou pour une seule ? Autrement dit, dès qu’un individu est impliqué dans un accouchement comme nouveau-né, est ce que cela suffit pour qu’il ne puisse pas être impliqué dans un autre accouchement ?

Au passage, rien ne nous empêche d’enfreindre les règles de cardinalité. Il nous faudra nous même mettre en place des mécanismes pour vérifier si les règles sont respectées.

Concernant les parents, le manuel indique pour E67 Birth que dans ce modèle, le père biologique n’est pas vu comme un participant nécessaire de l’événement. Ce qui conforte l’idée que l’entité E67 Birth permet de décrire un accouchement (un événement impliquant la mère et les nouveaux-nés, ayant lieu à une date, une durée et à un endroit donnés) et non pas des liens de parentés. Puisque comme chacun sait, les pères n’assistent pas systématiquement à la naissance de leurs enfants.

In this model, the biological father is not seen as a necessary participant in the E67 Birth event.

Le manuel précise également que P96 by mother et P97 from father concernent uniquement les parents biologiques. Le modèle n’écarte pas pour autant les parents non-biologiques puisqu’ils peuvent être déclarés avec la fameuse propriété P152 has parent évoquée précédemment :

This property associates an instance of E21 Person with another instance of E21 Person who plays the role of the first instance’s parent, regardless of whether the relationship is biological parenthood, assumed or pretended biological parenthood or an equivalent legal status of rights and obligations obtained by a social or legal act.

Extrait de l'acte de naissance de Théodore Hersart de la Villemarqué

Extrait de l’acte de naissance de Théodore Hersart de la Villemarqué. Source : Archives départementales du Finistère (http://mnesys-portail.archives-finistere.fr).

D’après l’acte de naissance de Théodore Hersart de la Villemarqué6, l’auteur du Barzaz-Breiz est né le 7 juillet 1815 à Quimperlé et il est le fils de Pierre Michel François Marie Toussaint Hersart de la Villemarqué et de Marie Ursule Claude Henriette Kerjean Feydeau.

Pour exprimer cette information en RDF, il nous faut une URI (si possible une URL permanente ou PURL) où un processeur SPARQL comme ARQ pourra trouver une version RDF Shema ou OWL du CIDOC CRM7. En tapant “CIDOC” sur LOV (Linked Open Vocabularies), on trouve que l’espace de nom du CIDOC est http://www.cidoc-crm.org/cidoc-crm/.

L’URI http://prelib.huma-num.fr/person/80 pourrait donc renvoyer le RDF suivant (exprimé ici avec Turtle) :

@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .

prelib:person/80 a cidoc:Person, foaf:Person ;
dc:title "Théodore-Claude-Henri Hersart de la Villemarqué (1815-1895)"@fr ;
foaf:name "Théodore-Claude-Henri Hersart de la Villemarqué"@fr ;
foaf:givenName "Théodore Claude Henri" ;
foaf:familyName "Hersart de la Villemarqué" ;
foaf:nickname "Barz Nizon", "Kervarker";
foaf:gender "male"@en, "homme"@fr.

Le CIDOC CRM permet de nommer les ressources mais je vais me contenter pour l’instant d’exprimer le nom et les pseudonymes de Théodore avec le Dublin Core et FOAF (Friend of a Friend) comme le fait la BnF sur data.bnf.fr.

Les informations concernant la naissance de Théodore devront être exprimées depuis une autre URI par une autre ressource de type E67 Birth. En effet, je ne peux exprimer à l’adresse http://prelib.huma-num.fr/person/80 que des triplets qui ont pour sujet8 la ressource elle-même (Enfin, je suppose que c’est comme cela qu’il faut procéder).

Je pourrai mettre à disposition la ressource à l’URI http://prelib.huma-num.fr/birth/1 (où le chiffre 1 indique le numéro de la ressource de type E67 Birth) mais pour éviter d’utiliser des chemins dédiés à chaque classe du CIDOC CRM, je vais utiliser le nom de la classe générique E5 Event dans le chemin de l’URI.

Supposons donc qu’à l’URI http://prelib.huma-num.fr/event/1 on va pouvoir récupérer le RDF suivant (en supposant que l’URI correspondant à Marie Kerjean Feydeau, la mère de Théodore soit http://prelib.huma-num.fr/person/1115) :

@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .

prelib:event/1 a cidoc:Event ;
prelib:event/1 a cidoc:Birth ;
cidoc:brought_into_life prelib:person/80 ;
cidoc:by_mother prelib:person/1115.

Comme rien ne prouve que le père de Théodore n’ai assisté à l’accouchement, on ne le rajoute pas à l’événement avec la propriété P97 from father. Par contre, comment signaler la date et le lieu de l’heureux événement ? C’est là que ça se complique.

En parcourant les représentations graphiques sur le site officiel du modèle, j’ai trouvé la modélisation des informations sur la nationalité d’une personne où l’on constate que l’on peut déclarer qu’un accouchement E67 Birth s’est produit durant une E4 Period et à une E53 Place.

Modélisation des informations sur une personne avec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.

Modélisation des informations sur une personne avec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.

Cependant, P10 falls within sert à lier entre elles des E4_Period et servirait plutôt à déclarer que la naissance de Théodore a eu lieu durant la Restauration. Comme E67 Birth est une sous-classe de E2 Temporal Entity (une sous-sous-sous-classe) il doit bien y avoir moyen de déclarer la date du 7 juillet 1815 avec une propriété quelconque de Temporal Entity ou de ses sous-classes ?

En cherchant sur le web, j’ai trouvé la présentation du modèle CIDOC CRM par Patrick Le Boeuf le 9 décembre 2010 (reproduite ci-dessus) où l’on constate à la diapositive n°37 que la valeur littérale de la date de l’accouchement pourrait être saisie grâce à une ressource de type E50 Date elle même reliée à notre accouchement par P4 has time-span.

Pour l’instant, j’utilise une ressource anonyme ou blank node en anglais pour exprimer la ressource de type E50 Date et je saisi la valeur littérale avec une propriété rdfs:label et en lui donnant un type xsd:date conforme au format ISO 8601.

@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

prelib:event/1 a cidoc:Event ;
prelib:event/1 a cidoc:Birth ;
cidoc:brought_into_life prelib:person/80 ;
cidoc:by_mother prelib:person/1115.
cidoc:is_identified_by _:date1

_:date1 a cidoc:Date ;
rdfs:label "1815-07-07"^^xsd:date

Pourquoi utiliser rdfs:label ? Et bien parce que c’est le seul moyen que j’ai trouvé l’instant pour saisir cette fameuse valeur. Si vous exprimez ces données avec RDF/XML, vous pouvez toujours mettre la valeur à l’intérieur d’une balise, comme dans l’exemple de la saisie de la période entre -500 à 500 tiré du wiki du projet Claros.

<crm:E52_Time-Span>
<crm:P82_at_some_time_within>
<claros:Period>
<claros:period_begin rdf:datatype="&xsd;gYear">-550</claros:period_begin>
<claros:period_end   rdf:datatype="&xsd;gYear">-500</claros:period_end>
</claros:Period>
</crm:P82_at_some_time_within>
</crm:E52_Time-Span>

Sauf qu’avec Turtle ou Notation3 (N3), la valeur (l’objet du triplet RDF) passe forcément par l’utilisation d’un prédicat. C’est pourquoi GND Ontology l’ontologie de la Deutsche Nationalbibliothek met à disposition la propriété (en non pas la classe) Date of birth qui permet la déclaration suivante :

@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix gnd: <http://d-nb.info/standards/elementset/gnd#> .

prelib:person/80 a cidoc:Person, foaf:Person , gnd:DifferentiatedPerson ;
dc:title "Théodore-Claude-Henri Hersart de la Villemarqué (1815-1895)"@fr ;
foaf:name "Théodore-Claude-Henri Hersart de la Villemarqué"@fr ;
gnd:dateOfBirth "1815/07/07"^^xsd:date .

Bon, ce billet est assez long comme ça. La suite au prochain épisode…

  1. Comité International pour la DOCumentation du Conseil international des musées []
  2. Conceptual Reference Model []
  3. Linked Open Vocabularies est un projet hébergé par l’Open Knowledge Fundation qui propose le référencement d’ontologies pour le web des données. []
  4. Wiki qui n’est certes pas mis en avant. []
  5. Pour en savoir plus, vous pouvez consulter la page Wikipedia sur la négociation de contenu : http://fr.wikipedia.org/wiki/N%C3%A9gociation_de_contenu. []
  6. L’acte de naissance de Théodore Hersart de la Villemarqué peut-être consulté en ligne dans la version numérisée des actes de naissances de Quimperlé entre 1814 et 1822 sur le portail des Archives départementales du Finistère. []
  7. Si vous n’êtes pas familiers avec ce vocabulaire, lisez le RDF 1.1 Primer du W3C. C’est une bonne introduction au web sémantique []
  8. Pour le concept de triplets RDF composés d’un sujet, d’un prédicat et d’un objet, lire le RDF 1.1 Primer. []

La saisie et les requêtes de dates pour la prosopographie (1ère partie)

Avertissement : Cet article est en cours de rédaction mais il est publié pour permettre une discussion sur ce sujet.

Depuis 2012, date de mon arrivée à l’UMS, je travaille avec deux enseignantes-chercheuses de Celtique, Mannaig Thomas et Nelly Blanchard à une base de données prosopographique des auteurs de langue bretonne. Cette base de données a été créée dans le cadre du projet PRELIB dont une des ambitions est de comprendre les raisons qui ont poussé des personnes à écrire et à publier en breton. En effet, écrire en breton, langue de tradition orale, ne va pas de soi et résulte d’un choix qui peut être influencé par la fréquentation de personnes rencontrées dans des lieux de sociabilité tels que des cercles littéraires, des associations ou des mouvements politiques.

La base contient des informations du type : François Jaffrennou est né le 15 mars 1879 à Carnoët, il a étudié au Collège Notre-Dame-de-Bon-Secours à Guingamp vers 1891 puis a débuté des études de droit à Rennes en 1899. Il a contribué aux revues An Oaled, War Sao, Buez Breiz. Il a été secrétaire de la section Langue et Littérature Bretonne de l’Union Régionaliste Bretonne à partir du 14 aout 1898. Il est l’auteur de Oberou yaouankiz, Ganedigez eun emzao, Le dictionnaire français-breton de poche.

Dans cette base de données relationnelle, conçue avec mySQL, la plupart des dates (par ex. une date de naissance) ne sont pas saisies dans un seul champ sous la forme d’une date complète (un jour, un mois, une année) mais dans trois champs séparant la saisie du jour, du mois et de l’année. Du point de vue du stockage, les dates ne sont pas stockées au format SQL DATE mais dans trois champs SQL de type INTEGER (un chiffre entier).

Les bases de données relationnelles ne permettent pas la saisie d’intervalles de temps. Elles ne permettent la saisie de données temporelles que sous la forme de dates (avec obligatoirement un jour, un mois, une année). Or les données historiques sont souvent imprécises et il n’est pas rare que l’on ne connaisse pas la date complète d’un événement (une date de naissance, la date à laquelle un individu a été élu président d’une association, etc.). La séparation de la saisie a donc été envisagée sous la forme de trois champs séparés pour le jour, le mois et l’année en attendant de trouver une solution plus orthodoxe.

Dans les bases de données SQL, les données de type date sont stockées au format aaaa-mm-jj (je parle bien ici du stockage dans la base et non pas de la saisie, le stockage dans ce format n’empêchant pas la saisie dans un formulaire web de dates au format français jj/mm/aaaa). La date du 3 juillet 1896 sera donc stockée sous la forme 1896-07-03.

On pourrait alors envisager de stocker une date incomplète en remplaçant le jour ou le mois par des zéros. Par exemple, si l’on sait que la personne est née en 1896 sans aucune précision sur le mois ou le jour de naissance, on pourrait stocker la date 1896-00-00 dans la base. Et si l’on sait au moins qu’elle est née en juillet 1896 de stocker la date 1896-07-00.

Mais cette solution amène d’autres problèmes : Premièrement, Django, le framework qui sert à élaborer les formulaires de saisie de notre base ne permet pas la saisie de dates non “valides” et l’adaptation de Django pour ajouter cette fonctionnalité ne semble pas chose aisée (Tout du moins si l’on en juge par la question How to deal with “partial” dates (2010-00-00) from MySQL in Django? posée sur le site de questions-réponses Stack Overflow en juin 2010).

Deuxièmement, il faudrait aussi adapter Django pour l’affichage des dates incomplètes. Car une personne souhaitant consulter la base comprendra peut-être qu’une personne est née en juillet 1896 mais comprendra moins l’affichage de 1896-07-00 ou 00/07/1896.

D’autre part les requêtes dans la base ne donnent pas des résultats attendus. En partant de la table prelib_participe_collectif qui stocke les participations d’individus à des collectifs, j’ai saisi des dates d’entrées dont certaines sont incomplètes (la saisie a été faite directement dans la base avec phpMyAdmin, sans passer par Django) : 0000-05-03 (le 3 mai d’une année indéterminée ?), 1898-08-14, 1959-00-00 (l’année 1959 ?), 1959-05-00 (le mois de mai 1959 ?), 1959-06-08, 2015-08-09.

Or la requête qui devrait permettre de récupérer les dates d’entrées dans des collectifs postérieures au 16 mai 1959 ne renvoie que 1959-06-08 et 2015-08-09 :

SELECT `date_entree`
FROM `prelib_participe_collectif`
WHERE `date_entree` > ‘1959-05-16’
ORDER BY `id_participe_collectif`

Alors que la requête qui devrait permettre de récupérer les dates d’entrées dans les collectifs antérieures au 16 mai 1959 renvoie les dates 0000-05-03, 1898-08-14, 1959-00-00, 1959-05-00 :

SELECT `id_participe_collectif`, `date_entree`
FROM `prelib_participe_collectif`
WHERE `date_entree` < ‘1959-05-16’
ORDER BY `id_participe_collectif`

Cela vient du fait que 1959-00-00 reste une date et n’est pas considérée par mySQL comme l’année 1959 soit une durée entre le 1er janvier 1959 à 0h et le 31 décembre 1959 à minuit. mySQL doit probablement comparer les années (1959 = 1959) puis les mois (00 < 05) puis les jours (00 < 16) de ces deux “dates” et en déduire que 1959-00-00 < 1959-05-16.

Ce qui amène à la constatation suivante : Les “dates” incomplètes sont en fait des durées (l’année 1959, le mois de mai 1959, d’avril à juin 1959). Il faudrait donc plutôt stocker une date de début et une date de fin quand on ne connait pas la date exacte d’un événement.

A ce propos, les développeurs de l’outil de création de bibliothèques numériques CollectiveAccess sont même allés plus loin puisqu’ils stockent toutes les métadonnées temporelles décrivant un document sous forme de durées. Ainsi la date du 7 juin 2007 est stockée sous la forme des deux dates (à la seconde près) du 7 juin 2007 à 00:00:00 et du 7 juin 2007 à 24:59:59. L’avantage de cette solution est que les deux dates sont stockées dans le format SQL TIMESTAMP prévu à cet effet. On bénéficie alors de tous les avantages des requêtes sur les dates en SQL.

Ce changement de paradigme du stockage d’une date vers le stockage d’une durée change aussi les requêtes. On ne fait plus de requête pour trouver les dates d’entrées dans un collectif antérieures au 16 mai 1959 pour reprendre l’exemple précédent, mais pour trouver des intervalles de temps terminés avant l’intervalle de temps du 16 mai 1959 à 00:00:00 au 16 mai à 24:59:59 ou des intervalles de temps dans lequel le 16 mai 1959 est compris.

Que donneraient donc les requêtes SQL sur des dates uniquement stockées sous forme d’intervalles temporels ? Ne seront-elles pas trop complexes ?

Autre piste : Le stockage en RDF offre-t-il des avantages pour le stockage des dates et à quoi ressemblerai des requêtes sur des durées avec SPARQL ?

Quel environnement de travail pour l’analyse de données avec Python ?

Si R est un langage de programmation qui revient souvent dans les articles sur l’analyse de données en Sciences Humaines et Sociales, Python a pour l’instant ma préférence. En effet, dans une petite UMS (Unité Mixte de Service) comme le Centre de Recherche Bretonne et Celtique où l’on doit être au four et au moulin, de la mise en place d’interfaces pour la saisie et la consultation dans des bases de données au traitement, la visualisation et l’analyse des données, Python, langage à tout faire, est un choix judicieux.

Quand vous développez en Python (mais c’est valable dans d’autres langages), vous évitez de réinventer la roue et vous utilisez ce que l’on appelle des librairies, c’est à dire des morceaux de codes développés par des tiers pour des usages spécialisés. Pour le traitement et l’analyse de données, je m’intéresse actuellement à la librairie Pandas (je vous conseille d’ailleurs la lecture du livre Python for Data Analysis par l’auteur de la librairie). Or quand vous utilisez Pandas et les librairies dites “scientifiques” comme NumPy et SciPy, il est habituellement conseillé d’installer des logiciels qui fournissent un environnement de travail clé en main tels que Enthought Canopy ou Anaconda (la bonne version de Python, les librairies scientifiques et leurs dépendances, des outils de mise à jour des libraires, un IDE1, etc.).

J’utilisais jusqu’à présent Anaconda mais je rencontrais depuis quelques temps des problèmes à répétition avec son IDE Spyder. Anaconda installait également bon nombre de librairies dont je n’avais pas l’usage et il m’imposait d’anciennes versions de ces librairies pour des raisons de compatibilité. Je suis donc passé à une solution plus légère basée sur Miniconda (la version allégée d’Anaconda), la console IPython et la version gratuite de l’IDE PyCharm, que j’utilise par ailleurs pour la configuration de Django.

Pour configurer vous aussi cet environnement de travail sous Windows, commencez par installer Miniconda 32 bits (Même si vous avez un environnement en 64 bits, je ne suis pas sûr que cela vaille la peine d’utiliser la version 64 bits de Miniconda, sauf usage spécifique). Vous avez aussi le choix de télécharger Miniconda avec Python 2.x ou avec Python 3.x. Ce choix concerne la version de Python dans l’environnement Miniconda par défaut. Cela ne vous empêchera pas de créer des environnements basés sur l’une ou l’autre de ces versions de Python.

Lors du processus d’installation de Miniconda, cochez l’option “Add Anaconda to the system PATH environment variable” et ne tenez pas compte du message d’avertissement qui s’affiche en rouge. Si vous ne le faites pas, vous pourrez toujours utiliser Miniconda mais uniquement en passant par sa propre invite de commande, Miniconda ne pourra pas être lancé depuis cmd.exe2.

Mettez ensuite à jour l’application conda à jour : Lancez l’invite de commandes Windows cmd.exe en tapant “cmd” dans la recherche de programmes et de fichiers du menu Démarrer et cliquez sur cmd.exe.

Dans Cmd, tapez conda update conda et validez les éventuelles mises à jour.

conda update conda

Si la mise à jour est refusée pour des raison de droits insuffisants (Message ‘Accès refusé’), relancez cmd.exe en mode administrateur : Lancez Cmd en tapant “cmd dans la recherche de programmes et de fichiers du menu Démarrer puis cliquez avec le bouton droit de la souris sur l’icône de cmd.exe et choisissez Exécuter en tant qu’administrateur.

Si vous avez par la suite des problèmes de droits pour installer ou mettre à jour des librairies Python, pensez à exécuter Cmd en tant qu’administrateur.

Nous allons ensuite procéder à la création d’un environnement virtuel. En effet, quand on utilise Python pour divers usages, mieux vaut ne pas mettre tous ses œufs dans le même panier et créer un environnement de développement par usage, c’est à dire un environnement dans lequel seront uniquement installées les librairies nécessaires.

Pour créer l’environnement virtuel “pandas”, tapez en ligne de commande conda create -n pandas python=3. Si vous souhaitez utiliser Python 2 remplacez le chiffre 3 par 2. Une fois l’environnement installé, activez-le avec la commande activate pandas. Installez ensuite Pandas et IPython par conda install pandas ipython.

Il est également possible d’installer la plupart des librairies avec la commande pip. Le problème, c’est que l’installation de certaines librairies Python nécessite la compilation de code C ou C++. Ce qui pose la plupart du temps des problèmes sous Windows. L’avantage de passer par conda, c’est de pouvoir récupérer des packages pré-compilés. L’inconvénient est que conda interroge par défaut un dépôt de librairies où elles ne sont pas toutes disponibles et si elles le sont, dans leur dernière version. Pour contourner le problème, il est toujours possible d’utiliser un autre dépôt compatible Miniconda (à trouver sur l’Anaconda Cloud puis à configurer selon la documentation de Miniconda), soit d’utiliser pip et des packages pré-compilés de Christoph Gohlke.

Installez ensuite la version Community de PyCharm. Après la création de votre premier projet dans PyCharm (menu File > New Project), allez dans le menu File > Settings puis dans Project:nom_de_votre_projet, puis cliquez sur Project Interpreter. Créez un nouvel interpréteur en cliquant sur la roue crantée puis sur Add ((La procédure et les captures d’écran sont susceptibles de changer avec la version de PyCharm. Les captures d’écran actuelles ont été faites avec la version 2018 de PyCharm.)).

Choisissez un environnement de type Conda Environment et cochez Exiting environment et Make available to all projects. Cliquez sur le bouton avec trois points (…) pour faire apparaitre la fenêtre de sélection du répertoire dans lequel se trouve l’environnement que vous avez créé précédemment.

Pour savoir où a été installé l’environnement, lancez la commande conda info --env dans Cmd. Dans mon cas, l’environnement pandas a été installé dans C:\ProgramData\Miniconda3\envs\pandas.

Sélectionnez le fichier python.exe dans le répertoire de l’environnement.

Normalement, PyCharm détecte automatiquement l’installation de IPython et propose ce  terminal amélioré quand vous lancez la console Python depuis le menu Tools > Python Console.

Pour installer des librairies complémentaires, vous pouvez utiliser PyCharm mais je vous déconseille de le faire car l’application utilise uniquement pip. Préférez plutôt une installation avec conda en ligne de commande comme vous l’avez fait pour installer Pandas.

Il ne vous reste plus qu’à vous lancer dans l’analyse de données avec Python.

Article mis à jour le 23 mai 2018

  1. Integrated Development Environment, voir http://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement []
  2. Au sujet de cmd.exe, voir https://fr.wikipedia.org/wiki/Cmd. []