Discussion module:Essai

Pour Discussion module:Essai :
n'a pas d'entrée WD
fin test pour Discussion module:Essai.

Pour Bob Dylan :
possède une entrée WD
c'est un être humain
métier(s) (P106) trouvés : artiste (Q483501)
fin test pour Bob Dylan.

Pour Charles de Gaulle :
possède une entrée WD
c'est un être humain
métier(s) (P106) trouvés : homme politique (Q82955) militaire (Q47064)
fin test pour Charles de Gaulle.

Donc

Alors si Q5 est (supposé être) toujours présent pour P31 lorsque c'est un humain ne vaut-il pas mieux pour le premier point privilégier ça (code plus simple) et retourner true/false selon que l'entité correspondante possède ou pas cette propriété ?

Comme je disais sinon pour les sous-classes et autres c'est aussi possible. Mais effectivement ça oblige à "charger" des entités autres que celle de l'article en cours, ce qui est classé dans "opération couteuse" dans wikimedia et donc à éviter si ce n'est pas nécessaire. Si Q5 doit être présent il vaut mieux détecter son absence/présence et corriger les erreurs dans WD, non ?

Sinon pour la profession c'est quoi le but ? Par exemple P106 (occupation) pour avoir la liste des métiers ?
Je présume que l'idée c'est d'avoir une table d'association "métier (sur WD)" / "type de catégorie (et/ou d'infobox)", c'est ça ? Et la gestion des sous-classes serait pour "remonter" jusqu'à un type connu ? Par exemple si quelqu'un est "professeur (Q121594)" trouver que c'est une sous-classe de "enseignant (Q37226)" ? (exemple réel mais peut-être pas pertinent, hein) Hexasoft (discuter) 12 janvier 2016 à 16:48 (CET)

Comme Q5 est censé être toujours défini, effectivement la première fonction peut simplement retourner true ou false.

Pour les professions l'idée est de pouvoir classer en fonction de grandes familles de métier. Donc pour le coup il faudrait pouvoir remonter à une classe mère. je t'ai mis un exemple pratique ci-dessous.

-- Hercule (discuter) 12 janvier 2016 à 16:52 (CET)

Par ailleurs il faudrait identifier également les articles sans Wikidata du tout (qui constituent une bonne par de catégorie « Wikipédia:Article non biographique appelant le modèle Suivi des biographies ». -- Hercule (discuter) 12 janvier 2016 à 16:54 (CET)

Hans von Aachen

Je pense que l'article Bob Dylan (d · h · j · ↵) (Q392) est un bon exemple pour tester les fonctions qu'il me faudrait (pour la profession).

Une requête sur pour P106=Q1028181 doit retourner Q1028181 (il est défini comme peintre)

Une requête pour P106=Q483501 ne doit rien retourner, mais la deuxième fonction doit retourner Q483501 (il est défini notamment comme peintre, qui est une sous-classe de plasticien, qui est une sous-classe d'artiste.

-- Hercule (discuter) 12 janvier 2016 à 16:49 (CET)

 Hercule : ok donc j'avais bien compris la chose.

Pour le premier point pas de problème. Encore que pour le moment je n'arrive pas à demander une propriété (Q5 par ex.) mais il est trivial de parcourir la liste des propriétés pour trouver celle cherchée.

Pour le second point c'est assez simple aussi, même s'il faudra quoi qu'il en soit ajouter une limite de "remontée" afin d'éviter d'éventuels problèmes.

Pas de problème non plus pour détecter l'absence d'élément WD (en fait je ne le teste pas actuellement, mon code plante sans doute dans ce cas).

Je vais faire quelques fonctions "propres" pour ça, utilisable en Lua (pas faites pour être appelées depuis un modèle, je veux dire, mais directement par un module) dans un premier temps.

De même pour pouvoir tester sans bidouiller de vrais articles ces fonctions prennent actuellement une entité, au lieu par défaut de travailler sur l'entité de l'article en cours. À modifier ultérieurement bien sûr.

Cordialement, Hexasoft (discuter) 12 janvier 2016 à 21:00 (CET)

 Hercule :

Note : tu peux voir un affichage de la fonction de test sur deux pages : la page courante (cette page de discussion, juste pour tester la détection WD que n'a bien sûr pas cette page) ; un sur Bob Dylan, où la détection "être humain" fonctionne (ainsi que la présence d'un élément WD).

Je travaille sur la partie sous-classes (sur le cas "métier"). Ceci dit sur ce dernier point je me rends compte qu'il faudrait des précisions sur l'utilisation et les résultats attendus.

Faut-il lister toutes les « occupation » et pour chaque indiquer le "parent" le plus haut ? Faut-il tester uniquement une occupation précise (et chercher dans les occupations listées si l'une d'entre-elles est sous-classe de celle cherchée) ? Faut-il créer une liste des "parents intéressant" (ceux gérés par ex. par les infobox / catégories / modèles / autres) ?

S'il faut une liste comment gérer les cas qui se recoupent (par ex. Bob Dylan est "auteur-compositeur-interpète" et "compositeur" sur WD, comment on gère ?) ?

Disons que l'approche en terme de programmation est similaire mais « l'enrobage » n'est pas le même. Et si le but est de tout parcourir il est dommage d'appeler N fois la même fonction sur plein de valeurs alors qu'on reçoit directement la liste de toutes les valeurs. Cordialement, Hexasoft (discuter) 12 janvier 2016 à 22:20 (CET)

Mon objectif premier est la classification des ébauches. Mais cette fonction sera également utile pour l'utilisation d'infobox dynamiques (actuellement l'{{infobox Biographie2}} change d'affichage en fonction du métier de la personne, mais je ne crois pas que ce soit fait de manière fine).

Mon cas pratique, tel que je l'envisage est : je passe en paramètre un champ (P106 par exemple) et une valeur (Q483501 par exemple). Si au moins une des valeur de P106 est égal à Q483501, ou si l'une d'elle est une sous-classe de Q483501 (disons sur 3 niveaux pour commencer) alors la fonction de retourne la valeur (ici Q483501). Comme ça je peux ensuite passer par des fonctions parser que je maîtrise plus que le Lua pour la classification (si c'est facile de modifier le Lua existant je peux m'y mettre).

Cette fonctionnalité pourrait être améliorée en définissant une liste de valeurs intéressantes ("artiste", "militaire", "sportif", "homme politique" pour commencer par exemple). Il faut alors retourner la première valeur trouvée (dans l'ordre de définition Wikidata) de cette liste.

• Bob Dylan (d · h · j · ↵) sera "artiste" du fait de "auteur-compositeur-interprète" (son P106 : Auteur-compositeur ou autrice-compositrice, acteur ou actrice de cinéma (en), poète ou poétesse, guitariste, autobiographe (en), artiste peintre, producteur de disques, réalisateur ou réalisatrice, parolier ou parolière, compositeur ou compositrice, scénariste, disc jockey, acteur ou actrice, chanteur ou chanteuse, animateur ou animatrice de radio, designer, écrivain ou écrivaine et musicien ou musicienne)
• Charles de Gaulle (d · h · j · ↵ · AdQ · Ls) sera "militaire" du fait de "officier" définit en premier dans ses occupations (son P106 : Homme d'État, mémorialiste (d), théoricien ou théoricienne militaire (d), officier et personnalité politique). Mais si on augmente le rang de "homme d'État" alors il deviendra "homme politique".

-- Hercule (discuter) 13 janvier 2016 à 11:04 (CET)

Ok, ça me semble clair. Et oui je pense que gérer cette liste en interne Lua est faisable est assez simple à éditer. Je vais partir là-dessus (sur quelques éléments) et on pourra voir ensemble si ça te semble assez compréhensible ou pas (d'ailleurs un peu comme les modèles on fait en général dans ce cas un module en sous-page dédié uniquement aux données pour alléger, simplifier et éviter de faire peur Hexasoft (discuter) 13 janvier 2016 à 12:05 (CET)

Ok

 Hercule : Donc voici quelques résultats. Sur Charles de Gaulle →

Pour Charles de Gaulle :
possède une entrée WD
c'est un être humain
métier(s) (P106) trouvés : militaire (Q47064) homme politique (Q82955) auteur (Q482980)
fin test pour Charles de Gaulle.

J'ai une fonction à qui on passe une entité (ou nil pour l'article en cours) et qui teste dans l'ordre : 1. qu'il y a une entrée wikidata (ne sert à rien quand on passe une entité bien sûr…) 2. que c'est un être humain 3. qui récupère la liste des métiers dont un parent est dans une liste fournie dans le code.

Chacune de ces actions correspond à une fonction (dans toutes ces fonctions le paramètre 'entity' devrait disparaitre puisqu'inutile depuis un article) :

• p.a_wikidata(entity) : retourne true/false selon si la page courante a une entrée WD
• p.presence_propriete(prop, value, entity) : retourne true/false selon si la propriété 'prop' contient la valeur 'value'
• p.propriete_parente(prop, entity) : retourne une liste (dé-doublonnée) des propriétés listées dans la "liste des propriétés qu'on veut récupérer" (dans notre cas des métiers). Chaque élément dans cette liste est soit directement présent dans la "liste", soit "équivalent à" l'un de ces éléments, soit a un parent (sous-classe de) qui est dans cette "liste". La limite de profondeur est actuellement de 4 (donc il s'arrête lorsqu'il a testé une sur-classe de sur-classe de sur-classe de sur-classe des éléments.

Sur l'exemple ci-dessus tu peux voir que j'ai ajouté "auteur" comme élément désiré, pour tester plus largement.

La fameuse liste est simple : des séries de ["Qxxx"] = { ["catégorie"] = "xxx", ["infobox"] = "Infobox yyy", ["texte"] = "[[zzz]]" },.
Seul le premier élément est important, le reste je l'ai mis pour l'exemple (et j'utilise "texte" pour l'affichage).
La fonction traite dans l'ordre des déclarations WD pour la propriété (P106 ici), donc les résultats sont normalement dans le même ordre. Par contre ma fonction arrête au premier élément trouvé pour une propriété donnée. Donc par exemple (fictif) si de Gaulle était un "dirigeant militaire" sous-classe à la fois de "militaire" et de "homme politique" ça ne retournerait que le premier trouvé (idem, dans l'ordre des déclarations).

Qu'en pense-tu ? Cordialement, Hexasoft (discuter) 13 janvier 2016 à 15:31 (CET)

Ça me paraît pas mal du tout. Maintenant il faut voir comment s'en servir en pratique :p

-- Hercule (discuter) 13 janvier 2016 à 15:35 (CET)

Sur les points que tu abordes :

• classification des articles qui ne sont pas des "personnes" → si test P5 pas ok retourner la catégorie-qui-va-bien, sinon retourner rien
• classification des ébauches : il te faut définir une liste de "types" d'ébauches que tu vas gérer et le (ou les) métiers à mettre en face. Après tu peux utiliser la liste des métiers retournés pour multi-catégoriser automatiquement (au lieu d'afficher comme je l'ai fait).
• sélection de type d'infobox : même principe mais il te faudra définir une forme de "priorité" (critères ?) lorsqu'un sujet a plusieurs cordes à son arc et que chaque sujet peut avoir un "thème" à lui. Attention toutefois, ceci me semble potentiellement plus "dangereux" que les 2 autres, avec des risques de changement d'infobox "à la volée" en fonction de ce qui est fait sur WD ! Le contexte actuel n'est à mon avis pas idéal pour prendre ce genre de risque Hexasoft (discuter) 13 janvier 2016 à 16:02 (CET)

Mise en œuvre

je ne vois toujours pas comment m'en servir en pratique. Peux-tu faire un modèle {{Suivi des biographies 2}} qui fasse les traitement suivants pour l'article dans lequel il est inclus :

• Si l'article n'a pas de Wikidata le catégoriser dans catégorie « Wikipédia:Article sans Wikidata appelant le modèle Suivi des biographies »
• Si l'article a un Wikidata et ne traite pas d'un être humain le classer dans catégorie « Wikipédia:Article non biographique appelant le modèle Suivi des biographies »
• Si l'article est une biographie, le classer dans catégorie « Wikipédia:Article biographique » et faire également la classification :
  • selon le premier métier remonté (il vaut mieux utiliser l'identifiant que le nom) :
    • si "artiste" catégoriser dans catégorie « Portail:Biographie/Articles liés/Culture et arts »
    • si "militaire" catégoriser dans catégorie « Portail:Biographie/Articles liés/Militaire »
    • si "personnalité politique" catégoriser dans catégorie « Portail:Biographie/Articles liés/Politique »
    • sinon catégoriser dans catégorie « Portail:Biographie/Articles liés/Général »

Je m'occuperai des autres classifications par métier, je pense que j'arriverai à modifier ça en conséquence.

Pour les infobox je pense également qu'il faut attendre avant de se lancer sur leur sélection automatique.

Si j'arrive à bien comprendre j'ai pas mal d'autres catégorisations en tête :

• date de naissance
• date de décès
• lieu de naissance
• lieu de décès
• âge au décès

Mais ce sera dans un autre temps .

--Hercule (discuter) 13 janvier 2016 à 16:37 (CET)

Ok, j'ai donc créé la fonction "categorise" qui fait ce que tu as demandé (la dernière, tout en bas).

Pour l'utiliser il suffit directement depuis un article ou depuis un modèle appelé depuis un article de mettre : {{#invoke:Essai|categorise}}.

Cette fonction ne gère aucun paramètre actuellement. Son comportement :

• si l'article appelant n'est pas dans l'espace encyclopédique elle ne fait rien
• si l'article n'a pas d'entrée WD elle catégorise comme demandé
• si l'entité (d'après WD) ne porte pas sur un humain elle catégorise comme demandé
• si l'entité (d'après WD) n'a aucun "métiers" (en tout cas aucun de la liste actuellement présente dans le code du module) elle catégorise en "Général"
• ensuite selon le 1er métier retourné dans la liste elle catégorise comme demandé ou dans "Général" si aucun des cas n'est trouvé.

Quelques remarques :

• je n'ai testé que "article qui ne porte pas sur un humain" (facile, je l'ai posé sur un article de reptile) et ça fonctionne. Mais je ne sais pas comment tester le reste "en vrai" puisque les articles que j'ai vu sont déjà catégorisés, et on ne sait pas d'où vient une catégorie puisqu'en mettre plusieurs identiques ne change rien
• d'après ce que je vois les articles sont multi-catégorisés (par ex. Charles de Gaulle est dans Portail:Biographie/Articles liés/Politique et dans Portail:Biographie/Articles liés/Militaire (au moins)). Ne faudrait-il pas plutôt parcourir tous les métiers "référencés" (dans le module, la fameuse liste des Qxxx à chercher) et retourner l'ensemble des catégories qui correspondent ?
• il faudrait mettre la cible des catégories dans la table, et utiliser le contenu, plutôt que d'avoir le contenu en dur dans le code : ça permet de modifier les cibles plus simplement en regroupant le tout au même endroit
• on peut très bien faire des tests plus complexes pour les actions : si tel métier et pas tel autre alors ceci sinon …
• tout ceci est encore du test. Si tu veux dépasser le stade du test il conviendra de créer un "vrai" module (pas qui s'appelle "Essai"), de lui faire une documentation et de nettoyer les parties de code qui ne servent pas.

Pour tes autres catégorisations le principe sera similaire à ce qui existe, et même plus simple. Chercher l'info WD, l'analyser, et si tout va bien ajouter la catégorie à partir de ça.

À noter toutefois qu'il faut bien réfléchir aux interactions avec d'autres modèles / modules. Par exemple si sur WP on a une naissance en 1900 (via l'infobox) et sur WD en 1901, et que le modèle catégorise déjà, tu peux te retrouver avec deux catégories de naissance en XXXX.

Par ailleurs il conviendra aussi de bien comprendre les cas de figure possibles sur WD. Si par exemple quelques entités ont plusieurs dates de naissance sur WD il faut le savoir afin de 1. ne pas planter comme un porc sur un cas non prévu 2. pouvoir prendre un décision "éclairée" en cas d'infos divergentes.

Cordialement, Hexasoft (discuter) 13 janvier 2016 à 18:28 (CET)

J'ai créé {{#invoke:Essai|categorise2}}. Même fonctionnement mais 1. toutes les informations sont dans la liste ou dans des variables dédiées (cat par défaut, cat d'erreur…). De plus cette version cumule toutes les catégories de métiers et ne sélectionne pas uniquement la première. Hexasoft (discuter) 13 janvier 2016 à 19:25 (CET)

Je viens de tester en utilisant la prévisualisation dans certains articles.

Le fait de catégoriser dans autant de sous-catégories qu'il y en a de possible me semble pas mal du tout comme idée. La catégorie unique est de toute façon catégorie « Wikipédia:Article biographique » (que n'ajoute pas la fonction 'categorise', les autres sont pour les projets voulant faire du suivi.

Je vais m'occuper de la migration vers un module dédié et voir où mettre l'appel initial (peut-être directement dans l'appel aux portails, pour traiter tous les articles).

'categorise2' ne catégorise pas dans Catégorie:Portail:Biographie/Articles liés/Général si aucune autre catégorie n'a été trouvée.

Merci beaucoup pour ton aide.

-- Hercule (discuter) 14 janvier 2016 à 10:13 (CET)

De rien.

Je viens de créer Module:Essai/données regroupant toutes les données en question. J'ai aussi modifié Module:Essai pour prendre en compte ce changement (il convient de valider que ça marche toujours comme avant).

Comme ça tu peux voir comment on peut séparer code et données, ce qui je pense est plus "propre" et aussi plus simple en terme de gestion : on peut protéger le module principal mais laisser modifiable le module de données, et ce dernier est plus simple à comprendre pour un rédacteur de passage.

Après comme je disais on peut faire évoluer le code de 'categorise2' pour modifier le comportement, ajouter des tests complexes (faire telle chose si telle autre sauf si encore autre chose…), gérer d'autres éléments WD, agir différemment selon le namespace… Hexasoft (discuter) 14 janvier 2016 à 11:21 (CET)

Je vais procéder sous peu à l'export, mais il reste un problème.

La catégorisation dans catégorie « Portail:Biographie/Articles liés/Général » ne se fait que quand il n'y a pas de valeur définie pour P106 (par exemple pour A-ca-oo-mah-ca-ye (d · h · j · ↵)). Il faudrait également que cela soit fait si aucune occupation existante ne permet de classe (par exemple Henri Aubin (d · h · j · ↵)).

Pour l'élargissement des traitements il va falloir que je commence par lancer des discussions.

-- Hercule (discuter) 14 janvier 2016 à 14:29 (CET)

Effectivement ! J'avais supposé que la fonction retournait nil ou alors quelque chose, mais elle peut aussi retourner une table vide. J'ai ajouté ce cas de figure auquel cas il insert la cat par défaut. Hexasoft (discuter) 14 janvier 2016 à 14:38 (CET)

J'ai créé Module:Suivi des biographies et fait un appel dans {{Suivi des biographies}}.

Merci encore pour ton aide.

--Hercule (discuter) 15 janvier 2016 à 11:10 (CET)