Genj - Rapports - Partitionnement en classe de patronyme
From Arvernes Wiki
 |
|---|
Accueil
-
Copies écrans
-
Prérequis
-
Télécharger
-
Installer
-
Guide utilisateur
-
F.A.Q.
-
Discuter
-
Liens
Auteur: Daniel MOYNE
Version 1.1.0 (04/10/2007)
Cet outil est l'un des nombreux rapports de GenJ.
Contents |
Avertissement
- Ce rapport va modifier le contenu de la base de données en ajoutant des informations normalisées dans votre fichier gedcom.
Celles-ci seront placées dans les étiquettes _CLAS personnalisées et créées pour l'occasion. - Si vous ne voulez pas conserver ces informations dans votre arbre il vous suffit après activation du rapport ou de ne pas sauvegarder votre fichier, ou encore d'utiliser l'option "sauvegarder sous..." avec filtrage des entités "INDI:_CLAS", ou enfin d'utiliser la fonction "défaire".
- Ce rapport n'accepte pas les noms vides (prénoms et noms) et se terminera le cas échéant en invitant l'utilisateur à corriger le problème.
- L'indentification d'enfants naturels exigent de nommer le père inconnu de la manière indiquée dans la fenêtre "Options".
Évidemment l'utilisateur doit s'assurer que ce même nom est utilisé dans la base de données.
Ce que ce rapport fait
- Ce rapport permet de construire des classes de patronyme à partir d'un individu représentant (nommé INDI dans la suite) tel que choisi par l'utilisateur.
L'ensemble des individus d'une même classe de patronyme ainsi créée peut alors être affiché dans les fenêtres Table (voire Arbre) si l'étiquette _CLAS est ajouté à la template de description. Tous ces individus ainsi classés font partie d'une même tribu et peuvent avoir de noms de famille avec des différences dues à la manière dont les patronymes ont été retranscrits ou dans les registres paroissiaux ou dans les registres d'état-civil.
Quelques particularités de ces classes de patronymes _CLAS ainsi construites :
- À partir du moment où une classe de patronyme a été crée quel que soit l'INDI de cette classe choisi comme représentant la construction de classe aboutira au même résultat à savoir création de la même classe.
- Dans l'usage courant cela correspond par exemple à l'appelation "les MARTIN de tel village" même si parmi ceux-ci les uns ont pour patronyme "MARTAIN" alors que d'autres peuvent se nommer "MARTIN".
Pour leurs voisins ils font partie de la même tribu.
Un INDI ne peut appartenir qu'à une seule classe de patronyme.
Si un INDI est né de père inconnu puis reconnu par un autre père il aura 2 représentations dans la base de données liées par un alias.
Chacun de ces INDIs appartient à des classes de patronyme distinctes ce qui n'est nullement en contradiction avec ce qui est dit plus haut.
Il est conseillé de nommer les classes de patronyme ainsi: un patronyme moderne couramment utilisé, par exemple on préfèrera "MARTIN" à "MARTAINT" ou "MARTEIN" auquel on ajoute un notion de territoire par exemple un nom de village ce qui par exemple pourrait donner comme nom de classe: "MARTIN-Ranchot". Au fur à mesure de l'extension de la classe on pourra être amené à en changer le nom en remplaçant l'attribut village par un attribut département puis région selon la répartition géographique des individus concernés.
Si 2 tribus distinctes ont le même patronyme à l'intérieur d'une même zone géographique il est conseillé de les distinguer en ajoutant par exemple "_1" et "_2" au patronyme commun.
- Dans ce cas on aurait par exemple les 2 classes de patronymes suivantes: "MARTIN_1-Ranchot" et "MARTIN_2-Ranchot".
Si à un moment un lien permet de prouver que INDIs de ces 2 tribus font en fait partie du même groupe ou classe de patronyme il suffira de relancer le rapport en partant d'un représentant quelconque de l'un ou l'autre de ces groupes pour attribuer un nom unique.
Les 2 anciens noms seront vus par le rapport au moment de choisir un nom unique par exemple "MARTIN-Ranchot".
Comme il y a un fondement mathématique à tout cela voici un petit rappel qui pourra éventuellement intéresser:
Si on revient maintenant à la généalogie:
Limitations
- Pour l'instant seuls les ascendants biologiques sont pris en compte dans la construction de classes de patronyme.
- Après construction il n'y a pas de mises à jour automatiques d'autres parents liés à ceux indexés et donc indexables par le même processus.
Travail à faire
Créer des valeurs pas défaut à la création d'individus pour éviter d'avoir des prénoms ou noms vides.
Dans une première phase il est souhaitable d'améliorer ce rapport avec mise à jour automatique pour toutes modifications réalisées à l'intérieur de l'application qui justifient ou une appartenance ou une non-appartenance à un classe de patronyme donnée avec la même logique que celle développée ici. En attendant il suffit de relancer l'exécution de ce rapport à partir d'un représentant quelconque de cette classe de partronyme pour une mise à jour globale.
Compte tenu de ce qui est dit plus haut il apparaît nécessaire d'intéger ce rapport après phase de test dans sa forme actuelle dans l'application.
