Spécification interface Web pour descriptions botaniques

$Header$

Les données

Spécification

En attendant d'avoir des données correspondant à un modèle sémantique solide, nous allons exploiter la structure existante dans les flores, en terme d'Organes ayant une suite de propriétés textuelles "brutes". On souhaite faire des requêtes à la Google étendues du genre:

family:Rosaceae basal_leaves:glabrous petals:5,yellow spine: edible

//species[ .//family="Rosaceae"]
              [contains( .//leaf/basal, "glabrous")]
              [contains( .//petals, "five")]
              [contains( .//petals, "yellow")]
              [ .//spine ]
              [contains( .,"edible") ]

• le nombre d'espèces satisfaisant la requête;
• des hyperliens vers les 100 premières; si moins de 100 réponses, on enverra une page contenant:
  • les descriptions complètes de toutes les réponses, avec un formattage et un moteur de requête XSLT + Javascript permettant d'affiner la recherche sans repasser par le serveur (prototype de la page interactive XSLT + Javascript);
  • un champ de saisie pour pouvoir modifier et relancer la requête initiale.
  • Un historique de la session, i.e. les requêtes successives; avec possibilité de rejouer les requêtes et de terminer la session
  • un diagramme ensembliste (diagramme de Venn) donnant les cardinalités de chaque sous-ensemble; ce diagramme sera cliquable, i.e. chaque sous-ensemble pourra permettre de rejouer ou d'affiner la requête correspondante. On pourra ainsi relancer la recherche dans une autre direction, surtout si la requête courante a donné zéro résultat.
  • le nombre de familles satisfaisant le critère, avec un hyperlien sur leur description
  • l'ensemble des Organes concernés par la requête courante, i.e. la réunion, pour toutes les espèces satisfaisant la requête, des organes effectivements décrits dans le document;

    Note: il se peut que des critères visibles sur l'échantillon ne soient pas présents dans la description correspondante; en fait, il faut accepter le fait que les descriptions sont toujours incomplètes. Donc il est utile de pouvoir connaitre les Organes effectivement décrits dans l'ensemble qui nous intéresse.

  • des hyperliens pour toutes les possibilités de couples Organe-mot, ou mieux encore des couples Organe-Propriétés (e.g. au lieu de "pétales jaunes" - "pétales rouges" etc, seulement pétale-couleur)

    Pour ordonner ces hyperliens Organe-Propriété, on peut évaluer leur Pouvoir Discriminant ainsi. D'abord si la Propriété est uniformément répartie, plus il y a de valeurs, et plus le Pouvoir Discriminant est grand. Maintenant si une des valeurs a beaucoup d'occurences, on risque de se retrouver avec un grand ensemble si notre échntillon a justement cette valeur. C'est le cas pire. On ordonnera donc les Propriétés (en sens inverse) par la quantité suivante: le maximum du nombre d'occurence pour toutes les valeurs existantes dans l'ensemble courant.

    • Dans un premier temps, on montrera seulement la liste des balises présentes dans le document; cliquer sur un nom de balise permettra d'ajouter un critère à la requête
  • un bouton "ratisser large", qui génére une requête moins restrictive, tenant compte:
    • des relations d'inclusions entre Organes (e.g. pétales jaunes ==> fleur jaune ), c'est à dire que la recherche pétale:jaune recherchera aussi fleur:jaune
    • des propriétés connues des familles possibles

On placera chaque fois que possible des hyperliens vers les définitions des termes botaniques. On essaiera de présenter des icones en plus ou à la place des libellés pour les Organes, et éventuellement pour les Propriétés. Les mots de la recherche (balises et contenus) seront colorés soit tous en jaune, soit (de préférence) avec une couleur par critère.

Problèmes

• génération de diagrammes de Venn: pas évident, et je n'ai pas trouvé de source sur Internet; il y a une problématique de mise en page, chaque intersection 2 par 2, 3 par 3, etc peut être vide ou non
• question annexe mais c'est plus de l'optimisation: si on fait les requêtes élémentaires avec eXist, comment peut-on obtenir ces intersections 2 par 2, 3 par 3, etc sans refaire 2ⁿ requêtes eXist (hélas 2ⁿ c'est le nombre de sous-ensembles d'un ensemble de taille n)
• comment donner à voir les balises (= Organes) et existantes et disponibles: par ordre alphabétique, ou par grande catégorie morphologique (plante entière, racine, tige, feuille, fleur, fruit, graine)
• récupérer description familles avec même formalisme que les espèces: partir de Flore de Chine ou d'une base Delta ?
• comment avoir un combo box en HTML? Application:
  • Organes
  • mots au sein des Organes
• faut-il avoir une double modalité de saisir les groupes Organe+mots?
  • simple saisie d'une chaîne à la Google
  • IHM avec bouton "ajouter un critère/contrainte" + bouton "ajouter un mot"

Design

Let's switch to English here; I'll translate the beginning when I'll have time.

Objects

The most important object is obviously the Query, with two properties: the "Google" style query,

family:Rosaceae basal_leaves:glabrous petals:5,yellow

and the XPath query (adapted to the actual structure of the XML data) :

//species[family="Rosaceae"]

              [contains( leaf/basal, "glabrous")]

              [contains( petals, "five")]

              [contains( petals, "yellow")] 

In fact a Query is an aggregation of one or more Criterium objects; in this example we have four (petals have two criteria). In turn a Criterium essentially connects an Organ and a plain Word. The Word is possibly connected to a Property (e.g. yellow with color ).

This is the query aspect. Now for the result aspect, a Query is associated with a set of Species, and a set of Families, both satisfying the Query.

Criterium class diagram in SVG - Criterium class diagram in PNG (Poseidon/ArgoUML source file) :

Note: the results for the Query is the intersection of the results for all the Criterium objects.

Now for the user interaction package, we have:

• a session having an history
• an history is essentially an ordered list of queries

Software tools

We will use an XML database compliant with the XML:DB standard. At least two free products exist: namely -;) eXist, and apache.org/xindice . We need a linguistic tool to try to associate a Word with a Property . I allready used WordNet to prepare the XML data set, so it just natural to continue using it.