Retour : page principale > sommaire de la version 0 d'eFlore > sommaire de la synthèse
Mon, 25 Jun 2001 22:36:34 +0200
Frederic legens
Bonjour,
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 +0200
Bonjour,
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 +0200
Bonjour
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. Commentaires
jean-christophe bottraud
Mon, 08 Oct 2001 07:56:28 -0000
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.
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 !
flegens
Wed, 10 Oct 2001 07:39:06 -0000
Merci 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 +0200
Bonjour,
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
4. Phase 1B - Services - Approfondissement
4.1. Maquette
Mon, 25 Jun 2001 22:36:34 +0200
Frederic legens
Bonjour,
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 +0200
Bonjour,
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 +0200
Bonjour
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. Commentaires
jean-christophe bottraud
Mon, 08 Oct 2001 07:56:28 -0000
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.
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 :
- o 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).
- o un ID est nécessairement alphanumérique, ce qui est facilement contournable en mettant un préfixe (par exemple cumclass='2' deviendrait numclass='C2').
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
- o 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).
- o PREMIER_TAXON, la référence du taxon à la racine de la classification.
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:
- o il n'y a pas vraiment de différences entre PREMIER_TAXON et CLASSIFICATION_TAXON. On purrait juste définir un élément TAXON
- o 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>
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 !
flegens
Wed, 10 Oct 2001 07:39:06 -0000
Merci 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:
- o l'information n'existe pas dans la base de donnée (exemple : la bibliographie).
- o 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).
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 +0200
Bonjour,
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
- Cette position me pose vraiment un problème, qui est liée à l'approche actuelle que je trouve trop orienté services (mais cela n'engage que moi). Il est clair que nous (enfin, moi au moins) n'avons pas une vision claire des informations qui pourrait figurer dans une Flore de France numérique (et de plus sur le Web). Mais il me semble qu'il faut distinguer deux choses :
- o la formalisation des données (ou des documents qui les contienent) d'une part,
- o la formalisation des vues sur ces données, fournies par les services, d'autre part. Et je crois que si le système prend de l'ampleur, la seule façon d'obtenir un système cohérent sera de ne définir chaque description d'élément qu'une fois, quelque soit son concept d'utilisation, et d'appeler cette description chaque fois que nécessaire (c'est d'ailleurs le problème qui semble s'être produit avec NOM_TAXON et BIBLIOGRAPHIE ?). Je ne crois pas que la gestion des fichiers à inclure soit très difficile, puisqu'on peut créer un fichier contenant toutes les définitions disponibles (qui servira donc d'index) et inclure systématiquement ce fichier. Si les références de fichier sont toutes relatives, le développement d'application ne doit pas s'en trouver trop compliquer ?
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