Property talk:P7722

Documentation

TLFi ID
identifier for a lexeme on the Trésor de la langue française informatisé

Applicable "stated in" value

Digitized Treasury of the French Language (Q3541344)

Data type

External identifier

Allowed values

([a-zàâäçéèêëîïôöùûüÿ'-]+(\/[0-9]+)?|)

Example

no label (L228281) → huileux
no label (L2331) → tour/2
no label (L20414) → pronom

Formatter URL

https://www.cnrtl.fr/definition/$1

Related to country

France (Q142) (See 638 others)

Et maintenant ?[edit]

@Nomen ad hoc, VIGNERON, Le Passant, Jsamwrites, ديفيد عادل وهبة خليل, Theklan:

Cette propriété a été créée il y a presque 2 mois maintenant, depuis elle est à l'abandon. Serait-il possible d'utiliser cette propriété ? voir même de l'ajouter semi-automatiquement sur les 10000 et quelques lexèmes en français ? (je peux aider sur l'aspect technique mais comme toujours il y a la question de l'alignement...)

Cdlt, VIGNERON (talk) 16:36, 29 February 2020 (UTC)[reply]

@Nomen ad hoc, VIGNERON, Le Passant, Jsamwrites, ديفيد عادل وهبة خليل, Theklan:

Peux-tu préciser ce que pourrait être un ajout semi-automatique ? Quel pourcentage de réussite peut-on en attendre ? A-t-on une idée de la charge de travail que représente l'"alignement". Je continue de penser que cette propriété est très intéressante, mais, n'ayant jamais pratiqué cette opération, je mesure mal l'investissement nécessaire pour la mettre en place. Bien cordialement, --Le Passant (talk) 14:17, 2 March 2020 (UTC)[reply]

@Le Passant: je dois avouer que je n'ai pas d'idée précise donc difficile de donner une estimation. En général pour un alignement, on essaye de se baser sur le plus de données possible mais les Lexèmes en français sont pour la plupart quasiment vides (quand ils ne sont pas erronés) donc je ne vois guère que le lemme principal pour effectuer l'alignement (sur ce point, je suis preneur de toute idée et remarque). C'est pourquoi je propose un alignement semi-automatique et non complètement automatique mais effectivement c'est chronophage car cela nécessite de vérifier chaque pair de suggestion à la main avant import. Cdlt, VIGNERON (talk) 15:05, 2 March 2020 (UTC)[reply]

Valeurs autorisées[edit]

@Nomen ad hoc, Le Passant, Jsamwrites, ديفيد عادل وهبة خليل, Theklan:

Bonjour,

Sur une suggestion de Hsarrazin j'ai remplacé les valeurs autorisées [a-z]+(\/[0-9]+)? par [a-zàâäçéèêëîïôöùûüÿ]+(\/[0-9]+)?. Pour le contexte, il s'agissait de résoudre la violation de contrainte sur été (L26716)TLFi ID (P7722)été mais en y regardant de plus près, je me rends compte que les deux URLs https://www.cnrtl.fr/definition/été et https://www.cnrtl.fr/definition/ete renvoie à la même page. Du coup, je m'interroge, vaut-il mieux conserver les accents ou non ? (question préliminaire à la question précédente d'ailleurs)

En bonus : et si on garde les accents, aurais-je oublié une lettre diacritée dans la nouvelle liste des valeurs autorisées ? Et y a-t-il une façon plus simple de l'écrire ?

Cdlt, VIGNERON (talk) 14:50, 31 March 2020 (UTC)[reply]

Je viens d'ajouter une contrainte complexe et du coup pour que cette contrainte fonctionne, le mieux est que l'identifiant correspondent au lemme. Sauf objection, je propose donc de partir sur cette règle.

Cdlt, VIGNERON (talk) 20:36, 20 July 2022 (UTC)[reply]

Ah et il reste la question des capitales (généralement initiales, sauf pH), avec ou sans ? @Hsarrazin, C. Erwan, Envlh, Eihel, Pamputt: qu'en pensez-vous ? Cdlt, VIGNERON (talk) 06:28, 21 July 2022 (UTC)[reply]

Bonjour. Je suis d'accord pour que l'identifiant soit au plus proche du lemme, donc avec les diacritiques. Pour les capitales, j'ai regardé ce qu'il y avait dans les URLS et dans le code HTML des pages. Le plus propre semble être de ne garder que les minuscules : à certains endroits, il y a un mix des deux, sauf dans le code JavaScript, où c'est systématiquement en minuscule (exemple : sendRequest(5,'/definition/ph//0') sur la page pH). — Envlh (talk) 12:29, 6 August 2022 (UTC)[reply]

Hello VIGNERON

[a-zà-ÿœ]+(\/[0-9]+)? puisque les caractères sont aussi à la suite ;) ―Eihel (talk) 17:05, 22 August 2022 (UTC)[reply]

Ce à quoi j'ajoute [a-zà-ÿœ']+(\/[0-9]+)?/i et le flag insensitiv, car le cas de « pH » et tous les habitants de… doivent forcément avoir une majuscule. En regardant la requête des mauvais formats, tous les cas sont possibles maintenant, comme « ångström ». Qu'en pensez-vous ? ―Eihel (talk) 17:13, 22 August 2022 (UTC)[reply]

@Eihel: es-tu sûr ? j'ai l'impression que certaines caractères valides en français sont en dehors de cette plage, inversement la plage va contenir des caractères que l'on veut exclure. J'aurais donc plutôt tendance à faire la liste explicite, non ?

Et pour la casse, la casse cela dépend si l'on souhaite mettre ou non dans la valeur : "Brésilien" ou "Brésilien" sur Brésilien (L592523) ?

Cdlt, VIGNERON (talk) 17:33, 22 August 2022 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ ah pardon, VIGNERON, j'ai encore modifié mon RegEx. Je n'étais pas dans la problématique des habitants. Pourquoi enlever ces valeurs d'habitants (Brésilien) ? Je ne comprends pas. Est-ce que les URLs sont toutes en minuscule ? Le problème de l'utilisateur lambda est d'ajouter ce qui lui semble le mieux comme valeur. Et ces valeurs ne sont pas fausses pour autant, non ? Il vaut mieux palier au problème en amont, àmha.
Pour la plage des caractères, j'ai regardé la table et j'ai vérifié les valeurs fausses : tout rentre. Cela dit, effectivement il y a des caractères en plus, mais ça ne me semble pas grave du tout. J'aurais pu agrandir les possibilités en prenant toutes les tables, mais là, il n'y a que 2 lignes. Cordialement. ―Eihel (talk) 17:50, 22 August 2022 (UTC)[reply]

Bref faut juste enlever le flag si on ne garde pas les majuscules et corriger une vingtaine de valeurs. ―Eihel (talk) 17:58, 22 August 2022 (UTC)[reply]

Bonjour. Petit rappel : il n'y a pas d'identifiant TLFi. On a juste un moteur de recherche, qui affiche des entrées du TLFi en fonction de la chaîne saisie. Cette chaîne est normalisée en minuscule, tant dans le champ de recherche, que dans le code visible du site (exemples déjà explicités précédemment : Brésilien et pH). Concernant la regex, je préfère nettement la version proposée par VIGNERON, pour les raisons qu'il a données (faux-positifs et faux-négatifs). Cdlt, ― Envlh (talk) 18:11, 22 August 2022 (UTC)[reply]

@Envlh, VIGNERON: J'ai modifié le RegEx suivant tout ce qui a été écrit ci-dessus : simplification, ajout des cas avec une valeur fausse, sans prise en compte des majuscules. Maintenant « ångström » est valable et j'ai ajouté une explication à la contrainte. Je vous laisse vérifier et modifier le cas échéant. Cordialement. ―Eihel (talk) 18:24, 22 August 2022 (UTC)[reply]

Envlh Suivant le résumé de https://www.wikidata.org/w/index.php?title=Property:P7722&oldid=prev&diff=1710559625, j'ai pris en compte ce qui est ici, donc vos avis. Qu'est-ce qui n'est pas pris en compte ? ―Eihel (talk) 18:29, 22 August 2022 (UTC)[reply]

@Eihel, Envlh: la question n'est pas si simple qu'elle paraît. D'abord, les diacritiques en français, c'est compliqué (voir fr:Diacritiques_utilisés_en_français où j'avais tenté de faire un tableau synthétique il y a fort longtemps sans jamais vraiment finir). Ensuite, les lexèmes en français sont encore peu nombreux, donc on ne peux pas juste se baser sur l'existant pour valider la regex (il faudrait faire une liste indépendamment du contenu actuel des lexèmes et en se basant sur le TLFi lui-même). Enfin, comme le dit Envlh, le TLFi lui-même a des URLs étranges (plusieurs URLs menant à la même page – cf. ete/été dont je parlais dès le début –, ou presque – cf. comptage/compter – et je ne parle même pas d'URL complètement exotiques comme https://www.cnrtl.fr/definition/9club8 ?!?) et c'est à la fois douloureux mais aussi une chance pour nous de déterminer quelle URLs on valide ou non (typiquement le cas des capitales, on peut choisir de valider "brésilien" et "Brésilien" ou bien juste l'un des deux et pour le moment – sauf erreur – on n'a pas du tout décidé que "les valeurs doivent être mises en minuscules "). PS: il y a encore d'autres cas qui n'ont pas encore été évoqué, ce sont tout les signes de ponctuations (espace, tiret, apostrophe, etc.) qui eux parfois rendent l'URL sensible https://www.cnrtl.fr/definition/tri et https://www.cnrtl.fr/definition/tri- sont deux pages différentes. Bref, je manque de temps mais il y a encore pas mal de boulot pour comprendre quel regex est souhaitable et optimale. Cdlt, VIGNERON (talk) 18:36, 22 August 2022 (UTC)[reply]

@Eihel: comme indiqué par VIGNERON, le sujet n'est pas aussi trivial que vous le pensez. La discussion est ouverte depuis 2 ans et, ce soir, en une heure, vous bombardez la page de discussion de messages contradictoires (avec de nombreux edits inutiles dans l'historique, alors que vous avez déjà été bloqué pour cela ; prenez le temps de la réflexion et d'écrire vos réponses sur un brouillon avant de les diffuser !), et décidez sans aucun recul ce qui doit être mis en place pour cette propriété. Par exemple, si vous ouvrez le TLFi, vous verriez que « ångström » n'est absolument pas valable : le nom de l'entrée est « ANGSTRÖM, ANGSTROEM, subst. masc. », avec le a initial sans rond en chef, d'où cette URL : [1]. Pourriez-vous tenir compte du fait que tous les contributeurices ne peuvent pas vous répondre dans la minute (vous m'avez notifié 2 fois en 5 minutes dans cette discussion...) et attendre quelques jours qu'on ait le temps de vous répondre svp ? Cdlt, ― Envlh (talk) 20:54, 22 August 2022 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Bonsoir. J'ai scrappé l'ensemble des formes du TLFi (le code source est disponible). Voici les caractères utilisés dans ces formes : !'-.1238_abcdefghijklmnopqrstuvwxyzàâæçèéêëîïñôöùûüœ. J'ai quelques diacritiques seules qui semblent également apparaître (U+0300, U+0301, U+0302, U+0303, U+0308, de la table des caractères Unicode U0300). Cdlt, ― Envlh (talk) 17:09, 24 August 2022 (UTC)[reply]

Merci beaucoup @Envlh:. Est-ce qu'il serait possible d'avoir un ou deux exemples pour chacun de ces caractères (certains me surprennent un peu, le ! ou le . par exemple pour lesquels je ne vois pas d'exemples évidents, idem pour les diacritiques seules). En tout cas, sauf correction éventuelle à la marge, je propose de partir sur cette liste pour la regex (qui ne contient pas un grand nombre des caractères de la suite à-ÿ proposée par @Eihel:, ce qui évite ainsi de nombreux faux-positifs). Enfin, il reste la question des capitales sur laquelle je n'arrive pas à me faire une certitude (il y a des avantages et des inconvénients dans les deux cas...). Cdlt, VIGNERON (talk) 16:58, 25 August 2022 (UTC)[reply]

Je t'ai envoyé deux listes par mail (je n'ai pas réussi à les mettre sur un pad ou un pastebin, n'hésitez pas à me les demander si vous voulez que je vous les envoie) :

l'ensemble des formes du TLFi ;
les formes avec ces diacritiques seules (un peu moins de 200). En fait, ces diacritiques ne sont pas seules, mais elles sont encodées comme étant des caractères séparés des lettres sur lesquelles elles sont utilisées. En pratique, ça ne semble ajouter que deux lettres par rapport à la liste précédente : ã et u + ~.

Pour les capitales, peux-tu expliciter les « avantages et inconvénients » que tu évoques stp ? Cdlt, ― Envlh (talk) 07:10, 27 August 2022 (UTC)[reply]

@Envlh: bien reçu.

Du coup, je comprends mieux la présence de caractères qui me surprenait : le point d'exclamation est présent dans des interjections comme chut! et le point dans des abréviations comme h.l.m (dans les deux cas la typographies est étrange, on attendrait une espace avant un point d'exclamation et il manque le point final des abréviations). Le 1 est présent uniquement dans [2] et 2 dans [3] (deux URLs avec le même contenu, idem pour 3 dans j3 et 8 dans super-8 (une sous-entrée de [4] avec quasiment le même contenu mais avec une précision en première ligne). L'utilisation _ est plus étrange et est présent dans un petit nombre d'entrées comme à l' _ de instar à l' _ de et signale apparemment où le mot vedette s'insère dans une locution figée. Pour les autres caractères, je peux donner des exemples mais il n'y rien de particulier.

Pour l'encodage des accents, ce n'est pas inhabituelle, mais par contre c'est inhabituel de ne pas être cohérent au sein d'un même ensemble... Si il y a une logique, je ne la vois pas...

Pour les capitales, l'avantage de « tout en minuscule » est sa simplicité. L'avantage de mettre les capitales est d'être plus riche (typiquement le cas de "pH" où l'on ne peut pas deviner que la capitale n'est pas initiale, mais il y a le lexème pour cela ce n'est pas forcément à la valeur de l'identifiant de porter cette information), d'être plus unique (distinct pour les noms Brésilien - un ou deux lexèmes d'ailleurs ? si deux, pas tout à fait unique alors - et l'adjectif brésilien) et de correspondre plus souvent au lemme principal de nos lexèmes (ceci dit, je me rends compte qu'il y a bien plus de cas que je ne le pensais où ce lemme Wikidata ne correspond pas au lemme du TLFi donc peut-être pas si important). Enfin, dans ta liste (issue du moissonnage de https://www.cnrtl.fr/portailindex/LEXI/TLFI/A ?) tout est en minuscule et dans la vedette tout est est en capitale donc le placement des capitales peut-être un peu hasardeux ou en tout cas facile à oublier lors de l'ajout de l'identifiant... Au final, je serais plutôt pour « tout en minuscule » mais je reste ouvert sur la question.

Cdlt, VIGNERON (talk) 18:08, 27 August 2022 (UTC)[reply]

Merci pour cet avis détaillé.

Pour information, j'ai fait un premier import (qui ne concerne que les formes sur lesquelles il n'y avait pas de débat) dans le cadre de Wikidata:Requests for permissions/Bot/EnvlhBot 3.

J'en ai profité pour générer un rapport des identifiants pour lesquels le numéro de l'onglet est manquant (ces identifiants ont été ajoutés dans Wikidata avant mon import). Je prépare un second rapport pour les identifiants qui ne respectent pas l'orthographe de la vedette.

Pour la regex, on arriverait à quelque chose comme ceci : [ !'-.1238_abcdefghijklmnopqrstuvwxyzàâãæçèéêëîïñôöùûüũœ]+(\/[0-9]+)?

Cdlt, ― Envlh (talk) 08:39, 3 September 2022 (UTC)[reply]

J'approuve cette regex (et donc seulement en minuscules). Notification des personnes utilisant le plus la propriétés (hormis nous deux) : @Hsarrazin, C. Erwan, Eihel, Pamputt: des objections sur ce format ? Cdlt, VIGNERON (talk) 09:44, 4 September 2022 (UTC)[reply]

PS: la regex ne devrait-elle pas aussi accepter les chaînes vides ? (utilisés quelque fois pour dire que le mot est absent du dictionnaire, comme sur candide (L1760))

Ça me semble bon. Pamputt (talk) 10:21, 4 September 2022 (UTC)[reply]

En ce qui concerne les chaines vides, j'imagine qu'utiliser la propriété avec « aucune valeur » est préférable. Pamputt (talk) 10:23, 4 September 2022 (UTC)[reply]

@Pamputt: tout à fait, une chaîne vide est justement la façon de représenter « aucune valeur » dans une expression régulière

(et d'ailleurs, on ne peut pas avoir une chaîne vide en valeur). Cdlt, VIGNERON (talk) 19:08, 4 September 2022 (UTC)[reply]

Autres contraintes ?[edit]

La discussion ci-dessus me fait penser qu'il y a finalement peu de contraintes sur cette propriété. Avez-vous des idées ou suggestions de contraintes à ajouter ?

Je pense notamment à single-value constraint (Q19474404), actuellement il n'y a qu'une seule violation : accuser (L18012) (que l'on peut soit scinder, soit mettre en exception). Je ne vois pas de raison de ne pas l'ajouter.

Sinon, distinct-values constraint (Q21502410) n'est évidemment pas applicable ici, il n'est pas inhabituel qu'une entrées du TLFi concernent plusieurs catégories grammaticales et donc mécaniquement, plusieurs lexèmes.

D'autres idées à explorer ?

Cdlt, VIGNERON (talk) 09:58, 4 September 2022 (UTC)[reply]

@Envlh, Hsarrazin, Metamorforme42: je vous relance sur les contraintes.

Et j'en ajoute une, je viens d'utiliser le TLFi en source sur un lexème en latin : vulpecula (L287904) ce qui cause une violation de contrainte. La contrainte "langue requise par le lexème = français" est bonne mais elle devrait s'appliquer uniquement aux valeurs principales, pas aux références ; une idée de solution ? (il me semble avoir vu ça résolu sur une autre propriété mais évidemment je ne me souviens plus laquelle)

Cdlt, VIGNERON (talk) 08:42, 19 September 2023 (UTC)[reply]

Property talk:P7722

Contents

Documentation

Et maintenant ?[edit]

Valeurs autorisées[edit]

Autres contraintes ?[edit]

Navigation menu

Property talk:P7722

Documentation

Et maintenant ?[edit]

Valeurs autorisées[edit]

Autres contraintes ?[edit]

Navigation menu

Search