Utilisateur:Hexasoft/Monolithique
Donc, quelques notes / exemples de ce qu'imposerait de créer un modèle « monolithique » pour les taxobox.
Existant modifier
Les taxobox sont « modulaires », à savoir qu'une taxobox est une suite de modèles simples (des briques de base) qui construisent ensemble le résultat :
{{Taxobox début | animal | Taxobox classique | Vipere gabon 28.JPG | ''Bitis gabonica'' | classification=reptileDB }}
{{Taxobox | embranchement | Chordata }}
{{Taxobox | classe | Reptilia }}
{{Taxobox | sous-classe | Lepidosauria }}
{{Taxobox | ordre | Squamata }}
{{Taxobox | sous-ordre | Serpentes }}
{{Taxobox | infra-ordre | Alethinophidia }}
{{Taxobox | famille | Viperidae }}
{{Taxobox | sous-famille | Viperinae }}
{{Taxobox | genre | Bitis }}
{{Taxobox taxon | animal | espèce | Bitis gabonica | ([[André Marie Constant Duméril|Duméril]], [[Gabriel Bibron|Bibron]] & [[Auguste Duméril|Duméril]], [[1854]]) }}
{{Taxobox synonymes | animal |
* ''Echidna gabonica''<br><small>Duméril, Bibron & Duméril, 1854</small>
* ''Vipera rhinoceros'' <small>Schlegel, 1855</small> }}
{{Taxobox fin}}
Les codes monolithiques utilisent en gros la même méthode, mais fournissent « au dessus » un modèle qui s'occupe de créer les appels aux différents sous-modèles (les briques de base). C'est le cas des infobox :
{{Infobox Musique (artiste)
|charte = vocal
|nom naissance = Matthieu Chedid
|nom alias = -M-
|image = [[Image:Matthieu Chedid Cannes 2010 (19).jpg|280px]]
|légende = Matthieu Chedid au [[Festival de Cannes 2010|Festival de Cannes]] en {{Date||mai|2010|en musique}}.
|naissance = {{Date de naissance|21|12|1971|âge=oui}}, [[Boulogne-Billancourt]], [[France]]
|décès =
|pays origine = France
|profession = [[Auteur-compositeur-interprète]]
|années actives = depuis [[1978]]
|genre = [[Chanson française]], [[rock]], [[funk]]
|instrument = [[Guitare]], [[guitare électrique]], [[Batterie (musique)|batterie]], [[Synthétiseur|claviers]], programmation, [[kazoo]], [[Bruitage]]
|label = Barclay
|entourage = [[Bumcello]], [[Vanessa Paradis]], [[Brigitte Fontaine]], [[Arthur H]], [[Sean Lennon]], [[Guillaume Canet]], [[Johnny Hallyday]], [[Yodelice]]
|site officiel = [http://www.mistermystere.com/ www.mistermystere.com]
}}
Avantages / inconvénients modifier
L'approche modulaire a des avantages :
- chaque brique est en général simple à comprendre
- ajouter des fonctionnalités consiste à créer une nouvelle brique, sans toucher à l'existant
- il est facile de chercher où est utilisé telle ou telle brique (pages liées du modèle)
- ça laisse au rédacteur une grande liberté de construction
- corolaire : ceux qui gèrent (qui codent) ces modèles n'ont pas besoin de connaître et de prévoir tous les cas possibles
Elle a aussi des inconvénients :
- le rédacteur doit connaître l'utilisation de plusieurs modèles, au lieu d'un seul (et connaître les modèles existants)
- liberté = possibilité de casser des choses : certaines configurations sont invalides, sans contrôle « au dessus »
- pas de possibilité de réutiliser certaines informations (modèles différents), typiquement le « règne » utilisé à plusieurs endroits (pour le choix de la couleur et de la convention d'affichage dans les taxobox)
L'approche monolithique a des avantages :
- modèle unique, documentation unique, on « masque » les multiples briques au rédacteur. Ceci simplifie aussi - la plupart du temps - les changements dans le code
- mutualisation des informations (typiquement le « règne », utilisé dans plusieurs briques)
- approche plus répandue, donc moins surprenante pour les rédacteurs non habitués aux taxobox
Elle a aussi des inconvénients :
- modèle lourd, devant prendre en compte l'ensemble des possibilités (du point de vue de ceux qui codent les modèles)
- gain en lisibilité discutable : modèles contre paramètres nommés
- éclatement d'éléments liés. Par exemple dans les taxobox si le rang Famille s'appelle Toto et l'article est homonyme, on a {{Taxobox | famille | Toto | Toto (homonymie)}}. Dans un modèle monolithique il faut créer deux (ou trois) paramètres : | rang_famille = Toto (homonymie) [retour à la ligne] | rang_famille_affiche = Toto
Note : pour détailler le "gain de lisibilité discutable" un exemple en ligne :
{{Taxobox début | animal | ''Uroplatus'' | UroplatusSikoraeSameiti.png | ''[[Uroplatus sameiti]]'' | classification=reptileDB }}
{{Taxobox | embranchement | Chordata }}
{{Taxobox | classe | Reptilia }}
{{Taxobox | sous-classe | Lepidosauria }}
{{Taxobox | ordre | Squamata }}
{{Taxobox | sous-ordre | Sauria }}
{{Taxobox | infra-ordre | Gekkota }}
{{Taxobox | famille | Gekkonidae }}
{{Taxobox taxon | animal | genre | Uroplatus | [[André Marie Constant Duméril|Duméril]], [[1806]] }}
{{Taxobox fin}}
deviendrait :
{{Taxobox
|regne=animal
|taxon=Uroplatus
|rang=genre
|image=UroplatusSikoraeSameiti.png
|classification=ReptileDB
|legende=''[[Uroplatus sameti]]''
|embranchement=Chordata
|classe=Reptilia
|sous-classe=Lepidosauria
|ordre=Squamata
|sous-ordre=Sauria
|infra-ordre=Gekkota
|famille=Gekkonidae
|auteur=[[André Marie Constant Duméril|Duméril]], [[1806]]
}}
Il s'agit ici d'un exemple simple (donc sans cas pénibles qui nécessiteraient des paramètres additionnels pour les cas spécifiques comme les homonymies, les niveaux non classés, anciens, obsolètes, ...). Il n'y a pas non plus de deuxième classification (phylo par ex.).
Pour la partie variable il s'agit donc principalement de remplacer :
{{Taxobox | classe | Reptilia }}
par
|classe=Reptilia
Problèmes difficiles à résoudre dans l'approche monolithique modifier
Sur un article « standard » le nombre de cas est déjà assez grand. Les paramètres indispensables sont :
- taxon (le nom du taxon décrit)
- rang (le rang du taxon décrit)
- auteur + date (le décriveur du taxon et la date de description)
- image (éventuelle)
- légende (de l'image, éventuelle)
- règne (première ligne de classification + choix du thème (couleur / icône / convention typographique))
- classification utilisée
Ajoutons quelques entrées diverses : synonymes, statut CITES, statut IUCN, carte de répartition + associés, …
À cela il faut ajouter un paramètre pour chaque rang de la classification (partie décrivant la classification au dessus du taxon considéré). Il y a de 30 à 50 rangs référencés. Sachant qu'il peut y avoir des rangs dont le nom pointe sur une homonymie (ou sur un nom en français), il faut deux paramètres pour chaque rang (le nom de l'article et le nom affiché). Donc de 60 à 100 paramètres pour la partie classification classique.
À cela il faut ajouter la classification phylogénétique. Ceci reprend le même principe même si en général il y a là moins de niveau (en pratique, car théoriquement il n'y a pas de raison). Donc encore au minimum une 50aine de paramètres.
On approche alors les 200 paramètres.
Ceci fait donc un code de modèle plutôt monstrueux et une documentation de même acabit.
Voici un exemple sur un cas simple :
{{Infobox taxobox
| nom scientifique=Bitis gabonica
| image=Vipere gabon 28.JPG
| légende=Test sur du V2
| règne=animal
| auteur=([[André Marie Constant Duméril|Duméril]], [[Gabriel Bibron|Bibron]] & [[Auguste Duméril|Duméril]], [[1854]])
| synonyme=* ''Echidna gabonica''<br><small>Duméril, Bibron & Duméril, 1854</small>
* ''Vipera rhinoceros'' <small>Schlegel, 1855</small>
| rang = espèce
| embranchement = Chordata
| classe = Reptilia
| sous-classe = Lepidosauria
| ordre = Squamata
| sous-ordre = Serpentes
| infra-ordre = Alethinophidia
| famille = Viperidae
| sous-famille = Viperinae
| genre = Bitis
}}
À ce cas très simple il faudrait ajouter des lignes du style :
| genre = Bitis (homonymie) | genre_affiche = Bitis
pour les taxons dont l'article est un homonyme ou un autre nom (autre nom = taxon dont l'article est titré avec un nom en français alors que la classification des taxobox est - par définition - basée sur les noms scientifiques).
Il faudrait également ajouter la classification phylogénétique (ici un exemple assez simple venant d'une plante) :
| phylo_ordre = Malpighiales | phylo_famille = Salicaceae
Mais le vrai problème est plus profond : certaines classifications sont non déterministes en ce sens qu'on ne peut prévoir la liste des rangs de manière énumérative.
Quelques exemples :
Dipsacales : ici la classification phylogénétique fait référence à 4 clades successifs (Angiospermes, Dicotylédones vraies, Astéridées, Campanulidées) avant l'ordre.
Comment prévoir à l'avance la possibilité d'inclure plusieurs rangs "phylo_clade" ? Il faudrait des paramètres additionnels :
| phylo_clade_sup3 = Angiospermes | phylo_clade_sup2 = Dicotylédones vraies | phylo_clade_sup1 = Astéridées | phylo_clade = Campanulidées
et bien sûr prévoir aussi les phylo_clade_sup3_affiche correspondants au cas où (cas = article homonyme ou titré en français).
Pseudoxenodontidae ou Verasper variegatus : ici la classification classique (ou une classification alternative) contient des rangs possédant un nom mais pour lesquels le rang n'a pas été positionné dans l'arborescence « classique » des taxons.
Il faudrait donc de la même manière que pour les clades multiples ci-dessus créer des rangs non classés. Mais il faudrait en prévoir assez (dans l'un des exemples il y en a 13 de suite) et surtout prévoir de pouvoir en insérer potentiellement entre n'importe quel rang « classique ». Ça donnerait :
| nc_sup_super-famille5 = Macrostomata | nc_sup_super-famille4 = Caenophidia | nc_sup_super-famille3 = Colubroides | nc_sup_super-famille2 = Colubriformes | nc_sup_super-famille1 = Endoglyptodonta | super-famille = Colubroidea
en prévoyant comme d'habitude les nc_sup_super-famille3_affiche pour chaque… Et en prévoyant assez de sup pour placer avant (ou après) chaque rang référencé.
Là on atteint je pense les 400 ou 500 paramètres, sans parler de la perte à peu près certaine de lisibilité.
Cela pose aussi un problème d'édition : dans l'exemple ci-dessus si je veux insérer un non classé entre les Colubriformes et les Colubroides, je dois au préalable renommer les paramètres pour « faire de la place » (5 → 6, 4 → 5, 3 → 4, et là je peux insérer à cette position).
Alternative :
Une alternative serait de ne pas nommer les rangs (au niveau des paramètres), pour éviter les contraintes de position et de nom. La classification serait alors une suite positionnelle de rang+nom (le 1er, le 2ème, le 3ème…). Mais il faudrait alors ajouter un troisième paramètre pour chaque niveau, à savoir le rang en question :
| rang1 = embranchement | rang1_nom = Chordata | rang2 = classe | rang2_nom = Reptilia | rang3 = sous-classe | rang3_nom = Lepidosauria | rang4 = ordre | rang4_nom = Squamata | rang5 = sous-ordre | rang5_nom = Serpentes | rang6 = infra-ordre | rang6_nom = Alethinophidia | rang7 = famille | rang7_nom = Viperidae | rang8 = sous-famille | rang8_nom = Viperinae | rang9 = genre | rang9_nom = Bitis (homonymie) | rang9_affiche = Bitis
et idem pour la classification phylogénétique ( | phylo_rang1…) ou les classification alternatives.
Là on aurait liberté à moduler les rangs comme on veut. Les inconvénients :
- perte de lisibilité des paramètres (décrire un rang occupe 2 ou 3 lignes consécutives) ; perte de lisibilité d'édition (le modèle "infobox taxobox" occupe beaucoup de place à l'écran) ; perte de simplicité de rédaction (« rang9 = genre + rang9_nom = Bitis (homonymie) + rang9_affiche = Bitis » nettement moins simple que {{Taxobox | genre | Bitis (homonymis) | Bitis}}).
- si on veut insérer un rang intermédiaire oublié, il faut renuméroter les paramètres pour « faire de la place » à la nouvelle entrée
- sans doute moins de paramètres au total que dans les cas précédents, mais tout de même un certain nombre (des classifications peuvent approcher les 30 niveaux, à multiplier par 3 (par niveau) = pas loin de 100 paramètres pour une classification.
Les autres wikipédia modifier
en.wikipédia a choisi deux approches :
- en:template:Taxobox un modèle monolithique ayant 240 paramètres différents ! Il faut remarquer les étranges paramètres unranked_divisio, unranked_classis, unranked_ordo utilisés par exemple dans en:Rose
- en:template:Automatic taxobox un modèle monolithique imbriqué nécessitant un modèle par taxon + un site web base de données externe pour les sous-taxons
Note : pour cette dernière approche se pose la question de la charge sur les serveurs (nombre de modèles). En effet il faut prévoir un modèle par taxon. La zoologie dépasse largement les 60000 taxons, soit donc autant de modèles à créer (et ceci sans compter la botanique !).
Ma conclusion modifier
Un modèle monolithique serait adapté et utilisable dans le cas de taxobox très simples : une seule classification (en botanique nous en fournissons 2), « courte », sans classification alternative ou phylogénétique ni aléa de classification ("non classé", "taxon obsolète", "taxobox conflit", "hybride", "taxobox synomymes", non abordé ici). Là on aurait une transcription assez simple du modèle modulaire au modèle monolithique.
Il serait par contre lourd, voire impossible à utiliser (et à créer en premier lieu) dans le cas de classifications multiples ou complexes.
Et l'idée d'avoir plusieurs types de taxobox selon les articles me fait frémir 
.
Autre approche modifier
Liné1 m'a indiqué un autre type d'approche partiellement utilisé sur en: : la classification ne fait plus partie de la taxobox, elle est « externalisée ». Sans entrer dans les détails, ils utilisent des modèles pour décrire les différents niveaux de classification. Exemple :
- modèle Bitis, indiquant les taxons inférieurs et indiquant le taxon parent (Viperinae)
- modèle Viperinae, indiquant les taxons inférieurs et le taxon parent (Viperidae)
- …
Il y a des subtilités, du style doit-on afficher ce taxon par défaut ou pas (niveaux intermédiaires « masqués »). La création de la classification revient alors à indiquer le parent du taxon concerné, et les modèles sont ensuite inclus à la chaîne pour construire l'arborescence.
L'intérêt est de séparer la classification, et surtout de la factoriser (en gros si on met à jour la classification elle se met à jour partout).
Par contre ça implique de :
- créer des milliers de modèles (un par taxon)
- transposer la classification hors de l'espace encyclopédique, et donc de rendre la gestion de la classification inaccessible au commun des éditeurs (réservé aux habitués des modèles, et aux admins ces modèles étant a priori destinés à être protégés en écriture)
- rendre délicat la gestion de classifications alternatives (sauf à prévoir dans chaque modèle un paramètre additionnel permettant de choisir la classification, avec des "taxons parent" qui vont dépendre de ce paramètre, ou alors de prévoir plusieurs séries de modèles de classification)
- rendre quasi-impossible les cas particuliers
Bref, ça ne me semble pas être la panacée.
Autre approche (bis) modifier
Il semble que le langage de programmation Lua arrivera début 2013 sur les wikipédias. Ce langage - sous le nom de Scribunto en tant que module mediawiki - a pour but de remplacer/compléter les modèles en permettant l'utilisation d'un vrai langage de programmation, et donc de prendre correctement en compte des situations complexes qui se présentent dans le cas des taxobox (heu, Lua n'a pas été porté sur WP pour gérer les taxobox hein, mais ce sera(it) pratique ).
Voir à ce propos : Utilisateur:Hexasoft/Lua - une tentative d'explication et de description des modules en Lua
Voir aussi mes tests d'utilisation de Lua et des modules pour faire un modèle monolithique de taxobox qui soit en mesure de traiter la variété des cas rencontrés (sur test2.wikipedia.org) : Module:Taxobox-fr (le module principal) ; Module:Taxoboxoutils (le module d'outils) ; Uroplatus guentheri (un exemple animal) ; Rosa canina (plante) (un exemple de plante) ; Rosier des chiens (le même avec titre vernaculaire).
Note : le module n'est pas complet, et génère encore du code de débug, ne s'attacher qu'aux fonctionnalités et pas au rendu exact.