La modélisation des noms propres 

La modélisation des noms propres 

Prolexème et forme vedette 

Théoriquement, nous aurions dû considérer le prolexème comme un identificateur : le couple pivot-langue. La table des alias aurait alors regroupé toutes les formes possibles du nom propre. Dans la pratique nous avons préféré définir le prolexème par une forme vedette, ce qui facilite la manipulation des données par des linguistes, en simplifiant l’accès au dictionnaire. Il n’est cependant pas évident de la choisir. Parmi les noms propres Organisation des Nations Unies, Nations Unies et ONU, lequel devons-nous prendre comme forme vedette ? Et sur quel critère devons-nous le choisir ? L’utilisation future de règles d’aliasisation et de dérivation nous a conduit à prendre la forme la plus longue comme prolexème. Nous pensons qu’il sera plus facile ainsi d’établir les règles de formation d’alias et de dérivés. Par exemple, il est plus évident de concevoir des règles pour former les noms propres Nations Unies et ONU à partir du nom propre Organisation des Nations Unies que d’utiliser les deux autres formes pour retrouver la première. Nous pourrions créer une règle qui consiste à effacer la partie générique Organisation pour obtenir le nom propre Nations Unies et une autre règle qui consiste à prendre les premières lettres de chaque mot plein pour générer le nom propre ONU. A la fin de cette thèse, ce travail sur la création de règles d’alias reste un projet. Suivant les applications, les stratégies pourront être différentes. Dans la traduction de l’anglais vers le français, il faudrait probablement proposer ONU pour UNO alors que dans la recherche d’information le prolexème et tous ses alias seront également intéressants. 

Date 

Nous nous sommes posé la question de savoir si nous devions ajouter une date pour certaines relations, comme la synonymie et la méronymie. Faut-il préciser la date dans une relation de synonymie diachronique ? Nous avons longtemps hésité sur cette question. La ville de Saint-Pétersbourg a été fondée vers 1703. Elle a pris le nom de Petrograd de 1914 à 1924, puis de 1924 à 1991 elle a porté le nom de Leningrad. Elle a repris le nom 137 Évaluation Fig. 8.1 – Exemple de cycle pour la relation de synonymie diachronique. de Saint-Pétersbourg à partir de 1991. Ces relations peuvent se modéliser de trois façons différentes (voir figure 8.1). Le cas 2 représente une modélisation de ces trois relations de synonymie avec la présence d’une date. Nous avons un cycle entre ces noms propres. Il faudra peut-être préciser une date de fin et une date de début à laquelle un nom propre a été renommé. Comme notre but n’est pas de créer une encyclopédie, nous n’avons pas précisé de date pour la synonymie diachronique. De plus, imposer une date (ou deux dates ?) dans cette relation peut compliquer le travail de remplissage de la base, car l’utilisateur devra faire une recherche sur la date pour laquelle un nom propre a été renommé. Il s’agit plutôt d’un travail d’historien. La présence de la date n’est pas utile pour toutes les applications. Pour des applications de traduction de textes datant de 1918, il faudrait plutôt proposer Petrograd comme traduction. Par contre, pour des applications de recherche d’information, la présence de la date n’a aucun intérêt. Si un utilisateur fait des recherches sur le nom propre Saint-Pétersbourg, l’application devrait non seulement lui fournir des textes ou apparaît ce nom propre mais aussi des textes ou apparaissent aussi les noms propres Petrograd et Leningrad. Si la présence de la date est nécessaire à une application donnée, nous pourrons toujours ajouter un attribut date dans la relation de synonymie diachronique dans le modèle conceptuel de données. Le cas 3 représente une modélisation où l’on distingue la ville de Saint-Pétersbourg à sa création (Saint-Pétersbourg1 ) et celle d’aujourd’hui (Saint-Pétersbourg2 ), sans préciser de date. Nous n’avons pas retenu ce cas, car il suppose une duplication inutile dans notre base de données. Dans notre modélisation, nous ne considérons qu’une ville de Saint-Pétersbourg. Le cas 1 correspond à notre modélisation de ces relations où nous n’avons gardé qu’une forme canonique, Saint-Pétersbourg. Pour l’étude de textes de l’après-guerre, il serait possible de modifier le canonique qui deviendrait Leningrad. Pour les textes actuels, Petrograd renvoie directement à Saint-Pétersbourg. Le problème de la date se pose aussi dans le cadre d’une relation de méronymie. La Bretagne est-elle est en France ? L’Alsace et la Lorraine sont-elles en France ? Selon la date, les réponses à ces questions peuvent varier. L’importance numérique de la méronymie rend cette information impossible. Avant le référendum du 5 juin 2006, nous avions dans notre base de données les noms propres : Serbie et Monténégro (type Pays), Serbie (type Région) et Monténégro (type 138 Région). Suite au référendum, nous avons modifié les entrées Serbie et Monténégro en changeant leur type Région en Pays. Cet exemple justifie la création de notre supertype Territoire. Si nous avions associé directement aux noms propres Serbie et Monténégro ce supertype, nous n’aurions pas eu besoin de faire de modification. 

Synonymie et forme canonique

 Dans le modèle conceptuel de données, nous avons précisé que la relation de synonymie relie une forme canonique (forme ayant la plus grande notoriété) et une forme synonyme (forme moins connue). Un nom propre peut être la forme canonique de plusieurs autres noms propres et chaque nom propre peut avoir au plus une seule forme canonique. Le modèle conceptuel de données n’interdit pas les cycles dans une telle relation. Par exemple, si un nom propre P1 est le canonique d’un nom propre P2 et si P2 est le canonique d’un nom propre P3, il est possible que P3 soit le canonique de P1 (voir figure 8.2). Ce cas peut poser des problèmes lors de la recherche d’une forme canonique, car en partant du nom propre P1 nous risquons de retomber sur celui-ci. Pour interdire les cycles, il faut créer une fonction de vérification des cycles dans l’interface de travail lors de la saisie des relations de synonymie. Actuellement, nous n’avons pas rencontré de noms propres vérifiant ce cas dans la base de données. Fig. 8.2 – Exemple de cycle pour la relation de synonymie. Soit le nom propre P1 qui est le canonique de deux autres noms propres P2 et P3. Si les noms propres P2 et P3 sont en relation de synonymie avec le nom propre P1 suivant un même diasystème, notre modèle ne propose alors aucun ordre entre P2 et P3. Pour différencier entre P2 et P3, il faudrait peut-être associer à chacun de ces noms propres des informations statistiques (voir table STATISTIQUE dans la section 5.2.5 du chapitre 5) pour indiquer leur notoriété.

Les relations d’hyperonymie et de méronymie

 La méronymie, la synonymie et la relation d’accessibilité sont les seules relations qui relient des noms propres entre eux. Nous nous sommes posé la question de savoir si nous pouvions trouver une relation d’hyperonymie entre des noms propres. Dans le modèle, nous avons des relations d’hyperonymie entre des noms propres et des types. Par exemple, le Jardin des Plantes est en relation d’hyperonymie avec le type Édifice. Nous avons essayé de chercher des exemples d’hyperonymie entre des noms propres, mais cela semble être un phénonème rare. Voici les exemples que nous avons trouvés : – Pouvons-nous dire qu’une Mégane II Estate est une Mégane ? – Pouvons-nous dire qu’une Mégane est une Renault ? – Pouvons-nous dire que Charlemagne est un Carolingien ? – Pouvons-nous dire que Georges Bush est un Bush ? Dans les deux premières questions, Mégane II Estate est un nom de produit, Mégane est un nom de gamme et Renault est un nom de marque. Nous ne faisons pas cette distinction dans notre typologie, car nous souhaitions avoir une typologie réduite. Ces trois noms sont classés dans le type Produit. Peut-on dire que les noms de produits, de gammes et de marques sont des noms propres ? Il n’est pas évident de répondre à cette question. Peut-on alors dire qu’il s’agit de noms communs ? Là aussi, la question reste ouverte. Il s’agit de noms se trouvant à la frontière entre les noms propres et les noms communs. Nous les avons considérés dans notre modèle comme des noms propres. Dans les deux dernières questions, nous avons une relation entre des célébrités et leur dynastie. Il s’agit de cas limites et discutables. Pour le cas des noms de dynastie, cette relation d’hyperonymie s’applique bien. Mais est-ce que les noms de dynastie sont des noms propres ? Nous pouvons aussi dire que le nom propre Mégane est en relation de méronymie avec le nom propre Renault. De même pour les noms propres Charlemagne et Carolingien, où nous avons une relation de méronymie entre un membre et une collection. Étant donné la rareté de la relation et son statut parfois discutable, nous avons décidé de considérer ces cas comme des relations de méronymie.

La relation d’accessiblité 

Les relations classiques, telles que la méronymie et la synonymie, ne sont pas les seules relations qui relient les noms propres. Il existe d’autres relations entre les noms propres : – Abel est un fils d’Adam – Wilbur Wright est un frère de Orville Wright – Alcibiade est un élève de Socrate – Pierre est un apôtre de Jésus-Christ – Platon est le fondateur de l’Académie – Pierre de Coubertin est l’inventeur des Jeux Olympiques – Bram Stoker est l’auteur de Dracula – Abd Allah II est un roi de la Jordanie – Seti Ier est un pharaon de l’Égypte antique – Mehmed II est un sultan de Turquie – Anne Stuart est une reine d’Angleterre – Copenhague est la capitale du Danemark – Pyongyang est la capitale nationale de la Corée du Nord – Lyon est le siège d’Interpol – … Repérage Expansions Capitale Capitale, chef-lieu, préfecture, etc. Créateur Sculpteur, auteur, peintre, etc. Dirigeant non politique Patron, directeur, chef, etc. Dirigeant politique Président, roi, empereur Élève Disciple, élève, apôtre, etc. … Fig. 8.3 – Repérages et expansions. 140 Nous avons dans notre base de données un grand nombre d’expansions différentes pour un nom propre. Créer autant de relations que d’expansions (par exemple : fils, frère, élève, etc.) risque d’être coûteux et de nuire à la lisibilité du modèle. Certaines expansions existent dans une langue et sont absentes dans d’autres langues. Par exemple, en France nous faisons la distinction entre un chef-lieu, une préfecture, une capitale, etc. Nous ne pouvons pas créer dans le niveau interlingue des relations qui ne serviront que pour une seule langue. Nous avons décidé de les regrouper dans une seule et unique relation que nous avons appelée relation d’accessibilité, à laquelle nous avons ajouté des repérages généraux (voir figure 8.3). Les informations sur les expansions sont conservées dans la relation d’expansion classifiante. Cette relation d’accessibilité n’est pas une modélisation idéale mais correspond à une solution économique, suffisante pour la plupart des applications de TAL. 8.2 L’interface de travail de Prolexbase L’interface de travail sous la forme d’une applet pose un certain nombre de problèmes : – il faut installer la machine virtuelle java pour pouvoir exécuter une applet. – une applet est exécutée du côté du client. Parfois, des règles au niveau du pare-feu chez le client peuvent empêcher l’applet de se connecter à la base de données se trouvant dans le laboratoire LI de l’université de Tours. Pour résoudre ces problèmes, il faudrait développer une nouvelle interface en utilisant JSP (Java Server Pages). JSP nécessite l’utilisation d’un serveur Tomcat, dont nous ne disposons pas dans notre laboratoire. Le travail de remplissage de Prolexbase ne peut se faire que par des spécialistes car l’utilisation de l’interface de travail collaboratif peut être compliquée pour les utilisateurs ne connaissant pas notre projet. Pour pouvoir l’utiliser correctement, chaque utilisateur doit obligatoirement connaître la structure de notre modèle et les termes employés. Il faut envisager de mettre en place une formation détaillée sur les fonctions de l’interface de travail pour leur permettre d’utiliser efficacement l’interface. Les points forts de l’interface sont sans doute les fonctions de travail sur les fichiers. Nos collaborateurs possèdent des données sous forme de fichiers. Ces fonctions leur permettent de faciliter le travail de remplissage de la base de données. De plus, le menu fichier accélère considérablement la phase de remplissage, car il est plus rapide et économique d’ajouter en une seule fois un fichier comprenant une centaine de noms propres avec leurs informations en utilisant le menu fichier que d’ajouter un par un chaque nom propre avec ses informations en utilisant le menu ajouter. Ce travail de remplissage se fait en deux étapes. La première étape consiste à travailler sur un fichier sous format Unicode en utilisant un tableur (Excel, Calc, etc.). Durant cette première phase, l’utilisateur n’a pas besoin de se connecter à l’interface de travail. Il peut travailler chez lui et sous n’importe quel système d’exploitation. La deuxième phase consiste à se connecter à l’interface de travail et à utiliser le menu fichier pour préciser les données qu’il souhaite intégrer à Prolexbase. 8.3 Analyse quantitative Au début de la phase de remplissage, nous nous sommes posé la question de savoir quels noms propres nous devions rentrer dans notre base de données et comment les classer suivant un critère de notoriété. Sur quels critères de notoriété devons-nous sélectionner ou non un nom propre ? Nous avons présenté à une étudiante de Licence de Lettres une liste de noms de personnages célèbres. Nous lui avons demandé de sélectionner ceux qu’elle connaissait. En lisant sa liste, nous nous sommes rendu compte qu’elle connaissait des noms de peintres, d’auteurs, de philosophes, etc. que nous ne connaissions pas et que les noms de scientifiques dans sa liste étaient peu nombreux. Selon la culture et le parcours de la personne, nous obtenons des listes très différentes. Or ce travail a déjà été fait par les éditeurs de dictionnaires. Nous avons décidé de prendre tous les noms propres du dictionnaire Larousse Collège et de les considérer comme les noms propres que tout français est censé connaître. Ce dictionnaire précise sur sa couverture qu’il comporte environ 6 000 noms propres. Ce travail nous a permis de vérifier et de tester la pertinence de notre modèle en traitant manuellement les 6 000 noms propres contenus dans le dictionnaire Larousse Collège. La première partie du travail consistait à parcourir le dictionnaire pour sélectionner tous les noms propres. Les noms propres sont recopiés dans un fichier Excel. A chaque nom propre, nous associons un type, une règle de flexion, les relations qu’il entretient avec d’autres noms propres, ses alias, les expansions, la détermination, etc. La figure 8.4 présente une partie des données de ce fichier extrait du dictionnaire Larousse Collège.