FR 2972280 A1 20120907 FR 1100634 A 20110303 -1- La présente invention est relative à une structure particulière de base de données généalogiques, référencées par un nom ou adresse standardisés et dont les champs index présentent un codage particulier, créant un système de base de données relationnelles permettant une recherche rapide d'individus, ainsi que la réduction significative des échanges de données ou fichiers généalogiques. En outre, le codage particulier des index repérant les individus et leurs familles, simplifie considérablement la complexité de tout logiciel de traitement ou consultation de données généalogiques et réduit le travail et temps de recherche des généalogistes. Tout généalogiste (personne cherchant à construire des généalogies, c'est à dire à prouver les relations de parenté existantes entre plusieurs individus donnés ou à trouver toutes sortes d'informations (comme l'état civil, la biographie, etc.) sur un groupe d'individus parents entre eux, sait que le volume de données à consulter est considérable. Considérons seulement les fichiers généalogiques au format gedcom (acronyme de GE nealogical D ata Com munication) qui contiennent, sous une forme textuelle standardisée, une liste numérotée d'individus, une liste numérotée de famille avec au moins pour chaque individu l'index de sa famille parentale et pour chaque famille, l'index des époux et enfants éventuels. Si l'on essaie d'imaginer le nombre de fichiers gedcom issus seulement des généalogistes d'un seul pays, ceux-ci se comptent par millions. En effet, si l'on prend la France comme exemple, où l'on dénombre environ 20 millions de foyers, en supposant un nombre d'environ 2 enfants par foyer, cela donne environ 2 parents, 4 grands-parents, 2 enfants, soient 4 familles en supposant qu'un des enfants est adulte ; si l'on considère qu'une seule personne parmi ces 8 s'occupe de la généalogie des 4 familles, cela donne 1 fichier gedcom pour 4 familles ou encore 5 millions de fichiers gedcom pour la France et 1 million de fichiers gedcom si l'on considère que seulement 1 famille sur 5 potentielles s'intéresse à la généalogie. Or en faisant un calcul simple, on peut montrer que ces 1 million de fichier gedcom représentent une énorme quantité de redondance et de travail refait sans cesse. En effet, sachant qu'il y a seulement environ 36 000 communes en France, il suffit selon la présente invention, de créer et mettre à jour 36 000 fichiers gedcom ou encore 36 000 bases de données locales pour contenir la généalogie de tous les français, en mettant en accès publique la lecture et la modification de ces bases de données. On voit tout de suite le gain de travail apporté par la présente invention, puisque 1 million de généalogistes travailleraient sur 36 000 fichiers, ou encore en divisant 1 million par le nombre proche de 100 de départements français, environ 10 000 généalogistes travailleraient sur 1 base de données locale départementale, ce qui est considérable. Il est à noter en effet, que les généalogistes se regroupent en « communautés » parce qu'ils travaillent sur les mêmes villes ou villages et ces échanges locaux sont très productifs. Pour continuer l'état de l'art technique et étudier les brevets existants, un bon exemple est le brevet EP 1 550 958 A3 / US 2005/0147947 Al. -2- Ce brevet revendique, en bref, des procédés logiciels et des serveurs associés, gérant une base de données (centrale ou distribuée), permettant d'ingurgiter et trier des millions de fichiers gedcom, afin, par des méthodes statistiques, d'éliminer les redondances ou incohérences ou divergences sur les données d'un individu ou d'une famille. On voit bien que ce brevet et ces méthodes ne font que s'adapter au foisonnement de fichiers gedcom. Aucun brevet ne s'attaque au mal à la racine, en essayant de diminuer la quantité de données généalogiques induite par le travail des généalogistes pour constituer leur fichier gedcom que ce soit de façon isolée ou grâce à des échanges. Le but du brevet en référence semble idéal : le but ultime revenant à constituer une base de données mondiale unique ; ainsi, ayant une seule base contenant tout, cela laisse penser que les recherches et résultats seraient forcément exhaustifs et pertinents. Mais cette idée présente plusieurs défauts : - une base de données unique mondiale serait sujette à des réticences, soit par peur de l'effet « big brother », soit par crainte de donner un monopole au propriétaire de la base dont on ne saurait trop qui il est, - le principe de levée de doute sur les doublons, incohérences etc. par des méthodes statistiques sur de grands nombres de gedcom, influencées par le vote majoritaire d'experts dont on ne sait qui ils sont, conduirait de même à une certaine méfiance ou doute ou insatisfaction, - l'émergence de bases de données mondiales concurrentes, diminuerait la qualité des résultats et sèmerait des confusions. En prenant du recul sur cette question de foisonnement de travaux de généalogistes, on peut faire des observations qui nous guident vers une meilleure solution, objet de la présente invention : - les généalogistes s'intéressent seulement à quelques dizaines, voire une centaine de villes, dont beaucoup se regroupent dans des zones géographiques, cela les pousse à contacter d'autres généalogistes travaillant sur les mêmes villes ou zones, tant et si bien que se créent des associations, clubs portant le nom de ces régions, - beaucoup de ces associations ou clubs créent des listes de « relevés » de registres paroissiaux ou d'état-civil pour chaque ville de la région qui les intéressent et les distribuent en interne aux membres. On voit donc bien qu'en fait, les outils efficaces des généalogistes reviennent à reconstituer, de manière numérique, les registres manquants, perdus ou presque illisibles des années passées antérieures à l'an 2000 environ (on peut raisonnablement retenir cette date comme étant le début de la période actuelle où tous les registres d'état-civil sont enregistrés directement sur ordinateur). -3- Mais il reste encore un grand pas à faire entre avoir des relevés clairement lisibles sur papier ou sur tableur ou même sur ordinateur des mairies, et la constitution de base de données exploitables et faciles à consulter par exemple via Internet. La présente invention vise donc à permettre de créer un ensemble de base de données, référencées et structurées de manière identique pour le monde entier. Structurées de manière identique s'entend sur : - la façon de nommer ou adresser les bases de données, - la façon d'indexer le contenu des données, - les catégories minimum à renseigner dans les bases (certaines bases pouvant contenir plus d'information selon le goût ou bonne volonté des responsables). La présente invention inclut également une méthode type utilisable sur un serveur de site Internet, utilisant le protocole AJAX (Asynchronous Javascript + XML) pour extraire des telles bases de données, les informations concernant un individu ou famille et le langage Javascript ou Vbscript pour présenter les résultats. Selon une réalisation type, les bases de données généalogiques regroupent les données d'environ 100 à 1000 villes ou villages d'une même zone (une base de données unique par pays serait tout aussi bien réalisable, mais cela reproduirait les défauts constatés pour le brevet type en référence, c'est-à-dire un manque d'attrait et rejet d'une telle base). Ainsi les généalogistes de la région pourront plus facilement s'approprier, au sens moral et légal, cette base de données et en assurer le remplissage et la mise à jour. Selon la présente invention, les bases de données locales comprennent au minimum deux tables, Pour la table individus : - un champ index de l'individu, dont le codage est particulier suivant la présente invention, un champ sexe, - un champ nom de famille, un champ prénom, un champ date de naissance, un champ index lieu de naissance, - un champ date de décès, un champ index lieu de décès, -4- - un champ index du mariage du ou des parents de l'individu, dont le codage est particulier suivant la présente invention, - un champ mariages où sont listés les index de chaque mariage ou famille de l'individu, dont le codage est particulier suivant la présente invention, - un champ note, Etc.... Pour la table familles/mariages : - un champ index de la famille, dont le codage est particulier suivant la présente invention, - un champ index de l'épouse, - un champ index de l'époux, - un champ date du mariage, - un champ index du lieu du mariage, - un champ enfants où sont listés les index de chaque enfant du couple ou individu monoparental, dont le codage est particulier suivant la présente invention, - un champ note, Etc.... Remarque 1 : dans l'exemple de réalisation ci-dessus, la table individus comporte au moins 11 champs et la table familles seulement 7. Mathématiquement, il serait faisable d'avoir une seule table mélangeant les enregistrements individus et familles en ajoutant un indice à l'index afin de distinguer s'il s'agit d'un enregistrement individu ou famille. Cependant, on voit que les lignes enregistrements familles comporteraient systématiquement 4 champs vides, ce qui n'est pas économique en termes de taille de base de données. Toutefois, si le nombre de champs venait à être bien supérieur pour chaque table (ajout de champs témoins, type de mariage, baptême, « sait signer », profession, alias, source etc....) le taux de perte serait réduit et pourrait permettre de ne faire qu'une seule table. Mais encore, on note qu'avoir deux tables correspond en fait à la structure existante des registres anciens, un registre des mariages distinct du registre des naissances (et décès). Avoir deux tables serait donc plus proche des habitudes et permet bien évidemment d'accélérer les recherches. Remarque 2 : Afin d'avoir une notation unique pour désigner 1 - un mariage officiel enregistré à l'état-civil, d'un couple ayant ou non des enfants 2 - ou bien un couple de parents non mariés ayant des enfants, -5- 3 - ou bien un parent isolé ayant des enfants, il est convenu de lister ces 3 cas dans la table que l'on appellera indifféremment « mariages/familles », de façon telle que - dans le premier cas l'enregistrement comporte un index d'épouse, un index d'époux, si possible des date et lieu de mariage, et éventuellement des index d'enfants, - dans le deuxième cas, l'enregistrement comporte un index d'épouse et un index d'époux, des champs vides pour les dates et lieu de mariage, et des index d'enfants - dans le troisième cas, l'enregistrement comporte soit un index d'épouse, soit un index d'époux, l'autre index étant vide ou à zéro et des index d'enfants, pour désigner une famille monoparentale, un parent seul ayant reconnu le ou les enfants. Remarque 3 : toujours pour optimiser la taille des bases de données, il est préférable de constituer la table des individus avec un seul champ contenant les mariages/familles des parents d'un individu, plutôt que d'utiliser 3 champs, un pour l'index du père, un pour l'index de la mère, un pour l'index du mariage/famille des parents. Comme dans presque 100% des requêtes il sera nécessaire de connaître ces trois informations, il sera facile de retrouver les index des parents à partir de l'enregistrement de leur mariage/famille. Or si l'enregistrement d'un individu ne contenait que les champs des ses mère et père et si l'on voulait chercher les données du mariage des parents, il faudrait consulter tous les mariages des père et mère pour savoir duquel est issu l'individu en question. Remarque 4 : enfin, il est recommandé d'enregistrer respectivement la liste des mariages/familles d'un individu et la liste des enfants d'une famille, dans respectivement un seul champ index mariages de la table individus et un seul champ de la table mariages/familles plutôt que d'inscrire un mariage par champ ou un enfant par champ, soit une quinzaine ou vingtaine de champs qui seraient nécessaires pour des époux ou parents courageux. Description détaillée des champs : - Champs index De par le fait de créer ces bases de données et les rendre publiques, on peut leur donner un nom ou adresse suivant un standard mondial, selon la présente invention, et constituer un index des individus et familles dont le codage comporte deux parties : l'une étant l'adresse de la base de données contenant tel individu ou famille, la seconde étant l'index ordinal de l'individu ou de la famille à l'intérieur de la table où il se trouve. En concaténant les deux parties par exemple par un point, on obtient un index qui ressemble à une adresse URL (« Uniform Resource -6- Locator ») de page Internet, permettant de situer et accéder à n'importe quel enregistrement, sans avoir à trop se demander dans quel serveur il se trouve (pour les personnes ou ordinateurs non avertis !), par un simple clic sur l'index de l'individu ou sur l'index de parent ou sur l'index d'un mariage ou d'un enfant, selon le schéma suivant : Index d'un individu d'index ordinal 105 dans la table individus, de la base de données « Ile de France » : nom de base ile de france indi.105 10 Selon une autre représentation similaire, si l'on crée un nom de domaine Internet correspondant au nom de la base de données, on obtient directement comme index une adresse URL en ajoutant l'index ordinal individu derrière un point d'interrogation http://nom_de_base_ile_de_france.fr ?indi=105 15 Et pour un mariage ou famille : Index d'un mariage d'index ordinal 467 dans la table famille, de la base de données « Ile de France » : nom_de_base_i le_de_france_fam ily.467 ou encore une adresse URL 20 http://nom_de_base_ile_de_france.fr ?fami=467 N.B. II est à noter que l'index des données d'un individu ou mariage étant littéralement une adresse URL et donc ayant l'aspect d'un lien Hypertexte, la présente invention peut avantageusement être dénommée « Hypergénéalogie » ! 25 - Champ sexe - Champ nom de famille, - Champ prénom, - Champ date de naissance, 30 - Champ date de décès, - Champ note, Ces champs ne nécessitent pas de remarque, ils ont des valeurs classiques5 - Champ index lieu de naissance, - Champ index lieu de décès, - Champ index lieu de mariage, Par économie de place mémoire, il sera judicieux de créer une table mondiale des lieux et de mettre dans ces champs l'index dans cette table, des lieux de naissance et de décès d'un individu ou l'index d'un lieu de mariage. II est à noter que si les lieux de naissance et décès sont locaux, donc dans la base de données locale, les généalogistes gestionnaires locaux sont libres de libeller et coder les noms de lieux comme ils l'entendent, par contre les logiciels d'interrogation de base de données, devront toujours renvoyer le nom d'un lieu, qu'il soit local ou non et dans ce deuxième cas, interroger la table mondiale des noms de lieux pour les noms de lieux hors base locale. - Champ index du mariage/famille des parents de l'individu, Il s'agit de mettre dans ce champ, selon le codage de l'invention, l'index du mariage ou famille du ou des parents de l'individu. Cet index peut pointer sur un mariage présent dans la même base de données locale ou bien présent dans une autre base de données dans le monde ! - Champ mariages/famille où sont listés les index de chaque mariage ou famille de 20 l'individu, Ce champ contient la liste des index des mariages officiels d'un individu ou bien l'index d'un enregistrement dans la table des mariages/familles où sont listés les enfants naturels d'un couple ou d'un individu parent isolé. Par commodité, les enregistrements d'un parent isolé pourront être situés dans la base de données de son lieu de naissance et les enregistrements 25 pour un couple non marié, pourront être enregistrés dans chacune des bases de données référençant chaque parent. Pour la table familles/mariages, les champs index de l'épouse, index de l'époux, date du mariage, index du lieu du mariage, suivent les règles énoncées ci-dessus, 30 - champ enfants Champ où sont listés les index de chaque enfant du couple ou individu monoparental, 7 -8- Selon ces dispositions, la présente invention améliore les systèmes existants en ce que : - il n'est quasiment plus nécessaire d'échanger des fichiers gedcom entre généalogistes locaux ! Ceux-ci auront à leur disposition comme outil, un site Internet relié au serveur de base de données locale par lequel ils pourront consulter le contenu de la base et le mettre à jour. - le lever de doute en cas de doublon ou erreur de saisie ne nécessitera plus de logiciels complexe ni de statistiques dont on pourrait douter. En effet, tout comme pour la mise à jour d'une page de l'encyclopédie Wikipédia, en marge d'une page de contenu, les généalogistes intéressés pourront avoir une page de discussion et il sera très aisé de trouver un avis commun entre quelques uns ou dix généalogistes plutôt que d'utiliser un ordinateur qui aura digéré des milliers de fichiers gedcom, d'où la dénomination « WikiGénéalogie » ! - et chose incroyable, un site personnel Internet de généalogie familiale pourra être mis en place sans qu'il contienne un quelconque fichier de données ! II suffira en effet de mentionner sur une page personnelle, le lien-index d'un individu de base (le « de cujus ») ou les liens-index de quelques individus supplémentaires (en cas d'époux non mariés ou de cousins éloignés que l'on veut mettre en valeur) et, en cliquant sur ces liens, le logiciel serveur du site personnel pourra aller chercher les données des ancêtres et descendants correspondants, dans les bases de données idoines. Description du système, selon l'invention : La figure 1 illustre un système type (100), réalisé selon l'invention, qui comprend un ordinateur hôte (101) serveur de la base de données locale (102), base contenant une table (103) d'enregistrements de données d'individus et une table (104) d'enregistrements de données de mariages/familles, un ordinateur (105) serveur réseau qui interroge la base de données, via le serveur (101), et répond aux requêtes émises par les ordinateurs (106) des utilisateurs, un réseau (107) (LAN ou Internet ou autre) à travers lequel l'ordinateur serveur (105) communique avec des serveurs de site Internet de généalogie (108), eux-mêmes communiquant avec les ordinateurs (106) des utilisateurs. L'ordinateur hôte (101) inclut un logiciel qui le contrôle pour exécuter les méthodes de recherches dans les tables d'enregistrements décrites ci-après, de même les serveurs (108) de site Internet incluent un logiciel qui les contrôle pour exécuter les méthodes d'interrogations des bases de données et présenter les résultats. La figure 2 illustre une page HTML type (200), comportant un tableau de résultats (201) et un ou plusieurs logiciels de contrôle (202) fonctionnant en arrière-plan. Le fonctionnement du système réalisé et décrit en figure 1 et figure 2, par exemple pour une requête concernant un individu, est le suivant :35 -9- Après avoir demandé à un serveur de site (108) de généalogie, par exemple une liste d'individus ayant un nom de famille donné et nés dans une ville donnée, un utilisateur (106) reçoit une page HTML (200) contenant une liste de résultats (201) et en arrière-plan un logiciel « client » (202) (aussi dénommé « User agent ») de type JavaScript. Ainsi lorsque l'utilisateur clique sur un individu dans la liste des résultats, ce logiciel script (202) déclenche une procédure de type AJAX (« Asynchronous Javascript + XML ») qui, toujours en arrière-plan, va envoyer des requêtes à la base de données (102) contenant les données de l'individu. Selon les possibilités offertes par le script (202), celui-ci pourra, à la réception de ces données, émettre d'autres requêtes AJAX vers les bases de données idoines, pour avoir les données individuelles par exemple des parents, des mariages et conjoints éventuels, ainsi que des enfants éventuels et ainsi de suite en continuant de génération en génération d'ascendants ou descendants, selon la limite souhaitée par l'utilisateur ou le concepteur du logiciel (202). Outre la structure des bases de données, les problèmes techniques à résoudre pour mettre en oeuvre l'invention, concernaient - l'accès par le logiciel JavaScript (202) à des sites différents de bases de données, - l'envoi de requêtes multiples enchaînées. Pour comprendre le premier problème, il faut savoir qu'habituellement, une page HTML (200) depuis un ordinateur « client » (106), ne peut accéder via le logiciel client (202), qu'à d'autres pages situées sur le même domaine Internet que celui auquel appartient la première page (200). La solution technique pour qu'un site Internet (105) gérant une base de données, accepte et réponde aux requêtes venant d'ordinateurs clients (106) via des sites Internet (108) différents du site (105), est de paramétrer le programme gérant le site (105) avec l'instruction suivante : header('Access-Control-Allow-Origin: *') qui autorise le programme de l'ordinateur (105) à être interrogé par un programme JavaScript client (202) quelle que soit l'adresse d'où il émane. La solution technique au deuxième problème concernant les requêtes enchaînées vers différents serveurs (105), est d'utiliser la méthode AJAX dans les logiciels clients (202) pour gérer ces requêtes. En général, un ordinateur client (106) envoie une seule requête et dans ce cas, le 35 serveur (108) du site Internet envoie une seule nouvelle page (200) qui contient la réponse et un nouveau logiciel script (202) ; le logiciel (202) de la page précédente a donc été effacé. 2972280 -10- Or, si l'utilisateur demande des informations s'étalant sur plusieurs générations (données d'un individu puis de ses parents) ou sur un mariage en demandant les données du mariage puis les données des époux, le programme JavaScript (202) de la première page étant appelé à disparaître, il ne sera pas possible de mémoriser dans l'ordinateur (106), la liste des 5 requêtes effectuées et les résultats intermédiaires à moins d'utiliser un cookie de très grosse taille. Il serait tout aussi illusoire de demander au serveur (108) de site Internet, de mémoriser toutes les demandes et résultats et surtout de rester actif pendant plusieurs dizaines de secondes en attendant de recevoir le dernier résultat. Heureusement, comme il a été annoncé, l'emploi de méthode script AJAX résout 10 élégamment ce problème. En effet, un logiciel script (202), peut très bien envoyer des requêtes multiples et/ou enchaînées, sans que ta page (200) soit rechargée donc sans que le logiciel (202) soit effacé. Le logiciel script (202) peut alors très bien mémoriser les requêtes et résultats intermédiaires et rester soit actif (mode synchrone), soit en veille (mode asynchrone) et se réactiver lors de l'arrivée d'une réponse à une requête et alors mettre à jour un tableau de 15 résultats. Le système selon l'invention, est particulièrement destiné à mettre en place un ou plusieurs réseaux mondiaux de bases de données généalogiques. REVENDICATIONS1. Systèmes de bases de données généalogiques, distribuées et indexées, caractérisés en ce que les bases de données (102) ont comme index, un nom ou une adresse standardisés au plan mondial, qui permet de les référencer et de les répartir dans le monde entier. 2. Systèmes selon la revendication 1, caractérisés par des champs des tables de données (103) et (104), tels que les champs d'indexation des individus ou mariages/familles sont standardisés et comportent une partie adresse de base de données selon la revendication 2 et une partie servant d'index ordinal donnant leur position à l'intérieur de la table de données correspondante. 3. Systèmes selon l'une des revendications 1 ou 2, caractérisés par une liste minimum de champs de données, suivante : Pour la table individus : - un champ index de l'individu, - un champ sexe, - un champ nom de famille, - un champ prénom, - un champ date de naissance, - un champ index lieu de naissance, - un champ date de décès, - un champ index lieu de décès, - un champ index du mariage/famille des parents de l'individu, - un seul champ mariages où sont listés les index de chaque mariage ou famille de l'individu, Pour la table familles/mariages : - un champ index de la famille, - un champ index de l'épouse, - un champ index de l'époux, - un champ date du mariage, - un champ index du lieu du mariage,- un seul champ enfants où sont listés les index de chaque enfant du couple ou individu monoparental, 4. Systèmes selon l'une des revendications 1, 2 ou 3, caractérisés par l'emploi d'un logiciel script (202) utilisant la méthode AJAX pour émettre des requêtes multiples enchaînées. 5. Systèmes selon l'une des revendications 1, 2, 3 ou 4 caractérisés par un serveur (105) acceptant des requêtes venant de domaines Internet différents de celui auquel il appartient. 6. Systèmes de serveurs associés en réseau et consultés par des ordinateurs d'utilisateurs, utilisant des bases de données nommées ou indexées, selon l'une quelconque des revendications précédentes.