Wikipédia abstraite/Mises à jour/2021-05-05

This page is a translated version of the page Abstract Wikipedia/Updates/2021-05-06 and the translation is 100% complete.
716-newspaper.svg Mises à jour de la Wikipédia abstraite Translate

liste de diffusion de la Wikipédia abstraite Wikipédia abstraite sur IRC Wikipédia abstraite sur Telegram Wikipédia abstraite sur Twitter Wikipédia abstraite sur Facebook Wikipédia abstraite sur Youtube site web de la Wikipédia abstraite Translate

Le lien manquant de la Wikipédia abstraite aux données lexicographiques dans Wikidata.

En 2018, Wikidata a lancé un projet pour collecter la connaissance lexicographique. Plusieurs centaines de milliers de lexèmes ont été créé depuis et cette année les outils seront développés davantage par Wikimédia Allemagne pour rendre plus faciles la création et la maintenance de la connaissance lexicographique dans Wikidata.

L’extension lexicographique de Wikidata a été développée avec l’objectif qui est devenu la Wikipédia abstraite dans l’esprit , mais une récente discussion au sein de la communauté m’a montrée que je n’avais pas encore clarifié la connexion possible entre ces deux parties. Aujourd’hui, je voudrais exprimer en quelques traits quelques unes des idées sur la façon dont la Wikipédia abstraite et les données lexicographiques dans Wikidata pourraient fonctionner ensembles.

Il y a deux façon principales d’orgoniser un dictionnaire : soit vous organisez les entrées les entrées par « lexème » ou par mot » et décrivez leurs sens (ceci s’appelle l’approche sémasiologique), soit vous organisez les entrées les entrées selon leurs « sens », « lemmes » ou « significations » (ceci s’appelle l’approche onomasiologique). Wikidata a intentionnellement choisi l’approche sémasiologique : les entrées dans Wikidata sont appelées des Lexèmes, et les contributeurs peuvent ajouter des Sens et des Formes aux Lexèmes. Les Sens sont utilisés pour les différentes significations qu’un même Lexème peut régulièrement invoquer, et les Formes sont les différentes façons selon lesquelles le Lexème peut être exprimé dans un texte en langue naturelle, p.ex. afin selon les règles grammatical d’accord en nombre, en cas, en temps, etc. Le Lexème « mouse » en anglais (« souris » en français, L1119) a donc has deux sens (un pour le petit animal rongeur et un pour le périphérique d’entrée d’un ordinateur) et deux formes en anglais (« mouse » et « mice » au pluriel) mais une seule forme en français. Pour un exemple de dictionnaire collaboratif onomasiologique, on peut en consulter un sur OmegaWiki, qui est principalement organisé selon se principe avec (actuellement plus de 51 000 entrées) lemmes différents et comment ils sont exprimés en différentes langues.

La raison pour laquelle Wikidata a choisi l’approche sémasiologique est basée sur l’observation qu’il est beaucoup plus simple pour un projet collaboratif sourcé par quantité de monde, et qu’il a moins de potentiel d’être contentieux. Il est bien plus facile de rassembler une liste de mots utilisés dans un corpus que de rassembler une liste de toutes les significations référencées dans le même corpus. Et bien que ce soit « plus simple », ce n’est pourtant pas trivial. Nous voulons collecter une liste des Lemmes (ou Sens) pour chaque Lexème, et nous voulons décrire les connexions entre ces Sens et savoir : si deux Lexèmes dans une langue ont le même Sens, comment ces Sens sont reliés au large catalogue d’éléments dans Wikidata, et comment les Sens dans des langues différentes sont reliés entre eux. Tout ceci sont des questions très difficiles avec lesquelles la communauté sur Wikidata est encore en train de se battre (voir également l’essai sur Faire sens).

Voyons un exemple.

« Stubbs était probablement un des plus jeunes maires de l’histoire du monde. Il est devenu le maire de Talkeetna, en Alaska, à l’âge de trois mois et six jours, et a tenu cette position jusqu’à sa mort il y a presque quatre ans. Également, Stubbs était un chat. »

Si nous voulons exprimer la dernière phrase — « Stubbs était un chat » — il nous faudra pouvoir exprimer le sens chat (donné en petites capitales pour la sémantique ; ici, nous voulons nous concentrer entièrement que le niveau lexical et nous ne discuterons pas des problèmes grammaticaux et idiomatiques ; nous laisserons cela pour un autre jour). Comment nous référons-nous à l’idée du chat pour le contenu abstrait ? Comment aboutissons nous éventuellement, en anglais, à la forme du mot « cat » (L7-F4) ? En français avec la forme du mot « chat » (L511-F4) ? En en allemand avec la forme du mot « Kater » (L303326-F1) ?

Notez que ces trois mots ne partagent pas la même signification. Le mot anglais « cat » peut se référer autant au mâle qu’à la femelle ; alors que le mot français peut se référer à un « chat » de façon générique, par exemple si nous ne connaissons pas le sexe de Stubb, ce mot utilisé est comme pour un mâle, mais une femelle serait habituellement référencée en utilisant le mot « chatte ». Le mot allemand, en revanche, ne pourrait référencer qu’un chat mâle. Si nous ne savons pas su Stubbs est mâle ou femelle, nous utiliserions en allement le mot « Katze » à la place, là où en français nous utiliserions encore le mot « chat », comme nous l’avons dit. Et l’anglais a également des mots pour les chats mâles, p.ex. « tom » ou « tomcat », mais ceux-ci sont beaucoup moins fréquemment utilisés. Une recherche sur le web de « Stubbs is a cat » en anglais retourne plus de 10 000 résultats, mais pas un seul pour « Stubbs is a tom » ni « Stubbs is a tomcat ».

En comparaison, pour Félicette, le premier chat dans l’espace et le seul jusqu’à présent, les articles utilisent évidemment les mots « chatte » en français et « Katze » en allemand.

Nous ne parlons pourtant ici que de trois langues relativement proches, nous ne parlons également que d’un nom assez simple. Ceci semblait n’être qu’un cas très simple et pourtant ce n’est pas le cas. Lorsque nous parlons des verbes, des adjectifs ou des noms de concepts plus complexes (par exemple des différents types de localités d’habitation humaine ou des différentes façons dont les parties du corps humain sont conceptualisées dans des langues différentes, par ex. bras et mains, ou encore des termes pour les couleurs), ceci devient très rapidement bien plus compliqué. Si nous devions exiger que tous les mots que nous souhaitons utiliser dans la Wikipédia abstraite doivent d’abord s’aligner sur leurs significations, cela conduirait à une tâche très difficile dans notre chemin critique. aussi, bien qu’il aurait été évidement très utile pour la Wikipédia abstraite de suivre une approche onomasiologique (comme ce serait merveilleux d’avoir un catalogue exhaustif des significations !), cette approche a été jugée trop difficile et une approche sémasiologique a plutôt été choisie.

Par chance, un catalogue des significations n’est pas nécessaire. La raison par laquelle nous pouvons l’éviter est le fait que la Wikipédia abstraite n’a besoin que de générer du texte, mais n’a pas besoin de l’analyser ou de le comprendre. Ceci nous permet de nous en sortir en utilisant un Constructeur qui, pour chaque langue, utilise un Moteur de rendu pour sélectionner le mot approprié (ou une autre représentation grammaticale). Par exemple, nous pourrions avoir un Constructeur qui prend plusieurs autres éléments d’information facultatifs : le type d’animal, son alimentation, sa couleur, si c’est un adulte, s’il est neutre et sinon son genre, le nombre d’entre eux, etc. Par chacun de ces éléments d’information, nous pouvons marquer si cette information doit être exprimée dans le Rendu, ou bien si cette information est facultative et peut être ignorée, et donc préciser ce qui est disponible pour sélectionner le mot le plus approprié. Note, ceci ne dit pas comment la communauté doit le faire, mais cela ébauche une approche possible qui permettrait d’éviter de dépendre d’un catalogue des significations.

Chaque Rendu dans une langue donnée pourrait alors utiliser les informations dont il a besoin pour sélectionner le mot approprié. Si une langue a une préférence pour exprimer le sexe (tel que l’allemand), il peut le faire, alors qu’une langue qui préfère ne pas l’exprimer (comme l’anglais) peut aussi le faire. Si pour une langue l’âge du chat compte pour la sélection du mot, son rendu peut l’en déduire. Si la couleur de l’animal compte (comme pour les chevaux en allemand), son Rendu respectif peut utiliser cette information. Si une information nécessaire est absente, nous pourrions ajouter ceci à une file de maintenance afin que les contributeurs puisse la compléter. Si une langue apparaissait n’avoir aucun mot, une expression nominale pourrait être utilisée, par exemple en utilisant un mot moins spécifique comme « animal », « félidé », ou une expression comme « félin mâle », ou encore « cheval noir » pour le mot allemand « Rappen ».

La caractéristique importante de conception ici est que nous n’avons pas besoin de nous assurer et de trouver un accord sur l’alignement des sens des mots entre des langues différentes. Nous n’avons pas besoin d’un catalogue des significations pour parvenir à ce que nous voulons.

Maintenant, il y a plein d’autres cas d’utilisation en faveur d’un tel catalogue de significations. Ce serait une ressource extrêmement précieuse. Et même sans avoir un tel catalogue, les déclarations connectant les Sens et les Éléments dans Wikidata peuvent être très utiles pour la création et la maintenance des Moteurs de rendus, mais ceux-ci n’ont pas besoin d’être utilisés quand le texte en langue naturelle pour Wikipédia est créé.

Cette suggestion n’est pas destinée à être prescriptive, comme nous l’avons dit. Ce sera à la communauté de décider de quelle façon mettre en œuvre les Moteurs de rendu et quelles informations utiliser. Par ceci, je dessine une architecture qui nous permet d’éviter de rester bloqué sur une ressource (précieuse mais difficile à créer), un catalogue exhaustif des significations alignant les significations des mots entre différentes langues.