Atelier “Interpréter son corpus de texte avec Iramuteq ou Alceste”

Lundi 23 mai de 14h00 à 16h00 – salle de formation de la Bibliothèque Universitaire de Lettres 11, Avenue Foch  29200 Brest

Cet atelier proposé par le séminaire Outils du Quanti à Brest s’inscrit dans la continuité de l’intervention de Catherine Adam et Cécile Plaud “Interpréter avec Alceste (ou IramuteQ)” à l’occasion du Séminaire Humanités Numériques 2022 #1 – Utiliser des outils et des services numériques dans sa pratique d’analyse de discours (oraux et écrits) – organisé par la Maison des sciences de l’homme en Bretagne le 14 avril 2022.

Vous pouvez réécouter sur la page du séminaire HN 2022 ou sur Canal U l’intervention de Catherine Adam et Cécile Plaud.

Pré-requis : Il ne s’agit pas d’une formation de découverte de Iramuteq ou de Alceste. Les participants devront déjà être familiers avec une utilisation de base d’un de ces logiciels et devront déjà avoir pré-analysé leur jeu de données.

Public : L’atelier est ouvert aux doctorants, post-doctorants, aux chercheurs, enseignants-chercheurs et aux personnels d’appui à la recherche ayant déjà pratiqué l’analyse textuelle avec Iramuteq ou Alceste mais souhaitant confronter et approfondir l’interprétation des résultats de leur corpus de texte.

Formatrices : Catherine Adam et Cécile Plaud, enseignantes-chercheuses du pôle Sciences humaines et sociales de l’École nationale supérieure de techniques avancées Bretagne (ENSTA Bretagne)

Matériel nécessaire : Un ordinateur portable avec Iramuteq ou Alceste installé et votre propre jeu de données prêt à être chargé dans Iramuteq ou Alceste.

Nombre de places disponibles : 20 places, sur pré-inscription

Date : Lundi 23 mai 2022 de 14h00 à 16h00

Lieu : Salle de formation de la Bibliothèque Universitaire de Lettres 11, Avenue Foch  29200 Brest

Pré-Inscriptions : https://forms.gle/Rg3gE8CgjuNs5Dre9

Des fichiers Excel au SQL, introduction aux bases de données relationnelles

Cet article, ainsi que Des fichiers Excel au SQL, bonnes pratiques avec Excel et LibreOffice Calc a été publié à la suite de la séance du 10 février 2020 du séminaire Outils du Quanti en SHS, Des fichiers Excel au SQL, introduction aux bases de données relationnelles .

Si vous stockez des données dans des fichiers Excel ou LibreOffice Calc (fichiers .ods) et que vous êtes confronté à des difficultés pour saisir vos données et les interroger, le passage à une base de données relationnelles est peut-être à envisager.

Admettons que vous souhaitiez étudier la production littéraire en langue bretonne. Vous créez un fichier Excel avec une colonne Titre pour saisir le titre des œuvres. Mais comment allez-vous gérer la saisie des auteurs ? Si une œuvre a plusieurs auteurs, allez-vous créer autant de colonnes que d’auteurs ou saisir les auteurs dans la même cellule de la colonne Auteurs ? Dans ce cas, comment trier les œuvres par auteur ? Comment afficher toutes les œuvres écrites par le même auteur ? Et si vous souhaitez par exemple connaître toutes les œuvres écrites par des auteurs nés à Quimperlé au XIXe siècle, comment saisir la ville et l’année de naissance des auteurs ? Vous pouvez choisir de créer une nouvelle feuille de calcul pour ne saisir que les données sur les auteurs, attribuer un chiffre pour identifier les auteurs et ne saisir dans la feuille des œuvres que l’identifiant des auteurs. Mais si vous supprimez un auteur, comment mettre à jour automatiquement les œuvres qui lui ont été attribuées ?

Pour résoudre ce type de difficultés, une solution : les bases de données relationnelles. Voyons tout de suite à quoi pourrait ressembler nos données sur la production littéraire en breton dans la base de données prelib.odb créée avec le logiciel LibreOffice Base. Les données de ce fichier sont une extraction de la base de données en ligne PRELIB1 (Projet de recherche en littérature de langue bretonne) du Centre de recherche bretonne et celtique2.

Les bases de données relationnelles stockent les données dans des tables ou relations, d’où le terme relationnel pour désigner ce type de bases de données. Le contenu d’une table peut être affichée sous la forme de tableau, avec des lignes et des colonnes, mais une table de base de données n’a rien à voir avec une feuille de calcul Excel.

Les systèmes de gestion de bases de données relationnelles

Pour créer et gérer des bases de données relationnelles, il faut un SGBD relationnel, un système de gestion de bases de données relationnelles. Les SGBD relationnels les plus courants sont MySQL, SQLite et PostGreSQL.

Vous n’avez probablement jamais entendu parler de ces SGBD mais lorsque vous consultez votre messagerie, quand vous mettez à jour votre blog sous WordPress, quand vous utilisez Dropbox, iTunes ou Skype, quand vous consultez en ligne votre journal favori, vous utilisez sans le savoir un SGBD.

Le principal avantage des bases de données relationnelles est le SQL, acronyme de Structured Query Language, un langage de requête qui permet de rechercher, ajouter, modifier ou supprimer des données dans les bases de données relationnelles.

LibreOffice Base

Dans ce tutoriel, vous allons utiliser LibreOffice Base, l’équivalent de Microsoft Access. Un SGBD relationnel de la suite LibreOffice. A l’inverse de MySQL, SQLite ou PostGreSQL, LibreOffice Base n’est pas adapté pour le partage des données sur un réseau informatique ou sur le web mais il fait très bien l’affaire pour un usage sur son ordinateur personnel.

Tables, clés primaires, clés étrangères et schéma de la base de données

Le fichier prelib.odb (à télécharger) contient quatre tables : Personne, Ville, Oeuvre et EcritOeuvre. Si vous ouvrez ce fichier avec LibreOffice Base et que vous double-cliquez sur chacune de ces tables, vous constaterez qu’elles ont toutes une colonne (ou attribut) “ID”. Cette colonne est la clé primaire de chaque table, sa valeur permet d’identifier de manière unique chaque ligne (ou enregistrement) de la table. Notez que si nous avions eu la garantie par exemple, qu’aucune personne ne pouvait avoir le même nom, la même date et la même ville de naissance qu’une autre, la combinaison de ces trois colonnes aurait pu servir de clé primaire pour la table Personne.

Contenu de la table Personne

Contenu de la table Personne

Dans la table Personne, les villes de naissance et de décès ne sont pas saisies en toutes lettres mais en faisant référence aux clés primaires de la table Ville. Par exemple, le premier individu, Jean-Guillaume Henry, a pour identifiant de ville de naissance le numéro 215, qui correspond dans la table Ville à la clé primaire de la commune de Mellac. Les attributs ville_naissance_id, ville_deces_id sont appelées clés étrangères.

Contenu de la table Ville

Contenu de la table Ville. La ville de Mellac a pour identifiant ID = 215.

Le fait de saisir les villes dans une table séparée plutôt que directement dans la table Personne a plusieurs avantages :

  1. La table Ville peut contenir d’autres informations que le nom de la ville, par ex. les coordonnées géospatiales pour l’affichage d’une carte, l’identifiant de la ville dans d’autres référentiels (code INSEE pour les villes françaises, identifiant Geonames).
  2. La Ville peut être utilisée pour d’autres tables. Par exemple, pour saisir la ville de l’éditeur de l’œuvre.
  3. Si l’on se trompe dans l’orthographe du nom de la ville, il suffit de le mettre à jour dans la table Ville et non plus partout où il a été utilisé, comme ce serait le cas avec un fichier Excel.

♣ Le nom de la ville n’aurait pas pu servi de clé primaire (d’identifiant unique d’une ville) car le vaste Monde ne manque pas de villes qui portent le même nom. Le code postal n’aurait pas pu servir de clé primaire car certains codes postaux regroupent plusieurs communes. Les codes communes de l’INSEE n’aurait également pu faire l’affaire car nous n’aurions pas pu saisir de villes postérieures à la création de l’INSEE et des villes de pays étrangers.

Bien entendu, la gestion des clés primaires doit être transparente pour l’utilisateur. En général, on laisse au logiciel de base de données le soin de générer la clé primaire pour chaque nouvel enregistrement.

Le schéma de la base de données (menu Outils > Relations) permet d’avoir une vue synthétique des tables et des relations entre elles.

Schéma de la base de données prelib.odb

Schéma de la base de données prelib.odb

Le fichier prelib.odb ne contient pas de formulaires de saisie mais il est possible d’en créer pour faciliter le choix des villes de naissance et de décès à l’aide de menus déroulants.

Qui est né à Mellac ?

Voyons maintenant notre première requête à l’aide du langage SQL. Allez dans le menu Insertion > Requête (mode SQL), saisissez la requête ci-dessous, puis choisissez dans le menu Édition > Exécuter la requête :

SELECT nom FROM Personne WHERE ville_naissance_id = 215

Le résultat de la requête est Jean-Guillaume Henry :

Personnes nées à Mellac

Requête SQL pour afficher le nom des personnes nées à Mellac

La commande SELECT permet d’extraire des données de la base. Entre SELECT et FROM, on précise les informations que l’on souhaite récupérer. FROM permet de préciser la table dans laquelle effectuer la requête.  La commande WHERE permet de préciser que l’on ne veut que les individus nés à Mellac. Le résultat est un nouveau tableau qui ne contient, selon ce critère, qu’une seule colonne (le nom de l’individu) et une seule ligne.

Pour afficher toutes les colonnes de la table Personne correspondant à ce critère, il suffit d’utiliser * :

SELECT * FROM Personne WHERE Personne.ville_naissance_id = 215

Qui sont les femmes nées au XIXe siècle ?

La commande optionnelle WHERE (combinée avec AND ou OR) peut s’appliquer à n’importe quelle colonne de la table Personne. Par exemple, la requête suivante permet d’afficher les femmes nées au XIXe siècle :

SELECT nom, sexe, annee_naissance, annee_deces FROM Personne WHERE annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F'

Les femmes nées au XIXe siècle

Les femmes nées au XIXe siècle

LIKE associé à % permet d’afficher les femmes dont le nom contient “Jeanne” (la requête est sensible à la case).

SELECT nom, sexe, annee_naissance, annee_deces FROM Personne WHERE sexe = 'F' AND nom LIKE '%Jeanne%'

Notez que le sexe a été précisé entre guillemets car cet attribut est de type Texte (chaîne de caractères, nombres y compris). En effet, dans une base de données relationnelle, tous les attributs (ou colonnes) des tables sont typés. Dans LibreOffice Base, les types peuvent être affichés par un clic-droit sur la table puis Éditer.

Les principaux types de données sont Texte (VARCHAR), Entier (INTEGER), Nombre (NUMERIC) et Date.

Des fonctions peuvent être appliquées aux attributs selon leur type. Pour les entiers et les nombres : SUM (somme), AVG (“average”, moyenne), SQRT (“square”, racine carrée), EXP (exponentielle), etc. Pour les dates : DATEDIFF (différence entre deux dates), DAY (jour du mois), YEAR (année de la date), etc. Toutes les fonctions sont listées dans le chapitre Built-in functions and stored procedures du LibreOffice Base Handbook (PDF).

Dans prelib.odb, les dates ont été séparées en trois attributs jour, mois et année car les dates de naissance et de décès sont parfois incomplètes. Or le format Date n’autorise que la saisie que de dates dont le jour, le mois et l’année sont connus.

Classement par année de naissance

Pour faciliter la lecture de la liste des femmes nées au XIXe siècle, la commande ORDER BY permet de classer les résultats par année de naissance croissante (ASC = ascendant, DESC = descendant).

SELECT nom, sexe, annee_naissance, annee_deces FROM Personne WHERE annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F' ORDER BY annee_naissance ASC

Les femmes nées au XIXe siècle, classées par année de naissance croissante

Les femmes nées au XIXe siècle, classées par année de naissance croissante

Nombre de femmes nées au XIXe siècle

Pour afficher le nombre de femmes nées au XIXe siècle, il faut utiliser la commande COUNT(*) :

SELECT COUNT(*) FROM "Personne" WHERE "annee_naissance" < 1900 AND "annee_naissance" >= 1800 AND "sexe" = 'F'

Nombre de femmes nées au XIXe siècle

Nombre de femmes nées au XIXe siècle

Il est possible de préciser le nom d’une colonne dans les paramètres de COUNT. Dans ce cas, COUNT(nom_colonne) renvoie le nombre de lignes où le contenu de la colonne est non NULL (NULL correspond à “aucune valeur saisie”). Par ex. la requête suivante renvoie le nombre de personnes pour lesquelles le jour de naissance a été saisi :

SELECT COUNT(jour_naissance) FROM "Personne"

Il est même possible d’afficher le nombre de personnes pour lesquelles le jour de naissance n’a pas été saisi avec cette soustraction :

SELECT COUNT(*) - COUNT(jour_naissance) FROM "Personne"

Nombre de femmes nées dans l’année

La commande GROUP BY permet de regrouper les lignes selon certains critères. Par exemple, la requête suivante regroupe les femmes par année de naissance et affiche le nombre de femmes nées dans l’année :

SELECT COUNT(*), "annee_naissance" FROM "Personne" GROUP BY "annee_naissance" ORDER BY "annee_naissance" ASC

Puisque nous avons utilisé COUNT(*) et non pas COUNT(annee_naissance),  le résultat renvoie également le nombre de femmes (28) dont l’année de naissance n’a pas été saisie.

Nombre de femmes nées dans l’année

Nombre de femmes nées dans l’année

Les femmes nées au XIXe et leur commune de naissance

Pour afficher toutes les femmes nées au XIXe avec leur ville de naissance, nous allons faire  une jointure (JOIN) avec la table Ville, c’est à dire une table virtuelle constituée par la combinaison des tables Personne et Ville par l’intermédiaire de la clé étrangère de Personne, ville_naissance_id, et de la clé primaire de ville, ID. La jointure permet d’ajouter Ville.nom au SELECT.

SELECT Personne.nom AS NomPersonne, Ville.nom AS NomVille FROM Personne JOIN Ville ON Ville.ID = Personne.ville_naissance_id WHERE annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F' ORDER BY NomPersonne ASC

L’attribut nom étant utilisé tout aussi bien dans la table Ville que dans table Personne, on préfixe les attributs par le nom de la table (par ex. Personne.nom). Et pour afficher des titres de colonnes du résultat plus explicites, on utilise des alias (commande AS), dont on se sert aussi pour afficher les résultats par ordre alphabétique du nom des femmes (ORDER BY NomPersonne ASC).

Femmes nées au XIXe siècle avec leur ville de naissance

Femmes nées au XIXe siècle avec leur ville de naissance

Si vous utilisez un SELECT * , vous pourrez constater que la réponse à cette requête est bien un tableau où chaque ligne est constituée de tous les attributs d’une femme (ID, sexe, nom, jour_naissance, …, ville_naissance_id, jour_deces, … ville_deces_id, …, ark_bnf, isni) et tous les attributs de sa ville de naissance (ID, nom, wikidata).

SELECT * FROM Personne JOIN Ville ON Ville.ID = Personne.ville_naissance_id WHERE annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F' ORDER BY Personne.nom ASC

Notez que la requête précédente ne renvoie que 13 résultats alors qu’il y a 20 femmes nées au XIXe dans prelib.odb. Cela vient du fait que la ville de naissance n’a pas été saisie pour 7 d’entre elles. La commande LEFT JOIN permet d’intégrer dans le résultat toutes les femmes, (toutes les lignes de Personne correspondant au critère annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F') même si la correspondance Ville.ID = Personne.ville_naissance_id n’est pas possible :

SELECT Personne.nom AS NomPersonne, Personne.annee_naissance, Ville.nom AS NomVille FROM Personne LEFT JOIN Ville ON Ville.ID = Personne.ville_naissance_id WHERE annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F' ORDER BY Personne.annee_naissance ASC

Femmes nées au XIXe sciècle avec leur ville de naissance (si elle a été saisie)

Femmes nées au XIXe sciècle avec leur ville de naissance (si elle a été saisie)

Puisque l’on sait écrire une requête pour afficher toutes les femmes nées au XIXe et leur ville de naissance, avec une case vide si cette information est absente, on peut donc afficher les femmes qui n’ont pas encore de ville de naissance en rajoutant le critère  AND Ville.nom IS NULL (NULL correspond à “aucune valeur saisie”) :

SELECT Personne.nom AS NomPersonne, Personne.annee_naissance, Ville.nom AS NomVille FROM Personne LEFT JOIN Ville ON Ville.ID = Personne.ville_naissance_id WHERE annee_naissance < 1900 AND annee_naissance >= 1800 AND sexe = 'F' AND Ville.nom IS NULL ORDER BY Personne.annee_naissance ASC

Femmes nées au XIXe dont la ville de naissance n'a pas été saisie

Femmes nées au XIXe dont la ville de naissance n’a pas été saisie

Toutes les femmes ayant écrit une œuvre

Les personnes sont liées aux œuvres qu’ils ont écrites par l’intermédiaire de la table EcritOeuvre, car une clé étrangère oeuvre_id ajoutée à la table Personne ne permettrait pas la saisie d’un nombre illimité d’œuvres écrites par le même individu. EcritOeuvre a trois attributs, sa clé primaire, ID, et deux clés étrangères, oeuvre_id et personne_id, qui font référence aux clés primaires de Oeuvre et Personne respectivement.

Schéma de la table EcritOeuvre

Schéma de la table EcritOeuvre

Une femme auteure est donc une personne de sexe féminin qui apparait au moins une fois dans EcritOeuvre. Afin de récupérer le nom de l’auteure, on crée une jointure avec la table Personne :

SELECT Personne.nom FROM EcritOeuvre JOIN Personne ON Personne.ID = EcritOeuvre.personne_id WHERE Personne.sexe = 'F' ORDER BY Personne.nom

Notez que l’on aurait tout aussi bien faire un SELECT sur Personne et faire une jointure avec EcritOeuvre :

SELECT Personne.nom FROM Personne JOIN EcritOeuvre ON Personne.ID = EcritOeuvre.personne_id WHERE Personne.sexe = 'F' ORDER BY Personne.nom

Par contre, certaines femmes sont affichées plusieurs fois :

Femmes auteures (avec doublons)

Femmes auteures (avec doublons)

C’est normal, la jointure associe chaque femme avec toutes ses œuvres. Le nom d’une écrivaine apparait donc autant de fois qu’elle a écrit d’œuvres. Pour supprimer les doublons, il suffit d’utiliser DISTINCT :

SELECT DISTINCT "Personne"."nom" FROM "EcritOeuvre" JOIN "Personne" ON "Personne"."ID" = "EcritOeuvre"."personne_id" WHERE "Personne"."sexe" = 'F'

Femmes auteures (sans doublons)

Femmes auteures (sans doublons)

Toutes les femmes qui ne sont pas écrivaines

Pour afficher les femmes qui n’ont pas écrit d’œuvres, on peut commencer par écrire une requête pour afficher toutes les femmes, qu’elles aient écrit une œuvre ou non.

Pour cela, faut faire une jointure par la droite avec RIGHT JOIN. C’est à dire que l’on veut toutes les lignes de la table située à droite de JOIN, c’est à dire Personne, même s’il n’existe pas de correspondance à cette table dans EcritOeuvre (autrement dit, même s’il n’existe aucune référence à la personne dans EcritOeuvre). Afin de nous aider à y voir plus clair dans le résultat obtenu, on affiche le nom de la personne et l’identifiant de l’œuvre.

SELECT "Personne"."nom", "EcritOeuvre"."oeuvre_id" FROM "EcritOeuvre" RIGHT JOIN "Personne" ON "Personne"."ID" = "EcritOeuvre"."personne_id" WHERE "Personne"."sexe" = 'F' ORDER BY "Personne"."nom"

La case est vide pour les femmes n’ayant pas écrit d’œuvres :

Ebauche de la requête des femmes n'ayant pas écrit d'œuvres

Ébauche de la requête des femmes n’ayant pas écrit d’œuvres

Il suffit donc de rajouter le critère AND "EcritOeuvre"."oeuvre_id" IS NULL à la précédente requête (EcritOeuvre"."oeuvre_id dans le SELECT est optionnel) :

SELECT "Personne"."nom", "EcritOeuvre"."oeuvre_id" FROM "EcritOeuvre" RIGHT JOIN "Personne" ON "Personne"."ID" = "EcritOeuvre"."personne_id" WHERE "Personne"."sexe" = 'F' AND "EcritOeuvre"."oeuvre_id" IS NULL ORDER BY "Personne"."nom"

Femmes n'ayant pas écrit d'œuvres

Femmes n’ayant pas écrit d’œuvres

Pour information, on aurait aussi pu écrire une requête sur Personne et faire une jointure par la gauche (LEFT JOIN) sur EcritOeuvre, c’est à dire en récupérant toutes les lignes de la table située à gauche de JOIN, c’est à dire Personne, même s’il n’existe pas de correspondance à cette table dans EcritOeuvre:

SELECT "Personne"."nom", "EcritOeuvre"."oeuvre_id" FROM "Personne" LEFT JOIN "EcritOeuvre" ON "Personne"."ID" = "EcritOeuvre"."personne_id" WHERE "Personne"."sexe" = 'F' AND "EcritOeuvre"."oeuvre_id" IS NULL ORDER BY "Personne"."nom"

Pour en savoir plus

Nous avons abordé les possibilités qu’offrent les bases de données relationnelles et le langage SQL.

Pour en savoir plus sur la conception de bases de données avec LibreOffice Base, consultez le guide officiel Débuter avec Base (traduction française, pour la version 6.0 de LibreOffice) et le LibreOffice Base Handbook (en anglais, pour la version 4.0 de LibreOffice mais qui doit être valable pour les version ultérieures). Vous trouverez des guides pour les versions antérieures de LibreOffice sur le wiki de la Document Foundation.

Pour aller plus loin avec le langage SQL, je vous conseille la lecture de Administrez vos bases de données avec MySQL de Chantal Gribaumont qui peut être lu et téléchargé au format epub sur Zeste de Savoirs ou acheté en version imprimée.

Dans une approche plus technique, il existe également Not Only SQL de Vincent Lozano et Étienne Georges (Licence Art Libre) paru chez Framabook.

  1. Nelly Blanchard, Jean-Baptiste Pressac et Mannaig Thomas, « PRELIB, base de données sur les acteurs du domaine littéraire en langue bretonne »Lengas [En ligne], 84 | 2018, mis en ligne le 15 juillet 2018, consulté le 27 mars 2020. URL : http://journals.openedition.org/lengas/1754 ; DOI : https://doi.org/10.4000/lengas.1754 []
  2. https://www.univ-brest.fr/crbc/ []

Des fichiers Excel au SQL, bonnes pratiques avec Excel et LibreOffice Calc

Cet article, ainsi que Des fichiers Excel au SQL, introduction aux bases de données relationnelles a été publié à la suite de la séance du 10 février 2020 du séminaire Outils du Quanti en SHS : Des fichiers Excel au SQL, introduction aux bases de données relationnelles .

Qu’est ce qu’une base de données ?

D’après Wikidata, une base de données informatique est une collection organisée de données (voir Outline of databases). Dans cette introduction aux bases de données, nous ne parlerons que de données “brutes” tabulaires, sous forme de tableaux.

Qu’est ce qu’une donnée “brute” ? Le nom de l’officier qui introduit la fraise blanche du Chili en France, sa date et ville de naissance, la liste des pays ayant produit plus de 50.000 tonnes de fraises en 2016, la liste des membres de votre club d’aviron avec leur adresse et leur numéro de téléphone, la température de l’eau sur la plage de Trégana un 21 juillet sont des données “brutes”.

Les tableurs, la forme la plus courante de stockage de données brutes

Les formes les plus courantes de bases de données tabulaires sont les fichiers Microsoft Excel ou LibreOffice Calc. Excel et Calc sont des tableurs, ils servent à manipuler des feuilles de calcul. Ces logiciels sont conçus pour calculer des sommes, des moyennes, des écarts-types, réaliser des tests du χ², des graphiques.

Si vous souhaitez vous servir d’Excel pour stocker la liste des livres écrits en breton du moyen-âge à nos jours avec leur date de publication, leur maison d’édition, leur auteur, la date et le lieu de naissance des auteurs, les collectifs fréquentés par ces auteurs et que vous souhaitez répondre à des questions telles que : Quelle est l’année où le plus d’œuvres en breton ont été publiées ? Quels sont les maisons d’éditions ayant publié les livres des femmes membres de l’Union régionaliste bretonne et de l’Académie des inscriptions et belles lettres ? Quels sont les collectifs dont les membres originaires de Quimperlé ont le plus publié entre 1895 et 1934 ? Même s’il est possible de répondre à certaines de ces questions avec des filtres ou des formules d’Excel ou de Calc, ces tableurs vont vite trouver leurs limites.

Pour répondre à ces questions, il faut passer à une autre forme de bases de données : les bases de données relationnelles et leur langage associé : le SQL.

Mais commençons par aborder les bonnes pratiques qui permettront l’exploitation de fichiers Excel, voire leur versement sans douleur dans une base de données relationnelle.

Bonnes pratiques avec Excel et LibreOffice Calc

La saisie dans Excel étant très permissive, on a tendance à y saisir de l’information sans se soucier de son exploitation. Tel des écureuils qui feraient moult provisions pour l’hiver sans jamais consommer.

Quelles sont les erreurs de saisie à éviter ? Comment passer de la saisie d’informations à la saisie de données exploitables ? Comment préparer l’exploitation et la diffusion de nos données ?

Aidez-vous des filtres pour contrôler les valeurs saisies

Premièrement, il est bon de contrôler régulièrement si l’on a pas fait d’erreur de saisie. Par exemple, vérifier que l’on a pas saisi des prénom dans une colonne Date. Pour avoir un aperçu rapide des valeurs saisies dans les colonnes d’un fichier Excel, sélectionnez la ligne du titre des colonnes puis allez dans le menu Données > AutoFiltre (LibreOffice) ou Données > Filtre (Microsoft Excel, voir la vidéo). Attention, pour que le filtre fonctionne correctement, votre tableau doit être exempt de lignes vides.

Prenons l’exemple l’inventaire du fonds Yves Berthou conservé au Centre de recherche bretonne et celtique : 72262_Inventaire-CRBC-Fonds-Yves-Berthou.xls (le fichier a été zippé). Le filtre permet de se rendre compte que certaines dates ne sont pas au format jj/mm/aaaa. Certaines dates respectent en apparence ce format mais la ligne de saisie permet (la zone dans laquelle vous pouvez saisir des formules) de se rendre compte qu’elles sont précédées d’une cédille (ex. ’31/10/1897).

Une colonne = Une donnée

Mieux vaut saisir dans deux colonnes séparées les dates de naissance et de décès d’une personne plutôt que dans une seule colonne (en les séparant par ex. avec un tiret : 04/07/1682-14/10/1773) et si vous voulez rajouter des commentaires pour préciser par exemple que la date de naissance est inconnue ou citer la source, faites-le dans une colonne dédiée.

Conservez les données sources et utilisez les formats de données

Si vous saisissez des dates, par exemple, vous ne pourrez les exploiter que si elles respectent le format recommandé par Excel, votre logiciel ou votre langage de programmation (R, Python). Autrement dit, Excel ne pourra pas dessiner un graphique avec des dates telles que “date inconnue” ou 13 vendémiaire an IV. Si votre source d’information (par exemple, un manuscrit du XIVe siècle) nécessite un reformatage des dates, créez deux colonnes : une pour la saisie de la date telle qu’elle apparaît dans la source (ex. en toutes lettres : le 3 juillet 1896) et une autre pour la date au format jj/mm/aaaa, voire au format ISO 8601 (aaaa-mm-jj ou aaaa-mm ou aaaa) qui permet la saisie de dates incomplètes.

Pour vous aidez à respecter ces règles, appliquez un format à vos colonnes et utilisez la validation des données. Pour appliquer un format aux colonnes (Nombre, Monétaire, Date, etc.) : Clic droit sur une colonne puis Format de cellule (Excel) ou Formater les cellules (LibreOffice). Pour la validation des données, allez dans le menu Données puis Validation des données (Excel, voir la vidéo) ou Validité (LibreOffice, voir la documentation).

Utilisez des normes et des référentiels internationaux

Afin de faciliter la diffusion de vos données à des collègues ou à un public plus large, utilisez des normes et des référentiels. En effet, les normes ou référentiels vous permettront de désambiguïser vos données (des communes françaises ou des individus portent le même nom, comment les distinguer ?) et de les rendre compréhensibles par des non francophones.

Par exemple, si vous souhaitez saisir la langue d’un document, utilisez la norme ISO 639-3 qui définit des identifiants sur trois lettres pour toutes les langues humaines connues, mortes ou vivantes. En signalant aux utilisateurs que vous utilisez cette norme, il leur suffira de se reporter aux tables de correspondance en ligne pour savoir à quelles langues vous faites référence.

Pour les communes françaises, en plus de leur nom, utilisez les codes INSEE plutôt que les codes postaux car ces derniers peuvent parfois regrouper plusieurs communes. Vous les trouverez sur les pages Wikipédia ou Wikidata des communes concernées. Par exemple, saisissez Quimper (29232) et non pas Quimper (29000).

Excel permet d’attribuer un type aux données saisies dans chaque colonne, notamment le type Date. Mais une date correspondant forcément à un jour, un mois, une année (ex. le 14 juillet 1789), le format Date de Excel ne permet pas la saisie de “dates” incomplètes, par ex. une année ou le mois d’une année donnée (juillet 1789). Pour ce type de données temporelles, gardez le type de colonne par défaut et saisissez vos dates au format ISO 8601, qui permet la saisie d’une année (1789) , du mois d’une année (1789-07) ou d’une date complète (1789-07-14). Ce format permettra également de trier ces “dates” par ordre chronologique.

Pour les noms de personnes connues, utilisez la forme internationale signalée dans les notices de la BnF. Par exemple, la forme internationale de Théodore Hersart de la Villemarqué est La Villemarqué, Théodore Hersart vicomte de (1815-1895). L’écrivain et poète Victor Hugo (auteur du roman Les misérables) a pour forme internationale Hugo, Victor (1802-1885). Ce qui permet de le distinguer de son homonyme chanteur de salsa.

Un autre moyen très efficace pour désambiguïser des lieux et des individus est de créer un colonne dédiée à la saisie du lien vers leur notice sur Wikidata, la plus importante base de connaissance libre et gratuite mondiale. Par exemple, la notice de Victor Hugo (l’écrivain) est https://www.wikidata.org/wiki/Q535.

Voici une liste non exhaustive de normes et de référentiels. Si vous en voyez d’autres, n’hésitez pas à les signaler en commentaire.

Type de données Normes ou référentiels Exemples
Langues norme ISO 639-3 fre, eng, ita, lat
Dates norme ISO 8601 2020-08-13
Communes françaises codes INSEE (disponibles sur les pages Wkipédia ou Wikidata des communes)
Individus et collectifs (entreprises, associations, etc.) IdRef, le catalogue de la BnF, Wikidata
Tout le reste Wikidata

Si vous n’arrivez pas à vous décider pour un référentiel, utilisez les identifiants de Wikidata. Cette base de connaissance, hébergée par la Wikimédia Foundation, propose des notices sur n’importe quel sujet, Victor Hugo (Q535), le zinc (Q758), la ville de Brest (Q12193), les pangolins (Q9027425). Ces pages Wikidata sont liées à de nombreux référentiels. Une fois que vous aurez trouvé le référentiel adéquat, vous pourrez toujours utiliser le logiciel OpenRefine pour récupérer l’identifiant dans le référentiel retenu à partir de l’identifiant Wikidata.

Utiliser le même caractère pour séparer les valeurs multiples

Il est parfois nécessaire de saisir plusieurs valeurs dans la même cellule. Par ex. toutes les langues parlées par la même personne. Utilisez le même caractère pour les séparer. Évidemment, il vaut mieux choisir un caractère que l’on ne risque pas de retrouver dans dans les valeurs à séparer. Par exemple, le symbole ¤ (Alt Gr + $) est un caractère peu utilisé.

Exploitez le plus tôt possible vos données

Même si vos données sont incomplètes, commencez le plus tôt possible à vérifier si les données que vous saisissez sont conformes au format attendu par vos logiciels d’analyse ou de visualisation de données. Par exemple, pour l’affichage d’une frise chronologique avec Timeline.js, il faut des événements avec une année ou une date complète. Pas la peine donc de saisir dans la colonne qui vous servira à faire la frise des dates du type “mai 1978” ou “un jour de juin”, indications à réserver pour une colonne de commentaires au sujet de la date de l’événement.

Nettoyez vos données avec OpenRefine

Au cours de la saisie, vous pouvez introduire des erreurs comme rajouter des espaces en trop ou saisir la même valeur de différentes manières (Saint-Malo, St-Malo, St. Malo). Pour corriger ces problèmes, utilisez le logiciel libre et gratuit OpenRefine.

Documentez vos données

Les titres des colonnes ne suffisent pas toujours à comprendre leur contenu. Joignez à votre fichier .xls ou .ods un fichier texte avec des informations en utilisant le schéma de métadonnées Dublin Core ou la spécification Table Schema.

Sauvegardez vos données

Il faut parfois des mois, voire des années pour constituer un corpus de données. Telles que les données de l’historien Philippe Jarnoux au sujet des bagnards de Brest retranscrites à partir des registres conservés au Service historique de la défense et consultables en ligne sur la biblithèque numérique du CRBC. Perdre ces données à cause d’un disque dur défectueux peut s’avérer catastrophique.Or il existe des solutions de stockage en ligne pour la communauté de la recherche.

Les universités proposent sur leur ENT (espace numérique de travail) des solutions de stockage. Tels que Google Drive et UBOCloud (basé sur le logiciel libre NextCloud) à l’Université de Bretagne Occidentale.

La DSI du CNRS propose à tous les personnels des unités CNRS la solution de sauvegarde MyCORE (basée sur le logiciel libre OwnCloud), qui permet de synchroniser des répertoires d’un ordinateur personnel avec un stockage en ligne.

Huma-Num propose gratuitement à la communauté de la recherche en sciences humaines et sociales les espaces de stockage ShareDocs (avec des fonctionnalités similaires à Google Drive, soit l’édition de fichiers bureautiques, le partage de dossiers avec ou sans mot de passe; accès possible par le protocole WebDAV), Nakala (pour le dépôt de fichiers publics ou privés avec obligation de saisie de métadonnées au format Dublin Core; les métadonnées peuvent être interrogées à travers un SPARQL endpoint; un identifiant pérenne est attribué à chaque fichier; service d’affichage des images selon le protocole IIIF) et Huma-Num Box (pour le stockage “en vrac” de gros volumes de données, accès par le protocole SFTP).

Une alternative aux tableurs : les bases de données relationnelles

Les tableurs, s’ils sont utilisés en respectant quelques bonnes pratiques, peuvent convenir pour la saisie de données peu structurées. Mais si la structure des données se complique, par exemple quand on souhaite étudier comme c’est le cas du projet PRELIB1 (Projet de recherche en littérature de langue bretonne), les raisons sociologiques qui ont conduit des individus à écrire en breton en créant une base de données contenant des information sur les auteurs (non, date et lieu de naissance/décès, etc.), leur participation à des collectifs, leur production littéraire, la publication de leurs œuvres sous forme de livre ou dans des revues; dans ce cas, il faut passer aux bases de données relationnelles.

Pour en savoir plus, lisez le billet Des fichiers Excel au SQL, introduction aux bases de données relationnelles.

  1. Nelly Blanchard, Jean-Baptiste Pressac et Mannaig Thomas, « PRELIB, base de données sur les acteurs du domaine littéraire en langue bretonne »Lengas [En ligne], 84 | 2018, mis en ligne le 15 juillet 2018, consulté le 27 mars 2020. URL : http://journals.openedition.org/lengas/1754 ; DOI : https://doi.org/10.4000/lengas.1754 []

Séminaire #02 du 10 février 2020 – Des fichiers Excel au SQL, introduction aux bases de données relationnelles

Un des premiers outil de stockage des données de la recherche est le tableur Microsoft Excel. Quelles bonnes pratiques adopter pour rendre exploitables et diffusables ses données saisies dans Excel ? Comment répondre aux limitations de Excel, notamment avec des bases de données dites relationnelles (MySQL, SQLite). Quels sont les avantages des bases de données relationnelles ? A quelles questions peuvent-elles répondre ? Voici les points que nous avons abordé lors de cette séance du séminaire Outils du Quanti en SHS.

Les deux articles suivants entrent en détail sur les notions abordées lors de cette séance :

Séminaire #01 du 4 novembre 2019 – R MarkDown et LaTeX

Bonjour à toutes et tous,

En ce début novembre, nous avons eu le plaisir de reprendre le cycle de rencontres autour du traitement et de l’analyse de données quantitatives en SHS pour l’année 2019/2020.

Cette première séance s’est déroulée le lundi 4 novembre 2019 de 15h00 à 16h00 à Brest dans la salle C206 à l’UFR Victor Segalen (plan d’accès).

Nous avons eu l’occasion d’écouter les interventions suivantes :

  • Pierre-Guillaume PRIGENT« R Markdown : produire et reproduire des rapports statistiques (et bien plus) »
  • Laurent MELL, « Bricolages et détournements en SHS. L’utilisation de LaTeX dans une enquête sociologique »

Pour celles et ceux qui n’auraient pas eu l’occasion de suivre cette séance de séminaire, vous pouvez retrouver les support de présentation ici :

*

Vous pouvez retrouver une grande partie des interventions des précédentes années sur le présent carnet hypothèses : 

Les Outils du Quanti en Sciences Humaines et Sociales

Par ailleurs, si vous souhaitez suivre l’actualité du séminaire, vous êtes libre de vous abonner à la liste de diffusion du séminaire :

Au plaisir de vous y retrouver prochainement.


Cordialement,


L’équipe d’organisation

Historique des séances du séminaire Outils du Quanti

Vous trouverez sur cette page la liste des séances du séminaire Outils du Quanti en sciences humaines et sociales depuis la création de ce blog en 2015.

  1. Voir les articles Des fichiers Excel au SQL, bonnes pratiques avec Excel et LibreOffice Calc et Des fichiers Excel au SQL, introduction aux bases de données relationnelles []
  2. Voir aussi Introduction aux expressions régulières avec LibreOffice et ce notebook sur GitHub []

Séminaire #04 du 12 mars 2019 – Découverte de Wikidata et du langage SPARQL

Wikidata est une base de données en ligne, gratuite et collaborative. C’est un wiki basé sur le même logiciel que Wikipédia mais qui permet de saisir des données “brutes” (voir par exemple la page Wikidata de Théodore Hersart de la Villemarqué, du gène ITK ou du cobalt) interrogeables avec son puissant Wikidata Query Service. Lors de cette séance du séminaire Outils du Quanti en SHS, nous avons vu ce que cette base de données peut apporter à la recherche, illustré par l’exemple de la base de données PRELIB (Projet de recherche en littérature de langue bretonne).

La séance du 12 mars 2019 (13h-14h30) était animée par Jean-Baptiste Pressac (chargé de la bibliothèque numérique et des bases de données au Centre de recherche bretonne et celtique).

Séminaire #03 du 19 février 2019 – Tenir son journal de bord sur Cassandre : retour d’expérience

Bonjour à toutes et tous,

Veuillez nous excuser pour cet envoi tardif.

Nous avons le plaisir de vous inviter à la troisième séance du cycle de rencontres autour du traitement et de l’analyse de données quantitatives en SHS pour l’année 2018/2019.

Cette dernière se déroulera le mardi 5 février 2019 de 14h00 à 17h00.

Ce séminaire pourra être suivi sur 2 sites :

  • À Brest dans la salle C206 à l’UFR Victor Segalen (plan d’accès)
  • À Rennes dans la salle T132-133 au Pôle Numérique Rennes Villejean (plan d’accès)

Nous aurons l’occasion d’écouter l’intervention suivante :

*

Alix HUBERT & Marie SCHNITZLER

Tenir son journal de bord sur Cassandre : retour d’expérience

*

*

Vous pouvez retrouver une grande partie des interventions des précédentes années sur le présent carnet hypothèses : 

Les Outils du Quanti en Sciences Humaines et Sociales

Par ailleurs, si vous souhaitez suivre l’actualité du séminaire, vous êtes libre de vous abonner à la liste de diffusion du séminaire :

Au plaisir de vous y retrouver prochainement.


Cordialement,


L’équipe d’organisation

Les leurres de l’analyse statistique en SHS – Vidéo du séminaire

Vous pouvez retrouver, ci-dessous, la vidéo de l’intervention d’Hervé GUYON le 20 novembre dernier sur “les leurres de l’analyse statistique en SHS”.

*

Hervé GUYON

Les leurres de l’analyse statistique en SHS. Les statistiques, ça trompe énormément

*


SI LA VIDÉO NE DÉMARRE PAS, CLIQUER ICI POUR LA VISIONNER

 

Pour rappel, vous Vous pouvez retrouver une grande partie des interventions des précédentes années sur le présent carnet hypothèses :

Les Outils du Quanti en Sciences Humaines et Sociales 

Par ailleurs, si vous souhaitez suivre l’actualité du séminaire, vous êtes libre de vous abonner à la liste de diffusion du séminaire.

 

Au plaisir de vous y retrouver prochainement.


Cordialement,


L’équipe d’organisation


Séminaire #02 du 18.12.18 – JASP et les approches Bayésiennes : une double révolution en statistique ?

Crédit : Liz (CC BY-NC-ND 2.0)

Bonjour à toutes et à tous,

Dans le prolongement du premier séminaire, nous sommes ravis de vous accueillir à la deuxième séance du cycle de rencontres autour du traitement et de l’analyse de données quantitatives en SHS pour l’année 2018/2019.

Celle-ci se déroulera le mardi 18 décembre 2018 de 14h00 à 17h00.

Ce séminaire pourra être suivi sur 2 sites :

  • À Brest dans la salle TD1 au Pôle Numérique Brest Bouguen (plan d’accès)
  • À Rennes dans la salle TD1 au Pôle Numérique Rennes Villejean (plan d’accès)

Nous aurons l’occasion d’écouter l’intervention suivante :

*

Hervé GUYON

JASP et les approches Bayésiennes : une double révolution en statistique ?

*

*

Vous pouvez retrouver une grande partie des interventions des précédentes années sur le présent carnet hypothèses : 

Les Outils du Quanti en Sciences Humaines et Sociales

Par ailleurs, si vous souhaitez suivre l’actualité du séminaire, vous êtes libre de vous abonner à la liste de diffusion du séminaire :

Au plaisir de vous y retrouver prochainement.


Cordialement,


L’équipe d’organisation