Référentiels (lieux et personnes), notes

architexte commented 2 years ago

Personnes

Le référentiel des personnes sert :

pour les métadonnées descriptives : correspondants (expéditeur, destinataire)
pour l’annotation des contenus éditoriaux : adresses, transcriptions, analyses, notes

Les personnes sont autant que possible identifiées par un QID Wikidata.

Comme la couverture de Wikidata est insuffisante (les éditeurs identifient de nombreux inconnus), l’application doit permettre de créer et décrire de nouvelles personnes.

Modèle / attributs

Une personne a les attributs suivants :

person.id : identifiant base de données, interne à l’application
person.label : un label, si possible au format 'Prénom Nom (AAAA-AAAA)' (simili NF Z 44-061)
person.ref : l’URI de référence (prioritairement Wikidata)

Le modèle permet de consigner des informations liées au contexte d’un échange épistolaire.

person_has_role.person_role_id : rôle tenu pour une lettre – vocabulaire contrôlé : sender, recipient ou inlined (personne citée')
person_has_role.function : la fonction de la personne au moment de l’échange : champ libre (pas de vocabulaire contrôlé)

Pour une personne, selon l’état des données saisies, on peut ainsi déterminer qu’elle est:

person_id	document_id	function
100	777	Grande-duchesse de Toscane
100	3468	Reine d'Espagne

Qualité de la donnée

Décrire des personnes physiques (et non des groupes : par ex. 'Les habitants de Chartres')
Garantir l’unicité (pas évident : le changement de nom d’une même personne peut rendre son identification difficile)
Éviter les doublons de fonctions (par ex. 'Ambassadeur en Angleterre' + 'Ambassadeur de France en Angleterre')

Lieux

Un lieu : un lieu d’habitation (villes/villages)

Le référentiel des lieux sert :

pour les métadonnées descriptives : date de lieu
pour l’annotation des contenus éditoriaux : adresses, transcriptions, analyses, notes

L’objectif est de pouvoir agréger toute la masse documentaire relative à une ville. Une note libre permet de préciser cette locatisation (par. Paris > Palais du Louvre).

Avantage de cette solution : nous gérons une liste plate de lieux d’habitation, sans soucis de la hiérarchie administrative

Inconvénients :

impossible de décrire la date de lieu si la seule information disponible est 'France' ou 'Bourgogne'.
pas de filtre région / département, etc.

Pour ce second point, nous pourrions inscrire pour chaque lieu un 'Concept Path' que nous pourrions exploiter pour l’indexation, par ex. :

id	label	concept_path	ref
131	Dijon	/France/Bourgogne-Franche-Comté/Côte-d'Or/Dijon	[https://www.wikidata.org/entity/Q7003	](https://www.wikidata.org/entity/Q7003%7C)
2	Turin	/Italie/Piémont/Turin	[https://www.wikidata.org/entity/Q495	](https://www.wikidata.org/entity/Q495%7C)

architexte commented 2 years ago

Évolution attendue par OP explicitée le 05/07/22 : une personne est une personne physique OU morale

Évaluer l’impact de cette nouvelle définition des personnes :

backend : nouvel attribut person.type (=PERS|ORG) pour typer les 'personnes'
frontend : revoir la requête SPARQL pour récupérer les personnes + les organisations (Q43229) / ou formuler une nouvelle requête spécifiquement pour les organisations (disposer d’un switch dans le formulaire)
NB. déterminer si les organisations sont bien typées côté Wikidata (ontologie complexe en la matière…)
frontend : évaluer l’impact pour la page de gestion du référentiel des personnes
recherche : évaluer l’impact pour l’indexation + conception du formulaire de recherche

MrGecko commented 2 years ago

Pour mémoire, voici la liste des personnes morales sorties du référentiel :

Et les documents impactés :

chartes / lettres-app