Skip to content

GitLab

Open
Created by Cyril Pommier@cyril.pommierOwner

Widget Ontology

code source actuel

GIT: https://github.com/gnpis/trait-ontology-widget

Contraintes de Portabilité

le widget doit pouvoir être utilisé dans une page html statique (par ex: https://urgi.versailles.inra.fr/ontologyportal) ou dans FAIDARE. L'ancienne version incluse dans GWT sera laissée dans une branche à part. Exemple existant:

<div id="brapiCropOntoWidget"></div>
	<script type="text/javascript" src="https://urgi.versailles.inra.fr/files/ephesis/trait-ontology/widget-v2/cropOntologyWidget.min.js"></script>
	<script type="text/javascript">
		var widget = new CropOntologyWidget("#brapiCropOntoWidget", {
			"breedingAPIEndpoint": "/ws/webresources"+"/brapi/v1",
			"showCheckBoxes": false, "useSearchField": true
		});
	</script>

        </div>

Principes

Modèle de données

Les json retournés par le web service est basé sur un triplet variable = trait + methode + scale. Ce triplet au complet est contenu dans le json, ainsi que l'ontologyId et ontologyName. Voir :

L'arborescence à afficher suit le modèle:

graph TD
  a(ontology)-->b(trait.class)
  b(trait.class)-->c(trait.name)
  c(trait.name)-->d(variable.name)

Source Web service / fichier

La souplesse de ce système repose sur la capacité à utiliser directement les fichier versionnées dans gitlab et stockés dans un web folder

Le web service est donc très simple. Il permet de charger toutes les ontologies, puis de charger toutes les observations variables

Le principe du widget est de charger toutes les ontologies, puis de faire des recherches uniquement client side. Le widget reçoit la liste brute des observation variables.
Le widget doit pouvoir exposer programmatiquement la liste des ID qui ont été sélectionnés par l'utilisateur, liste qui sera utilisée pour la recherche comme une facette/bucket. De même, il peut également prendre en entrée la liste des observationVariableId a utiliser et pré-cocher celles-ci une fois chargées.

Decision suite au call du 27 juillet

Un widget angular. Web service :

  • une API Faidare à façon qui remonte l'arbre de recherche. Cette arbre doit pouvoir permettre des recherches via le nom des variables et des traits. Il doit donc contenir les niveaux ontology, trait class et trait au complet, plus le niveau observationVariable avec uniquement les propriétés name, ID et synonymes. question : vu que cet arbre est assez riche, ne vaudrait il pas mieux preconstruire la totalité de l'arbre coté serveur, avec toutes les propriétés des observationVariable, et le remonter tel quel (taille non compressée: 7 Mo à priori, 500 ko compressé)
  • le call /brapi/v1/variables/{observationVariableDbId} pour afficher les détails de chaque observation variable.

Amélioration nécessaire des performances

L’initialisation du widget est de plus en plus coûteuse car il charge la totalité des ontologies et leurs variables d'observation avant affichage du widget.

  • Proposition de lazy loading pour le portail:
    1. get ontologies curl -X GET "https://urgi.versailles.inra.fr/faidare/brapi/v1/ontologies"
    2. get observationVariables by ontologyId (Post - /search/variables) : curl -X POST "/search/variables" { "ontologyDbIds": ["f44f7b23"]}
      NB: web service à implémenter, le backend fonctionne actuellement par fichier.
  • Proposition de lazy loading pour une approche facette :
    1. Via le bucket, récupérer la liste de toutes les variables de la recherche courante
    2. Via le web service récupérer les observation variables, le widget saura les reconstruire.
      NB: la méthode public List<ObservationVariableVO> getVariableByIds(Set<String> identifiers) existe mais n'est à priori pas exposée dans le web service.

Fonctionnalités minimales à valider

  • Réutiliser le web service actuel
  • Ajouter un web service observationVariable/ontologyId pour le lazy loading
  • Permettre au widget de n'afficher que les variables du bucket correspondant (@maud.marty , au vu du template de transformation je pense que ces id sortent déjà , pourrais tu vérifier stp)
  • Permettre au widget de filtrer les résultats en fonction des variables sélectionnées.

Fonctionnalités supplémentaires si le temps le permet

  • Permettre de charger directement un fichier d'ontology de ce type
  • Implementation du backend en elasticsearch. Ceci permet d'avoir un pool d'observation variable provenant des partenaires plutôt que provenant de plusieurs fichiers.
  • Chargement dans elasticsearch et requêtage. @maud.marty étudie le coté ETL :
Edited by Cyril Pommier