Retour : page principale > sommaire de la version 0 d'eFlore > sommaire de la synthèse
Tue, 13 Feb 2001 23:35:40 +0100
Frédéric legens
Décrire ce projet, n'est pas quelque chose de facile surtout sans faire référence à la technologie à employer. Cependant je vais essayer de le faire.
Prenons comme exemple ISFF. Benoît Bock aurait pu se contenter de mettre à jour le fichier texte fait par Kerguelen, cependant il a choisit de structurer l'information dans une base de donnée. Cette structuration a pour avantage de simplifier le travail à faire, et de rendre facilement utilisable l'information, ce qui n'était pas le cas dans le fichier texte.
C'est justement se que l'on souhaite faire dans le projet eFlore, pour les fonctionnalités dont aurons besoin notamment les projets flore de France et pour les listes départementales.
Ces deux projet ont un point commun. Ils consistent Ă associer de l' information Ă des taxons.
Une bonne structuration des ces informations permettra lorsqu'une correction est apportée à un taxon, de répercuter automatiquement cette modification aux listes départementales et aux clefs. Cependant il existe des avantages bien plus importants :
Ce projet, outre l'Ă©tablissement de ces structures d'informations, aura Ă©galement pour but de mettre en place les outils informatiques permettant l' exploitation de ces structures.
Il débouchera sur la création d'une base de données, hébergée sur le site de tela-botanica pour stocker ces informations. Ces informations seront accessibles soit par un navigateur sous la forme de page HTML (sur Mac ou sur PC), soit par des applications clientes (utilisant comme intermédiaire avec la base de donnée des documents XML) pour les données complexes (voir pour exemple mon prototype d'éditeur de clefs). Les fichiers HTML et XML seront générés par PHP.
Voila j'espère que c'est compréhensible et j'attend vos questions. Dans les jours à venir nous établirons un plan d'actions.
Sat, 2 Jun 2001 22:12:30 +0200
Frederic legens
Bonjour Daniel,
C'est vraiment étrange, la plupart des botanistes se plaignent car il y a de moins en moins de chercheurs dans ce domaine, de moins en moins de temps consacré à cette discipline en université , de moins en moins d'étudiants, de moins en moins de jeunes amateurs. Mais d'un autre coté, ils ne souhaite pas dépoussiérer l'image de la botanique, je parle de celle du vieux bonhomme errant parmi des piles de planches d'herbiers, avec ces plantes fanées aux couleurs délavées. Attention je n'ai rien contre les herbiers et je sais que cette image est fausse, mais c'est quand même l'image que s'en fait le grand public, c'est dommage car ce n'est vraiment pas porteur.
Tela-botanica a pu déjà il me semble redynamiser un certain nombre de botanistes. A l'intérieur de Tela-botanica j'espère bien que le projet eFlore puisse rendre dynamique la notion de flores. En effet quel est le problème principale d'une flore : c'est qu'elle est figée. En effet : · les changements nomenclaturaux, les erreurs sont rarement corrigées, · les flores nationales ne sont que rarement déclinées au niveau de la région, au niveau du département. · elles ne sont pas mises en lignes, sur CD-ROM, en base de données, utilisables sur un PDA.
Daniel tu vas me dire que je n'ai pas répondu à ta question : « le projet eflore peut-il concrètement aider à la réalisation d'UNE flore ?"
Si lorsque l'on parle d'UNE flore on considère que l'on va avoir une flore papier dont les erreurs ne seront jamais corrigées dans les rééditions, que les changements nomenclaturaux ne seront jamais répercutés, je pense que le projet eFlore n'apportera que peu de chose : un suivi facile de l'avancement, une consultation immédiate des parties déjà faites, un travail collectif plus facile à condition que les auteurs ne soient pas technophobes.
Par contre si l'on souhaite que les changements nomemclaturaux soient immédiatement pris en compte, que l'on souhaite pouvoir disposer de cette flore sur papier, sur son ordinateur, sur internet, sur PDA alors oui le projet eFlore apportera concrètement de l'aide car sa force est de reposer sur la technologie XML. XML permet à la fois de structurer l'information et également de la rendre relativement facilement malléable donc déclinable et personnalisable sous différentes formes. Ce n'est pas un hasard que XML puisse permettre cela car il résulte de la simplification du le langage SGML qui est couramment utilisé pour la rédaction de document très complexes : comme le mode d'emploie d'un mirage, d'une centrale nucléaire. Je ne suis pas un expert sur les logiciels de publications, mais de plus en plus peuvent utiliser ce format par exemple FrameMaker. Cela peut donc faciliter la mise en page donc la publication.
Il sera également facile d'en obtenir une déclinaison partielle de la flore, pour sa région, pour son département, pour un edition particulière.
Bref le projet eFlore permettra surtout d'obtenir SA flore personnelle. Cela me semble très important, cela pourrait permettre aussi bien à une association linnéenne ou de protection de la nature, ou à une entité territoriale, à une société faisant des études d'impacts, à un instituteur, de disposer de la flore convenant à ses besoins (en formation, en communication, en information).
Voilà pour la partie exploitation des données, maintenant il existe la partie concernant l'écriture des données. Pour cette partie les avantages me semblent moins importants, ils permettront principalement de pouvoir amalgamer des clefs, des descriptions, des dessins, de photos d'auteurs différents en temps réels et sans demander un grand travail de synthèse.
Voilà pour ma réponse j'ai pas l'impression d'avoir apporté d'éléments nouveaux. L'utilisation XML me semble quelque chose de très important maintenant ce n'est pas une solution miracle qui résoudrait tous les problèmes : une mauvaise clef de détermination sera toujours une mauvaise clef une fois structurée en XML.
Par contre je peux te proposer deux éléments concrets pour illustrer mes propos : Un livre électronique au format MicrosoftReader contenant une partie de la flore de Coste (monocotylédones (sans les poacées)) avec les clefs les descriptions et les illustrations le tout relié par hypertexte. Ce livre est lisible sur les derniers PocketPC ou sur tout PC équipé du logiciel MicorsoftReader. Un document pdf contenant la même partie de la flore de Coste mais sans les illustrations.
Ces deux fichiers ont été obtenus par les étapes suivantes : Base de données >> XML >>transformation en HTML par XSL >> Fichier Microfost Reader. Base de données >> XML >> transformation en LATEX par XSL >> Fichier PDF
On fera de mĂŞme avec le projet eFlore.
J'ai pas d'autre arguments à l'esprit, mais si tu peux me décrire les profils des personnes à convaincre, je pourrais peut-être compléter cette réponse.
Cordialement.
Daniel MATHIEU
Sun, 12 Aug 2001 20:45:06 +0200
Bonjour,
Je rejoins l'argumentaire de Frédéric en complétant les points suivants :
Des logiciels existent, et pour faire des choses multiples. Au niveau de Tela, ce que nous souhaitons, c'est développer ou utiliser des produits existants, mais dans le cadre de projets bien définis. Parmi ces projets citons :
Il faut faut pour cela une structure pérenne (l'Association Tela Botanica) et "professionnelle" (les permanents de Tela Botanica), capable de structurer et d'organiser des projets et de coordonner le travail des uns et des autres. Le piège à éviter est celui de la dispersion, très facile avec Internet ou chacun peut "faire son truc dans son coin" et le montrer à tous, mais sans soucis d'intégration avec le travail des autres.
Il faut aussi cultiver les collaborations, et lorsqu'une idée ou un produit nouveau et intéressant émerge, ne pas hésiter à collaborer avec les initiateurs.
Le projet eflore entre dans cette stratégie de maîtrise d'outils au service de projets plus globaux et en collaboration avec ce qui existe de mieux.
C'est de tous ces points que nous discuterons aux journées du 29 et 30, septembre prochains à Montpellier.
1.3. Outils
Sun, 11 Feb 2001 21:19:20 +0100
Frédéric legens
Je vous rappelle que le projet comporte principalement les parties suivantes :
Pour les personnes qui ne sont pas familières au XML vous pouvez trouver une introduction à l'emplacement suivant http://www.citeweb.net/apetitje/xml/ ou bien http://www.chez.com/xml/initiation/index.htm .
De mĂŞme pour PHP et mySQL a l'emplacement suivant : http://www.phpinfo.net/
1.4. DĂ©coupage
Wed, 21 Feb 2001 23:05:11 +0100
Frédéric legens
Comme je l'ai écrit dans un de mes précédents mails le projet consiste essentiellement à définir la structure des informations que l'on va associer à des taxons. Je propose donc qu'on commence à travailler sur la partie qui concerne le stockage des taxons et la structure à adopter en fonction de l' utilisation que l'on pense en faire, cette partie étant réellement la pierre angulaire du système. Pour cette partie nous avons la grande chance de ne pas partir de zéro grâce à l'ISFF (merci benoît) autant du point de vue du contenu que du contenant. Cependant on ne peut pas utiliser directement ISFF, en effet sa structure est bien adaptée à un index synonymique, mais pas forcément à nos besoins. Je pense notamment au fait qu'elle n'abrite il me semble que des taxons égaux ou inférieurs à l'espèce, de plus il n'y a pas réellement de notion de classification, notion qui me semble essentielle pour notre projet. Je vous propose donc dans un premier temps de lire le descriptif technique du travail de conversion qu'a rédiger Benoît Bock afin de se rendre compte de la structure de l'ISFF ainsi que des informations qui s'y trouvent. Vous pouvez trouver ce document à l'emplacement suivant : www.tela-botanica.net/projets/bdnff/bilan-bdnff.pdf Dans un second temps nous essayerons de définir les fonctionnalités que l'on souhaite avoir pour la manipulations de ces taxons (Phase 1B) Puis nous définirons la structure à adopter pour stocker les informations nécessaires à ces fonctionnalités ainsi que les premières fiches XML destinées à véhiculer l'information en dehors de la base de données. (Phase 1C)
Sun, 25 Feb 2001 12:09:42 +0100
Frédéric legens
Merci pour vos exemples de données à mettre en place dans eFlore, ils vont me permettre de présenter le phasage du projet.
Le premier groupe de données concerne en quelque sorte l'identité du taxon :
C'est le but de la phase 1, de définir les structures et les fiches XML associées à ces données.
Le deuxième groupe concerne la description d'un taxon. On se limitera certainement à définir le format d'une fiche XML permettant de structurer la description faite en français du taxon. Ce sera l'objet d'une phase spécifique.
Le troisième groupe concerne les clefs de détermination. On procédera certainement de la même façon que pour la description d'un taxon. Ce sera l' objet d'une phase spécifique.
Le quatrième groupe concerne les caractéristiques d'un taxon. Ces caractéristiques seront exprimées de façon à pourvoir facilement faire des requêtes dessus. Ce sera l'objet d'une phase spécifique.
Exemple de données :
1.5. ISFF/BDNFF
Thu, 01 Mar 2001 15:56:48 +0100
Benoit BOCK
subsp. = sous-espèce
= sous-espèce mais ce rang est non explicitement mentionné dans la descripion d'origine n-subsp.= nothosubsp. = sous-espèce hybride idem pour var. proles= rang taxonomique entre sous-espèce et variété plus usité aujourd'hui fa. = forme cv. et convar.: 2 types de cultivars (revoir discussion sur le sujet sur tela) BB
Fri, 02 Mar 2001 11:58:17 +0100
Benoit BOCK
Definition basionyme :
C'est le premier nom donné à une plante. Généralement, les autres noms données ensuite conservent l'épithète spécifique mais par nécessairement au même rang.
1.6. Attributs
Mon, 26 Feb 2001 16:56:52 EST
APIMEDIA
D'une manière générale, il semble très difficile d'intégrer la dimension géographique dans une base de données botanique, sauf à rendre la taille de la base démesurée.
Pourtant ces données sont intéressantes : stades phénologiques en fonction des lieux, statut à différents endroits, croisement des répartitions de différents taxons, indication de présence à différentes échelles, etc.
Quelqu'un a-t-il des idées sur la gestion de ces données géographiques ? Y-a-t-il un spécialiste SIG (systèmes d'informations géographiques) dans le groupe ?
Sat, 03 Mar 2001 22:25:39 +0100
Benoit BOCK
Toujours afin de rendre échangeables les données entre les différentes bases, il me semble nécessaire de se mettre d'accord sur le contenu des rubriques.
Pour la répartition des taxons, rubrique que j'ai appelée CHOROLOGIE, on peut ainsi utiliser :
Pour les pays de répartition, les codes utilisés par Flora Europaea semblent satisfaisants:
Ga, Co, Hs, It, ...
Ils peuvent couplés comme je l'ai fait dans l'ISFF à partir des information sde Kerguelen par A (adventice) N (Naturalisé) D(Disparu) E(à Exclure) I(Présence Incertaine) pour donner GaA ou GaN ou GaI ou GaE, ...
Il est ensuite facile de lancer une requĂŞte informatique pour obtenir toutes les plantes de France (Ga) en excluant par exemple les Adventices (- GaA)...
Sun, 4 Mar 2001 09:44:32 +0100
"Roger Cruon"
Aucune classification chorologique n'est satisfaisante, mais celle de Pignatti (Flora d'Italia, 1982) est intéressante. Elle privilégie évidemment les origines méditerranéennes, mais rien n'empêche de la compléter pour d'autres régions. La liste de Benoît mélange deux aspects: la répartition "naturelle" du taxon, et le fait qu'il soit introduit en France. Il n'est pas facile de séparer complètement ces deux aspects, à cause des naturalisations anciennes, qui font que certains taxons sont cosmopolites ou subcosmopolites (voir ci-après 94 et 95). Mais il vaut mieux avoir un code séparé pour la xénophytie (voir mon message du 24/02). Voici la liste de Pignatti, un peu modifiée:
Il faudrait peut-être la compléter pour les espèces américaines.
P5 Wed, 7 Mar 2001 21:53:09 +0100 P5 Jean-François Léger
On peut éventuellement compléter la liste de Benoît en s'aidant de celle que j'utilise, +/- inspirée de Pignatti:
1.7. Delta
Sat, 24 Feb 2001 15:30:37 +0100
Jean-François Léger
Que pensez-vous de Delta Access? BDD Delta au standard Access. http://www.bgbm.fu-berlin.de/projects/DeltaAccess/
"Denis ZIEGLER"
Friday, February 23, 2001 10:46 PM
Puisque nous en sommes à la phase de reflexion préliminaire, je me permets d'intervenir pour indiquer qu'il existe un format de fichier utilisé au niveau international, spécialement adapté à la description taxonomique, en vue du traitement informatique. Il s'agit du format DELTA (DEscription Language for TAxonomy) recommandé comme standard pour les échanges de données taxonomiques. Son utilisation dépasse le cadre de la botanique ; il a d'ailleurs été développé par le département d'entomologie du CSIRO à Canberra en Australie. Le format DELTA comprend essentiellement deux fichiers : un fichier CHARS décrivant les caractères et leurs modalités, et un fichier ITEMS décrivant les taxons c'est à dire indiquant les modalités des caractères pour chaque taxon.
A titre d'illustration (simplifiée), voici un extrait de ces fichiers pour un jeu de données sur le genre Viola :
ITEM DESCRIPTIONS
Un certain nombre de logiciels permettent d'exploiter ces fichiers, en vue de générer des clés de détermination, de réaliser des identifications interactives, etc... Le logiciel Intkey par exemple, développé par la même équipe, est très performant pour l'identification (y compris avec utilisation d'illustrations). Malheureusement, il s'agit d'un logiciel propriétaire et compilé sous Windows. Dans la même catégorie, le logiciel Navikey assure sensiblement les mêmes fonctionnalités sous forme d'une applet Java. C'est un logiciel libre. Personnellement, je collabore au projet FreeDelta, qui a pour but de créer des logiciels libres basés sur le format DELTA (une API en C++ est en cours d'écriture permettant d'analyser les fichiers Delta, utilisable par exemple par un programme d'identification).
Je ne sais pas si ce type de standard est utilisable dans le cadre de notre projet. Je pense qu'il n'est pas adapté à la réalisation de bases de données regroupant un grand nombre de taxons pour extraction, consultation, etc... Par contre, il permet de stocker toutes les informations nécessaires pour la description, l'identification, la réalisation de clés pour un genre donné par exemple.
Pour plus d'informations se reporter aux liens suivants :
Wed, 28 Feb 2001 00:35:06 +0100
"Denis ZIEGLER"
Parmi les valeurs "spéciales" que peut prendre un caractère vis-à -vis d'un taxon, on peut distinguer :
Tue, 27 Feb 2001 06:07:25 +0100
Frédéric legens
Nous avons déjà abordé le sujet de DELTA sur la liste Flore-de-France. Ces outils n'ont pas suscité un enthousiasme délirant, c'est le moins que l'on puisse dire (comme le reste d'ailleurs) ! remarque :il me semble que tous les intervenants sont abonnés à tb-eFlore. Pour ma part je trouve ce système intéressant. Je ne vais pas résumer la discussion qu'on a eu mais seulement citer la conclusion donnée par daniel :
« Pour les clefs, il me semble difficile d'avoir une génération automatique pertinente. C'est "à la main" que s'élabore une bonne clé. »
Je pense que cette remarque est Ă©galement valable pour la description des taxons.
Personnellement, il me semble très important que les clefs ainsi que les descriptions soient stockées en français (structurer en XML) dans la base, cela offre beaucoup plus de souplesse. Il me semble donc pas approprié de vouloir réaliser en php ce que font les différents outils du système DELTA. D'autant plus que je partage l'avis de Mr Ziegler sur le fait que les outils delta semblent plus adapté au travail sur un petit nombre de taxons que sur un grand nombre.
Cependant pour alimenter les clefs et les descriptions, il peut coexister différentes façon de faire :
On peut même envisager, s'il est possible de modifier le programme DELTA, que celui-ci demande directement via http au serveur eFlore, les identifiants uniques des taxons, et que celui-ci réalise directement l' export au format XML. Et si l'on veut avoir une intégration encore plus forte, que celui-ci demande également la liste des différentes catégories de caractères, ainsi que les caractères associés aux différents taxons. Pour ce dernier type d'échange il a eu une proposition de format XML DELTA que vous pouvez trouver à l'adresse suivante: http://www.bath.ac.uk/~ccslrd/delta/index.html. La formalisation des différentes catégories de caractères y semble très bien formalisé. Il me semble qu'il faudra s'en inspirer, et éventuellement adopter ce codage. (Mais il est également possible de renvoyer directement les informations dans le format DELTA).
1.8. Eflore et le Mac !
Wed, 28 Feb 2001 07:37:21 +0100
Frédéric legens
L'idée n'est bien entendu pas d'exclure les possesseurs de Mac, mais en effet cela pause un problème car un certain nombre d'outils informatiques que nous allons utiliser n'existent pas actuellement sur Mac OS.
Au niveau de la base de données et des outils permettant de générer des documents XML et de lire ces mêmes documents, nous avons opté pour les outils dont dispose Tela-botanica pour son site internet, ce qui semble logique. De plus ces outils ont l'avantage d'être couramment utilisés sur internet, et sont gratuits ou sont des sharewares (je pense notamment à mySQL sur windows), et sont librement distribuable (ce qui est très appréciable). A noter qu'il peuvent également fonctionner sur MAC à condition d'utiliser comme système d'exploitation LINUX (je sais cela n'est pas vraiment une solution), de plus il y a de grandes chances qu'ils soient adaptés à Mac OS X.
Dans le projet eFlore nous allons utiliser ces outils mais toute personne courageuse peut les remplacer par un autre outil, notamment pour la base de données qui peut être remplacer par oracle ou access par exemple. (PHP est capable de travailler directement avec ces bases de données). Il est également possible d'utiliser FileMaker pro qui peut remplacer à la fois mySQL et PHP, puisqu'il peut faire office de serveur internet. En effet le point majeur de ce projet est de définir des fichiers d'échanges de données en XML, ces fichiers étant des fichiers textes il est relativement facile de les analyser dans le but d'importer les informations dans sa propre base de données. Obtenir du serveur de telabotanica ces fichiers XML est facile puisque l'on passe par le protocole standard d'internet : http. Par exemple pour obtenir le squelette vierge d'une clef de détermination pour le genre Papaver dans mon prototype d'éditeur de clef, je demande url suivante http://flegens.free.fr/GetNewKey.php3?nom=Papaver (Il est possible de tester cela dans n'importe quel navigateur) .L'envoie de données se fait de façon analogue. De plus pour faciliter ces échanges d'informations la majorité des bases de données commerciales comportent dans leur nouvelles versions des outils facilitant l'analyse de fichiers XML (il me semble que c 'est notamment le cas FileMaker pro version 5).
Pour les applications clientes spécifiques à tela-botanica que l'on va être susceptible de développer, il existe plusieurs solutions : 1) développer une version spécifique au MAC, si l'on trouve quelqu'un qui peut le faire. 2) développer les applications en java ce qui permet à ces application de tourner à la fois sur mac, pc, linux . Mais il faut avoir un programmeur java. De plus java est lent sur des machines peu puissantes et est délicat à installer et l'installable est très gros (avec la jvm),donc difficilement chargeable d' internet. On risque donc d'exclure plus de personnes que le nombre de possesseurs de Mac ainsi dépannés. 3) Utiliser un logiciel de base de données façon FileMakerPro et intégrer les outils de manipulations à la base. Par exemple l'éditeur de clefs de benoît (qui en définitive est très proche de mon prototype), du moment qu' il comporte une fonction d'exportation en XML (qui n'est pas plus compliqué à développer que la fonction d'export en HTML).
Bref il y a plein de possibilités, j'espère donc que l'on pourra au moins en développer une pour les possesseurs de Mac.
Cordialement.
1. Phase 1A : Initialisation
1.1. Objectifs
Tue, 13 Feb 2001 23:35:40 +0100
Frédéric legens
Décrire ce projet, n'est pas quelque chose de facile surtout sans faire référence à la technologie à employer. Cependant je vais essayer de le faire.
Prenons comme exemple ISFF. Benoît Bock aurait pu se contenter de mettre à jour le fichier texte fait par Kerguelen, cependant il a choisit de structurer l'information dans une base de donnée. Cette structuration a pour avantage de simplifier le travail à faire, et de rendre facilement utilisable l'information, ce qui n'était pas le cas dans le fichier texte.
C'est justement se que l'on souhaite faire dans le projet eFlore, pour les fonctionnalités dont aurons besoin notamment les projets flore de France et pour les listes départementales.
Ces deux projet ont un point commun. Ils consistent Ă associer de l' information Ă des taxons.
- * Pour les listes départementales, l'information est la présence ou l' absence d'un taxon dans un département..
- * Pour une clef de détermination, c'est un enchaînement de questions partant d'un taxon donné aboutissant aux taxons hiérarchiquement inférieurs au taxon donné.
Une bonne structuration des ces informations permettra lorsqu'une correction est apportée à un taxon, de répercuter automatiquement cette modification aux listes départementales et aux clefs. Cependant il existe des avantages bien plus importants :
- * se concentrer sur une bonne structuration permet par exemple de remarquer que la différence entre une liste départementale, régionale, et entre une cartographie réside certainement dans le maillage qui à première vue est respectivement un département, une région, des carrés d'une certaine superficie. Rendre la structuration identique permettra alors de faire facilement des opérations d'unions, exclusions, etc..
- * avoir une structuration homogène d'informations de nature différentes. Par exemple lorsque l'on aura dans le système un dérivé de l'ISSFF pour les taxons, des clefs nationales associées à ces taxons, ainsi que des listes départementales, il sera alors possible d'obtenir facilement une déclinaison régionale des clefs par élagage automatique (suppression des questions aboutissant aux taxons absents du département), etc.
Ce projet, outre l'Ă©tablissement de ces structures d'informations, aura Ă©galement pour but de mettre en place les outils informatiques permettant l' exploitation de ces structures.
Il débouchera sur la création d'une base de données, hébergée sur le site de tela-botanica pour stocker ces informations. Ces informations seront accessibles soit par un navigateur sous la forme de page HTML (sur Mac ou sur PC), soit par des applications clientes (utilisant comme intermédiaire avec la base de donnée des documents XML) pour les données complexes (voir pour exemple mon prototype d'éditeur de clefs). Les fichiers HTML et XML seront générés par PHP.
Voila j'espère que c'est compréhensible et j'attend vos questions. Dans les jours à venir nous établirons un plan d'actions.
1.2. eflore et flore
Sat, 2 Jun 2001 22:12:30 +0200
Frederic legens
Bonjour Daniel,
C'est vraiment étrange, la plupart des botanistes se plaignent car il y a de moins en moins de chercheurs dans ce domaine, de moins en moins de temps consacré à cette discipline en université , de moins en moins d'étudiants, de moins en moins de jeunes amateurs. Mais d'un autre coté, ils ne souhaite pas dépoussiérer l'image de la botanique, je parle de celle du vieux bonhomme errant parmi des piles de planches d'herbiers, avec ces plantes fanées aux couleurs délavées. Attention je n'ai rien contre les herbiers et je sais que cette image est fausse, mais c'est quand même l'image que s'en fait le grand public, c'est dommage car ce n'est vraiment pas porteur.
Tela-botanica a pu déjà il me semble redynamiser un certain nombre de botanistes. A l'intérieur de Tela-botanica j'espère bien que le projet eFlore puisse rendre dynamique la notion de flores. En effet quel est le problème principale d'une flore : c'est qu'elle est figée. En effet : · les changements nomenclaturaux, les erreurs sont rarement corrigées, · les flores nationales ne sont que rarement déclinées au niveau de la région, au niveau du département. · elles ne sont pas mises en lignes, sur CD-ROM, en base de données, utilisables sur un PDA.
Daniel tu vas me dire que je n'ai pas répondu à ta question : « le projet eflore peut-il concrètement aider à la réalisation d'UNE flore ?"
Si lorsque l'on parle d'UNE flore on considère que l'on va avoir une flore papier dont les erreurs ne seront jamais corrigées dans les rééditions, que les changements nomenclaturaux ne seront jamais répercutés, je pense que le projet eFlore n'apportera que peu de chose : un suivi facile de l'avancement, une consultation immédiate des parties déjà faites, un travail collectif plus facile à condition que les auteurs ne soient pas technophobes.
Par contre si l'on souhaite que les changements nomemclaturaux soient immédiatement pris en compte, que l'on souhaite pouvoir disposer de cette flore sur papier, sur son ordinateur, sur internet, sur PDA alors oui le projet eFlore apportera concrètement de l'aide car sa force est de reposer sur la technologie XML. XML permet à la fois de structurer l'information et également de la rendre relativement facilement malléable donc déclinable et personnalisable sous différentes formes. Ce n'est pas un hasard que XML puisse permettre cela car il résulte de la simplification du le langage SGML qui est couramment utilisé pour la rédaction de document très complexes : comme le mode d'emploie d'un mirage, d'une centrale nucléaire. Je ne suis pas un expert sur les logiciels de publications, mais de plus en plus peuvent utiliser ce format par exemple FrameMaker. Cela peut donc faciliter la mise en page donc la publication.
Il sera également facile d'en obtenir une déclinaison partielle de la flore, pour sa région, pour son département, pour un edition particulière.
Bref le projet eFlore permettra surtout d'obtenir SA flore personnelle. Cela me semble très important, cela pourrait permettre aussi bien à une association linnéenne ou de protection de la nature, ou à une entité territoriale, à une société faisant des études d'impacts, à un instituteur, de disposer de la flore convenant à ses besoins (en formation, en communication, en information).
Voilà pour la partie exploitation des données, maintenant il existe la partie concernant l'écriture des données. Pour cette partie les avantages me semblent moins importants, ils permettront principalement de pouvoir amalgamer des clefs, des descriptions, des dessins, de photos d'auteurs différents en temps réels et sans demander un grand travail de synthèse.
Voilà pour ma réponse j'ai pas l'impression d'avoir apporté d'éléments nouveaux. L'utilisation XML me semble quelque chose de très important maintenant ce n'est pas une solution miracle qui résoudrait tous les problèmes : une mauvaise clef de détermination sera toujours une mauvaise clef une fois structurée en XML.
Par contre je peux te proposer deux éléments concrets pour illustrer mes propos : Un livre électronique au format MicrosoftReader contenant une partie de la flore de Coste (monocotylédones (sans les poacées)) avec les clefs les descriptions et les illustrations le tout relié par hypertexte. Ce livre est lisible sur les derniers PocketPC ou sur tout PC équipé du logiciel MicorsoftReader. Un document pdf contenant la même partie de la flore de Coste mais sans les illustrations.
Ces deux fichiers ont été obtenus par les étapes suivantes : Base de données >> XML >>transformation en HTML par XSL >> Fichier Microfost Reader. Base de données >> XML >> transformation en LATEX par XSL >> Fichier PDF
On fera de mĂŞme avec le projet eFlore.
J'ai pas d'autre arguments à l'esprit, mais si tu peux me décrire les profils des personnes à convaincre, je pourrais peut-être compléter cette réponse.
Cordialement.
Daniel MATHIEU
Sun, 12 Aug 2001 20:45:06 +0200
Bonjour,
Je rejoins l'argumentaire de Frédéric en complétant les points suivants :
Des logiciels existent, et pour faire des choses multiples. Au niveau de Tela, ce que nous souhaitons, c'est développer ou utiliser des produits existants, mais dans le cadre de projets bien définis. Parmi ces projets citons :
- * la préparation et l'accompagnement du développement de flores (Flore méditerranéenne, flore de France)
- * la publication de l'ISFF
- * la mise à disposition de données en ligne fiables et validées : chorologie, iconographie, diagnoses...
- * la production d'un cédérom intégrant ces données et permettant de faire des relevés de terrain et d'échanger des données.
Il faut faut pour cela une structure pérenne (l'Association Tela Botanica) et "professionnelle" (les permanents de Tela Botanica), capable de structurer et d'organiser des projets et de coordonner le travail des uns et des autres. Le piège à éviter est celui de la dispersion, très facile avec Internet ou chacun peut "faire son truc dans son coin" et le montrer à tous, mais sans soucis d'intégration avec le travail des autres.
Il faut aussi cultiver les collaborations, et lorsqu'une idée ou un produit nouveau et intéressant émerge, ne pas hésiter à collaborer avec les initiateurs.
Le projet eflore entre dans cette stratégie de maîtrise d'outils au service de projets plus globaux et en collaboration avec ce qui existe de mieux.
C'est de tous ces points que nous discuterons aux journées du 29 et 30, septembre prochains à Montpellier.
1.3. Outils
Sun, 11 Feb 2001 21:19:20 +0100
Frédéric legens
Je vous rappelle que le projet comporte principalement les parties suivantes :
- * La partie fonctionnelle,
- * La partie technique qui se décompose elle même en :
- o XML pour l'échange de données
- o PHP pour la création des fichiers XML, et l'intégration de l'information dans la base de données.
- o mySQL pour la base de données.
- o La réalisation d'applications clientes pour la manipulation du XML.
Pour les personnes qui ne sont pas familières au XML vous pouvez trouver une introduction à l'emplacement suivant http://www.citeweb.net/apetitje/xml/ ou bien http://www.chez.com/xml/initiation/index.htm .
De mĂŞme pour PHP et mySQL a l'emplacement suivant : http://www.phpinfo.net/
1.4. DĂ©coupage
Wed, 21 Feb 2001 23:05:11 +0100
Frédéric legens
Comme je l'ai écrit dans un de mes précédents mails le projet consiste essentiellement à définir la structure des informations que l'on va associer à des taxons. Je propose donc qu'on commence à travailler sur la partie qui concerne le stockage des taxons et la structure à adopter en fonction de l' utilisation que l'on pense en faire, cette partie étant réellement la pierre angulaire du système. Pour cette partie nous avons la grande chance de ne pas partir de zéro grâce à l'ISFF (merci benoît) autant du point de vue du contenu que du contenant. Cependant on ne peut pas utiliser directement ISFF, en effet sa structure est bien adaptée à un index synonymique, mais pas forcément à nos besoins. Je pense notamment au fait qu'elle n'abrite il me semble que des taxons égaux ou inférieurs à l'espèce, de plus il n'y a pas réellement de notion de classification, notion qui me semble essentielle pour notre projet. Je vous propose donc dans un premier temps de lire le descriptif technique du travail de conversion qu'a rédiger Benoît Bock afin de se rendre compte de la structure de l'ISFF ainsi que des informations qui s'y trouvent. Vous pouvez trouver ce document à l'emplacement suivant : www.tela-botanica.net/projets/bdnff/bilan-bdnff.pdf Dans un second temps nous essayerons de définir les fonctionnalités que l'on souhaite avoir pour la manipulations de ces taxons (Phase 1B) Puis nous définirons la structure à adopter pour stocker les informations nécessaires à ces fonctionnalités ainsi que les premières fiches XML destinées à véhiculer l'information en dehors de la base de données. (Phase 1C)
Sun, 25 Feb 2001 12:09:42 +0100
Frédéric legens
Merci pour vos exemples de données à mettre en place dans eFlore, ils vont me permettre de présenter le phasage du projet.
Le premier groupe de données concerne en quelque sorte l'identité du taxon :
- * Nom scientifique (cf ISSF et travaux de BB)
- * Noms français
- * Noms Ă©trangers
- * Synonymes.
- * Taxons hiérarchiquement supérieurs au taxon.
C'est le but de la phase 1, de définir les structures et les fiches XML associées à ces données.
Le deuxième groupe concerne la description d'un taxon. On se limitera certainement à définir le format d'une fiche XML permettant de structurer la description faite en français du taxon. Ce sera l'objet d'une phase spécifique.
Le troisième groupe concerne les clefs de détermination. On procédera certainement de la même façon que pour la description d'un taxon. Ce sera l' objet d'une phase spécifique.
Le quatrième groupe concerne les caractéristiques d'un taxon. Ces caractéristiques seront exprimées de façon à pourvoir facilement faire des requêtes dessus. Ce sera l'objet d'une phase spécifique.
Exemple de données :
- * Origine géographique
- * Aire de répartition
- * Forme végétale (Phanérophyte, etc.)
- * Type végétal (arbre, arbuste, arbrisseau, etc.) les valeurs dépendent de la forme végétale
- * pérennité (sempervirente, vivace, annuelle, etc.)
- * besoin en lumière (5 niveaux)
- * besoin en eau (7 niveaux)
- * besoin en azote (5 niveaux)
- * préférences calcaire/acidité (6 niveaux)
- * granulométrie du substrat (6 niveaux)
- * Statut de protection (nationale, régionale avec liste des régions, départementale
- * Statut de présence en France
- * Synanthropie ou Xénophytie: Planté, Échappé de jardin, Éphémère, Adventice, Subspontané, Naturalisé
1.5. ISFF/BDNFF
Thu, 01 Mar 2001 15:56:48 +0100
Benoit BOCK
subsp. = sous-espèce
= sous-espèce mais ce rang est non explicitement mentionné dans la descripion d'origine n-subsp.= nothosubsp. = sous-espèce hybride idem pour var. proles= rang taxonomique entre sous-espèce et variété plus usité aujourd'hui fa. = forme cv. et convar.: 2 types de cultivars (revoir discussion sur le sujet sur tela) BB
Fri, 02 Mar 2001 11:58:17 +0100
Benoit BOCK
Definition basionyme :
C'est le premier nom donné à une plante. Généralement, les autres noms données ensuite conservent l'épithète spécifique mais par nécessairement au même rang.
1.6. Attributs
Mon, 26 Feb 2001 16:56:52 EST
APIMEDIA
D'une manière générale, il semble très difficile d'intégrer la dimension géographique dans une base de données botanique, sauf à rendre la taille de la base démesurée.
Pourtant ces données sont intéressantes : stades phénologiques en fonction des lieux, statut à différents endroits, croisement des répartitions de différents taxons, indication de présence à différentes échelles, etc.
Quelqu'un a-t-il des idées sur la gestion de ces données géographiques ? Y-a-t-il un spécialiste SIG (systèmes d'informations géographiques) dans le groupe ?
Sat, 03 Mar 2001 22:25:39 +0100
Benoit BOCK
Toujours afin de rendre échangeables les données entre les différentes bases, il me semble nécessaire de se mettre d'accord sur le contenu des rubriques.
Pour la répartition des taxons, rubrique que j'ai appelée CHOROLOGIE, on peut ainsi utiliser :
- * Artico Alpin
- * Atlantique
- * Atlantique méridional
- * Atlantique occidental
- * Atlantique oriental
- * Atlantique septentrional
- * Atlantique tempéré
- * Boréal
- * Boréo Altantique
- * Circum Boréal
- * Cosmopolite
- * Cultivé
- * Endémique alpin
- * Endémique corse
- * Endémique pyrénéo-cantabrique
- * Endémique français
- * Micro Endémique
- * Eurasiatique
- * Eurasiatique méridional
- * Eurasiatique occidental
- * Eurasiatique oriental
- * Eurasiatique septentrional
- * Eurasiatique tempéré
- * Européen
- * Européen central
- * Européen méridional
- * Européen occidental
- * Européen oriental
- * Européen septentrional
- * Européen tempéré
- * Holarctique
- * Holarctique méridional
- * Holarctique septentrional
- * Holarctique tempéré
- * Introduit
- * Introduit (?)
- * Introduit (Afrique Centrale)
- * Introduit (Afrique de l'Est)
- * Introduit (Afrique de l'Ouest)
- * Introduit (Afrique du Nord)
- * Introduit (Afrique du Sud)
- * Introduit (Afrique)
- * Introduit (Amérique du Nord occidentale)
- * Introduit (Amérique du Nord orientale)
- * Introduit (Amérique du Nord septentrionale)
- * Introduit (Amérique du Nord)
- * Introduit (Amérique du Sud)
- * Introduit (Amérique tropicale)
- * Introduit (Amérique)
- * Introduit (Antartique)
- * Introduit (Antilles)
- * Introduit (Asie centrale)
- * Introduit (Asie méridionale)
- * Introduit (Asie occidentale)
- * Introduit (Asie orientale)
- * Introduit (Asie septentrionale)
- * Introduit (Asie)
- * Introduit (Australie)
- * Introduit (Balkans)
- * Introduit (Brésil)
- * Introduit (Canaries)
- * Introduit (Caucase)
- * Introduit (Chine)
- * Introduit (Himalaya)
- * Introduit (Japon)
- * Introduit (Maghreb)
- * Introduit (Mexique)
- * Introduit (Tibet)
- * Méditerranéen
- * Méditerranéen Atlantique
- * Méditerranéen méridional
- * Méditerranéen occidental
- * Méditerranéen oriental
- * Méditerranéen septentrional
- * Méditerranéen tempéré
- * Naturalisé
- * Orophyte
- * Sub Atlantique
- * Sub Méditerranéen liste à compléter
Pour les pays de répartition, les codes utilisés par Flora Europaea semblent satisfaisants:
Ga, Co, Hs, It, ...
Ils peuvent couplés comme je l'ai fait dans l'ISFF à partir des information sde Kerguelen par A (adventice) N (Naturalisé) D(Disparu) E(à Exclure) I(Présence Incertaine) pour donner GaA ou GaN ou GaI ou GaE, ...
Il est ensuite facile de lancer une requĂŞte informatique pour obtenir toutes les plantes de France (Ga) en excluant par exemple les Adventices (- GaA)...
Sun, 4 Mar 2001 09:44:32 +0100
"Roger Cruon"
Aucune classification chorologique n'est satisfaisante, mais celle de Pignatti (Flora d'Italia, 1982) est intéressante. Elle privilégie évidemment les origines méditerranéennes, mais rien n'empêche de la compléter pour d'autres régions. La liste de Benoît mélange deux aspects: la répartition "naturelle" du taxon, et le fait qu'il soit introduit en France. Il n'est pas facile de séparer complètement ces deux aspects, à cause des naturalisations anciennes, qui font que certains taxons sont cosmopolites ou subcosmopolites (voir ci-après 94 et 95). Mais il vaut mieux avoir un code séparé pour la xénophytie (voir mon message du 24/02). Voici la liste de Pignatti, un peu modifiée:
- * 11 Endémique
- * 12 Subendémique
- * 2 Sténoméditerranéen: côtes méditerranéennes, dans l'aire de l'olivier
- o 21 Sténomédit. s.l.: de Gibraltar à la mer
- o 22 Sténomédit. septentrional: Côtes méridionales de l'Europe, de l'Espagne à la Grèce
- o 23 Sténomédit. oriental: bassin méditerranéen oriental, des Balkans à la Turquie et à l'Egypte
- o 24 Sténomédit. méridional: côtes septentrionales de l'Afrique, du Maroc à l'Egypte
- o 25 Sténomédit. occidental: bassin méditerranéen occidental, de la Ligurie à l'Espagne et à l'Algérie
- o 26 Sténomédit. nord-occidental: de la Ligurie à l'Espagne
- o 27 Sténomédit. sud-occidental: du Maroc à la Tunisie et à la Sicile
- o 28 Sténomédit. nord-oriental: des Balkans à la Turquie
- * 3 Euryméditerranéen: bassin méditerranéen, dans l'aire de la vigne
- o 31 Eurymédit. s.l.: de Gibraltar à la mer Noire
- o 32 Eurymédit. septentrional: sud de l'Europe, de l'Espagne à la Grèce
- o 33 Eurymédit. oriental: Méditerranée orientale, des Balkans à la Turquie et à l'Egypte
- o 34 Eurymédit. méridional: nord de l'Afrique, du Maroc à l'Egypte
- o 35 EurymĂ©dit. occidental: MĂ©diterranĂ©e occidentale, de la Ligurie Ă
- o l'Espagne et à l'Algérie
- o 36 Eurymédit. nord-occidental: de la Ligurie à l'Espagne
- o 37 Eurymédit. sud-occidental: du Maroc à la Tunisie et à la Sicile
- o 38 Eurymédit. nord-oriental: des Balkans à la Turquie
- * 41 Méditerranéo-montagnard s.l.: montagnes du bassin méditerranéen
- * 5 Eurasiatique: continent eurasien
- o 51 Paléotempéré: Eurasiatique s.l., pouvant déborder sur l'Afrique du Nord
- o 52 Eurasiatique s.s.: de l'Europe au Japon
- o 53 Sud-européen - sud-sibérien: zones chaudes d'Europe et secteurs arides de la Sibérie méridionale
- o 54 Européo-caucasien: Europe et Caucase
- o 55 Européen: Europe
- o 56 Centreuropéen: Europe tempérée, de la France à l'Ukraine
- o 57 Nord-européen: Europe septentrionale
- o 58 Sud-est européen: région carpatico-danubienne
- o 59 Sud-européen: Europe méridionale
- * 6 Atlantique: cĂ´tes atlantiques de l'Europe
- o 61 Ouest-européen: Europe occidentale, de la Scandinavie à la péninsule Ibérique
- o 62 Subatlantique: zones à climat subocéanique
- o 63 Sténoméditerranéo-atlantique: côtes atlantiques et méditerrranéennes
- o 64 Amphi-atlantique: côtes de l'Europe et de l'Amérique du Nord
- o 65 Euryméditerranéo-atlantique: côtes atlantiques et méditerrranéennes
- o s.l.
- * 7 Orophyte sud-européen: montagnes de l'Europe méridionale
- o 71 Orophyte sud-européen s.l.: de la péninsule Ibérique au Balkans, et
- o Ă©ventuellement le Caucase et l'Anatolie
- o 72 Orophyte sud-est-européen: aire centrée sur les Balkans (manquant aux Pyrénées)
- o 73 Orophyte sud-ouest-européen: péninsule Ibérique, massifs centraux (rare ou manquant aux Balkans)
- o 74 Endémique alpin: chaîne des Alpes, quelquefois débordant au nord et à l'ouest
- o 75 Orophyte européen: montagnes d'Europe, parfois centré sur les chaînes méridionales
- o 76 Orophyte centreuropéen: Alpes, Jura, Carpates et même chaînes plus
- o méridionales
- * 8 Boréal: zones boréales
- o 81 Circumboréal: zones froides ou tempérées-froides d'Europe, d'Asie et d'Amérique du Nord
- o 82 Eurosibérien: zones froides ou tempérées-froides d'Eurasie
- o 83 Circumarctico-alpin: zones arctiques d'Eurasie et d'Amérique du Nord, et hautes montagnes
- o 84 Arctico-alpin eurasiatique: zones arctiques d'Eurasie et hautes
- o montagnes de ce continent
- o 85 Arctico-alpin européen: Europe arctique, Alpes et autres montagnes
- o sud-européennes
- o 86 Arctico-alpin euro-américain: Scandinavie, Amérique du Nord et hautes montagnes des zones tempérées
- * 9 RĂ©partition vaste
- o 91 Pantropical: zones tropicales d'Eurasie, d'Afrique et d'Amérique
- o 92 Saharo-sindien: zones désertiques, de l'Afrique septentrionale à l'Inde
- o 93 Méditerranéo-touranien: zones désertiques et subdésertiques, du bassin méditerranéen à l'Asie centrale
- o 94 Subcosmopolite: la plupart des continents et des zones climatiques
- o 95 Cosmopolite: tous les continents et les zones climatiques
- o 96 Paléotropical: zones tropicales d'Afrique et d'Asie
- o 97 Subtropical: zones tropicales et tempérées-chaudes
Il faudrait peut-être la compléter pour les espèces américaines.
P5 Wed, 7 Mar 2001 21:53:09 +0100 P5 Jean-François Léger
On peut éventuellement compléter la liste de Benoît en s'aidant de celle que j'utilise, +/- inspirée de Pignatti:
- * présumé disparu 0
- * microendémique 1
- * endémique d'un ou deux départements Présent dans seulement un ou deux départements 2
- * endémique de quelques départements Présent dans seulement 3 à 5 départements 3
- * endémique corse De Corse 4
- * endémique cyrno-sarde De Corse et de Sardaigne 5
- * endémique des Alpes occidentales 6
- * endémique Alpes SW & Apennins Endémique des Alpes du sud-ouest et des Apennins 7
- * endémique liguro-provençal 8
- * endémique français 9
- * Sténoméditérranéen: sténoméditerranéen De Gibraltar à la Mer Noire 20
- * sténoméditerranéen septentrional
- o De l'Espagne à la Grèce 21
- o sténoméditerranéen nord-oriental 22
- o sténoméditerranéen oriental Des Balkans à la Turquie et à l'Egypte 23
- o sténoméditerranéen méridional Des côtes d'Afrique du Nord 24
- o sténoméditerranéen sudoccidental Du Maroc à la Tunisie et à la Sardaigne, voire la Corse 25
- o sténoméditerranéen occidental De la Ligurie à l'Espagne et à l'Algérie 26
- o sténoméditerranéen nordoccidental De la Ligurie à l'Espagne 27
- o sténoméditerranéen franco-ibérique Des côtes méditerranéennes françaises et ibériques 28
- o sténoméditerranéen occidental - atlantique De la Ligurie à l'Espagne, à l'Algérie et à la Bretagne 29
- * Euryméditerranéen: euryméditerranéen
- o De Gibraltar Ă la Mer Noire 30
- o euryméditerranéen septentrional De l'Espagne à la Grèce 31
- o euryméditerranéen-pontique Des terres proches de la Méditerranée et de la Mer Noire 32
- o euryméditerranéen-caucasien Des terres proches de la Méditerranée et du Caucase 33
- o euryméditerranéen occidental De la Ligurie à l'Espagne et à l'Algérie 36
- o euryméditerranéen nordoccidental De la Ligurie à l'Espagne 37
- o euryméditerranéen franco-ibérique Des zones ± médit. de France et de la péninsule ibérique 38
- o euryméditerranéen occidental - atlantique De la Ligurie à l'Espagne, à l'Algérie et à la Bretagne 39
- * Méditerranéo-montagnard:
- o méditerranéo-montagnard De Gibraltar à la Mer Noire 40
- o méditerranéo-montagnard septentrional De l'Espagne à la Grèce 41
- o méditerranéo-montagnard oriental 43
- o méditerranéo-montagnard sudoccidental Du Maroc à la Tunisie et à la Sardaigne, voire la Corse 45
- o méditerranéo-montagnard occidental De la Ligurie à l'Espagne et à l'Algérie 46
- o méditerranéo-montagnard nordoccidental De la Ligurie à l'Espagne 47
- o méditerranéo-montagnard franco-ibérique Des montagnes méditerranéennes françaises et ibériques 48
- * Eurasiatique:
- o eurasiatique De l'Europe au Japon 50
- o européo-subpontique 51
- o européo-caucasien 52
- o européen-ouestasiatique 53
- o centroeuropéen-pontique d'Europe centrale et des rives de la Mer Noire 54
- o centroeuropéen-sudsibérien 55
- o centroeuropéen-ouestasiatique 56
- o sudeuropéen-pontique d'Europe du sud et des rives de la Mer Noire 57
- o sudeuropéo-sudsibérien Des zones chaudes d'Europe et arides de Sibérie (steppique) 58
- o sudeuropéen-centroasiatique 59
- o sudeuropéen-sudasiatique 60
- * Orophyte eurasiatique:
- o orophyte eurasiatique Des hautes montagnes d'Europe et d'Asie 70
- o orophyte alpino-asiatique 71
- o orophyte sudeurop.-ouestasiat. 72
- o orophyte européen-ouestasiat. 73
- o orophyte européo-caucasien 74
- o orophyte centroasiatique-méditerranéen 75
- o orophyte euryméditerranéen Des hautes montagnes méditerranéennes et sudeuropéennes 76
- * Européen:
- o européen 80
- o sudesteuropéen 81
- o sudeuropéen 82
- o sudouesteuropéen 83
- o nordeuropéen 84
- o centroeuropéen De la France à l'Ukraine 85
- o centro- et esteuropéen 86
- o centro- et sudeuropéen 87
- o centro- et ouesteuropéen 88
- o centro- et nordeuropéen 89
- * Orophyte européen:
- o orophyte européen 100
- o orophyte sudeuropéen De la péninsule ibérique aux Balkans, voire au Caucase 101
- o orophyte sudesteuropéen 102
- o orophyte sudouesteuropéen 103
- o orophyte centroeuropéen Des Alpes, du Jura et des Carpathes 104
- o orophyte centro- et sudeuropéen 105
- o orophyte franco-espagnol 106
- o orophyte (endémique) pyrénéen De la Chaîne des Pyrénées 107
- o orophyte (endémique) alpin De toutes les Alpes et de leur piémont 108
- o orophyte alpino-carpathique De toutes les Alpes et des Carpathes 109
- * Atlantique
- o euatlantique Des régions à climat typiquement atlantique 110
- o euatlant. franco-ibérique Des région côtières de la France et de la Péninsule Ibérique 111
- o ouesteuropéen (euatlant. s.l.) De la Scandinavie à la péninsule ibérique 112
- o nordouesteuropéen De la Scandinavie au NW de la France et aux Iles Britanniques 113
- o subatlantique Des zones à climat (sub)océanique d'Europe de l'ouest 114
- o atlantique franco-ibérique Idem, avec pénétration à l'intérieur des terres 115
- o sténoméditerranéo-atlantique Des côtes atlantiques et méditerranéennes 120
- o euryméditerranéo-atlantique Idem, avec pénétration à l'intérieur des terres 121
- o submédit.-subatlantique 122
- o amphi-atlantique Des zones atlantiques d'Amérique du Nord et d'Europe 129
- * Boréal:
- o circumboréal Des zones (tempérées-)froides de l'hémisphère nord 130
- o eurosibérien Des zones (tempérées-)froides d'Eurasie 131
- o arcticoalpin euro-américain Des hautes latitudes et altitudes d'Europe et d'Am. Du Nord 133
- o arcticoalpin européen Des hautes latitudes et altitudes d'Europe 134
- o arcticoalpin eurasiatique Des hautes latitudes et altitudes d'Eurasie 135
- o circum-arcticoalpin Des hautes latitudes et altitudes de l'hémisphère nord 136
- o orophyte euro-américain Des hautes montagnes d'Europe et d'Amérique du Nord 138
- o orophyte circumboréal Des hautes montagnes de l'hémisphère nord 139
- * Taxon Ă ample distribution:
- o européo-nordafricain d'Europe et d'Afrique du Nord 200
- o européen-boréoaméricain d'Europe et d'Amérique du Nord 201
- o méditerranéo-touranien Des zones (sub-)désertiques du Bassin Médit. et de l'Asie centrale. 202
- o paléotempéré De toute l'Eurasie et débordant sur l'Afrique du Nord 203
- o paléosubtropical 204
- o paléotropical 205
- o holarctique 210
- o subtropical Des zones tropicales et tempérées chaudes 212
- o pantropical 213
- o subcosmopolite tempéré Présent dans la plupart des régions tempérées du monde 214
- o orophyte subcosmopolite Présent dans la plupart des chaînes de montagnes du monde 215
- o subcosmopolite Présent dans la plupart des régions du monde 216
- o cosmopolite Présent quasiment dans le monde entier 219
- * Taxon introduit:
- o cultivé 220
- o naturalisé 221
- o cultivé et naturalisé 222
- o adventice 223
- o cultivé et adventice 224
- * Non déterminé:
- o répartition à préciser 250
- o présent avec les parents Répartition d'un hybride stérile 252
- o présent surtout avec les parents Répartition d'un hybride peu fertile 253
- o présent avec les parents, cultivé Répartition d'un hybride stérile, parfois cultivé 254
1.7. Delta
Sat, 24 Feb 2001 15:30:37 +0100
Jean-François Léger
Que pensez-vous de Delta Access? BDD Delta au standard Access. http://www.bgbm.fu-berlin.de/projects/DeltaAccess/
"Denis ZIEGLER"
Friday, February 23, 2001 10:46 PM
Puisque nous en sommes à la phase de reflexion préliminaire, je me permets d'intervenir pour indiquer qu'il existe un format de fichier utilisé au niveau international, spécialement adapté à la description taxonomique, en vue du traitement informatique. Il s'agit du format DELTA (DEscription Language for TAxonomy) recommandé comme standard pour les échanges de données taxonomiques. Son utilisation dépasse le cadre de la botanique ; il a d'ailleurs été développé par le département d'entomologie du CSIRO à Canberra en Australie. Le format DELTA comprend essentiellement deux fichiers : un fichier CHARS décrivant les caractères et leurs modalités, et un fichier ITEMS décrivant les taxons c'est à dire indiquant les modalités des caractères pour chaque taxon.
A titre d'illustration (simplifiée), voici un extrait de ces fichiers pour un jeu de données sur le genre Viola :
- * SHOW Genre Viola - Liste des caractères
- * SHOW Denis ZIEGLER - Novembre 1998
- * CHARACTER LIST
- * 1. fleurs <position des pétales>/ 1. de type violette <2 pétales dressés et 3 vers le bas>/ 2. de type pensée <4 pétales dressés et 1 vers le bas>/
- * 2. pétales <couleur>/ 1. violet/ 2. bleu/ 3. bleu pâle, lilas/ 4. blanc/ 5. jaune/ 6. bi ou tricolore/
- * 3. fleurs <odorantes ou inodores>/ 1. odorantes/ 2. inodores/
- * 4. taille des fleurs/ mm/
- * SHOW Genre Viola - Liste des taxons
- * SHOW Denis ZIEGLER - Novembre 1998
ITEM DESCRIPTIONS
- * Viola hirta <L.>/ 1,1 2,1/2 3,2 4,12-18 7,2 8,2 9,1 11,1 12,2 13,2 16,2 17,2 18,2 19,1 20,2 21,2 22,1 25,2 26,1 27,3 28,1 29,1 30,2 31,8-20 32,2
- * Viola palustris <L.>/ 1,1 2,3 3,2 4,12-15 6,1 7,2 9,1 11,2 12,1 13,2 16,1 17,2 18,1 19,1 20,2 21,2 22,3 25,1 26,1 27,3 28,1 29,1 30,1 31,3-10 32,2
- * Viola odorata <L.>/ 1,1 2,1 3,1 4,15-20 7,2 8,1 9,1 11,1 12,2 13,2 16,2 17,1 18,2 19,1 20,2 21,2 22,2 25,1 26,2 27,3 28,1 29,1 30,2 31,5-15 32,2
Un certain nombre de logiciels permettent d'exploiter ces fichiers, en vue de générer des clés de détermination, de réaliser des identifications interactives, etc... Le logiciel Intkey par exemple, développé par la même équipe, est très performant pour l'identification (y compris avec utilisation d'illustrations). Malheureusement, il s'agit d'un logiciel propriétaire et compilé sous Windows. Dans la même catégorie, le logiciel Navikey assure sensiblement les mêmes fonctionnalités sous forme d'une applet Java. C'est un logiciel libre. Personnellement, je collabore au projet FreeDelta, qui a pour but de créer des logiciels libres basés sur le format DELTA (une API en C++ est en cours d'écriture permettant d'analyser les fichiers Delta, utilisable par exemple par un programme d'identification).
Je ne sais pas si ce type de standard est utilisable dans le cadre de notre projet. Je pense qu'il n'est pas adapté à la réalisation de bases de données regroupant un grand nombre de taxons pour extraction, consultation, etc... Par contre, il permet de stocker toutes les informations nécessaires pour la description, l'identification, la réalisation de clés pour un genre donné par exemple.
Pour plus d'informations se reporter aux liens suivants :
- * Delta : http://biodiversity.uno.edu/delta/
- * FreeDelta : http://www.geocities.com/RainForest/Vines/8695/FreeDELTA/
- * Logiciels concernant la taxonomie (site très complet) : http://www.geocities.com/RainForest/Vines/8695/
Wed, 28 Feb 2001 00:35:06 +0100
"Denis ZIEGLER"
Parmi les valeurs "spéciales" que peut prendre un caractère vis-à -vis d'un taxon, on peut distinguer :
- 1. inconnu (pas d'info disponible Ă ce sujet)
- 2. impropre ou non applicable (ex : couleur des fleurs pour un gymnosperme)
- 3. variable (peut prendre une valeur quelconque pour ce caractère)
- 4. nul ou inexistant (ex : absence de stipules, glabre pour le caractère pilosité) Ces "pseudo-valeurs" sont codées dans le système Delta, on peut faire de même. Pour alléger la base de données (si l'on utilise une table de caractères séparée), on peut considérer que la première, voire les deux premières sont représentées par l'absence d'enregistrement du couplet taxon x caractère dans la table de relation. Les deux autres seront codées avec une valeur particulière.
Tue, 27 Feb 2001 06:07:25 +0100
Frédéric legens
Nous avons déjà abordé le sujet de DELTA sur la liste Flore-de-France. Ces outils n'ont pas suscité un enthousiasme délirant, c'est le moins que l'on puisse dire (comme le reste d'ailleurs) ! remarque :il me semble que tous les intervenants sont abonnés à tb-eFlore. Pour ma part je trouve ce système intéressant. Je ne vais pas résumer la discussion qu'on a eu mais seulement citer la conclusion donnée par daniel :
« Pour les clefs, il me semble difficile d'avoir une génération automatique pertinente. C'est "à la main" que s'élabore une bonne clé. »
Je pense que cette remarque est Ă©galement valable pour la description des taxons.
Personnellement, il me semble très important que les clefs ainsi que les descriptions soient stockées en français (structurer en XML) dans la base, cela offre beaucoup plus de souplesse. Il me semble donc pas approprié de vouloir réaliser en php ce que font les différents outils du système DELTA. D'autant plus que je partage l'avis de Mr Ziegler sur le fait que les outils delta semblent plus adapté au travail sur un petit nombre de taxons que sur un grand nombre.
Cependant pour alimenter les clefs et les descriptions, il peut coexister différentes façon de faire :
- o l'Ă©criture traditionnel Ă la main, via nos futurs Ă©diteurs,
- o ou utiliser un programme DELTA de façon totalement indépendante, puis de recopier les résultats dans l'un des éditeurs que l'on aura réalisé pour obtenir un résultat respectant la structure XML que l'on aura défini.
On peut même envisager, s'il est possible de modifier le programme DELTA, que celui-ci demande directement via http au serveur eFlore, les identifiants uniques des taxons, et que celui-ci réalise directement l' export au format XML. Et si l'on veut avoir une intégration encore plus forte, que celui-ci demande également la liste des différentes catégories de caractères, ainsi que les caractères associés aux différents taxons. Pour ce dernier type d'échange il a eu une proposition de format XML DELTA que vous pouvez trouver à l'adresse suivante: http://www.bath.ac.uk/~ccslrd/delta/index.html. La formalisation des différentes catégories de caractères y semble très bien formalisé. Il me semble qu'il faudra s'en inspirer, et éventuellement adopter ce codage. (Mais il est également possible de renvoyer directement les informations dans le format DELTA).
1.8. Eflore et le Mac !
Wed, 28 Feb 2001 07:37:21 +0100
Frédéric legens
L'idée n'est bien entendu pas d'exclure les possesseurs de Mac, mais en effet cela pause un problème car un certain nombre d'outils informatiques que nous allons utiliser n'existent pas actuellement sur Mac OS.
Au niveau de la base de données et des outils permettant de générer des documents XML et de lire ces mêmes documents, nous avons opté pour les outils dont dispose Tela-botanica pour son site internet, ce qui semble logique. De plus ces outils ont l'avantage d'être couramment utilisés sur internet, et sont gratuits ou sont des sharewares (je pense notamment à mySQL sur windows), et sont librement distribuable (ce qui est très appréciable). A noter qu'il peuvent également fonctionner sur MAC à condition d'utiliser comme système d'exploitation LINUX (je sais cela n'est pas vraiment une solution), de plus il y a de grandes chances qu'ils soient adaptés à Mac OS X.
Dans le projet eFlore nous allons utiliser ces outils mais toute personne courageuse peut les remplacer par un autre outil, notamment pour la base de données qui peut être remplacer par oracle ou access par exemple. (PHP est capable de travailler directement avec ces bases de données). Il est également possible d'utiliser FileMaker pro qui peut remplacer à la fois mySQL et PHP, puisqu'il peut faire office de serveur internet. En effet le point majeur de ce projet est de définir des fichiers d'échanges de données en XML, ces fichiers étant des fichiers textes il est relativement facile de les analyser dans le but d'importer les informations dans sa propre base de données. Obtenir du serveur de telabotanica ces fichiers XML est facile puisque l'on passe par le protocole standard d'internet : http. Par exemple pour obtenir le squelette vierge d'une clef de détermination pour le genre Papaver dans mon prototype d'éditeur de clef, je demande url suivante http://flegens.free.fr/GetNewKey.php3?nom=Papaver (Il est possible de tester cela dans n'importe quel navigateur) .L'envoie de données se fait de façon analogue. De plus pour faciliter ces échanges d'informations la majorité des bases de données commerciales comportent dans leur nouvelles versions des outils facilitant l'analyse de fichiers XML (il me semble que c 'est notamment le cas FileMaker pro version 5).
Pour les applications clientes spécifiques à tela-botanica que l'on va être susceptible de développer, il existe plusieurs solutions : 1) développer une version spécifique au MAC, si l'on trouve quelqu'un qui peut le faire. 2) développer les applications en java ce qui permet à ces application de tourner à la fois sur mac, pc, linux . Mais il faut avoir un programmeur java. De plus java est lent sur des machines peu puissantes et est délicat à installer et l'installable est très gros (avec la jvm),donc difficilement chargeable d' internet. On risque donc d'exclure plus de personnes que le nombre de possesseurs de Mac ainsi dépannés. 3) Utiliser un logiciel de base de données façon FileMakerPro et intégrer les outils de manipulations à la base. Par exemple l'éditeur de clefs de benoît (qui en définitive est très proche de mon prototype), du moment qu' il comporte une fonction d'exportation en XML (qui n'est pas plus compliqué à développer que la fonction d'export en HTML).
Bref il y a plein de possibilités, j'espère donc que l'on pourra au moins en développer une pour les possesseurs de Mac.
Cordialement.