|
|
|
|
|
|
Synthese16 November 2001Table of Contents1. Phase 1A : Initialisation1.1. ObjectifsTue, 13 Feb 2001 23:35:40 +0100Frédéric legensDé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. 1.2. eflore et flore"Frederic legens"Sat, 2 Jun 2001 22:12:30 +0200Bonjour 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 MATHIEUSun, 12 Aug 2001 20:45:06 +0200Bonjour, 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. OutilsSun, 11 Feb 2001 21:19:20 +0100Frédéric legensJe 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écoupageWed, 21 Feb 2001 23:05:11 +0100Frédéric legensComme 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 +0100Frédéric legensMerci 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/BDNFFThu, 01 Mar 2001 15:56:48 +0100Benoit BOCKsubsp. = 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 +0100Benoit BOCKDefinition 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. AttributsMon, 26 Feb 2001 16:56:52 ESTAPIMEDIAD'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 +0100Benoit BOCKToujours 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. DeltaSat, 24 Feb 2001 15:30:37 +0100Jean-François LégerQue 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 PMPuisque 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 +0100Frédéric legensNous 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 +0100Frédéric legensL'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. 2. Phase 1B : Services2.1. ListeMon, 5 Mar 2001 07:41:50 +0100"Frederic legens"Vous retrouverez ci-dessous une première descriptions des fonctionnalités en lecture que je souhaiterais avoir pour la partie1. N'hésitez surtout pas à ajouter les fonctionnalités qui vous semblent manquer. 1)récupérer le nom valide d'un taxon, et ses identifiants respectifs. 2)récupérer les synonymes d'un taxon et leurs identifiants respectifs. 3)récupérer l'enchaînement des noms valides des taxons hiérarchiquement supérieurs, ainsi que leurs identifiants respectifs. 4)récupérer l'ensemble des noms valides des taxons hiérarchiquement inférieurs (d'une façon directe), ainsi que leurs identifiants respectifs. 5)récupérer les noms communs en différentes langues d'un taxon. 6)récupérer les identifiants d'un taxon dans d'autres systèmes de codage que celui utilisé dans eFlore et inversement. Toutes ces informations devront être accessibles soit en donnant un nom latin, soit en donnant l'identifiant d'un taxon. "Frederic legens"Sat, 2 Jun 2001 22:11:56 +0200Bonjour, Je viens de placer sur http://eflore.tela-botanica.org, deux nouveaux fichiers décrivant la base de données que j'ai installés sur le site grâce à Jean-Charles (avec les données que m'a envoyé Benoît). Nous allons donc pouvoir dès la semaine prochaine passer au vif du sujet : la structuration XML. Pour cela je pense que nous allons discuter du premier service XML que nous allons mettre en place. Un service XML peut se définir de la façon suivante : c'est le fait de faire une demande d'information au serveur via http (comme vous le faites avec la barre d'adresse de votre navigateur internet) et de recevoir l' information demandée. L'information renvoyée par le serveur devra respecter un format XML que nous allons donc devoir définir. Je vous propose de commencer par le service XML qui nous permettra de recevoir une classification taxonomique. Cordialement. 3. Phase 1C : Structure3.1. PropositionMon, 5 Mar 2001 07:41:50 +0100"Frederic legens"Voici une proposition informelle de structures pour l'ensemble des fiches nécessaires à la réalisation de la phase1. J'y reprend principalement les rubriques présentes à la page 8 du document de Benoît. Fiche d'identité d'un taxon : N° Taxonomique N° nomenclatural Rang taxonomique (Embranchement, classe . espèces .) Nom du Taxon (noté en toutes lettres donne le nom complet du taxon jusqu'à l'espèce.) Auteur du taxon Type de sous-espèce Sous-espèce Auteur de la sous-espèce Type de l'inra2 Infra2 Auteur de l'infra2 Type de l'infra3 Infra3 Auteur de l'infra3 Année Source bilbliob Source biblio à exclure Info sur la combinaison Type de synonymie Doute nom valide Hybride Auteur principal In Statut Fiche des noms communs d'un taxon : N° Taxonomique Code de la langue Nom commun Note La rubrique code CIFF sera disponible par des fiches de transcodages. La rubrique Nombres chromosomiques sera à intégrer à la notion de caractères. Les rubriques suivantes n'ont pas été conservées mais seront d'une certaine façon disponible par la notion de classification : Famille Genre Flores La fiche de classification des taxons permettra de relier un taxon donné avec le taxon de niveau hiérarchiquement supérieur ( par exemple une espèce avec le genre, un genre avec la famille) . Cette fiche comportera les champs suivants : N° taxonomique du taxon de rang supérieur. N° taxonomique du taxon de rang inférieur. Dans la pratique on rajoutera un troisième champ, qui sera la concaténation de tous les N° taxonomique reliant le taxon de rang inférieur avec le taxon de plus haut rang. Ce champ n'apporte aucune information supplémentaire mais est utile pour optimiser certains traitements. Cette structure permet de gérer une classification unique, cela suppose donc que l'on se mette d'accord sur la classification à utiliser, de plus celle-ci devra couvrir l'ensemble des taxons. Une autre façon de voir les choses est de considérer que l'on peut avoir besoin de faire coexister plusieurs classifications. Par exemple la classifications d'Engler, de Cronquist, de Thorne ou de Dahlgren pour les angiospermes. Mais également la classification utilisé par Coste , Fournier ou Bonnier dans leurs flores respectives. Dans ce cas on aurait plutôt la structure suivante : N° de classification N° taxonomique du taxon de rang supérieur N° nomenclatural du taxon de rang supérieur N° taxonomique du taxon de rang inférieur N° nomenclatural du taxon de rang inférieur Ce cas me semble nettement plus intéressant, de plus on n'a pas besoin que chaque classification couvre l'ensemble des taxons (on peut donc avoir par exemple une classification qui se limite aux bryophytes. Il est également à noter que la notion de nom valide n'a plus la même utilité, puisque le nom est valide à l'intérieur d'une classification donnée. Il serait quand même possible de trouver le nom valide dans une classification moderne, du nom employé dans une classification ancienne. Que pensez-vous sur cette notion de classifications multiples ? (sachant que l'on peut de toute façon débuter avec une seule classification). Cordialement. Sat, 10 Mar 2001 11:26:25 +0100"Frederic legens"Le but n'étant pas de phagocyter le projet isff, toutes les fiches d' identités correspondant à des taxons inférieurs ou égaux à l'espèce, seront créés par l'importation des données correspondantes présentes dans l'isff. Nous utiliserons donc les mêmes numéros nomenclaturaux et taxonomiques. (Ces opérations d'export import se feront de façon régulière (à définir) pour suivre les évolutions de l'isff). Par contre pour les fiches concernant des taxons supérieurs à l'espèce, cela n'est pas actuellement possible puisque ces fiches n'existent pas dans l' isff. Je ne me trompe pas Benoît ? Est-ce une prochaine étape de l'isff ? Si c'est le cas nous procéderons de la même façon que pour les taxons égaux ou inférieurs à l'espèce. Dans le cas contraire il va falloir prévoir une façon de faire, dans ce cas on définira deux plages de numéros nomenclaturaux et taxonomiques non utilisables par l'isff pour numéroter nos nouveaux taxons. Note : Je vais faire un petit prototype pour illustrer mes différentes propositions, benoît tu m'avais proposer de me fournir l'ensemble des noms valides de l'isff, ne pourrais tu pas plutôt m'envoyer un export de tous les taxons (valides ou non valides ) appartenant aux deux familles suivantes Polyganacées et Oxalidacées. Cela permettrait d'avoir de meilleurs exemples. Pour le format je te propose d'exporter tous les champs (séparés par un point virgule ou un autre caractère non utilisé par ailleurs) dans un fichier texte, je ferai le tri dans l'export, c'est le plus simple. Cordialement "Benoit BOCK"Friday, March 09, 2001 10:44 PMComment feras tu pour rechercher tous les noms d'un même genre sachant qu'il y a des homonymies de genre appartenant à des familles différentes? Voir "petite" liste ci-dessous:
Sat, 10 Mar 2001 11:26:50 +0100Frederic legensMerci benoît, pour ta lecture détaillée de mes propositions. Je n'avais pas pensé au cas des homonymies de genres, mais cela ne semble pas être un problème. Par exemple dans la table des synonymes, on aura les lignes suivantes: N° taxonomique - N° nomenclaturale - Nom -Année -validité 1000 - 6845 - Polygonacées -valide 1052 - 3278 - Oxalidacées - valide 2301 - 345 - Acetosella (Meisner) Fourr. - 1869 -non valide 2304 - 998 - Acetosella O. Kuntze - 1891 - non valide 2301 - 300 - Rumex L. 1753 - valide 2304 - 350 - Oxalis L. 1753 -valide Si l'on fait une recherche de synonymes avec le N° taxonomique, ou le numéro nomenclaurale, il n'y a aucun problème. Par contre si l'on fait une recherche avec le nom, deux cas se présenterons: 1) Le nom n'existe qu'une fois dans la table (ex : Rumex ou Oxalis) : dans ce cas la réponse ne contiendra que les synonymes ayant respectivement les N° taxonomiques 2301 et 2304. 2) Le nom existe plusieurs fois dans la table (ex : Acetosella) : dans ce cas la réponse contiendra tous les synonymes existants , mais groupés par N° taxonomiques (structuration avec XML). Bien entendu cela dépend du type de fiches que l'on souhaite avoir pour réponse , c'est possible pour une fiche de synonymes, mais difficilement envisageable pour les clefs ou les fiches de descriptions : nous définirons donc un comportement pour ce cas pour tous les types de fiches. En continuant sur cet exemple et en s'intéressant à la notion de classification. Dans le cas ou l'on adopterait une classification unique : On aurait les liens suivants dans la table classification: N° taxonomique du taxon de rang supérieur - N° taxonomique du taxon de rang inférieur. 1052 - 2304 1000 - 2301 Certes pour ces numéros taxonomiques, on peut éventuellement avoir des synonymes ayant des rangs différents, mais le vrai rang du taxon , si j'ai bien compris ton système dans l'isff est le rang du nom valide, donc il n'y a pas de problèmes puisque on aura toujours un nom valide par n° taxonomique. Dans le cas ou l'on adopterai le système de classification multiple : On aurait une classification moderne (classification n°1) composée par les lignes suivantes: N° de classification -N° taxonomique du taxon de rang supérieur - N° nomenclatural du taxon de rang supérieur - N° taxonomique du taxon de rang inférieur. - N° nomenclatural du taxon de rang inférieur 1-1052 -3278- 2304 -350 1-1000 -6845- 2301 -300 On pourrait également avoir en plus une classification n°2 où le genre Acetosella serait associé aux Polygonacées : 2-1052 -3278- 2304 -350 2-1000 -6845- 2301 -345 Et inversement une classification n°3 où le genre Acetosella serait associé aux Oxalidacées : 3-1052 -3278- 2304 -998 3-1000 -6845- 2301 -300 Evidemment cette notion de classification multiple devra être utilisée de façon modérée, le but n'étant pas d'embrouiller les choses, mais de pouvoir faire éventuellement coexister plusieurs systèmes soit dans le but de faire des évolutions, soit dans un souci de faire apparaître des classifications ayant une importance historique ou pratique (classification utilisée par Bonnier, Coste, Fournier ...). Personnellement je pense que cette notion de classification multiple est la meilleur, même si dans un premier temps nous en réaliserons qu'une. "Roger Cruon"Saturday, March 10, 2001 9:29 AMLa discussion actuelle (sur [tb-eflore]) met en lumière la principale difficulté d'un index synonymique, qui est que les règles de la nomenclature ne s'appliquent qu'après que toutes les décisions taxonomiques aient été prises; le nom valide d'un taxon dépend des conceptions systématiques relatives à son rang taxonomique et plus généralement à sa place dans la classification. Mais, pour y voir clair, il faut distinguer d'une part le niveau du genre et de ses subdivisions, d'autre part les niveaux supra-génériques. Je commence par ces derniers. Prenons l'exemple du genre Smilax, classé par Fournier dans les Liliacées. Les classifications récentes (disons depuis 30 ans) éclatent les Liliacées s.l. en plusieurs familles; Kerguélen a suivi cette tendance et placé Smilax dans les Smilacacées. Ceci ne change rien au nom du genre et des espèces qui en font partie, par exemple Smilax aspera. Ce que propose Frédéric, c'est de supprimer l'indication de la famille dans l'index proprement dit, et de faire un fichier séparé pour traduire la classification, ici Smilax -> Smilacaceae. L'avantage est qu'on peut ne pas se limiter à une seule conception systématique, et indiquer aussi Smilax -> Liliaceae, à condition de préciser de quelle classification il s'agit (par exemple Engler-Melchior). Même à ce niveau, les choses ne sont pas toujours si simples. Par exemple, l'article 18.5 du Code de nomenclature valide les noms traditionnels (non formés à partir d'un nom de genre) de 8 familles, parmi lesquelles figure Leguminosae. Mais il indique aussi entre parenthèses un autre nom (ici Fabaceae) dont l'usage est également autorisé, ce qui est une entorse à la règle selon laquelle, à conception systématique donnée, un taxon ne peut avoir qu'un seul nom valide. En outre, l'article 19.7 indique que, si les Papilionaceae sont incluses dans la famille Leguminosae ou Fabaceae en tant que sous-famille (ce qui est une décision taxonomique, sur laquelle le Code ne peut pas prendre parti), le nom Papilionoideae peut être utilisé comme alternative à Faboideae. Au niveau du genre et en dessous, la situation est différente puisque les décisions taxonomiques influent sur le nom. Par exemple, l'ISFF utilisait Chamaecytisus hirsutus, alors que les travaux récents ne reconnaissent pas ce genre, inclus maintenant dans Cytisus (voir messages sur [isff] 18-23/11/2000). Ceci est une décision taxonomique, mais elle a une conséquence directe sur le nom. La synonymie qui figure dans l'index suffit à savoir que, pour quelqu'un qui considère comme justifiée la séparation du genre Chamaecytisus, le nom Chamaecytisus hirsutus est correct, alors que dans le cas contraire c'est Cytisus hirsutus qui est correct. En conclusion, je pense que l'idée de Frédéric d'un fichier de classification est à retenir seulement pour les niveaux supérieurs au genre. "Frederic legens"Thu, 19 Apr 2001 07:50:05 +0200Bonjour Benoît, Peux-tu me confirmer les choses suivantes concernant les fichiers que tu m'as envoyés? Lorsqu'il existe un doute sur la validité du nom (champ doute nom valide renseigné), le champ N° taxonomique est-il toujours vide ? Lorsqu'un enregistrement comporte des renseignements au niveau de l'infra 2 ou l'infra 3, j'ai constaté que les données de la sous-espèce ne sont pas toujours renseignées! Est-ce normal ? J'ai l'impression que cela signifie simplement qu'il n'y a pas de sous-espèce autre que la sous-espèce type (qui n'est donc pas exprimée). C'est bien cela. Cordialement. Benoit BOCKThu, 19 Apr 2001 10:00:01 +0200> Lorsqu'il existe un doute sur la validité du nom (champ doute nom valide > renseigné), le champ N° taxonomique est-il toujours vide ? NON. exemple: Acer fauriei H.Lév. & Vaniot [1906, Bull. Soc. Bot. Fr., 53 : 590] (t) = Acer negundo L. subsp. negundo ? (Aceraceae) {162} Acer faurei possède le même numéro taxonomique que Acer negundo subsp. negundo. Le champ doute nom valide comprend la valeur "1" qui est retranscrite en "?". Par contre lorsqu'un nom est "sans correspondance" noté "= ?" par Kerguelen. Le numéro "doute nom valide" est "2" retranscrite en "sans correspondance" Peut-être veux tu la liste complète des valeurs de la rubrique "doute nom valide" et leur signification? > Lorsqu'un enregistrement comporte des renseignements au niveau de l'infra 2 > ou l'infra 3, j'ai constaté que les données de la sous-espèce ne sont pas > toujours renseignées! Est-ce normal ? J'ai l'impression que cela signifie > simplement qu'il n'y a pas de sous-espèce autre que la sous-espèce type (qui > n'est donc pas exprimée). C'est bien cela. Effectivement, c'est un problème qui m'a beaucoup préoccupé. Logiquement, lorsque l'on trouve "Genre a var. b" on devrait écrire en fait : "Genre a subsp. a var. b". Cependant, lorsqu'il n'y a aucune sous-espèce mais simplement 2 ou 3 variétés, il est plus commode de ne pas rallonger la mention du nom. Mais dans beaucoup de cas Kerguelen a répertorié un grand nombre de variétés sans mention de la sous-espèce. J'ai homogénéisé ces citations pour les noms retenus mais pas pour les innombrables variétés synonymes. Ce qui donne par exemple:
>Brassica napus L. [1753, Sp. Pl. : 666] (Brassicaceae) {10308}
Brassica napus L. var. esculenta DC. [1821, Syst. Nat., 2 : 592] (t) = Brassica napus L. subsp. rapifera Metzg. (Brassicaceae) {10313} Brassica napus L. var. napobrassica (L.) Rchb. [18371838, Icon. Fl. Germ., 2 21] (t) = Brassica napus L. subsp. rapifera Metzg. (Brassicaceae) {10314} Brassica napus L. subsp. napobrassica (L.) O.Schwarz [1949, Mitt. Thüring. Bot. Ges., N. F., 1 (1) : 102] (t) = Brassica napus L. subsp. rapifera Metzg. (Brassicaceae) {10309}
>Brassica napus L. subsp. napus [, ] (Brassicaceae) {10310}
>Brassica napus L. subsp. oleifera (DC.) Metzg. [1833, Syst. Beschr. Kult.
>Kohlarten : 46] (t) = Brassica napus L. subsp. napus (Brassicaceae) {10311}
>Brassica napus L. subsp. rapifera Metzg. [1833, Syst. Beschr. Kult.
> Kohlarten : 46] (Brassicaceae) {10312}
"Frederic legens"Fri, 20 Apr 2001 09:52:26 +0200C'est en effet un problème. Je ne pense pas que dans la notion de classification liant un taxon de niveau hiérarchiquement supérieur avec des taxons de niveaux inférieurs il soit souhaitable d'avoir des taxons de niveaux différents. De plus si on lie a une espèce une sous-espèce, de facto les variétés devraient en toute logique changées également de taxon supérieur (pour être associées à la nouvelle sous-espèce ou à la sous-espèce type), ce qui est un gros inconvénient. Je pense donc que dans un premier temps pour le projet eFlore, il serait souhaitable de se limiter aux sous-espèces, pour les taxons de niveaux inférieurs. Qu'en pensez-vous ? "Benoit BOCK"Wednesday, June 27, 2001 7:08 PMEst-ce qu'il faut intÈgrer la bibliographie dans la balise <NOMTAXON> comme semble l'indiquer tous les mails de benoÓt faisant rÈfÈrence ý la bdnff. oui. L'idéal serait: année / source biblio / tome et pages dans ma base j'ai seulement découpé le champ en 2: année / source, tome et page Les sources biblio ne sont pas homogénéisées mais elles sont indispensables pour les chercheurs. C'est probablement le point le plus important de l'index de Kerguelen (au départ de celui là). Il faut absolument le conserver mais peut être définir deux options d'affichage comme je l'ai fait. Une pour les amateurs (botanistes de terrain) masquant l'information et une pour les "professionnels", ceux qui s'intéressent à la nomenclature et qui ont besoin de connaître les références précises concernant les noms. 4. Phase 1B - Services - Approfondissement4.1. Maquette"Frederic legens"Mon, 25 Jun 2001 22:36:34 +0200Bonjour, Voici enfin les deux premiers services xml que nous allons mettre en place concernant le dictionnaire taxonomique d'eFlore. Comme ce sont les deux premiers services j'ai developpe une maquette pour que tous le monde puisse voir a quoi cela peut ressembler. Par la suite il me semble preferable de commencer par definir le format XML, cela sera plus economique en temps et permettra de distribuer la partie programmation. Pour chaque service XML on pourra se poser les questions suivantes : est-ce que toutes les informations necessaires a l'usage que l'on souhaite en faire sont bien presentes ? est-ce qu'il n'y a pas des informations inutiles (disponibles par d'autres services) ? est-ce que la syntaxe et la semantique XML est correcte, comprehensible= , et facile d'usage ? est-ce que tous les parametres des services ont bien etes definis ? Il faudra egalement verifier que la syntaxe XML entre les differents services est bien homogene. J'ai redige deux documentations pour les deux services XML. Vous pouvez les trouver sur eflore.tela-botanica.org. Je me pose deja les questions generales suivantes : Quel langue choisir pour le nom des services, des balises et des attributs ? Est-ce que ce type de documentation vous semble clair. Au niveau du format XML, je me pose la question suivante : Est-ce qu'il faut integrer la bibliographie dans la balise <NOMTAXON> comme semble l'indiquer tous les mails de benoit faisant reference a la base dnff. Cordialement. 4.2. Objectifs"Frederic legens"Tue, 4 Sep 2001 23:05:44 +0200Bonjour, C'est la rentrée, je vous propose donc de reprendre nos activités. Nous avons à terminer les services XML du dictionnaire taxonomique, et comme convenu mettre en place un développement collaboratif via CVS. Pour la suite du dictionnaire taxonomique, il me semble qu'il manque les services XML de consultations suivants: 1) Un service permettant de recevoir une liste alphabétique de noms de taxons. 2) Un service permettant de recevoir la liste de synonymes et de noms communs d'un taxon dans une classification donnée. J'ai déjà réalisé quelque chose pour le premier que je vous soumettrai prochainement. Quelqu'un veut-il se charger de proposer un format pour le second, en s'inspirant de ce qui a déjà été fait pour les premiers services? (On en fera l'implémentation une fois CVS mis en place). Ensuite nous aborderons les services XML du dictionnaire taxonomique en écriture. Cordialement. "Frederic legens"Mon, 17 Sep 2001 07:43:55 +0200Bonjour J'ai placé sur le serveur le nouveau service XML donnelistetaxon. Vous avez comme d'habitude la documentation, et la possibilité de le tester. De plus j'ai comme convenu ajouté les balises BIBLIOGRAPHIE et BIBLIO_A_EXCLURE pour toutes les balises NOM_TAXON des différents services, ainsi qu'un attribut « version » à chaque fiche. Cordialement. 4.3. Commentairesjean-christophe bottraudMon, 08 Oct 2001 07:56:28 -00001.Remarques générales Ce serait bien d'avoir une section "Objectifs du service" (ou données restituées : description des classifications disponibles, extraits d'une classification, données bibliographiques ...). Cela permettrait de mieux voir les objectifs de la formalisation des documents XML et des DTDs présentés. Les attributs 'numclass' et 'numtaxo', si j'ai bien compris, jouent le rôle d'identifant pour les éléments correspondants. Dans ce cas ne devraient-ils pas être de type ID plutôt que CDATA ? Ils pourraient ainsi être référencés par d'autres objets par l'intermédiaire d'un attribut de type IDREF, avec une garantie de cohérence ou, ce qui est plus intéressant, être retrouvés à l'aide de services standard lors de l'utilisation d'une feuille de style XSLT. Remarques :
D'autre part, l'attribution d'un identifiant numérique de cette façon est arbitraire. Deux bases n'auront vraisemblablement pas le même numéro pour le même taxon, ce qui peut rendre difficile les comparaisons. Il me semble qu'il serait préférable de carrément utilisé le nom scientifique du taxon (latin en général, donc que des caractères ASCII et pas de problème en XML) comme base de l'identifiant. Si le nom scientifique (normalisé je suppose) n'est pas utilisé directement, un algorithme permettant de passer de ce nom à l'identifiant devrait être publié. Mais je ne suis pas sûr que ce soit la meilleure solution. Enfin la signification des attributs numnom et rangtaxo n'est pas claire. 2.donneclassification.php remarque : il y a une erreur (typo) dans le DTD - #REDUIRED doit être remplacé par #REQUIRED dans la ligne <!ATTLIST CLASSIFICATION numclass CDATA #REDUIRED > Je ne suis pas sûr de comprendre l'objectif de la DTD. Est-ce de définir des classifications indépendantes, avec les données suivante : FICHE_CLASSIFICATIONS correspond à la définition d'un ensemble de classification (mais à quoi sert l'attribut numclass ?). CLASSIFICATION définit une classification avec
Si c'est le cas, je pense que l'exemple est peut-être mal choisi. Il est certainement posible de trouver un Taxon englobant Polygonacées et Oxalydacées, et les deux classifications sont en fait des parties de la classification ayant ce taxon ancêtre commun comme PREMIER_TAXON. 3.donneclassificationtaxons.php Je crois que le nom LISTE_CLASSIFICATION_FILLES est mal choisi parce qu'il donne à penser que les éléments contenus sont des CLASSIFICATION, alors qu'il s'agit en fait de CLASSIFICATION_TAXON. Une meilleure appelaation, plus facile à réutiliser,serait peut-être LISTE_TAXONS. D'autre part, je pense qu'il est possible de simplifier les deux DTDs correspondants aux services donneclassification.php et donneclassificationtaxons.php et de les fusionner, à partir des remarques suivantes:
On pourrait donc utiliser les DTD suivantes (avec le remplacement de nom proposé ci-dessus) : Fichier common.dtd : <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT CLASSIFICATION (DESCRIPTION, TAXON)> <!ATTLIST CLASSIFICATION numclass CDATA #REDUIRED > <!ELEMENT DESCRIPTION (#PCDATA)> <!ELEMENT TAXON (NOM_TAXON, LISTE_TAXONS?)> <!ATTLIST TAXON numtaxo CDATA #REQUIRED > <!ELEMENT NOM_TAXON (NOM+)> <!ATTLIST NOM_TAXON numnom CDATA #REQUIRED rangtaxo CDATA #REQUIRED > <!ELEMENT NOM (#PCDATA)> <!ATTLIST NOM auteur CDATA #IMPLIED > <!ELEMENT LISTE_TAXONS (TAXON+)> Puis la DTD suivnte pour donneclassification.php : <?xml version="1.0" encoding="UTF-8"?> <!ENTITY % COMMON SYSTEM "common.dtd"> %COMMON; <!ELEMENT FICHE_CLASSIFICATIONS (CLASSIFICATION+)> <!ATTLIST FICHE_CLASSIFICATIONS numclass CDATA #IMPLIED> Et enfin la DTD suivante pour donneclassificationtaxons.php : <?xml version="1.0" encoding="UTF-8"?> <!ENTITY % COMMON SYSTEM "common.dtd"> %COMMON; <!ELEMENT FICHE_CLASSIFICATION_TAXONS (CLASSIFICATION, TAXON)> <!ATTLIST FICHE_CLASSIFICATION_TAXONS numclass CDATA #REQUIRED numtaxo CDATA #IMPLIED profondeur CDATA #IMPLIED rangtaxo CDATA #IMPLIED > Ces deux DTDs sont compatibles avec les exemples de donneclassification.php et de donneclassficationtaxons.php: <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <FICHE_CLASSIFICATIONS> <CLASSIFICATION numclass="1"> <DESCRIPTION>Classification des Polygonacées basée sur la bdnff. </DESCRIPTION> <TAXON> <NOM_TAXON numnom="200000" rangtaxo="40"> <NOM>Polygonaceae</NOM> </NOM_TAXON> </TAXON> </CLASSIFICATION> <CLASSIFICATION numclass="2"> <DESCRIPTION>Classification des Oxalydacées basée sur la bdnff. </DESCRIPTION> <TAXON> <NOM_TAXON numnom="200001" rangtaxo="40"> <NOM>Oxalidaceae</NOM> </NOM_TAXON> </TAXON> </CLASSIFICATION> </FICHE_CLASSIFICATIONS> Autre exemple : <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <FICHE_CLASSIFICATION_TAXONS numclass="2" numtaxo="100025" rangtaxo="110"> <CLASSIFICATION numclass="2"> <DESCRIPTION>2è me classification</DESCRIPTION> <TAXON numtaxo="200001"> <NOM_TAXON numnom="200001" rangtaxo="40"> <NOM>Oxalidaceae</NOM> </NOM_TAXON> </TAXON> </CLASSIFICATION> <TAXON numtaxo="100025" > <NOM_TAXON numnom="100025" rangtaxo="60"> <NOM >Oxalis</NOM></NOM_TAXON> <LISTE_TAXONS> <TAXON numtaxo="4007" > <NOM_TAXON numnom="47095" rangtaxo="100"> <NOM auteur="L.">Oxalis acetosella</NOM> </NOM_TAXON> </TAXON> <TAXON numtaxo="4008" > <NOM_TAXON numnom="47102" rangtaxo="100"> <NOM auteur="Savigny">Oxalis articulata</NOM> </NOM_TAXON> </TAXON> <TAXON numtaxo="13136" > <NOM_TAXON numnom="47110" rangtaxo="100"> <NOM auteur="Lindl.">Oxalis bowiei</NOM> </NOM_TAXON> </TAXON> </LISTE_TAXONS> </CLASSIFICATION_TAXON> </FICHE_CLASSIFICATION_TAXONS> 4.donnelistetaxons.php Ma première remarque concerne les paramètres de la procédure l'utilisation de valeurs minimales et maximales pour définir des intervalles sur les noms semblent indiquer l'existence d'une relation d'ordre, ce qui n'est généralement pas le cas dans les chaînes alphabétiques correspondants aux noms. Il serait peut-être plus justifié d'utiliser des préfixes ou des radicaux (ce qui est le cas de l'exemple : nommin=Oxalis et nommax=Oxalis => cela revient à sélectionner tous les noms commençant par Oxalis). On diviserait par deux le nombre de paramètres et le critère de sélection serait peut-être plus clair. Ma deuxième remarque concerne la liste d'attributs de NOM_TAXON : BIBLIOGRAPHIE et BIBLIO_A_EXCLURE sont des éléments facultatifs. Comme dans la discussion du paragrpahe 3, on pourrait les mettre dans une DTD commune, ce qui peremttrait de réutiliser pour LISTE_TAXONS la définition donnée ci-dessus, sans modification. Il n'y aurait alors qu'un seul élément nouveau de défini pour cette procédure. Voilà. Si vous avez des questions ou des commentaires sur ces quelques remarques, n'hésitez pas à me contacter, ou a répondre par la liste ! flegensWed, 10 Oct 2001 07:39:06 -0000Merci pour ces commentaires très constructifs, je n'ai pas de réponses pour tous les points. De toute manière il faut que l'on prenne tous ensemble les décisions sur ces différents points. > Voici quelques réflexions sur les formats XML proposés pour eFlore > sur le site eflore.tela-botanica.org. > > Aucun des points soulevés ci-dessous ne correspond à un problème > majeur et en fait, suivant les objectifs recherchés, il est même > possible que je sois le plus souvent "à côté de la plaque" à cause > peut être d'un manque de vision claire sur les objectifs du projet > (quelles sont les données que doit collecter le projet Flore de > France, comment seront-elles organisées et quels sont les moyens > prévus pour pouvoir retrouver ces données, etc.). > > Mon principal souci avec la présentation actuelle est qu'elle est > très orientée service, c'est à dire description de données renvoyées > en réponse à une demande (ce sont donc plutôt des descriptions de > messages, au sens SOAP), alors que le modèle sous-jacent des > informations stockées n'est pas décrit explicitement. On risque > ainsi d'introduire des incohérences dans la description des > différentes entités. En effet il faudrait peut-être séparer la notion de service, et la description des entités et du modèle sous-jacent, mais comment présenter cela simplement ? Il me semblait plus facile de présenter cela via les services, car à chaque fois on s'occupe d'une petite partie, de plus c'est la seule qui est facilement matérialisable. > 1.Remarques générales > > Ce serait bien d'avoir une section "Objectifs du service" (ou > données restituées : description des classifications disponibles, > extraits d'une classification, données bibliographiques ...). Cela > permettrait de mieux voir les objectifs de la formalisation des > documents XML et des DTDs présentés. Ok, on rajoutera une rubrique Objectifs du service: pour détailler la mini présentation que j'ai placée dans l'introduction. > Les attributs 'numclass' et 'numtaxo', si j'ai bien compris, jouent > le rôle d'identifant pour les éléments correspondants. > Dans ce cas ne devraient-ils pas être de type ID plutôt que > CDATA ? > Ils pourraient ainsi être référencés par d'autres objets > par l'intermédiaire d'un attribut de type IDREF, avec une garantie de > cohérence ou, ce qui est plus intéressant, être retrouvés à l'aide de > services standard lors de l'utilisation d'une feuille de style XSLT. > > Remarques : > - un document doit contenir la déclaration de tous les ID qu'ils > référencent (si le parseur XML utilisé est validant, ce qui > est une option). > - un ID est nécessairement alphanumérique, ce qui est > facilement contournable en mettant un préfixe (par exemple > cumclass='2' deviendrait numclass='C2'). je ne connaissais pas l'intérêt de ce type, donc en effet il serait mieux de les utiliser. Par contre cela risque de poser de sérieux problèmes techniques. Par exemple l'attribut numtaxo est très souvent employé. Il est donc possible d'avoir deux fois la même valeur dans un même document ce qui n'est pas possible. En plus je ne souhaite pas m'écarter des identifiants de la BDNFF (qui sont des entiers). Bref il y a du pour et du contre sur ce point. Dans les documents actuels l'utilisation d'une référence me semble inutile, par contre elle est peut-être souhaitable dans une clef de détermination par exemple? > D'autre part, l'attribution d'un identifiant numérique de cette > façon est arbitraire. Deux bases n'auront vraisemblablement pas le > même numéro pour le même taxon, ce qui peut rendre difficile les > comparaisons. Il me semble qu'il serait préférable de > carrément utilisé le nom scientifique du taxon (latin en général, donc > que des caractères ASCII et pas de problème en XML) comme base de > l'identifiant. Si le nom scientifique (normalisé je suppose) n'est > pas utilisé directement, un algorithme permettant de passer de ce > nom à l'identifiant devrait être publié. > Mais je ne suis pas sûr que ce soit la meilleure solution. On en a discuter dans le groupe de discussion IFFF. L'identifiant doit obligatoirement être autre chose que le nom car il est soumis à des changements (orthographe, nom d'auteur …), il faut donc conserver= notre code numérique. Au niveau de la base j'ai prévu une table permettant d'avoir les correspondances entre deux systèmes d'identifiants (je ne sais pas encore où et comment on l'intégrera au niveau de nos servicesXML). Remarque : Il faut savoir que dans la plupart des grands référentiels taxonomiques chaque taxon est identifié par un code et non pas par son nom. > Enfin la signification des attributs numnom et rangtaxo n'est pas > claire. En effet elle n'est décrite nulle part dans le document. Il faudrait les rajouter, cependant je ne sais pas trop où les faire apparaître. > 2.donneclassification.php > > remarque : il y a une erreur (typo) dans le DTD - #REDUIRED doit > être remplacé par #REQUIRED dans la ligne > <!ATTLIST CLASSIFICATION numclass CDATA #REDUIRED > > > Je ne suis pas sûr de comprendre l'objectif de la DTD. Est-ce de > définir des classifications indépendantes, avec les données suivante : > > FICHE_CLASSIFICATIONS correspond à la définition d'un ensemble > de classification (mais à quoi sert l'attribut numclass ?). numclass est l'identifiant d'une classification, il permet dans la liste d'identifier chaque classification et au niveau du service de ne ramener les données que sur une seule classification. > > CLASSIFICATION définit une classification avec > - DESCRIPTION, une description brève (ce serait bien d'avoir une > URL pointant sur la référence d'une description complète, > éventuellement correspondant à un organisme de référence - comme cela > se pratique pour XML par exemple). > - PREMIER_TAXON, la référence du taxon à la racine de la > classification. C'est à envisager cependant le but à ce niveau est d'être relativement indépendant, ne peut on pas considérer que l'on puisse mettre sous forme de teste une URL si nécessaire dans la description. > Si c'est le cas, je pense que l'exemple est peut-être mal choisi. > Il est certainement posible de trouver un Taxon englobant > Polygonacées et Oxalydacées, et les deux classifications sont en fait > des parties de la classification ayant ce taxon ancêtre commun comme > PREMIER_TAXON. Oui l'exemple n'est pas le meilleur, j'ai été au plus rapide. Le mieux serait par exemple d'avoir une classification moderne et celle employée par coste ou bonnier. Cependant l'exemple actuel peux être d'un usage réel, on peut penser que pour la réalisation d'une flore la classification servira de plan, dans ce cas on peut avoir une classification pour les orchidées employée pour une monographie sur ces mêmes orchidées et une classification générale pour une flore de France. > > 3.donneclassificationtaxons.php > > Je crois que le nom LISTE_CLASSIFICATION_FILLES est mal choisi parce > qu'il donne à penser que les éléments contenus sont des > CLASSIFICATION, alors qu'il s'agit en fait de CLASSIFICATION_TAXON. > Une meilleure appelaation, plus facile à réutiliser,serait peut- être > LISTE_TAXONS. En effet le nom est mal choisi, cependant la balise LISTE_TAXONS est déjà utilisée dans le service donnelistetaxons et a une autre signification. Il faut donc trouver un autre nom. > D'autre part, je pense qu'il est possible de simplifier les deux DTDs > correspondants aux services donneclassification.php et > donneclassificationtaxons.php et de les fusionner, à partir des > remarques suivantes: > - il n'y a pas vraiment de différences entre PREMIER_TAXON et > CLASSIFICATION_TAXON. On purrait juste définir un élément TAXON > - LISTE_CLASSIFICATIONS_FILLES est facultatif. > > On pourrait donc utiliser les DTD suivantes (avec le remplacement de > nom proposé ci-dessus) : > > Fichier common.dtd : > -------------------- > <?xml version="1.0" encoding="UTF-8"?> > > <!ELEMENT CLASSIFICATION (DESCRIPTION, TAXON)> > <!ATTLIST CLASSIFICATION numclass CDATA #REDUIRED > > > <!ELEMENT DESCRIPTION (#PCDATA)> > > <!ELEMENT TAXON (NOM_TAXON, LISTE_TAXONS?)> > <!ATTLIST TAXON numtaxo CDATA #REQUIRED > > > <!ELEMENT NOM_TAXON (NOM+)> > <!ATTLIST NOM_TAXON > numnom CDATA #REQUIRED > rangtaxo CDATA #REQUIRED > > > <!ELEMENT NOM (#PCDATA)> > <!ATTLIST NOM auteur CDATA #IMPLIED > > > <!ELEMENT LISTE_TAXONS (TAXON+)> > > Puis la DTD suivnte pour donneclassification.php : > > <?xml version="1.0" encoding="UTF-8"?> > <!ENTITY % COMMON SYSTEM "common.dtd"> > %COMMON; > > <!ELEMENT FICHE_CLASSIFICATIONS (CLASSIFICATION+)> > <!ATTLIST FICHE_CLASSIFICATIONS numclass CDATA #IMPLIED> > Techniquement c'est possible mais je me suis fixé une règle pour les balises optionnelles (avec un point d'interrogation dans la DTD). Que la balise soit optionnelles dans seulement les deux cas suivants:
Dans ce cas la balise LISTE_TAXONS est optionnelle et ne respecte pas cette règle, cela me semble vraiment dommage car cela n'apporte que des imprécisions. En lisant la DTD et la documentation du service on n'est plus capable de prévoir la structure du résultat. C'est donc quelque chose à éviter. D'une manière générale il me semble qu'il faut éviter toute simplification de DTD susceptible d'engendrer des ambiguïtés. > Et enfin la DTD suivante pour donneclassificationtaxons.php : > > <?xml version="1.0" encoding="UTF-8"?> > <!ENTITY % COMMON SYSTEM "common.dtd"> > %COMMON; > > <!ELEMENT FICHE_CLASSIFICATION_TAXONS (CLASSIFICATION, TAXON)> > <!ATTLIST FICHE_CLASSIFICATION_TAXONS > numclass CDATA #REQUIRED > numtaxo CDATA #IMPLIED > profondeur CDATA #IMPLIED > rangtaxo CDATA #IMPLIED > Techniquement c'est en effet possible, mais cependant cela signifie qu'il n'est plus possible d'avoir en même temps connaissance du premier taxon d'une classification et d'une partie seulement de cette classification. Cela me semble dommage car c'est un peu ambigu. Je préfère donc sur ce point la solution existante. D'autant plus qu'une classification peut être grande et qu'il est souhaitable de pouvoir y accéder par parties. > > Ces deux DTDs sont compatibles avec les exemples de > donneclassification.php et de donneclassficationtaxons.php: > > <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> > <FICHE_CLASSIFICATIONS> > <CLASSIFICATION numclass="1"> > <DESCRIPTION>Classification des Polygonacées basée > sur la bdnff. > </DESCRIPTION> > <TAXON> > <NOM_TAXON numnom="200000" rangtaxo="40"> > <NOM>Polygonaceae</NOM> > </NOM_TAXON> > </TAXON> > </CLASSIFICATION> > <CLASSIFICATION numclass="2"> > <DESCRIPTION>Classification des Oxalydacées basée sur > la bdnff. > </DESCRIPTION> > <TAXON> > <NOM_TAXON numnom="200001" rangtaxo="40"> > <NOM>Oxalidaceae</NOM> > </NOM_TAXON> > </TAXON> > </CLASSIFICATION> > </FICHE_CLASSIFICATIONS> > > Autre exemple : > <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> > <FICHE_CLASSIFICATION_TAXONS numclass="2" numtaxo="100025" > rangtaxo="110"> > <CLASSIFICATION numclass="2"> > <DESCRIPTION>2è me classification</DESCRIPTION> > <TAXON numtaxo="200001"> > <NOM_TAXON numnom="200001" rangtaxo="40"> > <NOM>Oxalidaceae</NOM> > </NOM_TAXON> > </TAXON> > </CLASSIFICATION> > <TAXON numtaxo="100025" > > <NOM_TAXON numnom="100025" rangtaxo="60"> > <NOM >Oxalis</NOM></NOM_TAXON> > <LISTE_TAXONS> > <TAXON numtaxo="4007" > > <NOM_TAXON numnom="47095" rangtaxo="100"> > <NOM auteur="L.">Oxalis acetosella</NOM> > </NOM_TAXON> > </TAXON> > <TAXON numtaxo="4008" > > <NOM_TAXON numnom="47102" rangtaxo="100"> > <NOM auteur="Savigny">Oxalis articulata</NOM> > </NOM_TAXON> > </TAXON> > <TAXON numtaxo="13136" > > <NOM_TAXON numnom="47110" rangtaxo="100"> > <NOM auteur="Lindl.">Oxalis bowiei</NOM> > </NOM_TAXON> > </TAXON> > </LISTE_TAXONS> > </CLASSIFICATION_TAXON> > </FICHE_CLASSIFICATION_TAXONS> Oui il est bien sur possible d'inclure des DTD dans une DTD. Je ne l'ai pas fait pour simplifier la lecture, de plus cela ne facilite pas le développement d'applications utilisant ces mêmes DTD (en effet le chargement et le stockage sont plus difficile à concevoir avec des DTD incluses, surtout pour travailler en mode déconnecté). Cependant en relisant la documentation des services je me suis aperçu que j'ai oublié de corriger la balise NOM_TAXON pour rajouter les balise BILIOGRAPHIE et BIBLIO_A_EXCLURE, car bien entendu le modèle sous- jacent doit être consistant, c'est à dire chaque DTD doit être compatible avec l'ensemble des éléments des autres DTD du projet eFlore. Remarque : de façon général on essayera d'éviter le nom TAXON comme nom de balise, car c'est trop général. En fonction du sujet abordé on est susceptible d'associer n'importe quel information à une balise TAXON, puisque tout le système consiste en définitive à associer des informations à des taxons. > 4.donnelistetaxons.php > Ma première remarque concerne les paramètres de la procédure > : > l'utilisation de valeurs minimales et maximales pour définir des > intervalles sur les noms semblent indiquer l'existence d'une relation > d'ordre, ce qui n'est généralement pas le cas dans les > chaînes alphabétiques correspondants aux noms. Si l'ordre alphabétique. > Il serait peut-être plus justifié d'utiliser des préfixes ou > des radicaux (ce qui est le cas de l'exemple : nommin=Oxalis et > nommax=Oxalis => cela revient à sélectionner tous les noms > commençant par Oxalis). On diviserait par deux le nombre de > paramètres et le critère de sélection serait peut-être plus clair. Ce n'est pas la même façon d'utiliser la liste. Le radical a d'ailleurs été demandé pour la mise en ligne de l'ISFF. Je pense que c'est complémentaire. Il faut mieux avoir le choix avec les paramètres même si certaines personnes n'utiliserons qu'un seul type d'interrogation que de se retrouver bêtement limité. De plus l'interrogation se fera rarement directement mais via une interface qui peut simplifier la saisie par exemple pour une interrogation par un préfix, l'interface s'occupera de générer les paramètres suivants : : nommin=Oxalis et nommax=Oxaliszzzzz. > Ma deuxième remarque concerne la liste d'attributs de NOM_TAXON : > BIBLIOGRAPHIE et BIBLIO_A_EXCLURE sont des éléments facultatifs. > Comme dans la discussion du paragrpahe 3, on pourrait les mettre dans > une DTD commune, ce qui peremttrait de réutiliser pour LISTE_TAXONS > la définition donnée ci-dessus, sans modification. Il n'y aurait > alors qu'un seul élément nouveau de défini pour cette procédure. Oui il faut que l'on tranche cette question des DTD incluses ou pas, et comment le présenter dans un document. > Voilà. > > Si vous avez des questions ou des commentaires sur ces quelques > remarques, n'hésitez pas à me contacter, ou a répondre par > la liste ! > > Jean-Christophe Conclusion : Cette intervention est très intéressante. Dans la démarche que j'ai adoptée pour l'écriture de ces formats de documents j'ai raisonné déjà en fonction du service mais en prenant en permanence en compte la consistance du modèle sous-jacent, sans jamais faire apparaître ce modèle dans les propositions de services. Il serait peut-être en effet souhaitable de le faire également apparaître. La description des services se limiterait dans ce cas à ne documenter que l'interface d'interrogation et l'encapsulation XML (balise FICHE_…) de la partie du modèle sous-jacent abordée. Par contre j'ai plus de difficultés pour percevoir la façon de documenter le modèle sous- jacent, dans le sens ou la réalisation d'une DTD est bien indispensable mais en aucune façon suffisante pour définir celui-ci. Jean-Chrisophe as tu une idée la dessus ? Pourrais-tu nous proposer quelques chose la dessus en prenant comme tu l'as déjà fait nos trois premiers documents XML comme base de travail? Existe t-il des exemples consultables sur le web pour ce problème ? Pour ce qui est des identifiants, je ne sais pas trop comment faire, c'est à la fois utile et complexe à mettre en place. Dans les documents actuels je ne vois pas bien l'intérêt de mettre cela en place, dans le sens ou l'information à identifier n'est présente qu'une fois et directement placé au bon endroit. Cependant il est très clair que pour de futurs services, il sera utile de les avoir comme par exemple une clef de détermination ou les caractéristiques d'un taxon (voir le format XDELTA). La difficulté réside sur 2 point l'identifiant doit commencer par une lettre et doit être unique. Le fait que l'attribut doit commencer par une lettre fait qu'il faut modifier la base de données en conséquence et que l'on s'écarte de la BDNFF. Surtout l'unicité de l'identifiant est vraiment problématique, peut-être devrait-on dissocier l’identifiant du document XML de celui= utilisé dans la base de données, il serait donc en plus et pas à la place. Amicalement frédéric. "Jean-Christophe Bottraud"Tue, 16 Oct 2001 20:00:54 +0200Bonjour, En continuant à réfléchir, après les commentaires de Frédéric, voici quelques commentaires ou suggestions complémentaires (j'ai repris uniquement les extraits nécessaires du message de Frédéric et de mon premier message, pour la discussion complète, voir Yahoo)... > En plus je ne souhaite pas m'écarter des identifiants de la BDNFF > (qui sont des entiers). Ce n'est pas vraiment un problème dans la mesure où un entier peut être transformé en chaîne alphanumérique simplement en le préfixant par un caractère alphabétique, qui peut être toujours le même (ex X1055 ou BDNFF1055). > Bref il y a du pour et du contre sur ce point. Dans les documents > actuels l'utilisation d'une référence me semble inutile, par contre > elle est peut-être souhaitable dans une clef de détermination par > exemple? Pour moi l'intérêt du couple ID/IDREF réside surtout dans la garantie de cohérence : un IDREF ne peut pas référencer un ID qui n'existe pas (donc une référence à un taxon parent est garantie de bien faire référence à un taxon qui existe). Avec l'inconvénient que cette cohérence est au niveau document ! > Remarque : Il faut savoir que dans la plupart des grands référentiels > taxonomiques chaque taxon est identifié par un code et non pas par > son nom. Est-ce qu'un de ces grands référentiels pourrait nous servir de référence ? (on utiliserait le même identifiant pour le même taxon, si cela a un sens) > > Je crois que le nom LISTE_CLASSIFICATION_FILLES est mal choisi >>....> > Une meilleure appellation, plus facile à réutiliser,serait peut- > être LISTE_TAXONS. > > > En effet le nom est mal choisi, cependant la balise LISTE_TAXONS est > déjà utilisée dans le service donnelistetaxons et a une autre > signification. Il faut donc trouver un autre nom. Je crois que c'est un des problèmes de l'approche choisie : en décrivant toutes les variantes possibles pour un élément (une liste de taxons en l'occurrence), on épuise vite les noms significatifs. Pour moi c'est l'indicateur d'un problème dans l'approche choisie. (mais voir plus loin, pour une approche alternative ou complémentaire ...) > > > Techniquement c'est possible mais je me suis fixé une règle pour les > balises optionnelles (avec un point d'interrogation dans la DTD). Que > la balise soit optionnelles dans seulement les deux cas suivants: > > - l'information n'existe pas dans la base de donnée (exemple : la > bibliographie). > - L'information n'a pas été demandée de façon explicite par > l'utilisateur via un paramètre dans l'interrogation d'un service > (exemple demander une classification jusqu'au niveau des espèces). Un problème que je vois à ces deux règles (mais c'est peut être mon problème à moi tout seul), c'est qu'elles concernent deux choses différentes : les données dans la base d'une part, les données de l'autre (mais cf. plus loin ...) > Dans ce cas la balise LISTE_TAXONS est optionnelle et ne respecte pas > cette règle, cela me semble vraiment dommage car cela n'apporte que > des imprécisions. En lisant la DTD et la documentation du service on > n'est plus capable de prévoir la structure du résultat. C'est donc > quelque chose à éviter. D'une manière générale il me semble qu'il > faut éviter toute simplification de DTD susceptible d'engendrer des > ambiguïtés. Strictement parlant, il n'y a pas d'ambiguïté : le service ne s'engage pas à fournir la donnée Bon d'accord, il ne s'engage pas non plus à ne jamais la fournir, ce qui peut conduire un utilisateur à penser qu'il lui faut prévoir le cas où cette donnée est fournie ... > > Et enfin la DTD suivante pour donneclassificationtaxons.php : > > > > <?xml version="1.0" encoding="UTF-8"?> > > <!ENTITY % COMMON SYSTEM "common.dtd"> > > %COMMON; > > > > <!ELEMENT FICHE_CLASSIFICATION_TAXONS (CLASSIFICATION, TAXON)> > > <!ATTLIST FICHE_CLASSIFICATION_TAXONS > > numclass CDATA #REQUIRED > > numtaxo CDATA #IMPLIED > > profondeur CDATA #IMPLIED > > rangtaxo CDATA #IMPLIED > > > Techniquement c'est en effet possible, mais cependant cela signifie > qu'il n'est plus possible d'avoir en même temps connaissance du > premier taxon d'une classification et d'une partie seulement de cette > classification. Cela me semble dommage car c'est un peu ambigu. Je > préfère donc sur ce point la solution existante. D'autant plus qu'une > classification peut être grande et qu'il est souhaitable de pouvoir y > accéder par parties. Je ne suis pas sûr que ce soit un problème parce que ce n'est pas la taille de la classification qui est en cause mais sa profondeur (la façon de faire présentée oblige à fournir tous les ascendants). Or quelle est la profondeur de la classification ? Même s'il y a 20 niveaux (ce que je ne crois pas être le cas), le surcoût n'est pas exagéré, et d'autre part il évite toute ambiguïté sur le positionnement d'un taxon (dont, à strictement parlé - encore une fois ;-) , l'identifiant est formé par la concaténation de son identifiant et de celui de tous les taxons ascendants). > Oui il est bien sur possible d'inclure des DTD dans une DTD. Je ne > l'ai pas fait pour simplifier la lecture, de plus cela ne facilite > pas le développement d'applications utilisant ces mêmes DTD (en effet > le chargement et le stockage sont plus difficile à concevoir avec des > DTD incluses, surtout pour travailler en mode déconnecté). Cependant > en relisant la documentation des services je me suis aperçu que j'ai > oublié de corriger la balise NOM_TAXON pour rajouter les balise > BILIOGRAPHIE et BIBLIO_A_EXCLURE, car bien entendu le modèle sous- > jacent doit être consistant, c'est à dire chaque DTD doit être > compatible avec l'ensemble des éléments des autres DTD du projet > eFlore
Par contre, le problème de l'organisation de l'information en documents ne va pas être simple :-( > > > Remarque : de façon général on essayera d'éviter le nom TAXON comme > nom de balise, car c'est trop général. En fonction du sujet abordé on > est susceptible d'associer n'importe quel information à une balise > TAXON, puisque tout le système consiste en définitive à associer des > informations à des taxons. Je ne sais pas. Il me semble que TAXON devrait être utilisé une fois (mais une seule, je suis d'accord) ne serait-ce que pour avoir un point d'ancrage pour lier toutes les informations susceptibles d'être associées à un taxon. On peut ensuite bien sûr dériver tous les noms nécessaires. > > > 4.donnelistetaxons.php > > Ma première remarque concerne les paramètres de la procédure > > : > > l'utilisation de valeurs minimales et maximales pour définir des > > intervalles sur les noms semblent indiquer l'existence d'une > relation > > d'ordre, ce qui n'est généralement pas le cas dans les > > chaînes alphabétiques correspondants aux noms. > > Si l'ordre alphabétique. A-t-il un sens dans la classification ? ou s'agit-il juste d'un moyen de limiter le nombre de taxons obtenus (et dans ce cas, autant spécifier directement une quantité max.) ? > Il faut mieux avoir le choix avec les > paramètres même si certaines personnes n'utiliserons qu'un seul type > d'interrogation que de se retrouver bêtement limité. Ca, c'est bien vrai .... > > Ma deuxième remarque concerne la liste d'attributs de NOM_TAXON : > > BIBLIOGRAPHIE et BIBLIO_A_EXCLURE sont des éléments facultatifs. > > Comme dans la discussion du paragrpahe 3, on pourrait les mettre > dans > > une DTD commune, ce qui peremttrait de réutiliser pour LISTE_TAXONS > > la définition donnée ci-dessus, sans modification. Il n'y aurait > > alors qu'un seul élément nouveau de défini pour cette procédure. > > Conclusion (où on se trouve enfin au "plus loin" annoncé!) : > > Dans la démarche que j'ai > adoptée pour l'écriture de ces formats de documents j'ai raisonné > déjà en fonction du service mais en prenant en permanence en compte > la consistance du modèle sous-jacent, sans jamais faire apparaître ce > modèle dans les propositions de services. Il serait peut-être en > effet souhaitable de le faire également apparaître. La description > des services se limiterait dans ce cas à ne documenter que > l'interface d'interrogation et l'encapsulation XML (balise FICHE_…) > de la partie du modèle sous-jacent abordée. Par contre j'ai plus de > difficultés pour percevoir la façon de documenter le modèle sous- > jacent, dans le sens ou la réalisation d'une DTD est bien > indispensable mais en aucune façon suffisante pour définir celui-ci. > Jean-Chrisophe as tu une idée la dessus ? > Pourrais-tu nous proposer quelques chose la dessus en prenant comme > tu l'as déjà fait nos trois premiers documents XML comme base de > travail? > Existe t-il des exemples consultables sur le web pour ce problème ? Ma première réaction est de dire que notre problème correspond en fait à celui qu'adresse les spécifications SOAP. En gros, SOAP (cf. http://www.w3.org/TR/SOAP/). correspond à un standard pour décrire les services fournit par un serveur, en précisant les messages disponibles, le contenu des messages, les erreurs possibles, etc. Le standard utilise XML. Un message SOAP est composé de plusieurs parties : un en-tête, donnant des informations sur le message (sa nature en particulier), le corps de message (qui peut être un message d'erreur), et une fin de message. Le message ne fait pas référence à une DTD, ce qui laisse pas mal de souplesse, et il me semble que la description permet de décrire les informations disponibles. Ce serait peut être une solution qui nous permettrait de réserver les DTDs à la description des documents et les descriptions SOAP aux services. Je vais essayer de creuser un peu. > Pour ce qui est des identifiants, je ne sais pas trop comment faire, > c'est à la fois utile et complexe à mettre en place. Dans les > documents actuels je ne vois pas bien l'intérêt de mettre cela en > place, dans le sens ou l'information à identifier n'est présente > qu'une fois et directement placé au bon endroit. Cependant il est > très clair que pour de futurs services, il sera utile de les avoir > comme par exemple une clef de détermination ou les caractéristiques > d'un taxon (voir le format XDELTA). La difficulté réside sur 2 point > l'identifiant doit commencer par une lettre et doit être unique. Le > fait que l'attribut doit commencer par une lettre fait qu'il faut > modifier la base de données en conséquence et que l'on s'écarte de la > BDNFF. Surtout l'unicité de l'identifiant est vraiment problématique, > peut-être devrait-on dissocier l'identifiant du document XML de celui > utilisé dans la base de données, il serait donc en plus et pas à la > place. Le problème de la cohérence avec la BDNFF ne me semble pas en être un si on prend une règle du type (par exemple): identifiant XML = X + identifiant BDNFF soit : si la BDNFF utilise 1055, les documents XML utiliseront X1055 (ou BDNFF1055, ou autre chose ...). Voilà. Encore une fois, n'hésitez pas à réagir ! Cordialement, Jean-Christophe 5. Gestion du projet5.1. Eflorephp"Frederic legens"Wed, 16 May 2001 07:28:19 +0200Bonjour, L'environnement informatique nommé eflorephp, fonctionnant sous windows est enfin terminé. Il consiste en la livraison d'un installable contenant :
Cet installable est téléchargeable à partir de l'url suivant : http://eflore.tela-botanica.org. Il vous permettra pour l'instant de prendre part au développement si vous le souhaitez. Le "site" http://eflore.tela-botanica.org, nous permettra de stocker les fichiers téléchargeables et de documenter les différents aspects du projet. Et encore merci à Jean-charles pour son aide. 5.2. CVSDavid DelonSat, 13 Oct 2001 11:30:57 +0200Bonjour, Le projet eflore est donc crée sur sourceforge.net. Pour le moment la page d'accueil renvoi sur http://eflore.tela-botanica.org, vous pouvez y accéder par http://eflore.sourceforge.net . Les personnes désirant intervenir sur le projet pour apporter de la documentation, des développements, des traductions ... doivent s'inscrire sur http://sourceforge.net en suivant le lien : "Nouvel Utilisateur via SSL". Ensuite elles devront me communiquer leur identifiant sourceforge (login) pour que je les autorise en mise à jour sur CVS. La récupération du projet pourra se faire de également de façon anonyme à partir de eflore.sourceforge.net. L'utilisation de CVS se fait à partir de Windows (Wincvs), Mac (MacCVS) et Linux. Par contre, comme la communication est sécurisé (cryptée) elle peut être délicate à mettre en place. Je donnerai bientôt toute les indications nécessaire pour le faire, vous pouvez récupérer dès maintenant les utilitaires suivants :
http://www.cvsgui.org/download.html : récupérer : Windows WinCvs 1.2 *STABLE* / Client + Local / Binaries ou Mac MacCvs 3.1 *STABLE* / Client Only / Binaries (Classic MacOS 8/9)
Windows : sfsetup.zip http://sfsetup.sourceforge.net/#sfsetup Mac : MacSSH - MacOS Secure Shell |
|
|
|
|