User talk:Jean-Baptiste Pressac

I am a CNRS engineer working in Brest, France, at the Centre de recherche bretonne et celtique, a research center and a library affiliated to the Centre national de la recherche scientifique (CNRS) and the Université de Bretagne Occidentale (UBO). The library holds books, periodicals and archival collections about Brittany and the Celtic worlds. We publish data on an digital library (https://bibnumcrbc.huma-num.fr/), tabular data such as our finding aids in ISAD(G) of the CRBC archives on https://crbc-dataset.huma-num.fr/ and PRELIB (Projet de recherche sur la littérature en breton) a prosopographic database of actors in Breton literature, which contributes to Wikidata and IdRef (Identifiants et Référentiels pour l'Enseignement supérieur et la Recherche). We would like to use FactGrid to give a federated access to the data produced in our databases.

PRELIB migration to FactGrid

Ressources

1. FactGrid:Directory of Properties
2. Un exemple de liaison entre les différentes acceptions de child sur child (young human offspring usually younger than 15)

Versement des Personnes (débuté le 22 aout 2022)

Tables SQL concernées :

• prelib_personne
• prelib_ville
• prelib_appellationpersonne

A faire

• Aligner et uploader les personnes créées depuis septembre par Elisabeth depuis l'export de prelib_personne pour le projet OpenRefine (et qui n'ont par conséquent pas été transférés sur FactGrid avec OpenRefine le 2 novembre 2022 - 2543 personnes de PRELIB sur FactGrid contre 2722 personnes au total).
• Supprimer dans PRELIB et dans le projet OpenRefine les personnes sans lien avec d'autres tables de la base
• Ajouter dans PRELIB et Wikidata les identifiants des Item FactGrid des personnes nouvellement créées
• Les pseudos ont-ils été versés sur factGrid ? Cas de Pierre Loisel, sans aucun des ses pseudos...

Fait

• Versement des personnes à partir du projet OpenRefine prelib_personne. Problématique : Les personnes ont été alignées à partir de leur appellation, depuis le projet OpenRefine prelib_appellationpersonnne, mais ce sont les lignes de prelib_personne que l'on veut importer dans FactGrid. De plus, à l'export de la table prelib_personne début septembre, la colonne factgrid était vide. Il faut donc récupérer depuis le projet prelib_appellationpersonne les identifiants des personnes déjà présentes dans FactGrid avec la fonction cell.cross() à partir des identifiants des personnes (colonne 'id' de prelib_personne et la colonne 'personne_id' de prelib_appellationpersonne). Mais cell.cross() renvoie le contenu de la première ligne qui a matché, or cette ligne peut ne pas contenir l'identifiant FactGrid si l'alignement a été fait avec une autre appellation. Il faut donc réorganiser en records le projet prelib_appellationpersonne et reporter l'identifiant FactGrid dans toutes les appellations d'une même personne.
  • Le projet OpenRefine prelib_appellationpersonne a été aligné avec FactGrid sur la colonne 'appellation', ce qui fait que pour les individus ayant plusieurs appellations, une seule appellation est associée à un identifiant FactGrid. Pour associer toutes les appellations d'une même personne à l'item FactGrid équivalent, le projet prelib_appellationpersonne a été réorganisé en records en classant en premier (dans la liste des colonnes) la colonne personne_id puis en appliquant la fonction 'Blank down' sur cette colonne. Un tri a ensuite été appliqué sur la colonne FactGridItemId puis le contenu de cette colonne a été reporté pour toutes les appellations d'un même individu avec la fonction Fill down.
  • Les identifiants FactGrid du projet OpenRefine prelib_appellationpersonne ont été comparés avec les 44 identifiants FactGrid déjà saisis dans PRELIB au 2 novembre 2022. Un export des 44 individus de PRELIB avec un identifiant FactGrid a été importé dans OpenRefine (projet prelib_personne avec factgrid 2022-11-02) et le contenu de la colonne 'factgrid' de ce projet a été importé dans le projet OpenRefine prelib_appellationpersonne avec la fonction GREL cross(). Un seul individu de PRELIB (Julien Green) n'avait pas encore été aligné.
  • Les identifiants FactGrid issus de l'alignement des appellations des personnes ont été récupérées depuis le projet prelib_appellationpersone dans la colonne FactGrid_from_appellation du projet prelib_personne.
  • Pour éditer des données avec OpenRefine, il faut avoir préalablement aligné une des colonnes du projet. La colonne FactGrid_from_appellation ne peut pas être utilisée pour cela car elle contient des lignes vides, lignes vides qui ne peuvent être marquées comme à créer (new) par la fonction de réconciliation. Une réconciliation "bidon" est donc lancée sur la colonne appellation_for_reconciliation, copie de la colonne appellation. Les alignements réussis sont vérifiés avec la colonne FactGrid_from_appellation. Le schéma d'export a été sauvegardé sous le nom de fichier OpenRefineWikidataExtensionSchema4FactGridHuman.json.
  • Import dans PRELIB des identifiants des items FactGrid nouvellement créés :
    • Récupération des identifiants FactGrid avec la fonction Add entity identifiers column appliquée la colonne appellation_for_reconciliation.
    • Création des requêtes SQL UPDATE à l'aide du templating export de OpenRefine. Mise à jour de 2543 personnes dans PRELIB. Au soir du 2 novembre 2022, 2590 personnes de PRELIB sur un total de 2722 (95%) ont un équivalent sur FactGrid.
  • Ajout avec QuickStatements des identifiants Wikidata (sitelink Swikidatawiki) aux item FactGrid nouvellements créés : Appliquer une facette sur la colonne wikidata du projet prelib_personne pour n'afficher que les personnes avec un identifiant Wikidata. Export des commandes QS au format CSV à l'aide du Templating export de OpenRefine.
  • Suppression de dix doublons créés sur FactGrid soit parce que le doublon existait déjà sur PRELIB (ex. Gaston Paris, doublon créé par Elisabeth, ex. Pierre-Paul Guieysse, doublon créé par Mannaig) auquel cas le doubon a été également fusionné sur PRELIB; soit parce que l'appellation était incomplète ou erronée et l'alignement n'a pas fonctionné (ex. Fiodor Dostoïevski, dont le label français sur FactGrid correspondait au label anglais) soit parce que OpenRefine ne gère pas les accents (ex. L'alignement ne trouve pas de similarité entre Léo Petruz et Leo Petruz); soit encore parce que l'item FactGrid a été créé après l'alignement (ex. William Shakespeare créé le 31 octobre 2022 par un autre contributeur de FactGrid).
• Uploader avec QS les appellations des personnes (sous forme de labels et d'alias).
• Supprimer de FactGrid et de Wikidata les doublons de personnes (à trouver avec leur identifiant Wikidata : Q23000808, Q3383454, Q514741, Q56692181, Q57835177)
• Suite au versement des personnes le 2022-11-02, mettre à jour PRELIB avec les identifiants FactGrid des items nouvellement créés.
• Associer à la main François Elard [PRELIB ID:798] avec le nom de famille associé.

Remarques

• L'alignement des patronymes a permis la correction de 35 saisies de noms d'état civil pour 2591 personnes (ex. Achille du Clésieux avec un nom d'état civil = Achille-Marie-Aimé et pas de prénom usuel saisi, ex. Anne ar C'hog avec un nom d'état civil = ar C'hog, Belbeoc'h (dédicataire de Bleuniou Yaouankiz) avec un nom d'état civil = Belbeoc'h, Bonaventure de Landerneau avec un nom d'état civil = de Landerneau)...
• Le nom d'état civil n'a pas été saisi pour 1418 personnes sur 2591, en partie car nous avons convenu à un moment donnée de la vie de PRELIB, que le nom d'état civil devait être pris exactement pour ce qu'il était (le nom d'état civil) et que sans vérification dans l'état civil, cette information ne serait pas saisie.
• Problème d'uniformisation des patronymes acentués dont il existe différentes versions (ex. Gueguen et Guéguen), j'aurais dû utiliser les clusters de OpenRefine avant la réconciliation.
• Des doublons ont été créés au dépot des personnes de PRELIB sur FactGrid, notamment parce que la version française du nom n'était pas correcte (ex. Fyodor Dostoyevsky (Q273330))

Procédure de versement des personnes

1. Vérifier que toutes les villes PRELIB ont un identifiant FactGrid
2. Vérifier que les langues des appellations des personnes sont en français par défaut (sinon, on ne tiendra pas compte de la langue de l'appellation lors du dépôt et on considéra que la langue des appellation est l'anglais)
3. Exporter les personnes avec la requête SQL45604208
4. Importer les données dans OpenRefine
5. Aligner le contenu de la colonne des appellations avec FactGrid
6. Si match PRELIB/FactGrid :
   1. Ajouter (avec l’extension Wikidata) P763 (PRELIB person ID) aux items FactGrid
   2. Mettre à jour PRELIB avec l'identifiant FactGrid des personnes avec TEO84959630
7. Associer les colonnes du projet contenant des identifiants avec l'item FactGrid idoine (ex. le sexe, villes de naissance et de décès)
8. Récupérer sur FactGrid le label anglais ou à défaut en français des villes
   1. Add column from reconciled column ville_naissance_factgrid_id
   2. Add Property = SPARQL: Len|Lfr / configure > limit : 1.
   3. Nom de la colonne = "ville_naissance_FactGrid(Len|Lfr)"
9. Créer une colonne FactGridItemDescription avec GREL74121793
10. Créer le schéma de versement des données dans FactGrid avec l’extension Wikidata. Noter que Wikibase n'utilise pas les codes ISO639 pour les langues des labels mais au code langue des Wikipedia (voir aussi List of language names ordered by code). Par exemple, le code langue du néerlandais est 'nd' et non pas le code ISO639-3 'nld'.
11. Verser les données dans FactGrid
12. Mettre à jour PRELIB avec l'identifiant FactGrid des personnes avec TEO84959630
13. Publier les données MAJ de PRELIB sur CRBC Dataset

Requêtes SQL

Requête SQL de l'export de prelib_personne pour le projet OpenRefine

# SQL45604208
# Requête SQL pour l'export de tous les champs de prelib_personne, de la forme retenue et du code ISO de sa langue, des dates de naissances et de décès au format YYYY, YYYY-MM ou YYYY-MM-dd, de l’identifiant FactGrid de la ville de naissance, de la ville de décès et du sexe, de l'ARK BnF réduit (sans le préfixe 12148/cb).
# Les noms des villes de naissance et de décès ne sont pas récupérés par SQL mais on récupère le label de l'item FactGrid équivalent dans OpenRefine (c.f. la procédure)

SELECT 
COALESCE(CONCAT(personne.annee_naissance, IF(personne.mois_naissance, CONCAT('-', lpad(personne.mois_naissance, 2, '0'), if (personne.jour_naissance, CONCAT('-', LPAD(personne.jour_naissance, 2, '0')), '')), '')), '') AS 'date_naissance',
COALESCE(CONCAT(personne.annee_deces, IF(personne.mois_deces, CONCAT('-', lpad(personne.mois_deces, 2, '0'), if (personne.jour_deces, CONCAT('-', LPAD(personne.jour_deces, 2, '0')), '')), '')), '') AS 'date_deces',
appellation.appellation, prelib_langue.code_iso_639_3 AS appelation_code_iso_639_3,
ville_naissance.factgrid AS ville_naissance_factgrid_id,
ville_deces.factgrid  AS ville_deces_factgrid_id,
IF(personne.sexe = 'M', 'Q18', IF(personne.sexe = 'F', 'Q17', NULL)) AS sexe_factgrid_id,
REPLACE(personne.ark_bnf, '12148/cb', '') AS ark_bnf_reduced,
personne.*
FROM prelib_personne AS personne
LEFT JOIN prelib_appellationpersonne AS appellation ON appellation.personne_id = personne.id AND appellation.forme = 2
INNER JOIN prelib_langue ON appellation.langue_id = prelib_langue.id
LEFT JOIN prelib_ville AS ville_naissance ON ville_naissance.id = personne.ville_naissance_id
LEFT JOIN prelib_ville AS ville_deces ON ville_deces.id = personne.ville_deces_id

Requête SQL pour afficher les personnes dont le prénom et le nom d'état civil tout attachés ne sont pas présents dans les appellations

# SQL83453878
SELECT CONCAT(personne.prenom_etat_civil, ' ', personne.nom_etat_civil), 0, 1, 1, personne.id
FROM prelib_personne AS personne
WHERE personne.prenom_etat_civil <> '' AND personne.nom_etat_civil <> ''
 AND CONCAT(personne.prenom_etat_civil, ' ', personne.nom_etat_civil)
  NOT IN (SELECT appellation.appellation
          FROM prelib_appellationpersonne AS appellation
          WHERE appellation.personne_id = personne.id)

Requête SQL pour afficher les personnes dont le nom usuel n'est pas présent dans la table des appellations

# SQL34056284
SELECT personne.id, personne.nom_usuel FROM prelib_personne as personne WHERE personne.nom_usuel NOT IN (SELECT appellation.appellation FROM prelib_appellationpersonne as appellation WHERE appellation.personne_id = personne.id)

Procédure de versement des appellations des personnes

Remarque préliminaire : Les information sur les prénoms, noms et peudonymes des personnes sont actuellement saisies dans

1. prelib_personne.nom_usuel (saisie PRELIB supprimée le 14 mars 2023 au profit de la seule appellation retenue)
2. prelib_personne.nom_etat_civil
3. prelib_personne.prenom_etat_civil
4. la table prelib_appellationpersonne.

Vérifier que les noms et prénoms d'état civils sont également saisis dans la table prelib_appellationpersonne (voir par ex. Alain Guel (1913-1993) dont le nom à l'état civil, Alexandre Jouanard, n'a pas été saisi dans les appellations) ou encore Per Denez et son nom d'étét civil, Pierre Denis. Corriger les erreurs et les omissions à la main car il faudra éventuellement choisir l'appellation retenue et saisir la langue des prénoms et nom usuel.

1. Toutes les appellations retenues (quel que soit leur langue dans PRELIB) ont été versées comme labels en français et en anglais avec OpenRefine depuis le projet prelib_personne.
2. Les appellations retenues dans d'autres langues que le français et l'anglais ont également été versées dans FactGrid comme label dans leur langue avec QS. Voir le lot QuickStatements PRELIB_appellations_retenues_ni_FR_ni_EN.
3. Les appellations non retenues ont été versées avec QuickStatements comme des alias dans leur langue. Voir le lot QuickStatements PRELIB_appellations_rejetees.

Mapping des appellations de personnes PRELIB avec FactGrid

PRELIB	Projet OpenRefine.Colonne	FactGrid	Méthode de versement	remarques
appellations (forme retenue)	prelib_personne.appellation	Label (fr) et Label (en)	export OpenRefine	Données issues de l'export SQL de la table prelib_personne avec une jointure avec prelib_appellationpersonne. L'appellation retenue avait été exportée avec son code ISO mais faute d'un alignement préalable de cette donnée avec FactGrid, elle n'a pas pu être exploitée dans schéma d'export OpenRefine.
appellations (formes retenues dans d'autres langues que le français et l'anglais)	prelib_appellationpersonne	Label dans la langue de l'appellation	QuickStatements
appellations (formes non retenues)	prelib_appellationpersonne	Alias dans la langue de l'appellation	QuickStatements

Voici la réflexion qui a conduit à ce choix :

Dans FactGrid :

1. Un item FactGrid ne peut avoir qu'un seul label par langue
2. Un item FactGrid peut avoir plusieurs alias de la même langue
3. Les alias ne sont pas forcément synonymes de pseudonyme car des personnes peuvent avoir des pseudonymes comme label (ex. Julien Green)
4. Il n'est pas possible de préciser qu'un label ou un alias est un pseudonyme (il doit y avoir une propriété pour déclarer cela)

Dans PRELIB :

1. Une personne peut avoir un nombre illimité d'appellations
2. Une seule appellation a le statut de forme retenue, toutes langues confondues
3. Les autres appellations sont obligatoirement de forme rejetées
4. Les appellations ont une langue
5. Les appellations peuvent être marquées comme étant des pseudonymes (prelib_appellationpersonne.alias = 1)
6. Les pseudonymes peuvent être des formes retenues

Toutes les formes non retenues qui sont dans la même langue que la forme retenue (qu'elles soient des pseudonymes ou non) deviennent des alias de l'item FactGrid. Par contre, pour les appellations qui ne sont pas dans la langue de la forme retenue, rien dans PRELIB ne permet de distinguer de manière certaine l'appellation à retenir comme label de l'item FactGrid. En effet, il peut exister plusieurs variantes d'un nom qui n'est pas un pseudonyme (ex. Pierre-Paul Guieysse aussi connu sous le nom de Paul Guieysse) ou bien une personne peut avoir plusieurs pseudonymes dans la même langue (ex. Jean-Guillaume Henry qui a pour pseudonymes bretons Barz an Aviel, Barzik Moal , I. W. H. b. (Iann Wilhou Herri beleg)).

Les appellations retenues n'ont pas pu être versées avec OpenRefine en précisant leur langue telle que saisie dans PRELIB. Elles ont été versées de manière arbitraires comme label en français et en anglais. On se retrouve d'ailleurs avec des informations inexactes où le label de Pierre Trépos en français est Per Trepos, sa forme retenue. Les appellations retenues dont la langue n'est pas le français et l'anglais peuvent ont également été versées comme label de la langue qui leur correspond (breton, russe, italien, gallois).

# Requête SQL pour générer des commandes QuickStatements de dépôt en tant que label des appellations retenues dont la langue n'est ni le français ni l'anglais 
SELECT CONCAT(personne.factgrid, '\t', 'L', LPAD(langue.code_iso_639_3, 2), '\t', '"', appellation.appellation, '"') 
FROM prelib_appellationpersonne as appellation 
JOIN prelib_personne as personne ON appellation.personne_id = personne.id
JOIN prelib_langue AS langue ON appellation.langue_id = langue.id
WHERE appellation.forme = 2 AND (langue.code_iso_639_3 <> 'fre' AND langue.code_iso_639_3 <> 'eng') AND personne.factgrid <> ''

Par simplification et en absence de moyens pour determiner parmi les appellations rejetées d'une même langue celle qui peut être versée comme label, toutes les appellations rejetées ont été versées comme des alias :

# Requête SQL pour générer des commandes QuickStatements de dépôt en tant qu'alias des appellations rejetées
SELECT CONCAT(personne.factgrid, '\t', 'A', LPAD(langue.code_iso_639_3, 2), '\t', '"', appellation.appellation, '"') 
FROM prelib_appellationpersonne as appellation 
JOIN prelib_personne as personne ON appellation.personne_id = personne.id
JOIN prelib_langue AS langue ON appellation.langue_id = langue.id
WHERE appellation.forme = 1 AND personne.factgrid <> ''

Templating export OpenRefine pour générer les requêtes SQL d'import des identifiants FactGrid des items créés par Upload edits

# TEO84959630 
# Prefix

# Row template
UPDATE prelib_personne 
SET factgrid = '{{cells["FactGridId"].value}}'
WHERE id = {{cells["id"].value}}

# Row separator
;

Templating export OpenRefine pour verser dans FactGrid par QuickStatements les identifiants Wikidata des personnes

# TEO52312788
# Prefix
qid,Swikidatawiki

# Row template
{{cells["FactGridId"].value}},{{cells["wikidata"].value}}

# Row separator

Mapping des personnes PRELIB avec FactGrid

Les colonnes de la table prelib_personne concernées :

• prelib_personne.id = Property:P763
• prelib_personne.sexe = Property:P154 avec pour valeurs Male (PRELIB = M) ou Female (PRELIB = F).
• prelib_personne.nom_usuel ne doit pas être importé dans FactGrid car n'a pas de language tag.
• Label de l'Item : Utiliser les colonnes appellation (i.e. l'appellation PRELIB retenue pour cette personne, Problème : L'appellation retenue n'est pas toujours judicieuse. Par exemple l'appellation retenue de Yves Désiré Stéphan est "Stephan") et code_iso_639_3 du projet OpenRefine (il aurait peut-être fallu aligner au préalable cette colonne avec FactGrid car OpenRefine refuse d'utiliser les valeurs brutes de la colonne pour spécifier la langue des labels. Finalement, appellation est utilisée arbitrairement pour saisir le label en français et en anglais). Note : Les épouses sont saisies comme Geneviève d'Auberjon de Murinais (née de La Vieuville), ce qui n'est pas le cas dans PRELIB.
• Alias de l'item : Voir le versement des appellations
• Description de l'Item : La description a pour modèle : * yyyy-mm-dd Place of birth, + yyyy-mm-dd Place of death, career statement. Si vous n'avez qu'un seul rendez-vous dans la durée de vie, utiliser ~ (Voir aussi https://database.factgrid.de/wiki/User_talk:Olaf_Simons#Person_normalized_description). Pour des exemples de descriptions, voir la requête SPARQL https://tinyurl.com/2nfk37mk. Voir GREL74121793 pour générer une colonne OpenRefine avec le descriptif.
• prelib_personne.prenom_etat_civil = Property:P248 avec pour valeur un Item instance de Item:Q31776 (vérifier s'ils sont déjà créés, à moins que QuickStatements puisse les créer à la volée). Attention, Les prénoms sont écrits séparément avec un ordre (Théophile René Hyacinthe Laennec) : https://database.factgrid.de/wiki/Item:Q148333. Problème : certains prénoms d'état civil ont été saisis avec des tirets sans que l'on puisse distinguer les prénoms composés. Les prénoms seront versés après le versement des individus
• prelib_personne.nom_etat_civil = Property:P247 avec pour valeur un Item instance de Item:Q24499.
  • Nécessite un alignement préalable des patronymes avec OpenRefine (alignement et versement effectué le 25 octobre 2022).
  • Note : Si l'on en juge par la valeur de la propriété different from de l'item équivalent sur Wikidata family name, il s'agit bien d'un patronyme et non pas du nom de la famille.
  • Note : Les noms avec particules sont saisis en général sous la forme de La Bourse Plate et non pas La Bourse Plate (de) si l'on en juge par les résultats des requêtes https://tinyurl.com/2pv8bs7w et https://tinyurl.com/2fmh8394.
• prelib_personne.particule_noblesse (oui/non) : non importé
• prelib_personne.date_naissance (prelib_personne.jour_naissance, prelib_personne.mois_naissance, prelib_personne.annee_naissance) = Property:P77. L'extension Wikidata de OpenRefine affiche l'avertissement suivant : Dates earlier than October 1582 (such as in year 1564) are unlikely to be expressed using the Gregorian calendar.
• prelib_personne.date_deces (prelib_personne.jour_deces, prelib_personne.mois_deces, prelib_personne.annee_deces) = Property:P38.
• ville_naissance_id = Property:P82 : C'est la ville seule qui est utilisée pour le lieu de décès, le département et le pays ne sont pas exploités. Une jointure SQL a été faite avec prelib_ville pour récupérer l'identifiant FactGrid de la ville (colonne du projet OpenRefine ville_naissance_factgrid_id). Le label anglais ou à défaut, le label français de l'item FactGrid a été récupéré dans la colonne OpenRefine ville_naissance_FactGrid(Len|Lfr).
• ville_deces_id = Property:P168 : Voir les remarques de ville_naissance_id.
• prelib_langue_maternelle_1 à prelib_langue_maternelle_3 : non importé
• prelib_langue_usuelle_1 à prelib_langue_usuelle_3 : non importé
• prelib_wikidata = Other sites avec pour valeur wikidatawiki (QuickStatements = Swikidatawiki) mais pour l'instant, il n'est pas possible d'éditer les sitelinks avec OpenRefine. Il faudra verser les identifiants Wikidata avec QuickStatements.
• prelib_idref = Property:P366
• prelib_ark_bnf = Property:P367 Attention, supprimer 12148/cb
• prelib_isni = Property:P821
• prelib_viaf = Property:P378
• Instance of [P2]:Human [Q7]
• Research projects that contributed to this data set [P131]:Research project in Breton-language literature [Q418506]

# GREL74121793
# Code GREL pour la création de la colonne FactGridItemDescription du projet OpenRefine prelib_personne
if(or(isNotNull(cells.annee_naissance), isNotNull(cells.ville_naissance)), '* ', '') +
if(isNotNull(cells.annee_naissance), cells.annee_naissance.value, '') +
if(and(isNotNull(cells.annee_naissance), isNotNull(cells["ville_naissance_FactGrid(Len|Lfr)"])), ' ', '') +
if(isNotNull(cells["ville_naissance_FactGrid(Len|Lfr)"]), cells["ville_naissance_FactGrid(Len|Lfr)"].value, '') +
if(and(or(isNotNull(cells.annee_naissance), isNotNull(cells["ville_naissance_FactGrid(Len|Lfr)"])), or(isNotNull(cells.annee_deces), isNotNull(cells["ville_deces_FactGrid(Len|Lfr)"]))), ', ', '') +
if(or(isNotNull(cells.annee_deces), isNotNull(cells["ville_deces_FactGrid(Len|Lfr)"])), '+ ', '') +
if(isNotNull(cells.annee_deces), cells.annee_deces.value, '') +
if(and(isNotNull(cells.annee_deces), isNotNull(cells["ville_deces_FactGrid(Len|Lfr)"])), ' ', '') +
if(isNotNull(cells["ville_deces_FactGrid(Len|Lfr)"]), cells["ville_deces_FactGrid(Len|Lfr)"].value, '')

# GREL60409360
# Code GREL pour récupérer dans la colonne FactGrid_from_appellation du projet OpenRefine prelib_personne les identifiants FactGrid issus de l'alignement avec FactGrid depuis le projet prelib_appellationpersonne
cell.cross('prelib_appelationpersonne2022-09-12_15h35', 'personne_id').cells['FactGridItemID'].value[0]

Relations interpersonnelles (en cours - débuté le 29 septembre 2022, interrompu puis repris le 4 novembre 2022, repris le 5 janvier 2023)

Tables SQL concernées

• prelib_relationinterpersonnelle
• prelib_qualiterelation

A faire

• Créer sur PRELIB les relations inverses (pas les qualités de relations inverses), bien que certaines relations inverses ne pourront pas avoir d'équivalent sur FactGrid (par ex. la qualité a pour mécène ou à pour chauffeur).
• Paramétrer MariaDB pour que soit automatiquement créée la relation inverse

Fait

• Vérifier tous les mapping des qualités de relation PRELIB avec leur équivalent sur Wikidata et FactGrid car il pourrait y avoir des erreur

En cours

Problèmes à résoudre (depuis le 13 janvier 2023) :

QS cannot add a second statement with the same property and value but with different qualifiers

Dans le cas ou deux personnes sont liées par plus de deux qualités de relations (ex. Per Trepos et François Falc'hun (assistant et correspondant), Per Trepos et Hélias (amis et correspondant) (voir la commande QS2023-01-16:17h35) QS a factorisé les qualités de relations dans la même valeur de statement plutôt que de créer des valeurs distinctes. Ce qui fait que les dates de début et de fin de relations sont partagées entre les modes de relations. Le batch ne pouvant être annulé (la fonction Discuss/revert batch de la liste des batchs de QS ne fonctionne pas), les erreurs vont devoir être corrigées à la main. Heureusement, il n'y a que 34 cas à traiter d'après la requête SQL2023-01-13:15h05 ci-dessous.

C'est une limitation documentée de QuickStatements :

QuickStatements version 2 currently cannot add a second statement with the same property and value but with different qualifiers, since additional qualifiers will be added to the first statement.

# QS2023-01-16:17h35
Q454877|P703|Q454257|P277|Q458463|P820|Q458463|P49|+1953-00-00T00:00:00Z/9|P50|+1957-00-00T00:00:00Z/9
Q454877|P703|Q454257|P277|Q399918|P820|Q399918

La fonction d'annulation des batchs QS ne fonctionne pas

Autre problème, la fonction d'annulation des batchs ne fonctionne pas. Le lien renvoie vers une application Wikidata.

Requête SQL de création des déclarations QS à corriger

1. Autre problème, il y a des erreurs dans le batch QuickStatements n°409 pour les déclarations où Qid de la fonction est absente. Elles correspondents à toutes les qualités sans équivalent dans FactGrid de type à pour. A signaler dans les objectifs de ce versement. Réécrire la requête SQL de création des commandes QS ci-dessous pour en tenir compte.

Requêtes SQL pour créer les commandes QuickStatements

Depuis la création de la propriété Associated persons (P703), un essai de création des relations interpersonnelles de Auguste Brizeux (mère et ami) a été fait avec QuickStatements en utilisant des items (et non pas des propriétés) comme qualificatifs (Subject has role / Object has role) :

Essai de commande QuickStatements pour déclarer que Auguste Brizeux a pour père Pélage-Julien Brizeux et que Pélage-Julien Brizeux a pour fils Auguste Brizeux :

Q453857|P703|Q453858|P820|Q399968|P277|Q256505
Q453858|P703|Q453857|P820|Q256505|P277|Q399968

Requête SQL pour générer les commandes QuickStatements pour ajouter les fils, c'est à dire sur la page des fils, la déclaration d'une Associated persons (P703) dont le Subject has role = Son et le Object has role a pour valeur Father (Q399968) si la personne associé est un homme et pour valeur Mother (Q400449) si la personne associée est une femme. Les relations où la personne associé a un sexe ni masculin ni féminin ne sont pas traités.

# P703 = Associated persons
# Q256505 = Son (fils)
# Q400449 = Mother
# Q399968 = Father
# P277 = Subject has role
# P820 = Object has role
# problématique : distinguer les mères des pères pour l'objet de P703
SELECT CONCAT(personne.factgrid, '|P703|', personne_associee.factgrid,'|P277|', 
qualite.factgrid, '|P820|', IF(personne_associee.sexe = 'M', 'Q399968', IF(personne_associee.sexe = 'F', 'Q400449', ''))) 
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE qualite.factgrid = 'Q256505' AND personne.factgrid <> '' AND personne_associee.factgrid <> '' AND personne_associee.sexe IN ('F', 'M')

En janvier 2023, suite à la fusion des qualités relationnelles genrées, les Items FactGrid ci-dessous ont été édités à la main pour utiliser les qualités non-genrées équivalentes.

La requête SQL précédente peut être élargie pour récupérer toutes les relations de type fils ou fille (@qualite_factgrid := 'Q469150') et les relations dont l'inverse est l'inverse de fils ou fille (qualite_inverse.factgrid = @qualite_factgrid), soit père ou mère (dont l'identifiant FactGrid, Q458433 est récupéré à partir d'une jointure; voir qualite_inverse) :

# Traitement des relations de qualité = @qualite_factgrid (qualite.factgrid = @qualite_factgrid)
# Note : A priori, QuickStatements ne crée pas de doublons des statements
# Note : UNION supprime les doublons
SET @qualite_factgrid := 'Q469150';
#
# Commandes QuickStatements sur les items FactGrid des personnes
# personne.factgrid
# P703 = Associated persons
# personne_associee.factgrid
# P277 = Subject has role (le sujet du statement est la personne)
# qualite_inverse.factgrid (Q458433 = Parent)
# P820 = Object has role (l'objet du statement est la relation)
# qualite.factgrid (Q469150 = Child)
SELECT CONCAT(personne.factgrid, '|P703|', personne_associee.factgrid,
'|P277|', qualite_inverse.factgrid, 
'|P820|', qualite.factgrid)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE qualite.factgrid = @qualite_factgrid AND personne.factgrid <> '' AND personne_associee.factgrid <> ''
UNION
# Commandes QuickStatements sur les items FactGrid des relations
# personne_associee.factgrid
# P703 = Associated persons
# personne.factgrid
# P277 = Subject has role (le sujet du statement est la relation)
# qualite.factgrid (Q469150 = Child)
# P820 = Object has role (l'objet du statement est la personne)
# qualite_inverse.factgrid (Q458433 = Parent)
SELECT CONCAT(personne_associee.factgrid, '|P703|', personne.factgrid,
'|P277|', qualite.factgrid, 
'|P820|', qualite_inverse.factgrid)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE qualite.factgrid = @qualite_factgrid AND personne.factgrid <> '' AND personne_associee.factgrid <> ''
UNION
#
# Traitement des relations de qualité inverse = @qualite_factgrid (qualite_inverse.factgrid = @qualite_factgrid)
#
# Commandes QuickStatements sur les items FactGrid des personnes
SELECT CONCAT(personne.factgrid, '|P703|', personne_associee.factgrid,
'|P277|', qualite_inverse.factgrid, 
'|P820|', qualite.factgrid)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE qualite_inverse.factgrid = @qualite_factgrid AND personne.factgrid <> '' AND personne_associee.factgrid <> ''
UNION
# Commandes QuickStatements sur les items FactGrid des relations
SELECT CONCAT(personne_associee.factgrid, '|P703|', personne.factgrid,
'|P277|', qualite.factgrid, 
'|P820|', qualite_inverse.factgrid)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE qualite_inverse.factgrid = @qualite_factgrid AND personne.factgrid <> '' AND personne_associee.factgrid <> ''

Le batch QuickStatements lancé avec le résultat de la requête SQL précédente : "PRELIB Parent and Child".

la requête SQL suivante permet la création de commandes QuickStatement pour verser dans FactGrid toutes les relations interpersonnelles de PRELIB :

# Création de commandes QuickStatement pour verser dans FactGrid toutes les relations interpersonnelles de PRELIB
# Note : A priori, QuickStatements ne crée pas de doublons des statements
# Note : UNION supprime les doublons (vs UNION ALL)
#
# Commandes QuickStatements sur les items FactGrid des personnes
# personne.factgrid
# P703 = Associated persons
# personne_associee.factgrid
# P277 = Subject has role (le sujet du statement est la personne)
# qualite_inverse.factgrid
# P820 = Object has role (l'objet du statement est la relation)
# qualite.factgrid
SELECT CONCAT(personne.factgrid, '|P703|', personne_associee.factgrid,
'|P277|', qualite_inverse.factgrid, 
'|P820|', qualite.factgrid)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE personne.factgrid <> '' AND personne_associee.factgrid <> ''
UNION
# Commandes QuickStatements sur les items FactGrid des relations
# personne_associee.factgrid
# P703 = Associated persons
# personne.factgrid
# P277 = Subject has role (le sujet du statement est la relation)
# qualite.factgrid
# P820 = Object has role (l'objet du statement est la personne)
# qualite_inverse.factgrid
SELECT CONCAT(personne_associee.factgrid, '|P703|', personne.factgrid,
'|P277|', qualite.factgrid, 
'|P820|', qualite_inverse.factgrid)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE personne.factgrid <> '' AND personne_associee.factgrid <> ''

Nouvelle version qui verse également les dates de début et de fin de la relation. Cette requête a fait l'objet du batch QuickStatements n°409.

# ID:SQL2023-01-13:15h05
# Requête SQL d'affichage des personnes ayant plus d'un type de relation en commun
SELECT COUNT(*) AS nbre_relations, GROUP_CONCAT(relation.id), personne.nom_usuel, personne_associee.nom_usuel
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
GROUP BY relation.personne_id, relation.relation_id having nbre_relations >= 2;

# Création de commandes QuickStatement pour verser dans FactGrid toutes les relations interpersonnelles de PRELIB
# Note : A priori, QuickStatements ne crée pas de doublons des statements
# Note : UNION supprime les doublons (vs UNION ALL)
#
# Commandes QuickStatements sur les items FactGrid des personnes
# personne.factgrid
# P703 = Associated persons
# personne_associee.factgrid
# P277 = Subject has role (le sujet du statement est la personne)
# qualite_inverse.factgrid
# P820 = Object has role (l'objet du statement est la relation)
# qualite.factgrid
SELECT CONCAT(personne.factgrid, '|P703|', personne_associee.factgrid,
'|P277|', qualite_inverse.factgrid, 
'|P820|', qualite.factgrid,
COALESCE(CONCAT(IF(relation.annee_debut_relation, '|P49|+', ''), relation.annee_debut_relation, IF(relation.annee_debut_relation AND relation.mois_debut_relation IS NULL AND relation.jour_debut_relation IS NULL, '-00-00T00:00:00Z/9', ''), IF(relation.mois_debut_relation, CONCAT('-', lpad(relation.mois_debut_relation, 2, '0'), IF(relation.annee_debut_relation AND relation.mois_debut_relation AND relation.jour_debut_relation IS NULL, '-00T00:00:00Z/10', ''), IF(relation.jour_debut_relation, CONCAT('-', LPAD(relation.jour_debut_relation, 2, '0'), IF(relation.annee_debut_relation AND relation.mois_debut_relation AND relation.jour_debut_relation, 'T00:00:00Z/11', '')), '')), '')), ''),
COALESCE(CONCAT(IF(relation.annee_fin_relation, '|P50|+', ''), relation.annee_fin_relation, IF(relation.annee_fin_relation AND relation.mois_fin_relation IS NULL AND relation.jour_fin_relation IS NULL, '-00-00T00:00:00Z/9', ''), IF(relation.mois_fin_relation, CONCAT('-', lpad(relation.mois_fin_relation, 2, '0'), IF(relation.annee_fin_relation AND relation.mois_fin_relation AND relation.jour_fin_relation IS NULL, '-00T00:00:00Z/10', ''), IF(relation.jour_fin_relation, CONCAT('-', LPAD(relation.jour_fin_relation, 2, '0'), IF(relation.annee_fin_relation AND relation.mois_fin_relation AND relation.jour_fin_relation, 'T00:00:00Z/11', '')), '')), '')), '')
)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE personne.factgrid <> '' AND personne_associee.factgrid <> ''
UNION
# Commandes QuickStatements sur les items FactGrid des relations
# personne_associee.factgrid
# P703 = Associated persons
# personne.factgrid
# P277 = Subject has role (le sujet du statement est la relation)
# qualite.factgrid
# P820 = Object has role (l'objet du statement est la personne)
# qualite_inverse.factgrid
SELECT CONCAT(personne_associee.factgrid, '|P703|', personne.factgrid,
'|P277|', qualite.factgrid, 
'|P820|', qualite_inverse.factgrid,
COALESCE(CONCAT(IF(relation.annee_debut_relation, '|P49|+', ''), relation.annee_debut_relation, IF(relation.annee_debut_relation AND relation.mois_debut_relation IS NULL AND relation.jour_debut_relation IS NULL, '-00-00T00:00:00Z/9', ''), IF(relation.mois_debut_relation, CONCAT('-', lpad(relation.mois_debut_relation, 2, '0'), IF(relation.annee_debut_relation AND relation.mois_debut_relation AND relation.jour_debut_relation IS NULL, '-00T00:00:00Z/10', ''), IF(relation.jour_debut_relation, CONCAT('-', LPAD(relation.jour_debut_relation, 2, '0'), IF(relation.annee_debut_relation AND relation.mois_debut_relation AND relation.jour_debut_relation, 'T00:00:00Z/11', '')), '')), '')), ''),
COALESCE(CONCAT(IF(relation.annee_fin_relation, '|P50|+', ''), relation.annee_fin_relation, IF(relation.annee_fin_relation AND relation.mois_fin_relation IS NULL AND relation.jour_fin_relation IS NULL, '-00-00T00:00:00Z/9', ''), IF(relation.mois_fin_relation, CONCAT('-', lpad(relation.mois_fin_relation, 2, '0'), IF(relation.annee_fin_relation AND relation.mois_fin_relation AND relation.jour_fin_relation IS NULL, '-00T00:00:00Z/10', ''), IF(relation.jour_fin_relation, CONCAT('-', LPAD(relation.jour_fin_relation, 2, '0'), IF(relation.annee_fin_relation AND relation.mois_fin_relation AND relation.jour_fin_relation, 'T00:00:00Z/11', '')), '')), '')), '')
)
FROM prelib_relationinterpersonnelle AS relation
JOIN prelib_qualiterelation AS qualite ON relation.qualite_relation_id = qualite.id
JOIN prelib_qualiterelation AS qualite_inverse ON qualite.relation_inverse_id = qualite_inverse.id
JOIN prelib_personne AS personne ON relation.personne_id = personne.id
JOIN prelib_personne AS personne_associee ON relation.relation_id = personne_associee.id
WHERE personne.factgrid <> '' AND personne_associee.factgrid <> ''

Fusion des qualités de relations genrées de PRELIB (Fait - terminé le 15 novembre 2022)

Transformation pour rendre non-binaires (sans genre) les qualités de relations interpersonnelles de PRELIB.

La réflexion qui a conduit à cette transformation : Il faudrait vraiment modifier PRELIB pour que soient saisies les relations inverses car pour l'instant, si l'on veut tous les liens père-enfant, par exemple, il faut croiser les déclarations mère, père , fils, fille.

Une solution possible serait de faire fi des variantes genrées, par exemple, fusionner oncle et tante en uncle or aunt comme sur Wikidata. Ce qui permettrait de lui associer la relation inverse niece or nephew dont les équivalents existent sur le Art & Architecture Thesaurus du Getty (voir par exemple nephews/nieces). Ces concepts non genrés permettraient de saisir des liens de parentés pour des personnes dont le sexe n'est pas encore connu (parce que leur prénom par exemple convient à un homme ou à une femme et que l'on n'a pas encore pris le temps de chercher un acte de naissance ou que l'acte de naissance n'est pas encore entré dans le domaine public) ou pour des personnes non-binaires.

Qualités de relations interpersonnelles PRELIB traitées (en cours, débuté le 14 novembre 2022, 54 avant la suppression des qualités en trop) :

1. père (id = 17) -> renommé en père ou mère
2. mère (id = 13) -> relations de ce type réaffectées à père ou mère (id = 17) puis qualité supprimée
3. arrière-grand-oncle (id = 59) -> renommé en arrière-grand-oncle ou arrière-grande-tante
4. grand-oncle (id = 10) -> renommé en grand-oncle ou grande-tante
5. oncle (id = 15) -> renommé en oncle ou tante
6. petit-neveu (fils du neveu ou de la nièce) (id = 19) -> renommé en petit-neveu ou petite nièce (fils ou fille du neveu ou de la nièce)
7. neveu (id = 14) -> renommé en neveu ou nièce
8. nièce (id = 67) -> relations de ce type réaffectées à neveu ou nièce (id = 14) puis qualité supprimée
9. arrière-petit-neveu (id = 75) -> renommé en arrière-petit-neveu ou arrière petite-nièce
10. assistant -> renommé en assistant ou assistante
11. a pour assistant -> renommé en a pour assistant ou assistante
12. collaborateur -> renommé en collaborateur ou collaboratrice
13. informateur -> renommé en informateur ou informatrice
14. a pour informateur -> renommé en a pour informateur ou informatrice
15. a pour collaborateur -> renommé en a pour collaborateur ou collaboratrice
16. arrière-grand-père -> renommé en arrière-grand-père ou arrière-grand-mère
17. grand-père -> renommé en grand-père ou grand-mère
18. grand-mère (id = 9) -> relations de ce type réaffectées à grand-père ou grand-mère (id = 11) puis qualité supprimée
19. beau-fils (id = 84) -> renommé en beau-fils ou belle-fille (gendre ou bru)
20. fils (id = 7) -> renommé en fils ou fille
21. fille (id = 6) -> relations de ce type réaffectées à fils ou fille (id = 7) puis qualité supprimée
22. arrière-petit-fils (id = 2) -> renommé en arrière-petit-fils ou arrière-petite-fille
23. petit-fils (id = 18) -> renommé en petit-fils ou petite-fille
24. petite-fille (id = 74) -> relations de ce type réaffectées à petit-fils ou petite-fille (id = 18) puis qualité supprimée
25. frère (id = 8) -> renommé en frère ou sœur
26. soeur (écrit oeu et non pas œu) (id = 55) -> relations de ce type réaffectées à frère ou sœur (id = 8) puis qualité supprimée
27. ami (id = 22) -> renommé en ami(e)
28. directeur de thèse (id = 23) -> renommé en directeur ou directrice de thèse
29. doctorant (id = 80) -> renommé en doctorant(e)
30. confesseur (id = 71) -> renommé en confesseur ou confesseuse
31. confessant (id = 72) -> renommé en confessant(e)
32. correspondant (id = 83) -> renommé en correspondant(e)
33. époux (id = 12) -> renommé en conjoint ou conjointe (sur le modèle de Wikidata, ce qui permet d'inclure les pacsés ou les personne en union libre)
34. épouse (id = 5) -> relations de ce type réaffectées à conjoint ou conjointe (id = 12) puis qualité supprimée
35. parrain (id = 16) -> renommé en parrain ou marraine
36. marraine (id = 56) -> relations de ce type réaffectées à parrain ou marraine (id = 16) puis qualité supprimée
37. créé filleul(e) (id = 85)
38. enseignant (id = 20) -> renommé en enseignant(e)
39. frère de lait (id = 68) -> renommé en frère ou sœur de lait
40. gendre (id = 40) -> relations de ce type réaffectées à beau-fils ou belle-fille (gendre ou bru) (id = 84) puis qualité supprimée
41. veuve (id = 69) -> renommé en veuf ou veuve
42. maître (id = 63) -> renommé en maître ou maîtresse

patron (id = 82) n'est utilisé qu'une seule fois pour qualifier la relation entre François Jaffrennou et Hippolyte Laterre, ouvrier imprimeur suite à la source "Sous l'impulsion de son patron, F. Jaffrennou, Laterre s'est consacré à l'étude de la langue et de la littérature bretonnes" Le Mercier d'Erm, Bardes et poètes..., p. 688. Cette qualité et la seule relation associée ont été supprimées le 5 janvier 2023.

maître (id = 63) et enseignant(e) (id = 20) sont peut-être synonymes pour certaines relations. Les quatre relations concernées ont été soumises à Nelly et Mannaig le 5 janvier 2023.

collaborateur ou collaboratrice (id = 61) est une notion très vague qui a été rattachée à item:Q394350 équivalent de collaborator sur Wikidata (description : someone who works with another person or group to create a piece of work) alors qu'il existe également sur Wikidata contributor (description : those who work with others on a collective work or project) exact match de [1].

Difficulté à trouver sur FactGrid, Wikidata ou OpenTheso (où la recherche sur informateur ne renvoie aucun résultat) à informateur ou informatrice utilisé une seule fois pour désigner un informateur de Théodore Hersart de la Villemarqué. Une définition qui semble correspondre le mieux est celui du Merriam-Webster pour informant.

# Requête SQL pour afficher les relations de type père ou mère (id = 17) ou de type mère (id = 13)
SELECT prelib_qualiterelation.*, prelib_relationinterpersonnelle.*
FROM prelib_relationinterpersonnelle
JOIN prelib_qualiterelation ON prelib_qualiterelation.id = prelib_relationinterpersonnelle.qualite_relation_id 
WHERE prelib_relationinterpersonnelle.qualite_relation_id in (17, 13)

# Requête SQL pour affecter les relations de type mère (id = 13) au type père ou mère (id = 17)
UPDATE prelib_relationinterpersonnelle SET qualite_relation_id = 17 
WHERE qualite_relation_id = 13

Création des relations inverses (depuis le 6 janvier 2023)

L'utilisation de la propriété Associated persons (P703) incite à la déclaration du rôle de chaque participant à la relation (subject has role et object has role). Or toutes les qualités inverses n'ont pas été saisies dans PRELIB. Par exemple, il manque la qualité inverse de mécène.

# 131 relations d'amitiés le 6 janvier 2023
SELECT * FROM prelib_relationinterpersonnelle as relation WHERE relation.qualite_relation_id = 22

Cette tâche est plus compliquée qu'elle en à l'air. Avant de créer les relations inverses, il faudrait lier explicitement entre elles les relations existantes et dupliquer dans la relation et son inverse les dates de début et de fin de la relation. En effet, PRELIB permet de déclarer le début et la fin d'une relation. Il peut donc y avoir plusieurs relations de même nature entre deux individus. Par ex. une amitié nait puis les amis se brouillent puis se réconcilient. Bien que ces cas soient probablement très rares dans PRELIB. Si une relation et son inverse sont liées, il faudrait créer des TRIGGER pour que si on modifie la relation ou son inverse, les caractéristiques de la relation (les dates de début et de fin de la relation, les protagonistes) soient mises à jour.

Il faudrait donc :

• Vérifier s'il n'existe qu'un seul type de relation entre chaque individu. Si c'est le cas, la création de la relation inverse et la liaison entre la relation et son inverse pourra peut peut-être réalisée automatiquement.
• Lier explicitement entre elles les relations et leur inverse, si l'inverse a déjà été saisie. C'est à dire créer une colonne supplémentaire dans la table prelib_relationinterpersonnelle permettant de déclarer la clé primaire de la relation inverse.
• Vérifier que les dates de début et de fin sont identiques dans la relation et son inverse. Les uniformiser si ce n'est pas le cas.
• Créer la relation inverse si cela n'a pas déjà été fait.

Pour que ces changement soient pérennes, il faudrait créer des TRIGGER pour que la modification/suppression d'une relation mette à jour/supprime son inverse.

Alignement ou Création des Items FactGrid et Wikidata équivalents aux qualités de relations interpersonnelles de PRELIB (en cours depuis le 15 novembre 2022)

Cette activité consiste à chercher sur Wikidata et sur FactGrid les Items équivalents à la version non-binaire des qualités (ex. uncle or aunt) et à les créer sur FactGrid si nécessaire. Certaines qualités posent des difficultés telle que secrétaire, qui a sur PRELIB le sens de secrétaire particulier ou encore collègue qui est un faux-ami en anglais et dont l'équivalent sur Wikidata n'a pas été facile à trouver (work colleague). Il faut donc parfois s'aider de dictionnaires (le Merriam-Webster pour l'anglais ou le portail lexical du CNRTL).

A propos de la création des nouveaux Item FactGrid :

1. Les qualités ont été déclarées comme instances de item:Q393634 (Relation), item:Q266808 (Activity) ou item:Q12670 (Kinship status) ou encore item:Q37073 (Career statement) dont est instance item:Q39644 (Student)
2. Les descriptions et les alias sont en général ceux des Items équivalents sur Wikidata
3. Dans la mesure du possible, les nouveaux Item FactGrid ont été déclarés dans les identifiants de leur équivalent sur Wikidata (ex. acquaintance).
4. Aucun Item n'a été crée pour les qualités inverses désignées par à pour [qualité] (ex. à pour secrétaire, à pour informateur ou informatrice).

J'en suis le jeudi 24 novembre 2022 à oncle ou tante dans la liste alphabétique des qualités de PRELIB. Reprise de cette tâche le 5 janvier 2023.

à faire :

• Il ne reste plus que child pour lequel il existe deux candidats sur FactGrid.

Réflexions

Difficultés à trouver comment exprimer les relations interpersonnelles sur FactGrid. Par exemple, il existe Item:Q399918 pour l'amitié mais dans quel cas cet item est utilisé ? A priori, il faut lui préférer la propriété équivalente Property:P192. Sur PRELIB, la réciproque n'a pas été systématiquement saisie, penser à le faire au versement dans FactGrid.

Voir aussi la saisie des liens de parentés sur Wikidata ?person wdt:P40 ?relative . ?relative wdt:P21 wd:Q6581097 (requête SPARQL donnée en exemple sur la page de fils) et la manière dont les parents (mother, father), les frères et sœurs (siblings), les membres de la famille (relatives) de George Washington ont été saisis.

An Item for a property is not unusual. If you want to express the relationship between two people you will use the Property. But if you have to say that a book is on friendship then you need the Item. --Olaf Simons (talk) 19:57, 29 September 2022 (CEST)

Sur Wikidata, il n'y a pas d'équivalent direct à Property:P192 (Friends with) mais une propriété générique, wikidata:Property:P3342, pour lier des personnes à des items à travers des qualificatifs (père, mère, frère, sœur, etc.) qui ne sont pas des propriétés mais des items.

Equivalences des données PRELIB avec des propriétés FactGrid et Wikidata

Colonnes des tables PRELIB	Valeur de la donnée PRELIB	équivalent FactGrid	requête SPARQL	équivalent Wikidata	requête SPARQL
prelib_personne.prenom_etat_civil	nom	Property:P192	https://tinyurl.com/2ftr49n3	wikidata:Property:P3342		prelib_qualiterelation.nom	ami	Property:P248

A faire :

• Au versement des relations d'amitié Property:P192, créer les relations réciproques

The alternative would be to create Items for each friendship and then to state the participants. That would be similar to our practice to create Items for meetings of people. The nodes between two people are nice as you can fill them with various sorts of information on a particular friendship - e.g. publications n this friendship. --Olaf Simons (talk) 10:33, 30 September 2022 (CEST)

Thank you for you suggestion. What would those Items be the instance of? Do you have exemple? By the way, is there any FactGrid equivalent to the wikidata:Property:P3342? Jean-Baptiste Pressac (talk) 11:59, 30 September 2022 (CEST)

I have to thank you for hinting at the Wikidata-solution. It seems we have some far more defined properties here, while Wikidata is shifting the nuances on the qualifiers - which is elegant too. Let's ask User:Bruno Belhoste what he thinks. Would you, Bruno, love to dissolve some our properties (we also have enemies P285, mistresses P217 etc.) to shift statements on qualifiers. (The messy aspect will then be all changes: the moments when you begin to hate your friend - this is where different properties are far better to handle especially in mass inputs via QuickStatements, and this is where I actually like our solution).

As to an example of a meeting: This search asks for all meetings where Q1308 met with Q133 - three events... We have lots of conferences or sessions of organisations where we had lists of participants. So: events with participants are extremely practical. But To create a node for each relation between two people would be possible but it would also become an alternative to the data model we are presently running relatively close to Wikidata (which has its own advantages in federated queries). So I am rather inclined to leave things as they are... --Olaf Simons (talk) 12:10, 30 September 2022 (CEST)

Bonjour Jean-Baptiste. A mon avis, nous avons intérêt à ne pas multiplier les propriétés. Donc, le modèle de wikidata consistant à avoir une propriété générique comme wikidata:Property:P3342 et un qualificatif pour préciser (par exemple ami, ennemi, partenaire d'affaire, etc.) me semble une excellente solution. Elle a aussi l'avantage de permettre très simplement de récupérer toutes les personnes qui ont un lien quelconque avec une personne données (utile pour les analyses de réseau). Nous utilisons d'ailleurs déjà des propriétés générique dans FactGrid comme Property:P165 à laquelle j'ai donné en français le libellé très général "Activités". Ce modèle a un seul inconvénient: les requêtes sont un peu plus difficiles pour le débutant en SPARQL puisqu'il faut écrire des clauses sur les qualificatifs. Une chose est certaine: nous devons maintenant choisir une bonne fois pour toute le modèle que nous privilégions, soit avec propriétés spécifiques comme Property:P192, soit avec propriétés génériques comme Property:P165. Pour ma part, j'opte pour la deuxième solution.--Bruno Belhoste (talk) 10:47, 2 October 2022 (CEST)

In which case it will make sense to move our Property:P192 "friends with" towards the open Wikidata solution, add qualifiers to these, and then to shift some of the other statements onto this property with the respective qualifiers. I have no problems with that. We will have to make sure that we do not loose source information on this path. --Olaf Simons (talk) 11:26, 2 October 2022 (CEST)

I just realised we also eventually created Property:P703 Associated Persons which is our closest equivalent to wikidata:Property:P3342. --Olaf Simons (talk) 13:44, 2 October 2022 (CEST)

It will be the clean way to move information to P703. --Olaf Simons (talk) 15:15, 2 October 2022 (CEST)

Thank you for your replies. As Bruno pointed out, my concern is not only to edit data but to edit it in a way that it could be easily queried, which makes the interest of wikidata:Property:P3342. As for Property:P703, it has a narrower domain than wikidata:Property:P3342, which allows to link any kind of Item with a person, as in the example given for wikidata:Property:P3342: Costa Serena significant person Marion Cotillard object has role ship christener Jean-Baptiste Pressac (talk) 09:45, 3 October 2022 (CEST)

I propose to slightly change the description of P703 in order to cover all the cases.--Bruno Belhoste (talk) 10:12, 3 October 2022 (CEST)

Requêtes SPARQL

https://database.factgrid.de/query/

Personnes versées par le projet

# PRELIB People (Personnes)
SELECT ?item ?itemLabel WHERE {
  # doit avoir comme nature Human (Q7)
  ?item wdt:P2 wd:Q7;
    wdt:P131 wd:Q418506.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Personnes et leurs relations

# PRELIB People and their associated persons (including people which associated persons (P703) are stated on the relation's items pages)
SELECT DISTINCT ?person ?personLabel ?associated_person ?associated_personLabel ?edgeLabel WHERE {
  ?person wdt:P2 wd:Q7;
    wdt:P131 wd:Q418506;
  # (wdt:P703|^wdt:P703) ?associated_person.
  (p:P703|^p:P703) [ps:P703 ?associated_person; pq:P277 ?edge].
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} 

Editions

Voir FactGrid:Print publications data model

Batch Fragments

Hi, Jean-Baptiste. Check our section of Batch fragments as soon as you want to create family and first names. Special purpose batch fragments are also particularly useful if you are opening Items one by one with loads of repetitive information. Best, --Olaf Simons (talk) 17:21, 7 June 2022 (CEST)

Family trees

https://www.entitree.com/factgrid/en/all/Q418508

just in case you have not seen... --Olaf Simons (talk) 17:10, 8 June 2022 (CEST)

Thanks Olaf, our Kerdanet family data dump was just about to use EntiTree ;-) Jean-Baptiste Pressac (talk) 15:17, 9 June 2022 (CEST)

PRELIB IDs

...and created, as Property:P763 and Property:P764 - let me know if you encounter any problems. (Just by they way: external identifiers are not critical. You can create them any time. But do make sure you set the type correctly as "external identifier", not as "Property" or "URL", to mention the two most common mistakes.) --Olaf Simons (talk) 09:41, 14 June 2022 (CEST)

Thank you Olaf, have a nice day Jean-Baptiste Pressac (talk) 09:49, 14 June 2022 (CEST)

Ah well, may be I was to fast with the green light for external identifiers. The corresponding Wikidata ID exists as Property:P343 --Olaf Simons (talk) 10:01, 14 June 2022 (CEST)

Maybe you find another external database which you need - to put on the number that has not been used so far... --Olaf Simons (talk) 10:10, 14 June 2022 (CEST)

However, Property:P343 could not reference https://www.wikidata.org/wiki/Q287667 for instance on Item:Q418804 Jean-Baptiste Pressac (talk) 10:17, 14 June 2022 (CEST)

Ah, yes, because that is what you should not do anyway. See Item:Q1308 and look into the section of Wikimedia-related projects. It is a clever arrangement, that prevents the creation of double records. Do link to the respective Wikidata entries whenever possible. --Olaf Simons (talk) 10:25, 14 June 2022 (CEST)

If you run a mass input the syntax is SWikidatawiki --Olaf Simons (talk) 10:28, 14 June 2022 (CEST)

OK, understood. Property:P765 could be deleted, then. Do you agree with the creation of the equivalent of https://www.wikidata.org/wiki/Property:P220. Could be useful to qualify the langages ? Jean-Baptiste Pressac (talk) 10:37, 14 June 2022 (CEST)

I just put it on P765 as that had not been used anyway. --Olaf Simons (talk) 10:45, 14 June 2022 (CEST)

Documents

Dear Jean-Baptiste, the following searches should run on the letters you are creating (and I am looking forward to other searches, you might eventually create...)

User:Bruno Belhoste's FactGrid Viewer is able to fuse transcripts into document pages. If you have transcripts you can put them on the wiki, for that purpose. Just create a D-Q12345 page for a Q12345 Item (to make it easy to spot these document pages) and set a Property:P251 link from your Item page to your Document page. It should work like this:

Item:Q6641 — linking to — [https://database.factgrid.de/wiki/D-Q6641]

generates the amalgamated page:

https://database.factgrid.de/viewer/item/Q6641

Tables

• Friedrich Cristian Rudorf, correspondence with him as author or recipient

• Friedrich Christian Rudorf as sender (right) and recipient (left)

• All documents authored by Friedrich Christian Rudorf with the corresponding documents

• All documents authored by Friedrich Christian Rudorf with holding institutions and shelf marks

• All documents sent to Adam Weishaupt
• All documents mentioning Adolph Franz Friedrich Ludwig Freiherr von Knigge
• All documents of Schwedenkiste, Vol. 12
• All Illuminati essays, where written? when? transcripts.

Maps

• the Illuminati correspondence, static Map view

• The Illuminati correspondence animated, Kepler.gl representation

---

As you have your own document viewer you might be able to play the same trick and to fuse transcripts into your viewer. --Olaf Simons (talk) 11:27, 14 June 2022 (CEST)

Thank you Bruno and Olaf for all those informations. About transcriptions, however, we would rather use the eScriptorium platform which generates TEI files. Concerning the display of digitized documents, would the display of documents via IIIF manifests possible ? Jean-Baptiste Pressac (talk) 11:52, 14 June 2022 (CEST)

mistake in the automatic translation

Dear Jean Jean-Baptiste - I just separated Item:Q163146 and Item:Q419135 again, as the English automatic version had smashed the German differentiation, just in case you want to create some chauffeurs, they are Item:Q419135. --Olaf Simons (talk) 17:44, 29 September 2022 (CEST)

Associated persons (P703)

Dear Jean-Baptiste Pressac,

you wrote:

Hello, I suggest the creation of kinship properties which could fit to any genre, as for sibling and as Wikidata did for example for uncle or aunt, niece or nephew or sibling-in-law.

I also suggest the creation of a property opposite of (see the equivalent Wikidata property opposite of) which could be used to declare that uncle or aunt is the opposite of niece or nephew.

This could be usefull to cary on uploading the PRELIB project data to FactGrid.

The PhiloBiblon people who are facing similar challenges persuaded me to create Property:P703 for any sort of associated person. You can then use the Qualifiers Property:P820 "Object has role" or alternatively Property:P277 "Subject has role" to state how the people are related, e.g. niece, uncle etc. --Olaf Simons (talk) 20:24, 14 November 2022 (CET)

Thank you Olaf. I am aware that you created Property:P703 and started using it. I deleted the property creation suggestion when I realized that I in fact needed Items nor Properties for the Object has role and Subject has role qualifiers. Jean-Baptiste Pressac (talk) 09:02, 15 November 2022 (CET)

Dear Jean-Baptiste. I just stumbled over these editis. Why don'rt you use the parent statements which we have? P241, P242, P150. --Olaf Simons (talk) 15:21, 10 January 2023 (CET)

Hello Olaf, My goal is to simplify the SPARQL queries to retrieve any connections between people, using only P703 instances Jean-Baptiste Pressac (talk) 13:21, 11 January 2023 (CET)

The problem is, however, that our regular searches will not get you data in this case. The chap compromise will be to create the regular statements and your preferred statements.

The P703 solution is cool, absolutely. Why didn't we take it right from the beginning? Basically because we tried to stay in line with Wikidata, so that future users can run "federated queries through both platforms. We do also have projects like this one from Denmark https://factgrid.ringgaard.com/ that amalgamate information, and here again your format will crate a data island. So, maybe, just add information on both ways - the one that suits you best and the one that will make you most readable. (PS, you can also searches on several properties together as in this query on [fathers and mothers of several generations) --Olaf Simons (talk) 13:43, 11 January 2023 (CET)

Bonjour Jean-Baptiste. Je suis de l'avis d'Olaf: il vaut mieux éviter l'utilisation de P703 pour les relations de filiation directe ou les relations maritales, puisqu'il existe des propriétés spécifiques pour ces relations. Il suffit d'utiliser l'opérateur | dans les requêtes si l'on veut faire des requêtes plus étendues, d'autant que les requêtes avec les qualificatifs sont délicates et peuvent produire des erreurs si l'on saute le statement node. Par ailleurs, il ne me paraît pas nécessaire de créer des doublons P277 et P820 pour la même relation. Il me semble que cela peut même être une source de confusion. Bien cordialeemnt ~--Bruno Belhoste (talk) 19:08, 16 January 2023 (CET)

Bonjour Bruno. J'avais bien noté la remarque de Olaf. Je règle des problèmes lié à ce premier import de relations interpersonnelles et je verse les filiations directes et les relations maritales. Par contre, je n'arrive pas à comprendre votre remarque concernant la production d'erreurs.

Integration des personnes créées par Elisabeth

https://crbc-dataset.huma-num.fr/prelib?sql=select+*+from+prelib_personne+where+factgrid+is+null

https://crbc-dataset.huma-num.fr/prelib?sql=select%0D%0A++distinct+prelib_personne.id%0D%0Afrom%0D%0A++prelib_personne%0D%0A++join+prelib_ecritoeuvre+on+prelib_ecritoeuvre.personne_id+%3D+prelib_personne.id%0D%0Awhere%0D%0A++prelib_personne.factgrid+is+null

https://crbc-dataset.huma-num.fr/prelib?sql=select%0D%0A++distinct+prelib_revue.titre%0D%0Afrom%0D%0A++prelib_personne%0D%0A++join+prelib_ecritoeuvre+on+prelib_ecritoeuvre.personne_id+%3D+prelib_personne.id%0D%0A++join+prelib_oeuvre+on+prelib_oeuvre.id+%3D+prelib_ecritoeuvre.oeuvre_id%0D%0A++join+prelib_paraitdans+on+prelib_paraitdans.oeuvre_id+%3D+prelib_oeuvre.id%0D%0A++join+prelib_revue+on+prelib_revue.id+%3D+prelib_paraitdans.revue_id%0D%0Awhere%0D%0A++prelib_personne.factgrid+is+null

Merging Items

Hi! Before you merge please have a look how many other items link to which of the two. Its less work to merge to the item which has the most items linking there. This is quite often the lowest Q-Nr (but does not have to...). These links have to be corrected too following the merge... Thank you!--Martin Gollasch (talk) 14:17, 15 November 2022 (CET)

M.A.

Item:Q456190 Hi Jean-Baptiste - are you sure this is not simply Magister Artium abbreviated? --Olaf Simons (talk) 22:49, 24 April 2023 (CEST)

Colours et Iconclass classification system

just briefly: we have loads of colours - Bruno Belhoste made the database colour sensitive.

• all 478 FactGrid colours

Hello Olav. You did not let me make arguments for the creation for this item. We would like to use the Iconclass classification system to describe wine labels. https://iconclass.org/22C4(BLACK) is one of them, although this is a colorJean-Baptiste Pressac (talk) 16:14, 16 October 2023 (CEST)

Dear Jean-Baptiste. I did not quite get the idea behind it. The general concept behind Wikibase is that we have items for objects of knowledge (which we identify with Q-numbers). If the object is "black" (the colour) then I should rather create a property for "Iconclass" - which I will do immediately: Here you are Property:P980 - since that Property is extremely useful to have, while two sorts of the same black (just under different names and classifications) will create a forge of information. --Olaf Simons (talk) 18:50, 16 October 2023 (CEST)

• all colours with a IconClass ID

Hello Olav, thank you for the creation of Property:P980 (equiv. to Wikidata property P1256 to declare that an item is equivalent to an iconclass concept). However, some iconclass concepts have no reason to have an equivalent FactGrid item (such as Christ crucified on a tree or on a vine). I also will create a property equivalent to P1257 which enables to declare the Iconclass code depicted in an artwork.

Dear Jean-Baptiste, and here you are: Property:P986 - I would not mind to have motifs such as Jesus crucified on a vine as Items, but it is of course easy to just ink to ICONCLASS-IDs. --Olaf Simons (talk) 10:56, 19 October 2023 (CEST)

Thank you, Olav ! Jean-Baptiste Pressac (talk) 13:29, 20 October 2023 (CEST)

Dedicatees or Subscribers?

Dear Jean-Baptiste, are these people Item:Q641683 dedicatees or subscribers? (Just looked into the publication...) --Olaf Simons (talk) 10:47, 8 November 2023 (CET)

Hello Olaf, According to PRELIB, they are not subscribers, but people to whom the book is dedicated, despite the fact the list is unusually long. But that's right there are no mention of any dedicatees in the digital edition in Google Books. I will figure out why.--Jean-Baptiste Pressac (talk) 11:38, 8 November 2023 (CET).

Hello, I had a look in a physical exemplary of the book, a collection of texts, and I confirm that those people are dedicatees (each text of the collection is dedicaded to one of them) and not subscribers. --Jean-Baptiste Pressac (talk) 13:58, 10 November 2023 (CET)

Interesting and wonderfully rare (says the book historian), --Olaf Simons (talk) 15:06, 10 November 2023 (CET)