Sprint Review #15W26: consolidation

Ce sprint n°13 a été consacré à la consolidation de l’outil ezVIS.
Nous avons principalement modifié la documentation et corrigé des bugs.

Tâches

  • 20 tâches prévues
  • 18 tâches effectuées (dont 15 avaient été prévues)
  • 24 tâches au total
  • plus de 24 points de complexité prévus
  • 37,5 points de complexité effectués

Le nombre de points de complexité prévus était très peu précis, car nous avions plusieurs bugs.
Les bugs sont par définition difficile à estimer.
N’ont pas été comptabilisés ici les travaux de déclaration des bugs par les documentalistes/utilisateurs.

Production

Basculements des URL publics

Les URL publics des rapports du service Appui au Pilotage de l’Inist pointent maintenant sur la machine de production dont la mise au point a été finalisée (via puppet).
Au passage, les instances ont été copiées de la machine d’intégration vers la machine de production (et vérifiées par les gestionnaires de ces instances).

Augmentation de l’espace disque

À cause de la manière dont ezVIS gère le cache des requêtes qu’il utilise, la place utilisée par une de ses instances dans la base de données augmente à mesure que ses utilisateurs en font des usages variés.

C’est pourquoi nous avons fait augmenter par le service Ingénierie de Production l’espace disque disponible sur la machine de production (c’était 10 Go au total sur la machine d’intégration, c’est 200 Go sur la machine de production).

Bugs

Déclaration des bugs par les gestionnaires

Ce sprint ayant été dédié à la consolidation d’ezVIS, nous avons demandé aux gestionnaires des instances déjà existantes de faire une déclaration formelle des bugs qu’ils ont rencontré.
De plus, ils ont dû faire en faire qu’on puisse reproduire ces bugs.
Nous avons donc utilisé l’application ezREF présente sur la machine d’intégration, et fait utiliser l’interface de dépôt de fichiers sur ce serveur pour y mettre:

  • la description du dysfonctionnement (dans un fichier *README.txt)
  • la configuration de l’instance (dans un fichier *.json)
  • le(s) corpus dans un ou plusieurs fichier(s) dont préfixe était commun à tous les fichiers concernant ce bug.

Tout le monde a parfaitement joué le jeu et nous avons obtenu la description de 5 bugs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(-rw-rw-r--)    3.6M    Bibliotep_XML_14_08_corpus_final_NCT.xml
(-rw-rw-r--) 4.2M Bibliotep_XML_14_10_corpus_final_NCT.xml
(-rw-rw-r--) 438B Bibliotep_XML_bibliotep.README.txt
(-rw-rw-r--) 25.4k Bibliotep_XML_bibliotep.json
(-rw-rw-r--) 1.1k bibliotep_entier_pertes.README.txt
(-rw-rw-r--) 6.0k bibliotep_entier_pertes.json
(-rw-rw-r--) 1.7M bibliotep_entier_pertes_2005-2006.csv
(-rw-rw-r--) 2.5M bibliotep_entier_pertes_2006-2007.csv
(-rw-rw-r--) 2.7M bibliotep_entier_pertes_2007-2008.csv
(-rw-rw-r--) 2.7M bibliotep_entier_pertes_2008-2009.csv
(-rw-rw-r--) 2.8M bibliotep_entier_pertes_2009_2010.csv
(-rw-rw-r--) 2.6M bibliotep_entier_pertes_2010-2011.csv
(-rw-rw-r--) 2.7M bibliotep_entier_pertes_2011-2012.csv
(-rw-rw-r--) 2.7M bibliotep_entier_pertes_2012-2013.csv
(-rw-rw-r--) 2.2M bibliotep_entier_pertes_2013-2014.csv
(-rw-rw-r--) 2.7M bibliotep_entier_pertes_2014-2015.csv
(-rw-rw-r--) 6.3k jsoncorpus_istex.json
(-rw-rw-r--) 498B jsoncorpus_istex_README.txt
(-rw-rw-r--) 30.7M jsoncorpus_istex_data.json
(-rw-rw-r--) 25.2k maj_config-corpus_ezpaarse_CONFIG-ancienneconfig.json
(-rw-rw-r--) 25.9k maj_config-corpus_ezpaarse_CONFIG-nouvelleconfig.json
(-rw-rw-r--) 5.2M maj_config-corpus_ezpaarse_CORPUS-initial.csv
(-rw-rw-r--) 5.2M maj_config-corpus_ezpaarse_CORPUS-modifie.csv
(-rw-rw-r--) 995B maj_config-corpus_ezpaarse_README.txt
(-rw-rw-r--) 5.7k wos_france_lux_csv.json
(-rw-rw-r--) 2.9M wos_france_lux_csv_CORPUS.csv
(-rw-rw-r--) 1.1k wos_france_lux_tsv-csv_README.txt
(-rw-rw-r--) 5.8k wos_france_lux_tsv.json
(-rw-rw-r--) 1.5M wos_france_lux_tsv_CORPUS-SansGuillemet_1-500Ref.txt
(-rw-rw-r--) 1.4M wos_france_lux_tsv_CORPUS-SansGuillemet_501-999Ref.txt
(-rw-rw-r--) 1.5M wos_france_lux_tsv_CORPUS_1-500Ref.txt
(-rw-rw-r--) 1.4M wos_france_lux_tsv_CORPUS_501-999Ref.txt

Correction du chargement incomplet

Dans plusieurs des bugs déclarés, lors du chargement des données au premier lancement, ezVIS ne rendait pas la main: la déclaration Files and Database are synchronised. n’arrivait pas (même quand tous les documents avaient été chargés), et donc encore moins le calcul des corpusFields (les métriques sur le corpus).
Souvent d’ailleurs, on pouvait contourner ce problème en relançant simplement l’instance (ezVIS détectait alors que le(s) fichier(s) n’avaient pas changés, et passait directement à l’étape suivante: le calcul des métriques).

Il s’est avéré que ce cas arrivait quand une erreur survenait lors du chargement (soit un problème de parsing du fichier, soit un problème JBJ lors du calcul des documentFields).
L’analyse a révélé que lors du chargement, les erreurs étaient complètement ignorées, et qu’ezVIS essayait quand même de traiter les données, sans même afficher l’erreur.

Dorénavant, l’erreur est affichée, accompagnée du nom du fichier et du numéro du document, dans ce fichier, pour lequel l’erreur s’est produite.

Exemple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
$ ezvis bibliotep_entier_pertes
Core version : 2.5.0
Configuration : /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes.json
Theme : /home/parmentf/dev/castorjs/ezvis
App : ezvis 6.7.3
Source : /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes
Server is listening on port 3000: http://localhost:3000
Index field : annee/annee_1
Index field : titre/titre_1
Index field : wid/wid_1
Index field : neoplasms/neoplasms_1
Index field : techniques/techniques_1
Index field : pays/pays_1
Index field : auteurs/auteurs_1
Index field : vpmid/vpmid_1
Index field : elements/elements_1
Index field : pmid/pmid_1
Index field : anatomical/anatomical_1
Index field : isotopes/isotopes_1
Index field : source/source_1
Index field : text/text_text
error [TypeError: Cannot call method 'slice' of undefined] in file /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes/bibliotep_entier_pertes_2014-2015.csv document # 3431
error [TypeError: Cannot call method 'slice' of undefined] in file /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes/bibliotep_entier_pertes_2014-2015.csv document # 3643
error [TypeError: Cannot call method 'slice' of undefined] in file /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes/bibliotep_entier_pertes_2014-2015.csv document # 3645
error [TypeError: Cannot call method 'slice' of undefined] in file /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes/bibliotep_entier_pertes_2014-2015.csv document # 3738
error [TypeError: Cannot call method 'slice' of undefined] in file /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes/bibliotep_entier_pertes_2014-2015.csv document # 3855
error [TypeError: Cannot call method 'slice' of undefined] in file /home/parmentf/dev/castorjs/bugs/bibliotep_entier_pertes/bibliotep_entier_pertes_2014-2015.csv document # 3895
Files and Database are synchronised.
127.0.0.1 - - [20/Jul/2015:15:41:03 +0000] "GET /compute.json?operator=count&field=wid HTTP/1.1" 200 - "-" "-"
127.0.0.1 - - [20/Jul/2015:15:41:03 +0000] "GET /compute.json?operator=distinct&field=annee HTTP/1.1" 200 - "-" "-"
127.0.0.1 - - [20/Jul/2015:15:41:03 +0000] "GET /compute.json?operator=distinct&field=isotopes HTTP/1.1" 200 - "-" "-"
Corpus fields computed.

Cette correction a modifier le comportement d’ezVIS sur plusieurs des bugs déclarés, révélant alors que c’était plutôt les fichiers d’origine qui ne respectaient pas le format demandé (CVS et l’échappement des guillemets, par exemple).

Voir sur GitHub: #46.

Correction: mettre à jour l’instance quand la configuration est modifiée

Un comportement pratique d’ezVIS a cessé de fonctionner il y a déjà quelques sprints: quand on modifie la configuration d’une instance et qu’on la relance sans modifier les données, les documents ne prennent pas en compte les modifications de la configuration.
En particulier, quand un gestionnaire modifie les documentFields, ces nouveaux champs ne sont calculés que pour les nouveaux documents (ou pour aucun). C’est très handicapant quand on met au point une configuration car on est alors contraint, quand on passe par ezMaster, de supprimer l’instance et de la recréer (ce qui implique de recharger les données).

Ce comportement a été rétabli: quand on modifie une configuration, si les documents sont plus anciens que le fichier de configuration, ezVIS les mets à jour en prenant en compte la nouvelle configuration.

Voir sur GitHub: #49.

Correction: mettre à jour l’instance quand les fichiers sont modifiés

Quand un fichier déjà chargé dans l’instance est remplacé par un fichier du même nom mais contenant des lignes en moins, les lignes ne disparaissaient pas.

Après une enquête approfondie (merci à Yannick pour son aide), nous avons trouvé et corrigé le bug.

Voir sur GitHub: #50.

ATTENTION : il est possible que des métriques faisant un comptage des documents ne soient pas mises à jour immédiatement. Dans ce cas, il est nécessaire de redémarrer l’instance (ou de la mettre en pause de la relancer, via ezMaster) pour bénéficier d’un calcul à jour.

Nouvelle documentation

Il commençait à être difficile de s’y retrouver dans l’ancienne documentation d’ezVIS, qui tenait sur une page, mais était dépourvue de table des matières (et souvent faisait référence à la documentation d’autres projets).

Il a donc été décidé d’utiliser un système dédié à la documentation de projets informatiques, qui se base sur le même format que l’ancienne documentation (Markdown): ReadTheDocs.

La nouvelle documentation, divisée en pages plus courtes, et agrémentée d’illustrations, est donc disponible sur http://ezvis.readthedocs.org/ ou http://ezvis.rtfd.org/.
Elle est mise à jour à chaque mise à jour du dépôt GitHub, et responsive (lisible sur un téléphone mobile).
Au besoin, on pourrait même en garder des versions différentes (une pour la version 6.*, et une pour la version suivante, par exemple).

Voir sur GitHub: #51.

Meilleurs messages d’erreur

oubli de lancer MongoDB

Quand on a oublié MongoDB avant de lancer ezVIS, il y a maintenant un message d’erreur:

1
failed to connect to [localhost:27017]

Il est certes sibyllin, mais il est difficile de faire mieux (principalement en raison du fait qu’ezVIS n’établit la connexion à MongoDB que lorsqu’il en a besoin).

oubli du paramètre

ezVIS a un paramètre obligatoire: le chemin du répertoire où se trouvent les fichiers contenant les données.
Auparavant, le message était très technique, et même les programmeurs avaient besoin de toute leur expérience pour le comprendre.

Maintenant c’est celui ci:

1
2
3
4
5
$ ezvis
Usage:
ezvis data
data being a directory path, and data.json the settings file.
See https://github.com/madec-project/ezvis for more details.

Voir sur GitHub: #52.

Erreurs JBJ

Afin de pouvoir afficher les erreurs JBJ (dues à la configuration des documentFields, corpusFields et flyingFields), nous avons mené une opération d’homogénéisation du traitement des erreurs dans JBJ.
Il sont maintenant traités comme n’importe quelle erreur dans ezVIS (en particulier lors du chargement des données).

Voir sur GitHub: #56.

Camemberts: position des légendes lorsque des labels sont précisés

Dans un pie, quand on déclare des labels, la position de la légende n’était pas prise en compte (voir image ci-dessous).

Ex:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"field": "Prf",
"type": "pie",
"title": "Projets de recherche fédératifs (PRF) - PRF avec labels ds chart",
"legend": {
"position": "right"
}
,

"labels": {
"ESU": "ESU - Environnement sonore urbain",
"Eval-PDU": "Eval-PDU - Evaluation environnementale des plans de déplacements urbains",
"GEOCONURB": "GEOCONURB - Géo-connaissances urbaines",
"MUE": "MUE - Microclimat urbain et énergie",
"ONEVU": "ONEVU - Observatoire nantais des environnements urbains",
"PUD": "PUD - Projet urbain durable",
"SOLURB": "SOLURB - Sols urbains",
"V&I": "V&I - Ville et image"
}
,

"removeLabels": "true",
}

C’est maintenant fonctionnel.

Voir sur GitHub: #55.

JBJ

Nouveaux alias: getIndex & getIndexVar

Quand getProperty et getPropertyVar sont appliqués à un tableau, il est plus naturel d’utiliser getIndex et getIndexVar (cliquez sur les liens pour voir des exemples dans la documentation de JBJ version ReadTheDocs).

Voir sur GitHub: #60.

JBJ Playground

Voir sur GitHub: #61.

Recherche dans les exemples

Nous avions déjà une recherche dans les actions, mais pas dans les exemples.
C’est fait.

Voir sur GitHub: f8cde74.

Agrandissement des éditeurs

La taille des INPUT, STYLESHEET et RESULT était fixe. Elle est maintenant dépendante de la largeur de la fenêtre du navigateur.

Voir sur GitHub: PR 12.

Supprimer les préfixes des exemples (Basic: find)

Les exemples étaient initialement classés par sujet, et partageaient leur input.
Nous avons supprimé le premier niveau (sujet).
Nous en avons aussi profité pour supprimer un effet de bord gênant: quand une feuille de style modifiait l’input, elle le modifiait aussi pour les autres exemples du même sujet. Chaque exemple est maintenant indépendant.

Voir sur GitHub: e3915c3.

Ajouter un champ URL

Nous avons ajouté un champ URL sous l’input pour pouvoir remplir cet éditeur avec la réponse d’une requête renvoyant du JSON.

Voir sur GitHub: 8174aae.

ezVIS: ajouter des boutons vers le JBJ Playground

Quand on ajoute dans la configuration d’ezVIS une propriété addlinkstojbj à true, on ajoute un lien vers le JBJ Playground :

  • dans la page d’affichage d’une notice (/display/) 7f51427
  • dans la liste des documents (/documents.html) 25f64c3
  • dans les graphiques (/chart.html) c0dad22

Voir dans la documentation, l’annexe sur JBJ.

Voir sur GitHub: #62.

castor-clean: message explicite

Auparavant, castor-clean était une commande muette: qu’elle ait accompli sa mission ou non, l’utilisateur n’en savait rien.

Maintenant, quand tout s’est bien passé, elle écrit OK.
Sinon, le message est:

1
Warning: no collections dropped.
         Either you mistyped the name, or it was already cleaned up.

Voir sur GitHub: 8229754.

Pour en profiter: npm install -g castor-clean. (version 1.2.0).

ezref: usage

Comme pour ezVIS, quand on oublie le paramètre obligatoire d’ezref, on a maintenant un message indiquant l’usage normal de la commande:

1
2
3
4
5
$ ezref
Usage:
ezref public
public being a directory path, and public.json the settings file.
See https://github.com/madec-project/ezref for more details.

ezvis: mise à jour de dépendances

Il existe un site qui recense la fraîcheur des dépendences de projets Node, et qui signale des trous de sécurité potentiels.

Badge des dépendances d'ezvis

J’ai donc procédé à quelques mises à jour (marked, sha1, et qs).

Sans doute à surveiller de près.

Comme d’habitude, pour profiter des ajouts de ce sprint dans ezVIS :

1
$ npm install --production -g ezvis

À ce jour, c’est la version 6.8.0.

Sprint Review #15W23: calculs complexes

Nous voici arrivés à la sprint review n°12, qui concerne les calculs complexes.
Comme le dit Anne-Marie, la division est une opération complexe par rapport au simple comptage. Mais la complexité dont nous parlons réside plutôt dans l’appel des données intégrées aux calculs: ils sont externes, dans des tableaux.

Tâches

  • 10 tâches prévues
  • 10 tâches effectuées (dont 9 avaient été prévues)
  • 24 tâches au total
  • plus de 25 points de complexité prévus
  • 24,5 points de complexité effectués

Ce ne sont là que les points pour le développement, sachant que les utilisateurs ont fait plus (notamment sur les tests).

Calcul d’un taux de citation normalisé

Nous avons identifié 4 étapes pour le calcul d’un taux de citation normalisé:

  1. calculer le nombre de publications par année
  2. calculer le nombre de citations par année
  3. calculer le taux de citations par année
  4. normaliser ce taux par rapport à un taux de citation global

1. Calculer le nombre de publications par année

Ce calcul se fait sur le corpus complet, donc on peut stocker le résultat dans un corpusFields (appelons-le publiPerYear).
Nous avons un opérateur classique pour compter le nombre de documents par valeurs distinctes d’un champ: distinct.

1
2
3
4
5
6
7
8
9
{
"corpusFields": {
"$publiPerYear": {
"$?": "local:///compute.json?operator=distinct&field=Year",
"parseJSON": true,
"get": "data"
}

}

}

Nous obtenons donc:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[
{
"_id": "2007",
"value": 5
},

{
"_id": "2008",
"value": 3
},

{
"_id": "2009",
"value": 4
},

{
"_id": "2010",
"value": 1
},

{
"_id": "2011",
"value": 1
}

]

2. Calculer le nombre de citations par année

De la même manière, ce calcul peut se faire sur tout le corpus. On le stocke dans le corpusFields nommé citationsPerYear:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"corpusFields": {
"$publiPerYear": {
"$?": "local:///compute.json?operator=distinct&field=Year",
"parseJSON": true,
"get": "data"
}
,

"$citationsPerYear": {
"$?": "local:///compute.json?operator=sum_field1_by_field2&field=NbCitations&field=Year",
"parseJSON": true,
"get": "data"
}

}

}

Cette fois, nous avons utilisé l’opérateur sum_field1_by_field2 qui ramène bien ce qui nous intéresse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[
{
"_id": "2007",
"value": 868
},

{
"_id": "2008",
"value": 39
},

{
"_id": "2009",
"value": 46
},

{
"_id": "2010",
"value": 5
},

{
"_id": "2011",
"value": 106
}

]

3. calculer le taux de citations par année

Calculer le taux de citations par année revient à diviser la valeur de citationsPerYear par celle qui correspond dans publiPerYear (donc, le nombre de citations pour une année par le nombre de publications pour cette année, ce qui donne bien le nombre moyen de citations par publication, ou taux de citation):

1
2
3
4
5
6
7
8
9
"$citationRatioPerYear": {
"zip": ["publiPerYear","citationsPerYear"],
"foreach": {
"$value": {
"compute": "citationsPerYear / publiPerYear"
},
"mask": "_id,value"
}
}

Ici, nous obtenons un résultat sous forme d’un tableau d’éléments structurés { _id, value } qui sont nécessaires pour pouvoir dessiner un graphe.

4. normaliser ce taux par rapport à un taux de citation global

Une fois qu’on a le taux de citations par années, on peut le diviser par le taux de citations global par années (obtenu par un autre moyen).

Pour cela, on va stocker dans un serveur web statique (par exemple un ezref) un fichier JSON contenant cette table:

1
[{"_id":2004,"value":23.56},{"_id":2005,"value":21.87},{"_id":2006,"value":19.83},{"_id":2007,"value":17.9},{"_id":2008,"value":15.56},{"_id":2009,"value":13.38},{"_id":2010,"value":10.9},{"_id":2011,"value":8.11},{"_id":2012,"value":5.37},{"_id":2013,"value":2.61},{"_id":2014,"value":0.53}]

Puis, nous ajoutons un corpusFields nommé globalCitationRatios:

1
2
3
4
5
6
7
8
9
{
"corpusFields": {
"$globalCitationRatios": {
"$?": "http://localhost:35000/ESI_AllFields_20150407.json",
"parseJSON": true,
"array2object": true
}

}

}

Pour obtenir un objet JSON:

1
2
3
4
5
6
7
8
9
10
11
12
13
{
"2004": 23.56,
"2005": 21.87,
"2006": 19.83,
"2007": 17.9,
"2008": 15.56,
"2009": 13.38,
"2010": 10.9,
"2011": 8.11,
"2012": 5.37,
"2013": 2.61,
"2014": 0.53
}

JBJ: getPropertyVar et array2object

Cet objet JSON donne directement accès à un taux de citation global, en utilisant, par exemple "getproperty": "2008", on récupère la valeur associée: 15.56.

C’est pourquoi nous avons créé l’action array2object, qui transforme un tableau d’objets {_id,value} en objet associant les _id et les values.

Malheureusement, l’action JBJ getproperty ne prend qu’un paramètre littéral, et s’applique sur l’environnement courant. Or, nous voulons parcourir le tableau des taux de citations pour pouvoir normaliser chaque valeur par rapport à la valeur correspondante dans le tableau global.

Nous avons donc créé le pendant de getproperty prenant des variables en paramètres: getpropertyvar, qui prend en paramètre un tableau de deux noms de variables: la variable contenant le tableau, et la variable contenant l’indice à aller chercher.

Ça a permis d’appliquer le flyingFields suivant au résultat de l’opérateur retournant le nombre de publication par année:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
"$normalizeCitationRatioPerYear": {
"$cpy": {
"get": "citationsPerYear",
"array2object": true
},
"$citations": {
"getpropertyvar": ["cpy","_id"]
},
"$globalCitation":{
"getpropertyvar": ["globalCitationRatios","_id"]
},
"$value": {
"compute": "citations / value / globalCitation"
},
"mask": "_id,value"
}

Rappel : flyingFields a accès à la fois aux corpusFields et aux variables _id et value retournées par l’opérateur (distinct dans ce cas), citationsPerYear et globalCitationRatios étant des corpusFields, ils sont accessibles aussi.

Ce flyingFields appliqué à l’opérateur distinct(Year) via l’URL http://localhost:3000/compute.json?o=distinct&f=Year&ff=normalizeCitationRatioPerYear renvoie un data dont le contenu est prêt à être affiché dans un chart (soit un histogram, soit un horizontalbars, soit un pie):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[
{
"_id": "2007",
"value": 9.69832402234637
},

{
"_id": "2008",
"value": 0.8354755784061696
},

{
"_id": "2009",
"value": 0.85949177877429
},

{
"_id": "2010",
"value": 0.4587155963302752
},

{
"_id": "2011",
"value": 13.07028360049322
}

]

Graphes superposés

Un taux de citation normalisé par année est intéressant à comparer à un nombre de publications par année, sur un corpus donné. Dans les versions 6.6 d’ezVIS, le seul moyen disponible était de créer un graphe avec les publications par année, puis un autre graphe avec les taux de citations pour qu’ils soient un au-dessus de l’autre dans le tableau de bord. Pas très pratique.

Un autre moyen est de superposer les deux graphiques (une manière classique est d’avoir un histogramme et une ligne, comme dans cette démonstration de la bibliothèque amCharts).

Nous avons donc introduit le moyen de le faire avec ezVIS 6.7.2, en ajoutant la propriété overlay à un graphique de type histogram:

1
2
3
4
5
6
7
8
9
10
{
"fields": ["content.json.Py"],
"type": "histogram",
"title": "Années & taux de citations normalisés",
"help": "Nombre total de publications et de taux de citations normalisés par année",
"overlay": {
"label": "Taux de citation normalisé par année:",
"flying": [ "normalizeCitationRatioPerYear" ]
}

}

Un overlay doit contenir un label (qui s’affiche sur les points de la ligne), et un flying qui s’appliquera sur les data fournis par l’opérateur (par défaut distinct) et les fields.

La convention est un qu’un overlay se nourrit d’éléments semblables à ceux d’un chart normal (composé d’un _id et d’une value) auquels on ajoute une deuxième valeur value2.
Il faut donc modifier le flyingFields nommé normalizeCitationRatioPerYear exposé plus haut:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"flyingFields": {
"$normalizeCitationRatioPerYear": {
"$cpy": {
"get": "citationsPerYear",
"array2object": true
}
,

"$citations": {
"getpropertyvar": ["cpy","_id"]
}
,

"$globalCitation":{
"getpropertyvar": ["globalCitationRatios","_id"]
}
,

"$value2": {
"compute": "citations / value / globalCitation"
}
,

"mask": "_id,value,value2"
}

}

}

firstOnly

Quand on veut appliquer le même genre de flyingFields à des valeurs déjà présentes dans corpusFields, on est quand même obligé de passer par une route de type compute qui applique un opérateur retournant systématiquement un tableau de résultats (même quand il n’y en a qu’un).
Or le principe des flyingFields est de s’appliquer à tous les éléments de ce tableau data. On obtient donc un tableau de tableaux, qu’ezVIS n’est pas capable d’interpréter. Nous avons donc ajouté la propriété firstOnly qui, au lieu de renvoyer un tableau d’éléments, ne renvoie que le premier élément du tableau. Voir le ticket Add a “firstOnly” parameter to the routes returning data.

Ainsi, quand on veut afficher un histogram avec un overlay contenant les taux de citations par années (présents dans le corpusFields appelé citationsPerYear), il faut utiliser une configuration comme celle-là (contenant un firstOnly):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
"dashboard": {
"charts": [
{
"fields": ["content.json.Py"],
"type": "histogram",
"title": "Années & taux de citation",
"help": "Nombre total de publications et de taux de citations par année",
"overlay": {
"label": "Taux de citation par année:",
"firstOnly": true,
"flying": [ "publiCitationRatioPerYear" ]
}

}

]
}

}

sans oublier de modifier le flyingFields nommé publiCitationRatioPerYear pour qu’il renvoie deux valeurs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"flyingFields": {
"$publiCitationRatioPerYear": {
"zip": ["publiPerYear","citationsPerYear"],
"foreach": {
"$value": {
"get": "publiPerYear"
}
,

"$value2": {
"compute": "citationsPerYear / publiPerYear"
}
,

"mask": "_id,value,value2"
}

}

}

}

Tests de chargement (.tsv WoS)

Nous utilisons des fichiers extraits du WoS (Web of Science) au format TSV (Tabulation Separated Values), et certaines notices passaient mal.

Nous avons trouvé des champs contenant des guillemets (double quotes anglaises), non échappés (mais c’est normal, il n’y avait pas d’ambiguité), et c’est visiblement ce qui posait problème. Une correction a été apportée à la bibliothèque qui analyse les CSV: csv-string. Voir ticket 19 de csv-string.

Mais après tests, les fichiers qui posaient problème ne passent toujours pas correctement: sur un corpus de 999 notices, seules les notices contenant des guillemets ne sont pas chargées (en enlevant les guillemets, tout passe).

Tests de dépôt de plusieurs fichiers (XML ou CSV)

Nous avons remarqué un comportement erronné d’ezVIS: quand on met deux fichiers XML dans le répertoire des données, on obtient des erreurs SAX, alors que séparément, les deux fichiers sont bien chargés.

Après test, ce comportement ne se produit pas avec des fichiers CSV.

Test de la machine de production avec plus de dix rapports

13 rapports ont été créés sur la machine de production, sans aucun problème (rappel: 12 rapports étaient déjà de trop sur la machine d’intégration avant qu’ezMaster soit corrigé).

Test de la prise en compte des modifications de configuration dans ezMaster

Les modifications des documentFields dans la configuration d’une instance ne sont pas prises en compte, même après rechargement du corpus.

Test de la prise en compte des modifications de corpus dans ezMaster

Les modifications du corpus d’une instance (suppression de notices) ne sont pas prises en compte.
Par contre l’ajout d’un nouveau corpus dans la même instance est bien traité et les modifications des documentFields dans la configuration d’une instance sont également prises en compte pour le nouveau corpus.

Documentation du protocole HTTP dans les documentFields

L’utilisation du protocole HTTP dans les documentFields n’avait pas été documentée, c’est chose faite: 6a7147.

Modification des entêtes des exports

Les exports de documents prennent maintenant comme noms de colonnes les labels des champs, et non plus leurs identifiants. Voir ticket 48.

Mise à jour de getting-started-with-visir

Le dépôt getting-started-with-visir a été renommé en getting-started-with-ezvis, la documentation adaptée à la version 6+ d’ezVIS, ainsi que l’exemple fourni.

Explication d’ezVIS pour ISTEX

Kibana ne fournissant pas assez de graphiques, ISTEX s’est intéressé à ezVIS.
C’est l’occasion pour nous d’expérimenter le loader de corpus JSON castor-load-jsoncorpus.

Mise à jour / installation d’ezVIS

Pour profiter de la dernière version d’ezVIS:

1
$ npm install --production -g ezvis

À ce jour, c’est la version 6.7.2.