Retour : SynthesesDiscussions
- Wikipédia est une encyclopédie généraliste qui utilise le logiciel Mediawiki ; elle se décline en de nombreuses versions linguistiques autonomes.
- Mediawiki est un logiciel de type wiki qui a été développé pour les besoins de Wikipédia et Wikimédia, mais est disponible gratuitement pour quiconque.
- Wikimedia est l'organisation qui gère l'ensemble des activités autour de Wikipédia.
- Wikimedia-Commons est le serveur de medias (images, vidéos, pdf...) commun à tous les projets (dont les Wikipedias).
- Wikispecies est un site dédié à la taxonomie des espèces vivantes (en anglais), avec une format assez rigide (qui le rend peu utilisé).
- Wikisource est un site spécialisé dans la reproduction en mode texte formaté de livres numérisés.
- Wikidata est une initiative récente visant à adosser à Wikipedia une base de données structurées, en s'aidant de tout ce qui est déjà dans les box (taxobox par exemple).
http://www.tela-botanica.org/page:eflore_bdtfx?referentiel=bdtfx&niveau=2&module=fiche&action=fiche&num_nom=77191&type_nom=nom_scientifique&nom=rubus
Pour info, dans Flora gallica qui va paraître, j'ai rédigé une clé succinte des Rubus qui renvoi vers cette fiche pour aller plus loin, où se trouve le tableau téléchargeable, tableau qui compare les espèces pour lesquelles il y a de l'information dans les monographies modernes et qui permet d'identifier ces espèces. C'est l'un des seuls endroits (sinon le seul) où Tela Botanica et e-flore seront mentionnés dans cette flore qui est vouée à devenir un standard pour les botanistes francophones européens.
A mon avis, la dynamique de remplissage d'e-Flore se fera comme sur wikipédia, par plusieurs dynamiques mêlées :
- des compilateurs/traducteurs qui feront l'apport principal de données sourcées
- des normateurs qui s'occuperont de la relecture de ces données et leur agencement, de l'adéquation du vocabulaire
- des relecteurs qui trouveront les petites fautes de frappe ou les tournures de phrases les plus agréables pour peaufiner le tout
Je crois que pour mettre en route cette dynamique, il faudrait un indicateur qui permette de savoir quelles fiches ont été modifiées chaque jour (sorte de flux rss ?). Et que ce flux soit visible depuis la page d'accueil d'eFlore par exemple.
Question : y-a-t-il comme sur wikipédia un historique de l'écriture d'une page, avec un versionnage ? C'est quand même une sécurité si quelqu'un vient effacer une fiche ou y écrire n'importe quoi.
Une remarque sur la différence entre "la dynamique de remplissage d'e-Flore" et wikipedia : sur wikipedia, les informations sont "sourcées", c'est à dire qu'on les a déjà vues ailleurs, qu'elles ont fait l'objet de publications dans des endroits qui ont pignon sur rue, qu'elles sont acceptées par "le plus grand nombre". C'est une bonne façon de faire une encyclopédie de notre époque, consensuelle, ça élimine les rigolos qui disent n'importe quoi, évidement ça limite les apports de données très anciennes introuvables sur internet, mais ce n'est pas dramatique, ça peut se résoudre.
Mais par contre ça n'est pas une démarche scientifique dans le sens où la science doit être un lieu de recherche et d’innovation, de questionnements et de remises en question, d’hypothèses qu'on vérifie.
Pour eflore, si Tela se veut non seulement une grande compilation de vieilles données mais aussi un lieu de création de connaissance, un endroit pour les génies fous, il faudra trouver notre propre façon de valider les données qui rempliront e flore, et pas seulement la caution du passé, ni du plus grand nombre.
Une plante qui n'est pas à sa place sera t elle éliminée des cartes car non conforme ? ou bien reconnue comme la première indication d'un mouvement, d'un changement inévitable du monde végétal ?
Question : comment indiquer la provenance des données ?
Je propose : un chapitre "Discussion", où il y a la provenance indiquée et un avis critique sur les données.
Voici deux exemples :
- Torilis japonica : http://www.tela-botanica.org/bdtfx:nn:68580
- Bolboschoenus glaucus : http://www.tela-botanica.org/bdtfx:nn:101814
Problème technique : il semble que ce n'est pas possible de créer un permalien avec une écriture partiellement italique, tel que Torilis japonica subsp. japonica. Voir la fiche : http://www.tela-botanica.org/bdtfx:nn:120780
Voici un exemple de page Wiki eFlore remplie :
Rubus : http://www.tela-botanica.org/bdtfx:nn:77191
Il s'agit en faite d'une ardoise sur laquelle n'importe qui peut Ă©crire, effacer, modifier la page.
Il n'y a aucun historique associé à cette page.
Il n'y a pas non plus, de page de discussion associée.
Le système Wikipédia est bien plus sécurisé :
Rubus : https://fr.wikipedia.org/wiki/Rubus
En onglet en haut, vous avez la page "Discussion", où se trouve des discussion sur la rédaction de la fiche
En haut à droit, se trouve "Afficher l'historique", où il est possible de visualiser l'apport de chaque contributeur, et à quelle date. Pour l'article Rubus de Wikipédia, il y a eu une centaine de contributions depuis la première création de la page en 2004.
Cet historique permet de garder en mémoire toutes les versions, et de revenir à une version antérieure à tout moment.
On peut également, en tant que contributeur à un article, être tenu informé de toute modification sur cet article.
Bref, le système Wikipédia est largement meilleur.
Il me semble bien que depuis le temps que ça a été introduit il y a eu remarquablement peu de contributions. Je vais souvent sur eflore, et je ne me souviens pas avoir vu plus d'une ou deux contributions et beaucoup, beaucoup d'espace vide, très décourageants et qui me font partir aussitot sur wikipedia ou autres sites.
Personnellement je n'ai jamais contribué car les wiki sont particulièrement rebutants à utiliser.
Et puis, dans le cas d'un contribution qui demande du travail personnel, des connaissances, du temps, comme celle sur les rubus , il est normal que l'auteur qui a fait ça bénévolement soit cité et que tout un chacun ne puisse pas venir modifier et dégrader sa contribution, il me semble que c'est la moindre des choses, la seule reconnaissance qu'il aura.
Introduire des relecteurs ? des validateurs ? difficile à mettre en place, et puis non, je ne crois pas que c'est nécessaire (en dehors d'une modération minimum pour supprimer les pignoufs :)) . L'auteur est clairement indiqué, les textes ne sont pas anonymes et chacun reste responsable de ce qu'il dit, les commentaires sont les bienvenus et tout le monde doit pouvoir participer facilement, mais pas modifier ce qu'un autre a dit. Je suis sure qu'il serait rapidement évident qui est sérieux et compétent ou pas sans donner de badges, sur les forums comme celui de détermination, les participants savent très bien qui est qui, et quelles personnes sont crédibles.
En fait , pour avoir une certaine qualité, un système inspiré des "forum" (contributions personnelles, non anonymes, non modifiables par un tiers, présence d'un modérateur et possibilité de critique et commentaire par tous) qui est déjà éprouvé depuis longtemps, me parait plus efficace et accessible à tous que toute tentative d'automatisation de la régulation, ou tout contrôle d'une autorité supérieure.
un encadré, "Projet Internet lié : Tela Botanica" et si on clique on accède au site de TB. Au regard de leurs propres
objectifs quelle est la nature des liens unissant les deux entités ?
Un site que j'apprécie beaucoup et dans lequel, même si le portugais est pour moi une langue que je ne parle pas, j'aime
aller faire un tour pour vérifier une espèce est http://www.spbotanica.pt/
Outre sa présentation qui ressemble à un eFlore (en plus simple) on y trouve "Plantas em volta" qui ouvre la
collaboration aux amateurs pour évoquer une espèce, bien mieux qu'on peut le faire sur le wiki.
Dans le nouvel eFlore, il faudra réfléchir à la façon d’organiser cette connaissance apportée par les contributeurs : une seule page Wiki par taxon ou différents espaces (comme maintenant dans eFlore), quel outil utiliser, suivi des modifications avec historique, signature, espace discussion, etc.
Les wikis diffèrent en fonctionnalités. Mediawiki (celui de Pl@ntUse et de Wikipédia) offre les avantages suivants :
- page de discussion liée à chaque page ; j'utilise cette page en particulier pour informer sur l'état d'avancement du travail dans la page, pour dire si la page a été validée ou non... On peut parfaitement utiliser cette page de discussion pour préciser si elle a été relue par des personnes ayant le statut de relecteur, de validateur, etc.
- possibilité de visonner l'historique de la page, et de revenir sur une version antérieure.
- possibilité de marquer chaque page sur sa "liste de suivi", qui permet d'être informé chaque fois que cette page a été modifiée ;
- possibilité de réserver l'écriture sur une page à des personnes ayant le statut d'administrateur. Il doit même y avoir possibilité de différencier plusieurs statuts, par exemple "utilisateur confirmé" et "administrateur", mais je n'ai pas cherché jusqu'à présent.
- tout le monde n'a pas besoin d'être expert dans l'usage des balises et autres codes. On peut parfaitement mettre du texte brut, ou avec seulement les gras et italiques, et demander de l'aide pour un formatage plus poussé.
- chaque utilisateur dispose d'un page personnelle où il peut se présenter, où on peut discuter avec lui et où il peut mettre et commenter ses meilleures images dans des "galeries".
Par ailleurs, Wikipédia a fait ses choix propres, mais on peut en faire d'autres, par exemple, avoir des pages signées. C'est ce que je fais sur Pl@ntUse (mais j'avoue que n'ai pas à gérer une multiplicité de contributeurs...).
En ce qui concerne les images, je pense effectivement qu'il faudrait trouver le moyen d'en éliminer, en commençant par les mauvaises photos techniquement parlant. Avec Mediawiki, on a en fait un système à deux étages : le premier (Wikimedia Commons) sert simplement à stocker les images et à les classer dans des catégories pour permettre leur repérage. Le second consiste à choisir les meilleures images pour les mettre dans les pages de texte (Wikipédia en l'occurence). Là aussi, on a le choix : Wikipédia préfère mettre peu d'images pour simplement illustrer l'encyclopédie, alors que sur Pl@ntUse, je préfère en mettre davantage pour illustrer les différents stades de vie d'un taxon ou sa variabiité. On n'est pas limité, mais on peut choisir.
Comme cela, aucune image correcte n'est éliminée, mais seule les meilleures apparaissent dans l'encyclopédie, à la discrétion non pas du photographe mais du rédacteur de la page. Chacun y trouve son compte.
Rapports avec Wikipédia
Quoi qu'on en pense, Wikipédia est bien plus visible que Tela Botanica. Personnellement, j'écris très peu dans Wikipédia, parce que je me concentre sur Pl@ntUse et que je n'ai pas envie de perdre du temps à négocier avec plein de gens sur le contenu. Mais je suis de plus en plus présent dans les discussions de Wikipédia (les "bistrots"). J'essaie de positionner Pl@ntUse comme un site de référence que Wikipédia peut ensuite utiliser. Car Wikipédia a fait le choix de ne pas mettre de données originales, mais uniquement des synthèses qui s'appuient sur des données originales extérieures. Et en fait, les wikipédiens sont demandeurs de sources extérieures sérieuses. Tela Botanica pourrait assez facilement le devenir. On aurait ainsi une complémentarité entre les deux.
Conclusion
Je suis devenu un fervent adepte des wikis, et de Mediawiki en particulier. Si la solution d'un wiki est retenue par Tela Botanica, il faudra s'assurer que les fonctionnalités requises soient bien supportées. Les remarques des uns et des autres montrent que ce n'est pas le cas actuellement.
Le gros avantage de Mediawiki est que sa pérennité est assurée par la communauté Wikipédia. Par ailleurs, il est ordinairement installé sur de grosses machines une seule fois, et de nombreux wikis particuliers peuvent alors l'utiliser, dans ce qu'on appelle des "fermes de wikis". C'est le cas de Pl@ntUse, qui utilise le consortium Biowikifarm. C'est solution a un avantage énorme : je n'ai pas à m'occuper du tout de la maintenance du logiciel, et je peux donc travailler pratiquement sans informaticien ! Tela pourrait ainsi allouer ses (faibles) moyens à autre chose, comme écrire des modèles de formatage et valider des données...
Le reste est une affaire d'organisation, pas de moyens informatiques. On devrait bien trouver des botanistes pour cela, ou alors c'est à désespérer.
Son évolution au cours du temps a permis d’arriver à un dispositif très performant et très complet. Il n’y a pas photo par rapport à nos Wiki d’eFlore...
Dans nos rapport avec Wikipédia, si Tela pouvait être pris comme référence externe serait très bien. Il l’est de fait déjà un peu aujourd’hui, car pratiquement toutes les pages sur les plantes ont un lien vers Tela (mais pas toujours bien adapté)
Autre avantage d’être sur Wikimédia : pas de maintenance informatique, c’est un plus évident. Il y a suffisamment de choses à faire par ailleurs.
Mais la question centrale que je me pose, c’est comment adapter un site sous Wikimédia à notre structure de données.
Pas question de créer les pages à la main les unes après les autres. Il faut qu’elles soient créées automatiquement à partir des référentiels (BDNFF ou autre). Or ces référentiels évoluent au cours du temps : ajout / suppression de taxon, changements de noms, etc. comme faire suivre le Wiki ?
Le Wiki devrait-il remplacer totalement eFlore, ou bien ne serait-il que le volet d’Eflore dédié à l’écriture collaborative ?
Doit on faire une page par taxon (référentiel taxonomique à la Wikipédia) ou pas nom (référentiel nomenclatural, comme Genève) ?
Pas simple tout ça. Beaucoup de réflexion et d’avis à recueillir, notamment auprès des informaticiens de Tela et des responsables de Wikimédia.
A sujet des questions posées, c'est difficile de répondre, quand on ne connaît pas bien Wikimédia. Ce qui est mon cas.
Les référentiels évoluent, certes, mais de façon ponctuelle. Il n'y a donc pas de réel problème pour mettre les fiches à jour. Sur Mediawiki, il suffit de renommer la page, et cela crée automatiquement une redirection. Le système des redirections permet d'ailleurs d'inclure les synonymes usuels et les noms vernaculaires dans des pages de redirection. Les noms des pages de redirection sont alors bien accessibles dans l'onglet Recherche, et conduisent automatiquement aux bonnes pages. Quand on a affaire à un nom ambigu, on peut étoffer ces pages de redirection en donnant des infos qui permettent de sortir de l'ambiguité. Voir par exemple ma page Laurier <http://uses.plantnet-project.org/fr/Laurier> .
Les deux systèmes (e-flore et wiki) peuvent parfaitement cohabiter côte à côte ! On verra bien à l'usage lequel est le plus utilisé. E-flore restera de toute façon une base nomenclaturale indispensable, mais pour les spécialistes.
Quant à ta dernière question, Daniel, elle m'a fait sourire, car elle souligne le "vice congénital" de la BDNFF, qui est une base nomenclaturale par nature, mais avec une taxonomie implicite. Or ce n'est pas la nomenclature qui intéresse avant tout les gens, ce sont les plantes elles-mêmes !
L'avis des informaticiens est pertinent, mais n'est pas essentiel à mon avis. Il vaudrait mieux recueillir l'avis de personnes qui mettent déjà du contenu sur Internet. A commencer par les contributeurs de Wikipédia, mais aussi ceux de Plantalex <http://www.plantalex.com/index.asp> , Hortipedia <http://fr.hortipedia.com/wiki/Accueil> , Toild'épices <http://www.toildepices.com/> ...
A propos de Wikipédia, d'ailleurs, il est inutile de demander aux "responsables" de Wikimedia. Chaque "projet" (comme la botanique) est géré collectivement pas ses utilisateurs ! Il faut donc éventuellement discuter sur le bistro du projet Botanique <https://fr.wikipedia.org/wiki/Discussion_Projet:Botanique> . On y trouve déjà des télabotanistes, et il serait d'ailleurs dommage que d'autres y aillent, ne trouvant pas ce qu'ils souhaitent sur le site de Tela.
C'est d'ailleurs pour moi un des principaux risques pour Tela : que les internautes aillent voir ailleurs, parce que le site de Tela est trop complexe, donne trop de renseignements inutiles et n'est pas assez interactif et convivial.
Je signale aussi un problème gênant pour citer Tela : il faut aller chercher en bas des pages le lien permanent, et cela apparemment manuellement ! Pour mon robot, j'ai pu faire automatiser l'écriture de liens profonds quand ceux-ci se terminent par "genre+espèce". Ce n'est pas le cas de Tela, mais c'est le cas de Wikipédia, Pl@ntUse, Pl@ntUse, GRIN, PlantList et bien d'autres. Je ne sais pas si mes collègues pourront pointer sur Tela à partir de Pl@ntNet-Mobile à cause de ça ; de plus, le site de Tela se prête apparemment mal à une lecture sur smartphone...
Quant à Mediawiki, non seulement il ne me demande aucun soutien informatique, mais de plus, l'insertion de Pl@ntUse dans Biowikifarm est gratuite ! Ce qu'apprécie Biowikifarm, c'est qu'un informaticien contribue éventuellement à la gestion du logiciel (mais à Pl@ntUse, nous ne le faisons même pas).
Si c'est pour essayer de faire des synthèses bibliographiques meilleurs que Wikipédia, au point de vue de la pertinence des informations, c'est concurrentiel, car l'objectif d'excellence est aussi celui de Wikipédia.
Le niveau scientifique est bien là chez Wikipédia : https://fr.wikipedia.org/wiki/Discussion_Projet:Botanique
La spécificité de Tela Botanica se situe au niveau de la production de données de référence : BDTFX, eVeg, chorodep.
En ce qui concerne les pages d'Ă©criture de eFlore, je propose :
1) de les remplacer par les wikis développés par wikimédia, à historique et écriture non anonyme, et mise en page agréable,
2) de les destiner à des synthèses commentées, les commentaires étant une valeur ajoutée par rapport aux articles sur Wikipédia. Ces commentaires pourraient contiendraient en effet des données inédites, tel que "les flores indiquent que tel caractère discriminant fonctionne, mais ça ne fonctionne pas si bien que ça ; voir les mesures ci-dessous."
Voici un exemple de ce que cela donnerait :
http://fr.wikipedia.org/wiki/Rubus_lejeunei
J'ai écrit cette page il y a longtemps, et vous remarquerez le commentaire sous "Synonymes". Il s'agit d'un commentaire qui a été, peu après sa rédaction, retiré de l'article et déplacé dans la page "discussion" par un administrateur. J'avais alors argumenté qu'il s'agissait d'une information importante à faire figurer dans l'article lui-même, ce qui a pu se faire. Mais ce texte est effectivement en limite du champs d'action de Wikipédia, dont l'objectif n'est pas la production de données inédites, mais au contraire, la synthèse de données éditées ailleurs.
J'ai sous le coude la traduction en français de plusieurs dizaines de protologues de Rubus écrits en allemand. Je compte bien pouvoir mettre ces protologues dans eFlore quand ce sera possible. De même, j'ai fait des mesures sur des spécimens type, qui ont pour vocation à alimenter eFlore.
Dans ce contexte de production données inédites, eFlore (page d'écriture "Usage") deviendra par contre concurrentiel de Pl@ntUse. Une solution serait de faire un lien à Pl@ntUse sur eFlore, ou alors de l'afficher directement, ce qui me semble préférable. Ce serait une solution pour faire connaître et solliciter des participants à l'amélioration de Pl@ntUse !
Exemple :
http://fr.wikipedia.org/wiki/Asplenium_marinum
http://species.wikimedia.org/wiki/Asplenium_marinum
Il y a déjà concurrence entre les wikipedia de différentes langues…
En revanche jÂ’ai lÂ’impression que wikispecies nÂ’existe quÂ’en anglais ?
Simplement, pour stimuler les contributions (ce qui est le point essentiel), il vaut mieux autoriser l'écriture sans contrôle a priori. Ensuite, on peut très bien faire relire les pages par des "experts", voire les bloquer, auquel cas les contributions passent par les pages de discussions.
On peut aussi soumettre l'écriture à une procédure d'inscription (ce que je fais sur Pl@ntUse). On peut alors suivre les contributions de chacun, et si on constate que quelqu'un met vraiment n'importe quoi, on peut l'exclure !
Je crois que si l'on précise dans des pages d'aide ce qu'on attend comme contenu, et qu'on donne des instructions précises, il pourra y avoir des candidats. Enfin, espérons-le, car pour l'instant, ça ne marche pas vraiment pour Pl@ntUse.
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia
Voir en particulier au chapitre 3.4.
Wikispecies est un référentiel taxonomique et systématique des taxons du monde vivant. Cette référence sert de base aux données taxonomiques et systématiques de Wikipédia.
Pour créer un nouveau Wiki porté par Wikimédia, toute la démarche à suivre ici :
http://incubator.wikimedia.org/wiki/Incubator:Main_Page/fr
- des protologues (dans la langue originale et en traduction)
- des descriptions dans un format normalisé (au contraire de Wikipédia qui rédige des phrases)
- des clés de détermination et critères discriminants
- des précisions nomenclaturales et taxonomiques ; ce que tu as fait sur Wikipédia à propos de Rubus lejeunei me paraît effectivement excessif pour Wikipédia, mais intéressant pour Tela.
- etc.
Quant à l'interaction avec Pl@ntUse, tout est possible, puisque le site est en CC-BY-SA. On pourrait mettre des liens systématiques de Tela vers Pl@ntUse (je fais déjà l'inverse), ou bien copier l'info pertinente de Pl@ntUse dans les pages de Tela, ce qui suppose que les données soient formatées de la même façon...
Un élément à prendre en compte est que Tela ne couvre que la flore de France (+DOM et Afrique du Nord !), alors que Pl@ntUse ambitionne une couverture mondiale.
Effectivement, Wikispecies apparaît plus proche de l'approche de Tela Botanica. J'ai cru comprendre que ça évoluait très lentement. Il faudrait y regarder de plus près. Ils semblent avoir adopté un format assez rigide et limité, ce qui freine peut-être les contributions.
Une explication des objectifs et des méthodes de Wikispecies se trouve dans une page d'aide générale <https://species.wikimedia.org/wiki/Help:General_Wikispecies> et à la page Ce que Wikispecies n'est pas <https://species.wikimedia.org/wiki/Wikispecies:What_Wikispecies_is_not>.
je vous envoie le compte-rendu d'une réunion tela botanica-wikipedia qui
a eu lieu en ... 2004 :
http://fr.wikipedia.org/wiki/Projet:Botanique/Partenariat_avec_Tela-Botanica
Ceci dit, il est évident que wikini n'est pas très agréable à manipuler, mais bon ce n'est pas la première fois qu'on en parle, l'équipe technique a déjà eu l'occasion d'expliquer pourquoi wikini avait été choisi et pas un autre moteur de wiki, mais j'avoue ne pas avoir retenu l'explication donnée (pardon).
Ceci dit, et bien que l'exemple proposé par Jean-Claude me semble tout à fait intéressant, je trouve que l'utilisation d'un wiki à l'avantage d'être immédiatement accessible, alors que les pages non éditables de "plantas em volta" n'encourage pas la participation papillon.
Si on veut des monographies, alors c'est sûr qu'on peut abandonner le wiki, mais ce n'est pas la peine de chercher à se tourner vers un forum type phpbb ni non plus vers les possibilités offertes par les stackexchanges que j'ai déjà évoqué ici en vain.
Si on veut des monographies, il faut recruter des monographes, c'est tout, il n'y a rien d'autre Ă faire. Mais je ne crois pas que ce soit l'objectif de Tela qui est plutĂ´t de chercher Ă encourager le travail collaboratif. Ou alors on ouvre un projet "monographie des taxons de la BDNFF" et on peut toujours prier pour que les fiches eFlore se remplisse...
Si on veut des descriptions collaboratives, avant même de chercher à avoir des participants compétents et de qualité il faudrait déjà avoir des participants. De ce point de vue là je suis d'accord pour dire que wikini est trop repoussoir, mais je continu de préférer un système participatif ouvert à un système de monographie figées.
Pour ce qui est de la traçabilité, un wiki n'empêche pas de signer une participation, mais il est certain que l'édition à volonté met la permanence des signatures et des contenus à la merci de qui que ce soit. Je n'ai pas la même appréciation de Wikipédia que Philippe de ce point de vue là .
Personnellement je commence à être un peu usé des réflexions récurrentes sur la nécessaire qualification des participants. Soit le CA de Tela valide cette nécessité et on demande à l'équipe technique d'introduire un système de hiérarchie entre les utilisateurs avec une reconnaissance des compétences et un accès différencié à l'édition / validation des données sur le site. Soit le CA ne valide pas cette nécessité et il faut qu'on arrive à passer outre cette interrogation et qu'on réfléchisse uniquement dans un fonctionnement ouvert à  tous.
Je me permet de rappeler encore une fois que le système de stackexchange permet la réalisation communautaire de cette hiérarchisation, mais je ne reviendrais pas plus là dessus étant donné que j'ai déjà suffisamment argumenté.
Dans Wikipédia, il y a apparemment plusieurs cas. Les images semblent être systématiquement vérifiées au début, et si rien ne s'y oppose, le contributeur change de statut au bout d'une certain nombre de contributions.
Pour les textes, quand quelqu'un remarque une contribution qui pose problème, il peut regarder les autres contributions de leur auteur et soit ouvrir une discussion, soit faire des remarques à l'auteur. Si ces remarques sont acceptées, tout rentre dans le rang. Si l'auteur continue à faire n'importe quoi, il finit par être viré.
Tout cela repose sur le fait qu'on peut disposer de la liste des contributions d'un auteur donné.
http://www.tela-botanica.org/projets/8/telechargement/18694
Il ne s'agit peut être pas de la même problématique qu’actuellement mais ça concerne le sujet "wikipedia et tela"
Dans notre discussion récente, il s’agit de savoir s’il était envisageable et intéressant de créer un espace Wikimédia dédié à Tela pour y mettre des données eFlore.
Cet espace pouvant alors servir de référence pour Wikipédia. L’inverse du cas précédent ou c’est Wikipédia qui servait à alimenter eFlore.
Voici deux liens utiles :
- page de Wikipédia ; https://fr.wikipedia.org/wiki/Wikidata
- page d'accueil du site Wikidata. https://www.wikidata.org/wiki/Wikidata:Main_Page
Une autre voie à explorer serait d’évaluer la faisabilité d’utiliser Mediawiki pour l’intégralité d’eFlore. J’ai parcouru tous les onglets d’eFlore pour un taxon et j’ai essayé de les placer dans un Mediawiki imaginaire. Dommage qu’on ne puisse pas faire de maquette, mais on peut assez facilement l’imaginer à partir d’une page d’un taxon en prenant la mise en page dans Wikipédia (test avec Prunus serotina et les informations d’Eflore)
http://www.tela-botanica.org/bdtfx-nn-53647
http://fr.wikipedia.org/wiki/Prunus_serotina
En tĂŞte de page :
Prunus serotina Ehrh. ROSACEAE
Cerisier d'automne (nom français recommandé)
Synonymie (complète)
Noms vernaculaires (issus de la base Tela (Jeff) et regroupés par langue)
fra Cerisier d'automne, Cerisier noir, Cerisier tardif
ndl Amerikaanse Vogelkers
deu Amerikanische Spätkirsche, Herbst-Kirsche, Spätblühende Traubenkirsche, Späte Traubenkirsche
eng Black Cherry, Rum Cherry, Whisky Cherry
spa CapulĂn, Cerezo del ron, Cerezo negro
ita Ciliego nero, Ciliego tardivo, Prugno della Virginia , Pruno autumnale
Description collaborative (classique type Wikipédia)
Le cerisier tardif est un arbre à feuillage caduc pouvant atteindre une hauteur de 20 m en Europe et jusque 35 m aux États-Unis[réf. souhaitée]. Son écorce est gris foncé et se fissure avec l'âge 1 .
Les feuilles sont de forme elliptique à lancéolée (12cm de long pour 5cm de large). Elles sont coriaces et munies d'une fine dentelure dirigée vers l’avant. Leur face supérieure est de couleur vert foncé luisante et est lisse, tandis que leur face inférieure est plus claire et est pubescente le long de la nervure principale.
En automne, elles deviennent jaunes avant de tomber2.
Le fruit est une sphère de couleur rouge foncé à noir et large de 8-10 mm. Il est comestible.
Bibliographie (dans la biblio de Tela)
- GUINIER Ernest - Le Cerisier de Virginie (Prunus virginiana L., Cerasus virginiana DC) et le Cerisier tardif (Prunus serotina Ehrh., Cerasus serotina DC.). - 1902, p. 21- 23 - Départ./Région : , Bulletin de la Société Botanique de France, 2, Tome 49 - Fascicule 1
- JAVELLE Aurélie - Plantes envahissantes et perception sociologique, le cas du cerisier tardif à Compiègne - 2005.06, p. 31- 35 - Départ./Région : Oise, La Garance voyageuse, 1, N°70
- O. CHABRERIE, H. HOEBLICH, G. DECOCQ - Déterminisme et conséquences écologiques de la dynamique invasive du Cerisier tardif (Prunus serotina Ehrh.) sur les communautés végétales de la forêt de Compiègne - 2007, p. 383- 394 - Départ./Région : , Acta Botanica Gallica, 1, Tome 154 - Fascicule 3
- Tournay F. - Le cerisier capulin - 2008, p. 38- 40 - Départ./Région : , Hommes et Plantes, 1, N°66
Liens vers les autres sites
IPNI, Jstore, Grin, INPN, etc.
Ainsi, sur une page on peut tout voir. La page est un peu longue, mais ce nÂ’est pas plus difficile de scroller que de jouer avec des onglets.
Il pourrait y avoir une page par nom (fabriquée par un robot à partir de la base de données nomenclaturale). Si le nom est retenu, la page est complète. Si le nom est un synonyme, on ne donne que les donnes liées au nom avec liens vers le protologue, les scans de type, la biblio... et le nom retenu.
Par contre il faut voir comment cela peut-être réalisé sur le plan informatique, notamment si les Webservices développés dans eFlore pour les affichages sont réutilisables.
Il faudrait pouvoir faire une maquette. Michel tu sais faire ?
L'intérêt serait de voir si le résultat plaît aux lecteurs. On verra ensuite
Il suffirait alors de proposer des formulaires de participations pour recueillir les informations que les utilisateurs souhaiteraient compléter, par exemple : au lieu d'avoir un seul champs texte dans lequel sont mélangées les informations concernant la description, les critères d'identifications, les espèces proches avec lesquelles des confusions sont possibles, les usages, la bibliographie, des noms régionaux,
Ne serait-il pas plus intéressant d'avoir pour chaque fiche eFlore une page "affichage" dans laquelle personne ne pourrait rien modifier. Et une page "participation" qui contiendrait en fait un formulaire avec tout plein de champs permettant de recueillir précisément l'info complémentaire que chacun peut vouloir apporter ponctuellement. Il suffirait alors de valider le formulaire via un bouton "envoyer" puis de mettre en place un outils de vérification comme IdentiPlante qui listerait les propositions d'ajouts / modifications / suppressions afin que les utilisateurs du réseau puissent valider ou invalider.
Les infos nouvellement envoyées seraient alors récupérées dans la base de données FloraData, taguées avec un tag de type "info utilisateur non vérifiée", affichées directement dans la fiche eFlore, affichées également dans un outils de vérifications des infos transmises sur le modèle d' IdentiPlante, validées ou invalidées par les utilisateurs, en fonction de ce vote les infos pourraient alors être retaguées "info utilisateur validée" ou "info utilisateur invalidée" auquel cas l'information pourrait être retirée de l'affichage dans la fiche eFlore.
Voici les avantages que je vois dans cette proposition :
- très peu de travail d'intégration d'outils nouveau pour l'équipe technique : il s'agit en effet uniquement d'utiliser de manière différente des outils que nous possédons déjà : les fiches eFlores sont générées automatiquement sur la base de FloraData et des référentiels taxonomiques, l'outil de validation par le réseau est déjà existant ( IdentiPlante), il suffirait de le modifier légèrement pour l'adapter aux informations transmises en terme d'affichage.
- mise en place pour chaque fiche eFlore, d'une page de saisie de données via des formulaires détaillées (aux aussi générés automatiquement en fonction des champs à remplir dans FloraData), c'est également quelque chose de déjà en place via la possibilité actuelle d'apporter des informations en double cliquant sur les zones d'édition directement sur eFlore. La seule différence résiderait dans la finesse de séparation des informations dans des champs différents (au lieu d'un champ unique actuellement)
- mise en place d'une interface de validation supplémentaire " ValidiFlore" ou "Valid-eFlore" (à lier à un projet ?) qui récupérerait les
informations envoyées par les formulaires désignés ci-avant et les soumettrait à validation par vote des membres du réseau exactement de la même manière que ce qu'on fait déjà sur identiPlante.
qu'en pensez-vous ?
Oui, c’est comme ça qu’eFlore fonctionne aujourd’hui !
Je ne comprends pas. CÂ’est exactement ce quÂ’il y a dans eFlore actuellement ! Sauf quÂ’il nÂ’y a pas de validation (presque personne nÂ’Ă©crit....)
Les infos nouvellement envoyées seraient alors récupérées dans la base de données FloraData, taguées avec un tag de type "info utilisateur non vérifiée", affichées directement dans la fiche eFlore, affichées également dans un outils de vérifications des infos transmises sur le modèle d' IdentiPlante, validées ou invalidées par les utilisateurs, en fonction de ce vote les infos pourraient alors être retaguées "info utilisateur validée" ou "info utilisateur invalidée" auquel cas l'information pourrait être retirée de l'affichage dans la fiche eFlore.
Le problème que l’on cherche à résoudre est double :
D’où l’idée d’utiliser Médiawiki pour faciliter la collaboration sur des pages plus agréables à consulter
1 - le découpage du champs de formulaire unique en un nombre de champs égal au nombre de types d'informations différents :
par exemple au lieu de regrouper dans un seul et même champs des informations la description, les critères de détermination, les nom vernaculaires locaux, les usages, la bibliographie etc. l'idée serait de proposer un champs unique pour chaque type d'information (donc un formulaire avec plein de champs).
de cette manière l'information est atomisée et on ressentirait moins un besoin de formatage du texte, cette tâche serait alors réalisée automatiquement par les serveurs de Tela qui intégreraient ces données "textes" dans notre base de donnée afin de les afficher dans les fiches eFlore comme s'il s'agissait de données issues de Coste ou de la baseflor par exemple.
Le besoin de formatage (d'avoir un joli texte) pour les utilisateurs serait alors bien moins important étant donné qu'ils ne rédigent plus dans une grande case (quand l'édition à lieu sur la fiche eFlore), voir dans une page de wiki. Je crois que ce sont ces environnements de saisie qui font ressentir le besoin du formatage.
Dans la forme, la participation se présenterait plus comme une réponse à un questionnaire en remplissant des cases bien précises et non comme une participation texte libre - qu'elle resterait bien évidement mais dont elle aurait moins l'apparence.
2 - En recueillant l'information de cette manière là et en demandant aux utilisateurs d'être connecté au moment de remplir le formulaire, on a la possibilité d'associer un nom d'auteur à une information. On gagne donc en traçabilité, et ce quel que soit l'importance / la taille / l'ampleur de l'apport : que la participation se résume à ajouter une source bibliographique ou bien qu'il s'agisse de faire une description détaillée d'un taxon, on pourra associer l'apport à un auteur défini.
3 - On instaure un système de vérification de l'information, toujours a posteriori, l'affichage resterait immédiat. L'information ne serait retirée que si les utilisateurs l'invalident par un vote. Si personne ne vote l'information pourrait resté affichée (comme c'est la règle actuellement), mais on pourrait avoir un tag dans FloraData "information utilisateur non validée" ce qui permettrait quand même de la distinguer, en interne, d'une info issue d'une base personnelle.
De plus,
comme chaque envoi de formulaire disposerait d'un identifiant unique, on ne risque pas de supprimer des données (donc pas de risque de suppression de la super description des Rubus)
Actuellement les participations sont rares, j'imagine donc que les corrections de données existantes sont encore plus rares.
Si toutefois pour un taxon donné, on devait recevoir plusieurs descriptions (c'est un exemple) alors on pourrait imaginer que la description postée en deuxième (ou 3e, ou 4e etc.) soit affichée dans l'interface de validation des données avec un rappel de la description déjà disponible. Les utilisateurs pourraient alors voter pour la meilleure des deux ou bien comme sur IdentiPlante, proposer une nouvelle version qui permettrait alors de reprendre les éléments pertinents des deux propositions afin d'avoir un texte remanié complet.
Comme on peut supposer que de tels cas seraient relativement rare, la gestion des cas problématiques pourrait rester du ressors d'une intervention humaine, de l'équipe technique et/ou du CST en fonction des cas de figure qui se présenteraient.
En résumé :
-> suppression des réticences d'utilisation dues à l'interface peu agréable car non WYSIWYG - en réalité suppression du sentiment de besoin de WYSIWYG,
-> uniformisation de l'affichage de l'information via un formatage par les serveurs et non par les participants,
-> résolution du problème de traçabilité de l'information,
-> mise en valeur des participations via une interface de validation,
-> amélioration de l'implication des membres via ce même interface,
-> possibilité de gestion au cas par cas, par le réseau ou par l'équipe technique ou CST des conflits particuliers qui peuvent apparaître (qui sont supposés rares),
-> pas de complexification disproportionnée des outils du réseau (l'ensemble des propositions est basée sur l'existant)
-> concrétisation technique supposée sans complication majeure pour l'équipe technique. Comme on se base sur l'existant, on n'introduit pas de nouvel technologie, ou de nouvelle composante informatique étrangère à l'équipe : il s'agirait plutôt de réutiliser l'existant de manière différente, complémentaire.
Les questions qui se posent pour moi sont plutĂ´t :
a) jusqu'où atomiser les champs de formulaire à remplir ? (par exemple suffit-il de distinguer "description" de "confusions" ou bien faut-il aussi atomiser encore plus avec "description:organe d'ancrage", "description:organe végétatif", "description:organe reproducteur" et "confusion_1", "confusion_2", "confusion_n", ...
b-1) une interface de validation des données des fiches eFlore sera-t-elle attractive pour les membres du réseau, se l'approprieront-ils comme ils le font actuellement avec IdentiPlante ?
b-2) est-ce qu'un nouveau projet serait nécessaire / souhaitable pour animer une telle interface de validation ?
b-3) quel nom retenir pour une telle interface ? "Valid-eFlore" ?
Concrètement, avec ce système, aura-t-on la souplesse des pages d'écriture Wikipédia, avec la possibilité de corriger une faute d'orthographe, un terme inadapté, compléter un détail d'une description (indiquer la largeur des pétales quand l'information de la longueur est déjà remplie), sourcer l'information ?
Wikipédia permet aussi de sourcer les informations, c'est-à -dire qu'il est possible d'indiquer de quel ouvrage provient telle information, avec un système de renvoi numéroté. Le renvoi pourrait aussi orienter sur un commentaire, par exemple, dans la description : pétales longs de 3-10 mm(exposant36). Exposant36 : Coste (Fl. Fr.) indique des pétales de 3,5 à 7 mm, Fournier indique 4 à 9 mm, Flora europaea indique 3 à 10 mm.
CÂ’est exactement ce quÂ’il y a aujourdÂ’hui dans eFlore et qui ne marche pas !
Voici les champs Wikini indépendants qui existent aujourd’hui dans eFlore : Description (Générale, Identification, confusions possibles, références), noms communs, usages, culture et art, compléments sur l’écologie, bibliographie, compléments sur le protection. Il y a de 1 à 3 champs par onglets que l’on peut remplir indépendamment. L’ensemble étant regroupé dans une page unique dont l’adresse est en bas de page, onglet synthèse. Ex : http://www.tela-botanica.org/eflore:wiki:BDTFXnt4846
Le wikini actuel garde en mémoire tout ce qui se passe sur la page (et donc dans chaque case d’eFlore) : http://www.tela-botanica.org/wikini/eFloreRedaction/wakka.php?wiki=TableauDeBordDeCeWiki
3 - On instaure un système de vérification de l'information, toujours a posteriori, l'affichage resterait immédiat. L'information ne serait retirée que si les utilisateurs l'invalident par un vote. Si personne ne vote l'information pourrait resté affichée (comme c'est la règle actuellement), mais on pourrait avoir un tag dans FloraData "information utilisateur non validée" ce qui permettrait quand même de la distinguer, en interne, d'une info issue d'une base personnelle.
Avant que l’on mette en place un système de vote ou de contrôle, il faudrait que ces Wiki soient utilisés. Et c’est là tout le problème. Les botanistes préfèrent écrire dans Wikipédia. Quelle en est la raison ????
Je ne sais pas trop comment l'expliciter d'avantage, mais essayons.
Quand on navigue dans eFlore, disons dans l'onglet description, on a trois grands titres oranges :
- description de Coste
- description Baseflor
- description collaborative
sous ce dernier titre on a un cadre gris cliquable qui permet l'édition directement dans la fiche eFlore de l'information concernant quatre domaines d'informations différents :
Participez à l’écriture collaborative de la description générale du taxon
Listez les caractères spécifiques permettant de déterminer ce taxon
Listez ici les taxons avec lesquels celui-ci risque dÂ’ĂŞtre confondu
Vous pouvez également mettre des liens vers des documents (déposez les ici)
On est donc en présence d'une seul formulaire : le cadre gris que l'on édite en bloc et que l'on valide en bloc avec le bouton "envoyer" situé directement sous lui.
Dans ce formulaire unique on a quatre partitions dont l'édition n'est pas indépendante : quand on édite la partie description générale on peut directement éditer "identification" juste en dessous et les modifications sont envoyées via le même bouton de confirmation : "envoyer".
Ce que je propose c'est d'atomiser ce formulaire unique pour le remplacer par plein de petits formulaires qui permettraient un remplissage très ciblé des informations. (voir pdf joint : Proposition d'une nouvelle interface de saisie eFlore.pdf)
Il s'agirait ensuite de modifier l'affichage pour s'orienter vers un affichage type description de Coste ou de Baseflor : avec des champs bien définis. L'idée est de brider la forme de rédaction des informations : en conservant un style télégraphique on peut enregistrer les informations communiquées par les membres du réseau dans une base de données (comme baseflor) qui serait vide au départ puis complétée au fur et à mesure des participations. L'affichage et la mise en page serait alors du ressort de décisions graphiques prises par l'équipe technique de Tela qui gère l'affichage du site et réalisée automatiquement par les serveurs, de la même manière que les infos de baseflor sont automatiquement affichées.
Concernant la question de David à propos de la flexibilité d'un tel système, c'est effectivement une des limites que j'y vois encore : corriger une virgule ou une faute d'orthographe ne semble pas très simple dans la configuration que je favoriserais, mais n'est pas impossible non plus. Je développe :
Pour l'instant la démarche de modification / correction que j'ai imaginée me semble un peu lourde étant donné qu'elle passerait par un outil Valid-eFlore : un champ non renseigné pourrait être complété et envoyé avec affichage direct dans la fiche eFlore, mais un champ déjà renseigné que l'on souhaiterait compléter ou corriger nécessiterait un passage en validation par Valid-eFlore avant l'affichage dans la fiche eFlore afin d'éviter que n'importe qui puisse "détruire" un bon travail préalablement existant en envoyant une "correction" vide ou remplie de bêtises. La lourdeur d'un tel processus est à relativiser avec le nombre restreint de participations que l'on observe actuellement dans les fiches eFlore et dont je doute qu'il augmente en flèche, quelle que soit l'évolution retenue pour eFlore.
Ceci-dit, on pourrait aussi laisser les propositions de compléments ou de correction s'afficher directement mais je ne vois pas ça comme étant très sécurisant pour les données, car ça risquerait de conduire à des gue-guerres comme sur wikipédia pour savoir comment exprimer telle ou telle information.
L'idée du Valid-eFlore permettrait également de favoriser la discussion sur le contenu via un système de commentaires comme actuellement en place sur IdentiPlante et qui fonctionne très bien.
Donc les principaux changements par rapport à la méthode actuelle seraient :
- atomisation des formulaires pour permettre une bonne individualisation des données
- enregistrement des données transmises dans une base de donnée (structurée un peu comme baseflor)
- affichage et formatage automatisé par les serveurs : suppression de la possibilité de mettre du gras, des titres, de l'italique : tout devra être prédéfini dans une charte graphique et appliquer automatiquement à chaque information transmise - d'où la nécessité d'atomiser les champs de transmission des données
- possibilité de traçage des informations puisque les utilisateurs compléteraient les formulaires en étant connecté au site de Tela : les participations seraient donc identifiées
- encouragement au débat, en d'autres termes : vérification des informations transmises par le réseau via un outil Valid-eFlore, ce qui manque actuellement (on a dit plus tôt dans nos discussions qu'il manque une page de discussion sur le mode de wikipédia).
Enfin concernant les remarques suivantes :
Le wikini actuel garde en mémoire tout ce qui se passe sur la page (et donc dans chaque case d’eFlore) : http://www.tela-botanica.org/wikini/eFloreRedaction/wakka.php?wiki=TableauDeBordDeCeWiki
tant mieux alors : ça fera ça de travail en moins pour les informaticiens de Tela. Il faudrait cependant réfléchir à un moyen de rendre cette mémoire des modifications plus facilement accessible. Par exemple, copier le lien vers le wikini qui se trouve en pied de page et le coller à côté des formulaires de saisies dans les fiches eFlores.
Avant que l’on mette en place un système de vote ou de contrôle, il faudrait que ces Wiki soient utilisés. Et c’est là tout le problème. Les botanistes préfèrent écrire dans Wikipédia. Quelle en est la raison ????
Nos wikinis sont déjà utilisés - très peu, certes - mais je ne vois pas l'intérêt de faire doublon avec Wikipédia en adoptant un système de fonctionnement et une interface identique à eux. Je ne comprends pas bien en quoi ça donnerait plus envie aux botanistes de rédiger sur eFlore : à mon avis, ils se diront plutôt "mais c'est ridicule, ce travail est déjà en place sur wikipédia et bien plus avancé". Je crois au contraire qu'une solution possible est d'encadrer et d'accompagner beaucoup plus la saisie des informations, on pourrait même aller plus loin dans la réflexion que je propose en remplaçant certains champs à renseigner par des listes d'éléments à choisir, mais je vais développer ça dans un second mail, sinon ça fera trop, j'ai déjà beaucoup écrit ici.
Bonne lecture et à tantôt pour vos réactions :-)
Wikimédia et eFlore
le 13 janvier, Michel Chauvet
Pour la clarté de nos discussions, il vaut mieux utiliser les bons mots :- Wikipédia est une encyclopédie généraliste qui utilise le logiciel Mediawiki ; elle se décline en de nombreuses versions linguistiques autonomes.
- Mediawiki est un logiciel de type wiki qui a été développé pour les besoins de Wikipédia et Wikimédia, mais est disponible gratuitement pour quiconque.
- Wikimedia est l'organisation qui gère l'ensemble des activités autour de Wikipédia.
- Wikimedia-Commons est le serveur de medias (images, vidéos, pdf...) commun à tous les projets (dont les Wikipedias).
- Wikispecies est un site dédié à la taxonomie des espèces vivantes (en anglais), avec une format assez rigide (qui le rend peu utilisé).
- Wikisource est un site spécialisé dans la reproduction en mode texte formaté de livres numérisés.
- Wikidata est une initiative récente visant à adosser à Wikipedia une base de données structurées, en s'aidant de tout ce qui est déjà dans les box (taxobox par exemple).
Le 6 novembre 2013 22:51, David Mercier <davidpmercier@yahoo.fr> a Ă©crit :
j'ai rédigé la fiche e-Flore description de "Rubus L.".http://www.tela-botanica.org/page:eflore_bdtfx?referentiel=bdtfx&niveau=2&module=fiche&action=fiche&num_nom=77191&type_nom=nom_scientifique&nom=rubus
Pour info, dans Flora gallica qui va paraître, j'ai rédigé une clé succinte des Rubus qui renvoi vers cette fiche pour aller plus loin, où se trouve le tableau téléchargeable, tableau qui compare les espèces pour lesquelles il y a de l'information dans les monographies modernes et qui permet d'identifier ces espèces. C'est l'un des seuls endroits (sinon le seul) où Tela Botanica et e-flore seront mentionnés dans cette flore qui est vouée à devenir un standard pour les botanistes francophones européens.
A mon avis, la dynamique de remplissage d'e-Flore se fera comme sur wikipédia, par plusieurs dynamiques mêlées :
- des compilateurs/traducteurs qui feront l'apport principal de données sourcées
- des normateurs qui s'occuperont de la relecture de ces données et leur agencement, de l'adéquation du vocabulaire
- des relecteurs qui trouveront les petites fautes de frappe ou les tournures de phrases les plus agréables pour peaufiner le tout
Je crois que pour mettre en route cette dynamique, il faudrait un indicateur qui permette de savoir quelles fiches ont été modifiées chaque jour (sorte de flux rss ?). Et que ce flux soit visible depuis la page d'accueil d'eFlore par exemple.
Question : y-a-t-il comme sur wikipédia un historique de l'écriture d'une page, avec un versionnage ? C'est quand même une sécurité si quelqu'un vient effacer une fiche ou y écrire n'importe quoi.
Le 7 novembre 2013, Michèle Van Panhuys
un très beau travail, David !Une remarque sur la différence entre "la dynamique de remplissage d'e-Flore" et wikipedia : sur wikipedia, les informations sont "sourcées", c'est à dire qu'on les a déjà vues ailleurs, qu'elles ont fait l'objet de publications dans des endroits qui ont pignon sur rue, qu'elles sont acceptées par "le plus grand nombre". C'est une bonne façon de faire une encyclopédie de notre époque, consensuelle, ça élimine les rigolos qui disent n'importe quoi, évidement ça limite les apports de données très anciennes introuvables sur internet, mais ce n'est pas dramatique, ça peut se résoudre.
Mais par contre ça n'est pas une démarche scientifique dans le sens où la science doit être un lieu de recherche et d’innovation, de questionnements et de remises en question, d’hypothèses qu'on vérifie.
Pour eflore, si Tela se veut non seulement une grande compilation de vieilles données mais aussi un lieu de création de connaissance, un endroit pour les génies fous, il faudra trouver notre propre façon de valider les données qui rempliront e flore, et pas seulement la caution du passé, ni du plus grand nombre.
Une plante qui n'est pas à sa place sera t elle éliminée des cartes car non conforme ? ou bien reconnue comme la première indication d'un mouvement, d'un changement inévitable du monde végétal ?
Le 7 novembre 2013, David Mercier
Note : par données sourcées, j'entends surtout par là qu'il s'agit d'indiquer d'où viennent les données. Elles peuvent venir d'observations inédites, et tant mieux ! Et c'est justement ce qui distingue eFlore de Wikipédia (où les données inédites sont proscrites). Mais si on accumule de l'information sur les taxons sans les sourcer, on perd de l'information et du sérieux scientifique. C'est très important aussi quand on s'aperçoit qu'une description d'une flore correspond en réalité à un autre taxon : si les données sont sourcées, on peut les éliminer de la fiche après coup pour rétablir la véracité de la description. Il y a aussi des flores plus fiables que d'autres, et lorsqu'une information paraît douteuse, on peut voir d'où elle vient.Question : comment indiquer la provenance des données ?
Je propose : un chapitre "Discussion", où il y a la provenance indiquée et un avis critique sur les données.
Voici deux exemples :
- Torilis japonica : http://www.tela-botanica.org/bdtfx:nn:68580
- Bolboschoenus glaucus : http://www.tela-botanica.org/bdtfx:nn:101814
Problème technique : il semble que ce n'est pas possible de créer un permalien avec une écriture partiellement italique, tel que Torilis japonica subsp. japonica. Voir la fiche : http://www.tela-botanica.org/bdtfx:nn:120780
le 3 janvier, David Mercier
je pose la question de savoir si, selon vous, les pages wiki de eFlore sont bien adaptées à la contribution collaborative ?Voici un exemple de page Wiki eFlore remplie :
Rubus : http://www.tela-botanica.org/bdtfx:nn:77191
Il s'agit en faite d'une ardoise sur laquelle n'importe qui peut Ă©crire, effacer, modifier la page.
Il n'y a aucun historique associé à cette page.
Il n'y a pas non plus, de page de discussion associée.
Le système Wikipédia est bien plus sécurisé :
Rubus : https://fr.wikipedia.org/wiki/Rubus
En onglet en haut, vous avez la page "Discussion", où se trouve des discussion sur la rédaction de la fiche
En haut à droit, se trouve "Afficher l'historique", où il est possible de visualiser l'apport de chaque contributeur, et à quelle date. Pour l'article Rubus de Wikipédia, il y a eu une centaine de contributions depuis la première création de la page en 2004.
Cet historique permet de garder en mémoire toutes les versions, et de revenir à une version antérieure à tout moment.
On peut également, en tant que contributeur à un article, être tenu informé de toute modification sur cet article.
Bref, le système Wikipédia est largement meilleur.
le 3 janvier, Philippe Julve
Oui wikipédia est meilleur, mais un bon contributeur ne va pas passer tous les jours pour voir si quelqu’un n’a pas modifié et dégradé sa contribution. Et jamais personne ne va voir l’historique. C’est d’ailleurs pour ces raisons que j’ai cessé de collaborer à wikipédia. J’ajoute que wikipédia ne permet pas de savoir qui a rédigé, alors que c’est un des seuls critères de confiance que l’on peut recenser. Pour moi il faut séparer franchement les contributions majeures d’auteurs identifiés, qui devraient rester stables, et s’il y a des contradicteurs et bien publier les deux ou plus versions contradictoires… et les bacs à sables pour débutants.le 4 janvier, Michelle Van Panhyus
Pour en revenir à la question initiale de David: "Les wikis sont-ils adaptés à la contribution collaborative sur eFlore ?", ma réponse est : non.Il me semble bien que depuis le temps que ça a été introduit il y a eu remarquablement peu de contributions. Je vais souvent sur eflore, et je ne me souviens pas avoir vu plus d'une ou deux contributions et beaucoup, beaucoup d'espace vide, très décourageants et qui me font partir aussitot sur wikipedia ou autres sites.
Personnellement je n'ai jamais contribué car les wiki sont particulièrement rebutants à utiliser.
Et puis, dans le cas d'un contribution qui demande du travail personnel, des connaissances, du temps, comme celle sur les rubus , il est normal que l'auteur qui a fait ça bénévolement soit cité et que tout un chacun ne puisse pas venir modifier et dégrader sa contribution, il me semble que c'est la moindre des choses, la seule reconnaissance qu'il aura.
Introduire des relecteurs ? des validateurs ? difficile à mettre en place, et puis non, je ne crois pas que c'est nécessaire (en dehors d'une modération minimum pour supprimer les pignoufs :)) . L'auteur est clairement indiqué, les textes ne sont pas anonymes et chacun reste responsable de ce qu'il dit, les commentaires sont les bienvenus et tout le monde doit pouvoir participer facilement, mais pas modifier ce qu'un autre a dit. Je suis sure qu'il serait rapidement évident qui est sérieux et compétent ou pas sans donner de badges, sur les forums comme celui de détermination, les participants savent très bien qui est qui, et quelles personnes sont crédibles.
En fait , pour avoir une certaine qualité, un système inspiré des "forum" (contributions personnelles, non anonymes, non modifiables par un tiers, présence d'un modérateur et possibilité de critique et commentaire par tous) qui est déjà éprouvé depuis longtemps, me parait plus efficace et accessible à tous que toute tentative d'automatisation de la régulation, ou tout contrôle d'une autorité supérieure.
le 4 janvier, Jaen-Claude Bouzat
Pour ma part j'ai une question, quand je vais sur le "Portail de la botanique" de Wikipedia je note une information dansun encadré, "Projet Internet lié : Tela Botanica" et si on clique on accède au site de TB. Au regard de leurs propres
objectifs quelle est la nature des liens unissant les deux entités ?
Un site que j'apprécie beaucoup et dans lequel, même si le portugais est pour moi une langue que je ne parle pas, j'aime
aller faire un tour pour vérifier une espèce est http://www.spbotanica.pt/
Outre sa présentation qui ressemble à un eFlore (en plus simple) on y trouve "Plantas em volta" qui ouvre la
collaboration aux amateurs pour évoquer une espèce, bien mieux qu'on peut le faire sur le wiki.
le 5 janvier, Daniel Mathieu
Je suis d’accord avec vous, les Wiki de Tela sont très mal fait pour attirer les contributeurs (la preuve, ils sont très peu nombreux) et le résultat affiché en lecture est très rébarbatif, même quand le contenu est de qualité (cf les Rubus de David : http://www.tela-botanica.org/bdtfx:nn:77191 )Dans le nouvel eFlore, il faudra réfléchir à la façon d’organiser cette connaissance apportée par les contributeurs : une seule page Wiki par taxon ou différents espaces (comme maintenant dans eFlore), quel outil utiliser, suivi des modifications avec historique, signature, espace discussion, etc.
le 6 janvier, Michel Chauvet
Intérêt des wikisLes wikis diffèrent en fonctionnalités. Mediawiki (celui de Pl@ntUse et de Wikipédia) offre les avantages suivants :
- page de discussion liée à chaque page ; j'utilise cette page en particulier pour informer sur l'état d'avancement du travail dans la page, pour dire si la page a été validée ou non... On peut parfaitement utiliser cette page de discussion pour préciser si elle a été relue par des personnes ayant le statut de relecteur, de validateur, etc.
- possibilité de visonner l'historique de la page, et de revenir sur une version antérieure.
- possibilité de marquer chaque page sur sa "liste de suivi", qui permet d'être informé chaque fois que cette page a été modifiée ;
- possibilité de réserver l'écriture sur une page à des personnes ayant le statut d'administrateur. Il doit même y avoir possibilité de différencier plusieurs statuts, par exemple "utilisateur confirmé" et "administrateur", mais je n'ai pas cherché jusqu'à présent.
- tout le monde n'a pas besoin d'être expert dans l'usage des balises et autres codes. On peut parfaitement mettre du texte brut, ou avec seulement les gras et italiques, et demander de l'aide pour un formatage plus poussé.
- chaque utilisateur dispose d'un page personnelle où il peut se présenter, où on peut discuter avec lui et où il peut mettre et commenter ses meilleures images dans des "galeries".
Par ailleurs, Wikipédia a fait ses choix propres, mais on peut en faire d'autres, par exemple, avoir des pages signées. C'est ce que je fais sur Pl@ntUse (mais j'avoue que n'ai pas à gérer une multiplicité de contributeurs...).
En ce qui concerne les images, je pense effectivement qu'il faudrait trouver le moyen d'en éliminer, en commençant par les mauvaises photos techniquement parlant. Avec Mediawiki, on a en fait un système à deux étages : le premier (Wikimedia Commons) sert simplement à stocker les images et à les classer dans des catégories pour permettre leur repérage. Le second consiste à choisir les meilleures images pour les mettre dans les pages de texte (Wikipédia en l'occurence). Là aussi, on a le choix : Wikipédia préfère mettre peu d'images pour simplement illustrer l'encyclopédie, alors que sur Pl@ntUse, je préfère en mettre davantage pour illustrer les différents stades de vie d'un taxon ou sa variabiité. On n'est pas limité, mais on peut choisir.
Comme cela, aucune image correcte n'est éliminée, mais seule les meilleures apparaissent dans l'encyclopédie, à la discrétion non pas du photographe mais du rédacteur de la page. Chacun y trouve son compte.
Rapports avec Wikipédia
Quoi qu'on en pense, Wikipédia est bien plus visible que Tela Botanica. Personnellement, j'écris très peu dans Wikipédia, parce que je me concentre sur Pl@ntUse et que je n'ai pas envie de perdre du temps à négocier avec plein de gens sur le contenu. Mais je suis de plus en plus présent dans les discussions de Wikipédia (les "bistrots"). J'essaie de positionner Pl@ntUse comme un site de référence que Wikipédia peut ensuite utiliser. Car Wikipédia a fait le choix de ne pas mettre de données originales, mais uniquement des synthèses qui s'appuient sur des données originales extérieures. Et en fait, les wikipédiens sont demandeurs de sources extérieures sérieuses. Tela Botanica pourrait assez facilement le devenir. On aurait ainsi une complémentarité entre les deux.
Conclusion
Je suis devenu un fervent adepte des wikis, et de Mediawiki en particulier. Si la solution d'un wiki est retenue par Tela Botanica, il faudra s'assurer que les fonctionnalités requises soient bien supportées. Les remarques des uns et des autres montrent que ce n'est pas le cas actuellement.
Le gros avantage de Mediawiki est que sa pérennité est assurée par la communauté Wikipédia. Par ailleurs, il est ordinairement installé sur de grosses machines une seule fois, et de nombreux wikis particuliers peuvent alors l'utiliser, dans ce qu'on appelle des "fermes de wikis". C'est le cas de Pl@ntUse, qui utilise le consortium Biowikifarm. C'est solution a un avantage énorme : je n'ai pas à m'occuper du tout de la maintenance du logiciel, et je peux donc travailler pratiquement sans informaticien ! Tela pourrait ainsi allouer ses (faibles) moyens à autre chose, comme écrire des modèles de formatage et valider des données...
Le reste est une affaire d'organisation, pas de moyens informatiques. On devrait bien trouver des botanistes pour cela, ou alors c'est à désespérer.
le 6 janvier, Daniel Mathieu
L’adéquation de Wikimédia à une participation collaborative n’est plus à démontrer. C’est un fait !Son évolution au cours du temps a permis d’arriver à un dispositif très performant et très complet. Il n’y a pas photo par rapport à nos Wiki d’eFlore...
Dans nos rapport avec Wikipédia, si Tela pouvait être pris comme référence externe serait très bien. Il l’est de fait déjà un peu aujourd’hui, car pratiquement toutes les pages sur les plantes ont un lien vers Tela (mais pas toujours bien adapté)
Autre avantage d’être sur Wikimédia : pas de maintenance informatique, c’est un plus évident. Il y a suffisamment de choses à faire par ailleurs.
Mais la question centrale que je me pose, c’est comment adapter un site sous Wikimédia à notre structure de données.
Pas question de créer les pages à la main les unes après les autres. Il faut qu’elles soient créées automatiquement à partir des référentiels (BDNFF ou autre). Or ces référentiels évoluent au cours du temps : ajout / suppression de taxon, changements de noms, etc. comme faire suivre le Wiki ?
Le Wiki devrait-il remplacer totalement eFlore, ou bien ne serait-il que le volet d’Eflore dédié à l’écriture collaborative ?
Doit on faire une page par taxon (référentiel taxonomique à la Wikipédia) ou pas nom (référentiel nomenclatural, comme Genève) ?
Pas simple tout ça. Beaucoup de réflexion et d’avis à recueillir, notamment auprès des informaticiens de Tela et des responsables de Wikimédia.
le 6 janvier, David Mercier
ce rapprochement avec Wikimedia serait très bénéfique, autant à Tela Botanica qu'à Wikimedia. Ces deux réseaux semblent peu connecté, il y a les telabotanistes d'un côté, les wikipédiens de l'autre.A sujet des questions posées, c'est difficile de répondre, quand on ne connaît pas bien Wikimédia. Ce qui est mon cas.
le 7 janvier, Michel Chauvet
Sur Pl@ntUse, je dispose d'un petit robot (réalisé par des informaticiens de Tela dans le cadre de Pl@ntNet !) qui permet de créer des pages automatiquement, avec un format préalablement défini (taxobox, rubriques, liens...). Donc pas de problème.Les référentiels évoluent, certes, mais de façon ponctuelle. Il n'y a donc pas de réel problème pour mettre les fiches à jour. Sur Mediawiki, il suffit de renommer la page, et cela crée automatiquement une redirection. Le système des redirections permet d'ailleurs d'inclure les synonymes usuels et les noms vernaculaires dans des pages de redirection. Les noms des pages de redirection sont alors bien accessibles dans l'onglet Recherche, et conduisent automatiquement aux bonnes pages. Quand on a affaire à un nom ambigu, on peut étoffer ces pages de redirection en donnant des infos qui permettent de sortir de l'ambiguité. Voir par exemple ma page Laurier <http://uses.plantnet-project.org/fr/Laurier> .
Les deux systèmes (e-flore et wiki) peuvent parfaitement cohabiter côte à côte ! On verra bien à l'usage lequel est le plus utilisé. E-flore restera de toute façon une base nomenclaturale indispensable, mais pour les spécialistes.
Quant à ta dernière question, Daniel, elle m'a fait sourire, car elle souligne le "vice congénital" de la BDNFF, qui est une base nomenclaturale par nature, mais avec une taxonomie implicite. Or ce n'est pas la nomenclature qui intéresse avant tout les gens, ce sont les plantes elles-mêmes !
L'avis des informaticiens est pertinent, mais n'est pas essentiel à mon avis. Il vaudrait mieux recueillir l'avis de personnes qui mettent déjà du contenu sur Internet. A commencer par les contributeurs de Wikipédia, mais aussi ceux de Plantalex <http://www.plantalex.com/index.asp> , Hortipedia <http://fr.hortipedia.com/wiki/Accueil> , Toild'épices <http://www.toildepices.com/> ...
A propos de Wikipédia, d'ailleurs, il est inutile de demander aux "responsables" de Wikimedia. Chaque "projet" (comme la botanique) est géré collectivement pas ses utilisateurs ! Il faut donc éventuellement discuter sur le bistro du projet Botanique <https://fr.wikipedia.org/wiki/Discussion_Projet:Botanique> . On y trouve déjà des télabotanistes, et il serait d'ailleurs dommage que d'autres y aillent, ne trouvant pas ce qu'ils souhaitent sur le site de Tela.
C'est d'ailleurs pour moi un des principaux risques pour Tela : que les internautes aillent voir ailleurs, parce que le site de Tela est trop complexe, donne trop de renseignements inutiles et n'est pas assez interactif et convivial.
Je signale aussi un problème gênant pour citer Tela : il faut aller chercher en bas des pages le lien permanent, et cela apparemment manuellement ! Pour mon robot, j'ai pu faire automatiser l'écriture de liens profonds quand ceux-ci se terminent par "genre+espèce". Ce n'est pas le cas de Tela, mais c'est le cas de Wikipédia, Pl@ntUse, Pl@ntUse, GRIN, PlantList et bien d'autres. Je ne sais pas si mes collègues pourront pointer sur Tela à partir de Pl@ntNet-Mobile à cause de ça ; de plus, le site de Tela se prête apparemment mal à une lecture sur smartphone...
Quant à Mediawiki, non seulement il ne me demande aucun soutien informatique, mais de plus, l'insertion de Pl@ntUse dans Biowikifarm est gratuite ! Ce qu'apprécie Biowikifarm, c'est qu'un informaticien contribue éventuellement à la gestion du logiciel (mais à Pl@ntUse, nous ne le faisons même pas).
le 7 janvier 2014, David Mercier
effectivement, la question est là : trouver la complémentarité wiki / tela.Si c'est pour essayer de faire des synthèses bibliographiques meilleurs que Wikipédia, au point de vue de la pertinence des informations, c'est concurrentiel, car l'objectif d'excellence est aussi celui de Wikipédia.
Le niveau scientifique est bien là chez Wikipédia : https://fr.wikipedia.org/wiki/Discussion_Projet:Botanique
La spécificité de Tela Botanica se situe au niveau de la production de données de référence : BDTFX, eVeg, chorodep.
En ce qui concerne les pages d'Ă©criture de eFlore, je propose :
1) de les remplacer par les wikis développés par wikimédia, à historique et écriture non anonyme, et mise en page agréable,
2) de les destiner à des synthèses commentées, les commentaires étant une valeur ajoutée par rapport aux articles sur Wikipédia. Ces commentaires pourraient contiendraient en effet des données inédites, tel que "les flores indiquent que tel caractère discriminant fonctionne, mais ça ne fonctionne pas si bien que ça ; voir les mesures ci-dessous."
Voici un exemple de ce que cela donnerait :
http://fr.wikipedia.org/wiki/Rubus_lejeunei
J'ai écrit cette page il y a longtemps, et vous remarquerez le commentaire sous "Synonymes". Il s'agit d'un commentaire qui a été, peu après sa rédaction, retiré de l'article et déplacé dans la page "discussion" par un administrateur. J'avais alors argumenté qu'il s'agissait d'une information importante à faire figurer dans l'article lui-même, ce qui a pu se faire. Mais ce texte est effectivement en limite du champs d'action de Wikipédia, dont l'objectif n'est pas la production de données inédites, mais au contraire, la synthèse de données éditées ailleurs.
J'ai sous le coude la traduction en français de plusieurs dizaines de protologues de Rubus écrits en allemand. Je compte bien pouvoir mettre ces protologues dans eFlore quand ce sera possible. De même, j'ai fait des mesures sur des spécimens type, qui ont pour vocation à alimenter eFlore.
Dans ce contexte de production données inédites, eFlore (page d'écriture "Usage") deviendra par contre concurrentiel de Pl@ntUse. Une solution serait de faire un lien à Pl@ntUse sur eFlore, ou alors de l'afficher directement, ce qui me semble préférable. Ce serait une solution pour faire connaître et solliciter des participants à l'amélioration de Pl@ntUse !
le 7 janvier, Erol Vela
Je me (re)pose une question sur l’existence de wikispecies aux côtés de wikipedia, alors que les espèces sont désormais aussi dans wikipédia… pourquoi ?Exemple :
http://fr.wikipedia.org/wiki/Asplenium_marinum
http://species.wikimedia.org/wiki/Asplenium_marinum
Il y a déjà concurrence entre les wikipedia de différentes langues…
En revanche jÂ’ai lÂ’impression que wikispecies nÂ’existe quÂ’en anglais ?
le 7 janvier, Michel Chauvet
Non, on ne peut pas dire qu'un wiki est par essence "non contrôlé". J'insiste sur le fait que c'est une question d'organisation, pas d'informatique.Simplement, pour stimuler les contributions (ce qui est le point essentiel), il vaut mieux autoriser l'écriture sans contrôle a priori. Ensuite, on peut très bien faire relire les pages par des "experts", voire les bloquer, auquel cas les contributions passent par les pages de discussions.
On peut aussi soumettre l'écriture à une procédure d'inscription (ce que je fais sur Pl@ntUse). On peut alors suivre les contributions de chacun, et si on constate que quelqu'un met vraiment n'importe quoi, on peut l'exclure !
Je crois que si l'on précise dans des pages d'aide ce qu'on attend comme contenu, et qu'on donne des instructions précises, il pourra y avoir des candidats. Enfin, espérons-le, car pour l'instant, ça ne marche pas vraiment pour Pl@ntUse.
le 7 janvier, David Mercier
pour connaître l'essentiel sur Wikipédia et les projets frères (Wikispecies, Wikimédia commons, Wikisource, etc.), voici l'article sur Wikipédia dans Wikipédia :http://fr.wikipedia.org/wiki/Wikip%C3%A9dia
Voir en particulier au chapitre 3.4.
Wikispecies est un référentiel taxonomique et systématique des taxons du monde vivant. Cette référence sert de base aux données taxonomiques et systématiques de Wikipédia.
Pour créer un nouveau Wiki porté par Wikimédia, toute la démarche à suivre ici :
http://incubator.wikimedia.org/wiki/Incubator:Main_Page/fr
le 7 janvier, Michel Chauvet
David, je suis heureux que tu ailles dans le sens de propositions précises. Il nous faudrait en effet définir le type de données à mettre dans un wiki, et de préférence des données non acceptées par Wikipédia. Tu as déjà donné quelques exemples :- des protologues (dans la langue originale et en traduction)
- des descriptions dans un format normalisé (au contraire de Wikipédia qui rédige des phrases)
- des clés de détermination et critères discriminants
- des précisions nomenclaturales et taxonomiques ; ce que tu as fait sur Wikipédia à propos de Rubus lejeunei me paraît effectivement excessif pour Wikipédia, mais intéressant pour Tela.
- etc.
Quant à l'interaction avec Pl@ntUse, tout est possible, puisque le site est en CC-BY-SA. On pourrait mettre des liens systématiques de Tela vers Pl@ntUse (je fais déjà l'inverse), ou bien copier l'info pertinente de Pl@ntUse dans les pages de Tela, ce qui suppose que les données soient formatées de la même façon...
Un élément à prendre en compte est que Tela ne couvre que la flore de France (+DOM et Afrique du Nord !), alors que Pl@ntUse ambitionne une couverture mondiale.
Effectivement, Wikispecies apparaît plus proche de l'approche de Tela Botanica. J'ai cru comprendre que ça évoluait très lentement. Il faudrait y regarder de plus près. Ils semblent avoir adopté un format assez rigide et limité, ce qui freine peut-être les contributions.
Une explication des objectifs et des méthodes de Wikispecies se trouve dans une page d'aide générale <https://species.wikimedia.org/wiki/Help:General_Wikispecies> et à la page Ce que Wikispecies n'est pas <https://species.wikimedia.org/wiki/Wikispecies:What_Wikispecies_is_not>.
le 7 janvier, Delphine Cauquil
je vous envoie le compte-rendu d'une réunion tela botanica-wikipedia qui
a eu lieu en ... 2004 :
http://fr.wikipedia.org/wiki/Projet:Botanique/Partenariat_avec_Tela-Botanica
le 8 janvier, Florent Beck
Une petite précision me semble nécessaire : attention avec l'utilisation du mot "wiki", il s'agit d'un terme générique : wikipédia est un wiki. Le wiki utilisé sur Tela s'appelle "wikini".Ceci dit, il est évident que wikini n'est pas très agréable à manipuler, mais bon ce n'est pas la première fois qu'on en parle, l'équipe technique a déjà eu l'occasion d'expliquer pourquoi wikini avait été choisi et pas un autre moteur de wiki, mais j'avoue ne pas avoir retenu l'explication donnée (pardon).
Ceci dit, et bien que l'exemple proposé par Jean-Claude me semble tout à fait intéressant, je trouve que l'utilisation d'un wiki à l'avantage d'être immédiatement accessible, alors que les pages non éditables de "plantas em volta" n'encourage pas la participation papillon.
Si on veut des monographies, alors c'est sûr qu'on peut abandonner le wiki, mais ce n'est pas la peine de chercher à se tourner vers un forum type phpbb ni non plus vers les possibilités offertes par les stackexchanges que j'ai déjà évoqué ici en vain.
Si on veut des monographies, il faut recruter des monographes, c'est tout, il n'y a rien d'autre Ă faire. Mais je ne crois pas que ce soit l'objectif de Tela qui est plutĂ´t de chercher Ă encourager le travail collaboratif. Ou alors on ouvre un projet "monographie des taxons de la BDNFF" et on peut toujours prier pour que les fiches eFlore se remplisse...
Si on veut des descriptions collaboratives, avant même de chercher à avoir des participants compétents et de qualité il faudrait déjà avoir des participants. De ce point de vue là je suis d'accord pour dire que wikini est trop repoussoir, mais je continu de préférer un système participatif ouvert à un système de monographie figées.
Pour ce qui est de la traçabilité, un wiki n'empêche pas de signer une participation, mais il est certain que l'édition à volonté met la permanence des signatures et des contenus à la merci de qui que ce soit. Je n'ai pas la même appréciation de Wikipédia que Philippe de ce point de vue là .
Personnellement je commence à être un peu usé des réflexions récurrentes sur la nécessaire qualification des participants. Soit le CA de Tela valide cette nécessité et on demande à l'équipe technique d'introduire un système de hiérarchie entre les utilisateurs avec une reconnaissance des compétences et un accès différencié à l'édition / validation des données sur le site. Soit le CA ne valide pas cette nécessité et il faut qu'on arrive à passer outre cette interrogation et qu'on réfléchisse uniquement dans un fonctionnement ouvert à  tous.
Je me permet de rappeler encore une fois que le système de stackexchange permet la réalisation communautaire de cette hiérarchisation, mais je ne reviendrais pas plus là dessus étant donné que j'ai déjà suffisamment argumenté.
le 8 janvier, Michel Chauvet
Dans Wikipédia, il y a une part d'automaticité, mais aussi une part d'évaluation par des humains ! Pour Tela, je crains que ce soit une limite, car cela demande du travail...Dans Wikipédia, il y a apparemment plusieurs cas. Les images semblent être systématiquement vérifiées au début, et si rien ne s'y oppose, le contributeur change de statut au bout d'une certain nombre de contributions.
Pour les textes, quand quelqu'un remarque une contribution qui pose problème, il peut regarder les autres contributions de leur auteur et soit ouvrir une discussion, soit faire des remarques à l'auteur. Si ces remarques sont acceptées, tout rentre dans le rang. Si l'auteur continue à faire n'importe quoi, il finit par être viré.
Tout cela repose sur le fait qu'on peut disposer de la liste des contributions d'un auteur donné.
le 10 janvier, VĂ©ronique Schaffer
concernant le point wikipedia je vous invite à relire le document " Echanges au sujet de Wikipédia "de 2012 ( "Synthèse des échanges de courriels au sujet de la controverse Tela versus Wikipédia qui ont eu lieu entre le 10 février et le 1er mars 2012 sur le forum du CST ") mis sur le porte document du CSThttp://www.tela-botanica.org/projets/8/telechargement/18694
Il ne s'agit peut être pas de la même problématique qu’actuellement mais ça concerne le sujet "wikipedia et tela"
le 12 janvier, Daniel Mathieu
Effectivement, il ne s’agissait pas de la même problématique. Ces échanges ont eu lieu à un moment où des pages de Wikipédia ont été introduites dans eFlore.Dans notre discussion récente, il s’agit de savoir s’il était envisageable et intéressant de créer un espace Wikimédia dédié à Tela pour y mettre des données eFlore.
Cet espace pouvant alors servir de référence pour Wikipédia. L’inverse du cas précédent ou c’est Wikipédia qui servait à alimenter eFlore.
le 13 janvier, David Mercier
l'action proposée consiste donc simplement à utiliser le logiciel Mediawiki pour les pages d'écriture de eFlore.le 13 janvier, Michel Chauvet
En fait, Wikidata dépasse largement mon niveau de compétence. C'est une initiative de développeurs informatiques pour créer une base de données factuelles sur laquelle pourrait s'appuyer les diverses versions linguistiques de Wikipedia.Voici deux liens utiles :
- page de Wikipédia ; https://fr.wikipedia.org/wiki/Wikidata
- page d'accueil du site Wikidata. https://www.wikidata.org/wiki/Wikidata:Main_Page
le 13 janvier, Daniel Mathieu
Dans l’hypothèse d’une utilisation de MediaWiki pour Tela Botanica, utiliser cet outil uniquement pour la partie collaborative ne serait pas très profitable.Une autre voie à explorer serait d’évaluer la faisabilité d’utiliser Mediawiki pour l’intégralité d’eFlore. J’ai parcouru tous les onglets d’eFlore pour un taxon et j’ai essayé de les placer dans un Mediawiki imaginaire. Dommage qu’on ne puisse pas faire de maquette, mais on peut assez facilement l’imaginer à partir d’une page d’un taxon en prenant la mise en page dans Wikipédia (test avec Prunus serotina et les informations d’Eflore)
http://www.tela-botanica.org/bdtfx-nn-53647
http://fr.wikipedia.org/wiki/Prunus_serotina
En tĂŞte de page :
Prunus serotina Ehrh. ROSACEAE
Cerisier d'automne (nom français recommandé)
Synonymie (complète)
- Cerasus serotina (Ehrh.) Loisel. [1812, in Duhamel ; Traité Arbr. Arbust., éd. nov., 5 : 3]
- Basionyme : Prunus serotina Ehrh. [1788, Beitr. Naturk., 3 : 20]
- Padus serotina (Ehrh.) Borkh. [1797, in Roem. ; Arch. Bot. (Leipzig), 1 (2) : 38]
- Basionyme : Prunus serotina Ehrh. [1788, Beitr. Naturk., 3 : 20]
- Padus virginiana Mill. 1768, Gard. Dict., éd. 8 : n°3]
- Prunus salicifolia Kunth [1820, in Humb., Bonpl. & Kunth ; Nov. Gen. Sp. Pl., 4 : 241, tab. 563]
Noms vernaculaires (issus de la base Tela (Jeff) et regroupés par langue)
fra Cerisier d'automne, Cerisier noir, Cerisier tardif
ndl Amerikaanse Vogelkers
deu Amerikanische Spätkirsche, Herbst-Kirsche, Spätblühende Traubenkirsche, Späte Traubenkirsche
eng Black Cherry, Rum Cherry, Whisky Cherry
spa CapulĂn, Cerezo del ron, Cerezo negro
ita Ciliego nero, Ciliego tardivo, Prugno della Virginia , Pruno autumnale
Description collaborative (classique type Wikipédia)
Le cerisier tardif est un arbre à feuillage caduc pouvant atteindre une hauteur de 20 m en Europe et jusque 35 m aux États-Unis[réf. souhaitée]. Son écorce est gris foncé et se fissure avec l'âge 1 .
Les feuilles sont de forme elliptique à lancéolée (12cm de long pour 5cm de large). Elles sont coriaces et munies d'une fine dentelure dirigée vers l’avant. Leur face supérieure est de couleur vert foncé luisante et est lisse, tandis que leur face inférieure est plus claire et est pubescente le long de la nervure principale.
En automne, elles deviennent jaunes avant de tomber2.
Le fruit est une sphère de couleur rouge foncé à noir et large de 8-10 mm. Il est comestible.
Bibliographie (dans la biblio de Tela)
- GUINIER Ernest - Le Cerisier de Virginie (Prunus virginiana L., Cerasus virginiana DC) et le Cerisier tardif (Prunus serotina Ehrh., Cerasus serotina DC.). - 1902, p. 21- 23 - Départ./Région : , Bulletin de la Société Botanique de France, 2, Tome 49 - Fascicule 1
- JAVELLE Aurélie - Plantes envahissantes et perception sociologique, le cas du cerisier tardif à Compiègne - 2005.06, p. 31- 35 - Départ./Région : Oise, La Garance voyageuse, 1, N°70
- O. CHABRERIE, H. HOEBLICH, G. DECOCQ - Déterminisme et conséquences écologiques de la dynamique invasive du Cerisier tardif (Prunus serotina Ehrh.) sur les communautés végétales de la forêt de Compiègne - 2007, p. 383- 394 - Départ./Région : , Acta Botanica Gallica, 1, Tome 154 - Fascicule 3
- Tournay F. - Le cerisier capulin - 2008, p. 38- 40 - Départ./Région : , Hommes et Plantes, 1, N°66
Liens vers les autres sites
IPNI, Jstore, Grin, INPN, etc.
- Sur la droite de la page il y aurait les illustrations suivantes
- Une Photo très représentative (scan par exemple)
- Un lien vers toutes les photos de Flora data (Tela) et PhotoFlora
- la classification selon APG3
- le statut de protection national
- lÂ’Ă©cologie : barre-graphe horizontal issu de Baseflor (comme sur Tela)
- lien vers eVeg (qui pourrait ĂŞtre de mĂŞme facture)
- carte départementale
- carte de moissonnage
Ainsi, sur une page on peut tout voir. La page est un peu longue, mais ce nÂ’est pas plus difficile de scroller que de jouer avec des onglets.
Il pourrait y avoir une page par nom (fabriquée par un robot à partir de la base de données nomenclaturale). Si le nom est retenu, la page est complète. Si le nom est un synonyme, on ne donne que les donnes liées au nom avec liens vers le protologue, les scans de type, la biblio... et le nom retenu.
Par contre il faut voir comment cela peut-être réalisé sur le plan informatique, notamment si les Webservices développés dans eFlore pour les affichages sont réutilisables.
Il faudrait pouvoir faire une maquette. Michel tu sais faire ?
le 13 janvier, Michel Chauvet
Daniel, tu peux utiliser Pl@ntUse pour faire des pages d'essai ! Si tu veux, j'ouvre une page pour Prunus serotina, en y mettant les données que je peux. Les images peuvent être téléversées dans Openmedia (qui est le serveur de Biowikifarm analogue à Wikimedia Commons). Je préfèrerais que ce soit un des informaticiens de Tela qui le fasse.L'intérêt serait de voir si le résultat plaît aux lecteurs. On verra ensuite
le 13 janvier, Florent Beck
Je suis en train de me poser la question de savoir s'il ne serait pas plus intéressant, au lieu d'envisager un fonctionnement wiki, d'imaginer un fonctionnement avec des pages automatiquement remplies via des bases de données relationnelles.Il suffirait alors de proposer des formulaires de participations pour recueillir les informations que les utilisateurs souhaiteraient compléter, par exemple : au lieu d'avoir un seul champs texte dans lequel sont mélangées les informations concernant la description, les critères d'identifications, les espèces proches avec lesquelles des confusions sont possibles, les usages, la bibliographie, des noms régionaux,
Ne serait-il pas plus intéressant d'avoir pour chaque fiche eFlore une page "affichage" dans laquelle personne ne pourrait rien modifier. Et une page "participation" qui contiendrait en fait un formulaire avec tout plein de champs permettant de recueillir précisément l'info complémentaire que chacun peut vouloir apporter ponctuellement. Il suffirait alors de valider le formulaire via un bouton "envoyer" puis de mettre en place un outils de vérification comme IdentiPlante qui listerait les propositions d'ajouts / modifications / suppressions afin que les utilisateurs du réseau puissent valider ou invalider.
Les infos nouvellement envoyées seraient alors récupérées dans la base de données FloraData, taguées avec un tag de type "info utilisateur non vérifiée", affichées directement dans la fiche eFlore, affichées également dans un outils de vérifications des infos transmises sur le modèle d' IdentiPlante, validées ou invalidées par les utilisateurs, en fonction de ce vote les infos pourraient alors être retaguées "info utilisateur validée" ou "info utilisateur invalidée" auquel cas l'information pourrait être retirée de l'affichage dans la fiche eFlore.
Voici les avantages que je vois dans cette proposition :
- très peu de travail d'intégration d'outils nouveau pour l'équipe technique : il s'agit en effet uniquement d'utiliser de manière différente des outils que nous possédons déjà : les fiches eFlores sont générées automatiquement sur la base de FloraData et des référentiels taxonomiques, l'outil de validation par le réseau est déjà existant ( IdentiPlante), il suffirait de le modifier légèrement pour l'adapter aux informations transmises en terme d'affichage.
- mise en place pour chaque fiche eFlore, d'une page de saisie de données via des formulaires détaillées (aux aussi générés automatiquement en fonction des champs à remplir dans FloraData), c'est également quelque chose de déjà en place via la possibilité actuelle d'apporter des informations en double cliquant sur les zones d'édition directement sur eFlore. La seule différence résiderait dans la finesse de séparation des informations dans des champs différents (au lieu d'un champ unique actuellement)
- mise en place d'une interface de validation supplémentaire " ValidiFlore" ou "Valid-eFlore" (à lier à un projet ?) qui récupérerait les
informations envoyées par les formulaires désignés ci-avant et les soumettrait à validation par vote des membres du réseau exactement de la même manière que ce qu'on fait déjà sur identiPlante.
qu'en pensez-vous ?
le 13 janvier, Errol Vela
Moi je préfère nettement ça !le 13 janvier, Daniel Mathieu
- Je suis en train de me poser la question de savoir s'il ne serait pas plus intéressant, au lieu d'envisager un fonctionnement wiki, d'imaginer un fonctionnement avec des pages automatiquement remplies via des bases de données relationnelles.
Oui, c’est comme ça qu’eFlore fonctionne aujourd’hui !
- Il suffirait alors de proposer des formulaires de participations pour recueillir les informations que les utilisateurs souhaiteraient compléter, par exemple : au lieu d'avoir un seul champs texte dans lequel sont mélangées les informations concernant la description, les critères d'identifications, les espèces proches avec lesquelles des confusions sont possibles, les usages, la bibliographie, des noms régionaux,
- Ne serait-il pas plus intéressant d'avoir pour chaque fiche eFlore une page "affichage" dans laquelle personne ne pourrait rien modifier. Et une page "participation" qui contiendrait en fait un formulaire avec tout plein de champs permettant de recueillir précisément l'info complémentaire que chacun peut vouloir apporter ponctuellement. Il suffirait alors de valider le formulaire via un bouton "envoyer" puis de mettre en place un outils de vérification comme IdentiPlante qui listerait les propositions d'ajouts / modifications / suppressions afin que les utilisateurs du réseau puissent valider ou invalider.
Je ne comprends pas. CÂ’est exactement ce quÂ’il y a dans eFlore actuellement ! Sauf quÂ’il nÂ’y a pas de validation (presque personne nÂ’Ă©crit....)
Les infos nouvellement envoyées seraient alors récupérées dans la base de données FloraData, taguées avec un tag de type "info utilisateur non vérifiée", affichées directement dans la fiche eFlore, affichées également dans un outils de vérifications des infos transmises sur le modèle d' IdentiPlante, validées ou invalidées par les utilisateurs, en fonction de ce vote les infos pourraient alors être retaguées "info utilisateur validée" ou "info utilisateur invalidée" auquel cas l'information pourrait être retirée de l'affichage dans la fiche eFlore.
- Voici les avantages que je vois dans cette proposition :
- très peu de travail d'intégration d'outils nouveau pour l'équipe technique : il s'agit en effet uniquement d'utiliser de manière différente des outils que nous possédons déjà : les fiches eFlores sont générées automatiquement sur la base de FloraData et des référentiels taxonomiques, l'outil de validation par le réseau est déjà existant ( IdentiPlante), il suffirait de le modifier légèrement pour l'adapter aux informations transmises en terme d'affichage.
- mise en place pour chaque fiche eFlore, d'une page de saisie de données via des formulaires détaillées (aux aussi générés automatiquement en fonction des champs à remplir dans FloraData), c'est également quelque chose de déjà en place via la possibilité actuelle d'apporter des informations en double cliquant sur les zones d'édition directement sur eFlore. La seule différence résiderait dans la finesse de séparation des informations dans des champs différents (au lieu d'un champ unique actuellement)
- mise en place d'une interface de validation supplémentaire " ValidiFlore" ou "Valid-eFlore" (à lier à un projet ?) qui récupérerait les
- informations envoyées par les formulaires désignés ci-avant et les soumettrait à validation par vote des membres du réseau exactement de la même manière que ce qu'on fait déjà sur identiPlante.
Le problème que l’on cherche à résoudre est double :
- les pages eFlore actuelles sont peu ergonomiques
- la participation est collaborative y est très faible
D’où l’idée d’utiliser Médiawiki pour faciliter la collaboration sur des pages plus agréables à consulter
le 13 janvier, Florent Beck
Oui le fonctionnement que je propose est très semblable à celui en place actuellement, le principal changement réside dans trois aspects :1 - le découpage du champs de formulaire unique en un nombre de champs égal au nombre de types d'informations différents :
par exemple au lieu de regrouper dans un seul et même champs des informations la description, les critères de détermination, les nom vernaculaires locaux, les usages, la bibliographie etc. l'idée serait de proposer un champs unique pour chaque type d'information (donc un formulaire avec plein de champs).
de cette manière l'information est atomisée et on ressentirait moins un besoin de formatage du texte, cette tâche serait alors réalisée automatiquement par les serveurs de Tela qui intégreraient ces données "textes" dans notre base de donnée afin de les afficher dans les fiches eFlore comme s'il s'agissait de données issues de Coste ou de la baseflor par exemple.
Le besoin de formatage (d'avoir un joli texte) pour les utilisateurs serait alors bien moins important étant donné qu'ils ne rédigent plus dans une grande case (quand l'édition à lieu sur la fiche eFlore), voir dans une page de wiki. Je crois que ce sont ces environnements de saisie qui font ressentir le besoin du formatage.
Dans la forme, la participation se présenterait plus comme une réponse à un questionnaire en remplissant des cases bien précises et non comme une participation texte libre - qu'elle resterait bien évidement mais dont elle aurait moins l'apparence.
2 - En recueillant l'information de cette manière là et en demandant aux utilisateurs d'être connecté au moment de remplir le formulaire, on a la possibilité d'associer un nom d'auteur à une information. On gagne donc en traçabilité, et ce quel que soit l'importance / la taille / l'ampleur de l'apport : que la participation se résume à ajouter une source bibliographique ou bien qu'il s'agisse de faire une description détaillée d'un taxon, on pourra associer l'apport à un auteur défini.
3 - On instaure un système de vérification de l'information, toujours a posteriori, l'affichage resterait immédiat. L'information ne serait retirée que si les utilisateurs l'invalident par un vote. Si personne ne vote l'information pourrait resté affichée (comme c'est la règle actuellement), mais on pourrait avoir un tag dans FloraData "information utilisateur non validée" ce qui permettrait quand même de la distinguer, en interne, d'une info issue d'une base personnelle.
De plus,
comme chaque envoi de formulaire disposerait d'un identifiant unique, on ne risque pas de supprimer des données (donc pas de risque de suppression de la super description des Rubus)
Actuellement les participations sont rares, j'imagine donc que les corrections de données existantes sont encore plus rares.
Si toutefois pour un taxon donné, on devait recevoir plusieurs descriptions (c'est un exemple) alors on pourrait imaginer que la description postée en deuxième (ou 3e, ou 4e etc.) soit affichée dans l'interface de validation des données avec un rappel de la description déjà disponible. Les utilisateurs pourraient alors voter pour la meilleure des deux ou bien comme sur IdentiPlante, proposer une nouvelle version qui permettrait alors de reprendre les éléments pertinents des deux propositions afin d'avoir un texte remanié complet.
Comme on peut supposer que de tels cas seraient relativement rare, la gestion des cas problématiques pourrait rester du ressors d'une intervention humaine, de l'équipe technique et/ou du CST en fonction des cas de figure qui se présenteraient.
En résumé :
-> suppression des réticences d'utilisation dues à l'interface peu agréable car non WYSIWYG - en réalité suppression du sentiment de besoin de WYSIWYG,
-> uniformisation de l'affichage de l'information via un formatage par les serveurs et non par les participants,
-> résolution du problème de traçabilité de l'information,
-> mise en valeur des participations via une interface de validation,
-> amélioration de l'implication des membres via ce même interface,
-> possibilité de gestion au cas par cas, par le réseau ou par l'équipe technique ou CST des conflits particuliers qui peuvent apparaître (qui sont supposés rares),
-> pas de complexification disproportionnée des outils du réseau (l'ensemble des propositions est basée sur l'existant)
-> concrétisation technique supposée sans complication majeure pour l'équipe technique. Comme on se base sur l'existant, on n'introduit pas de nouvel technologie, ou de nouvelle composante informatique étrangère à l'équipe : il s'agirait plutôt de réutiliser l'existant de manière différente, complémentaire.
Les questions qui se posent pour moi sont plutĂ´t :
a) jusqu'où atomiser les champs de formulaire à remplir ? (par exemple suffit-il de distinguer "description" de "confusions" ou bien faut-il aussi atomiser encore plus avec "description:organe d'ancrage", "description:organe végétatif", "description:organe reproducteur" et "confusion_1", "confusion_2", "confusion_n", ...
b-1) une interface de validation des données des fiches eFlore sera-t-elle attractive pour les membres du réseau, se l'approprieront-ils comme ils le font actuellement avec IdentiPlante ?
b-2) est-ce qu'un nouveau projet serait nécessaire / souhaitable pour animer une telle interface de validation ?
b-3) quel nom retenir pour une telle interface ? "Valid-eFlore" ?
le 13 janvier, David Mercier
Bonsoir Florent, tu as fait un gros travail pour imaginer et décrire ce système.Concrètement, avec ce système, aura-t-on la souplesse des pages d'écriture Wikipédia, avec la possibilité de corriger une faute d'orthographe, un terme inadapté, compléter un détail d'une description (indiquer la largeur des pétales quand l'information de la longueur est déjà remplie), sourcer l'information ?
Wikipédia permet aussi de sourcer les informations, c'est-à -dire qu'il est possible d'indiquer de quel ouvrage provient telle information, avec un système de renvoi numéroté. Le renvoi pourrait aussi orienter sur un commentaire, par exemple, dans la description : pétales longs de 3-10 mm(exposant36). Exposant36 : Coste (Fl. Fr.) indique des pétales de 3,5 à 7 mm, Fournier indique 4 à 9 mm, Flora europaea indique 3 à 10 mm.
le 14 janvier, Daniel Mathieu
Florent,- Oui le fonctionnement que je propose est très semblable à celui en place actuellement, le principal changement réside dans trois aspects :
- 1 - le découpage du champs de formulaire unique en un nombre de champs égal au nombre de types d'informations différents :
- par exemple au lieu de regrouper dans un seul et même champs des informations la description, les critères de détermination, les nom vernaculaires locaux, les usages, la bibliographie etc. l'idée serait de proposer un champs unique pour chaque type d'information (donc un formulaire avec plein de champs).
- de cette manière l'information est atomisée et on ressentirait moins un besoin de formatage du texte, cette tâche serait alors réalisée automatiquement par les serveurs de Tela qui intégreraient ces données "textes" dans notre base de donnée afin de les afficher dans les fiches eFlore comme s'il s'agissait de données issues de Coste ou de la baseflor par exemple.
CÂ’est exactement ce quÂ’il y a aujourdÂ’hui dans eFlore et qui ne marche pas !
Voici les champs Wikini indépendants qui existent aujourd’hui dans eFlore : Description (Générale, Identification, confusions possibles, références), noms communs, usages, culture et art, compléments sur l’écologie, bibliographie, compléments sur le protection. Il y a de 1 à 3 champs par onglets que l’on peut remplir indépendamment. L’ensemble étant regroupé dans une page unique dont l’adresse est en bas de page, onglet synthèse. Ex : http://www.tela-botanica.org/eflore:wiki:BDTFXnt4846
- Le besoin de formatage (d'avoir un joli texte) pour les utilisateurs serait alors bien moins important étant donné qu'ils ne rédigent plus dans une grande case (quand l'édition à lieu sur la fiche eFlore), voir dans une page de wiki. Je crois que ce sont ces environnements de saisie qui font ressentir le besoin du formatage.
- Dans la forme, la participation se présenterait plus comme une réponse à un questionnaire en remplissant des cases bien précises et non comme une participation texte libre - qu'elle resterait bien évidement mais dont elle aurait moins l'apparence.
- 2 - En recueillant l'information de cette manière là et en demandant aux utilisateurs d'être connecté au moment de remplir le formulaire, on a la possibilité d'associer un nom d'auteur à une information. On gagne donc en traçabilité, et ce quel que soit l'importance / la taille / l'ampleur de l'apport : que la participation se résume à ajouter une source bibliographique ou bien qu'il s'agisse de faire une description détaillée d'un taxon, on pourra associer l'apport à un auteur défini.
Le wikini actuel garde en mémoire tout ce qui se passe sur la page (et donc dans chaque case d’eFlore) : http://www.tela-botanica.org/wikini/eFloreRedaction/wakka.php?wiki=TableauDeBordDeCeWiki
3 - On instaure un système de vérification de l'information, toujours a posteriori, l'affichage resterait immédiat. L'information ne serait retirée que si les utilisateurs l'invalident par un vote. Si personne ne vote l'information pourrait resté affichée (comme c'est la règle actuellement), mais on pourrait avoir un tag dans FloraData "information utilisateur non validée" ce qui permettrait quand même de la distinguer, en interne, d'une info issue d'une base personnelle.
Avant que l’on mette en place un système de vote ou de contrôle, il faudrait que ces Wiki soient utilisés. Et c’est là tout le problème. Les botanistes préfèrent écrire dans Wikipédia. Quelle en est la raison ????
le 14 janvier, Florent Beck
Je sais bien ce qu'il y a dans eFlore et dans les pages wikini associées actuellement et ce n'est pas du tout ça que je propose.Je ne sais pas trop comment l'expliciter d'avantage, mais essayons.
Quand on navigue dans eFlore, disons dans l'onglet description, on a trois grands titres oranges :
- description de Coste
- description Baseflor
- description collaborative
sous ce dernier titre on a un cadre gris cliquable qui permet l'édition directement dans la fiche eFlore de l'information concernant quatre domaines d'informations différents :
Générale
Participez à l’écriture collaborative de la description générale du taxon
Identification
Listez les caractères spécifiques permettant de déterminer ce taxon
Confusions possibles
Listez ici les taxons avec lesquels celui-ci risque dÂ’ĂŞtre confondu
Références
Listez ici les ouvrages spécifiques à la description/identification de ce taxon.Vous pouvez également mettre des liens vers des documents (déposez les ici)
On est donc en présence d'une seul formulaire : le cadre gris que l'on édite en bloc et que l'on valide en bloc avec le bouton "envoyer" situé directement sous lui.
Dans ce formulaire unique on a quatre partitions dont l'édition n'est pas indépendante : quand on édite la partie description générale on peut directement éditer "identification" juste en dessous et les modifications sont envoyées via le même bouton de confirmation : "envoyer".
Ce que je propose c'est d'atomiser ce formulaire unique pour le remplacer par plein de petits formulaires qui permettraient un remplissage très ciblé des informations. (voir pdf joint : Proposition d'une nouvelle interface de saisie eFlore.pdf)
Il s'agirait ensuite de modifier l'affichage pour s'orienter vers un affichage type description de Coste ou de Baseflor : avec des champs bien définis. L'idée est de brider la forme de rédaction des informations : en conservant un style télégraphique on peut enregistrer les informations communiquées par les membres du réseau dans une base de données (comme baseflor) qui serait vide au départ puis complétée au fur et à mesure des participations. L'affichage et la mise en page serait alors du ressort de décisions graphiques prises par l'équipe technique de Tela qui gère l'affichage du site et réalisée automatiquement par les serveurs, de la même manière que les infos de baseflor sont automatiquement affichées.
Concernant la question de David à propos de la flexibilité d'un tel système, c'est effectivement une des limites que j'y vois encore : corriger une virgule ou une faute d'orthographe ne semble pas très simple dans la configuration que je favoriserais, mais n'est pas impossible non plus. Je développe :
Pour l'instant la démarche de modification / correction que j'ai imaginée me semble un peu lourde étant donné qu'elle passerait par un outil Valid-eFlore : un champ non renseigné pourrait être complété et envoyé avec affichage direct dans la fiche eFlore, mais un champ déjà renseigné que l'on souhaiterait compléter ou corriger nécessiterait un passage en validation par Valid-eFlore avant l'affichage dans la fiche eFlore afin d'éviter que n'importe qui puisse "détruire" un bon travail préalablement existant en envoyant une "correction" vide ou remplie de bêtises. La lourdeur d'un tel processus est à relativiser avec le nombre restreint de participations que l'on observe actuellement dans les fiches eFlore et dont je doute qu'il augmente en flèche, quelle que soit l'évolution retenue pour eFlore.
Ceci-dit, on pourrait aussi laisser les propositions de compléments ou de correction s'afficher directement mais je ne vois pas ça comme étant très sécurisant pour les données, car ça risquerait de conduire à des gue-guerres comme sur wikipédia pour savoir comment exprimer telle ou telle information.
L'idée du Valid-eFlore permettrait également de favoriser la discussion sur le contenu via un système de commentaires comme actuellement en place sur IdentiPlante et qui fonctionne très bien.
Donc les principaux changements par rapport à la méthode actuelle seraient :
- atomisation des formulaires pour permettre une bonne individualisation des données
- enregistrement des données transmises dans une base de donnée (structurée un peu comme baseflor)
- affichage et formatage automatisé par les serveurs : suppression de la possibilité de mettre du gras, des titres, de l'italique : tout devra être prédéfini dans une charte graphique et appliquer automatiquement à chaque information transmise - d'où la nécessité d'atomiser les champs de transmission des données
- possibilité de traçage des informations puisque les utilisateurs compléteraient les formulaires en étant connecté au site de Tela : les participations seraient donc identifiées
- encouragement au débat, en d'autres termes : vérification des informations transmises par le réseau via un outil Valid-eFlore, ce qui manque actuellement (on a dit plus tôt dans nos discussions qu'il manque une page de discussion sur le mode de wikipédia).
Enfin concernant les remarques suivantes :
Le wikini actuel garde en mémoire tout ce qui se passe sur la page (et donc dans chaque case d’eFlore) : http://www.tela-botanica.org/wikini/eFloreRedaction/wakka.php?wiki=TableauDeBordDeCeWiki
tant mieux alors : ça fera ça de travail en moins pour les informaticiens de Tela. Il faudrait cependant réfléchir à un moyen de rendre cette mémoire des modifications plus facilement accessible. Par exemple, copier le lien vers le wikini qui se trouve en pied de page et le coller à côté des formulaires de saisies dans les fiches eFlores.
Avant que l’on mette en place un système de vote ou de contrôle, il faudrait que ces Wiki soient utilisés. Et c’est là tout le problème. Les botanistes préfèrent écrire dans Wikipédia. Quelle en est la raison ????
Nos wikinis sont déjà utilisés - très peu, certes - mais je ne vois pas l'intérêt de faire doublon avec Wikipédia en adoptant un système de fonctionnement et une interface identique à eux. Je ne comprends pas bien en quoi ça donnerait plus envie aux botanistes de rédiger sur eFlore : à mon avis, ils se diront plutôt "mais c'est ridicule, ce travail est déjà en place sur wikipédia et bien plus avancé". Je crois au contraire qu'une solution possible est d'encadrer et d'accompagner beaucoup plus la saisie des informations, on pourrait même aller plus loin dans la réflexion que je propose en remplaçant certains champs à renseigner par des listes d'éléments à choisir, mais je vais développer ça dans un second mail, sinon ça fera trop, j'ai déjà beaucoup écrit ici.
Bonne lecture et à tantôt pour vos réactions :-)