Bonjour,
Dans un précédent article sur les comparaisons des statistiques éditeurs avec les ECs d’ezPAARSE, nous avions exposé les bonnes pratiques à adopter pour vérifier la reconnaissance des plateformes dans ezPAARSE avec l’outil ezLOGGER.
Aujourd’hui, nous vous proposons une méthodologie simple pour chercher des consultations dans les lignes de logs rejetées par ezPAARSE.
Ce tutoriel prendra pour exemple la plateforme Nature dans les logs du portail INSB de BibCNRS.
Nous avons observé une augmentation importante des consultations de type ARTICLE dans les rapports COUNTER de l’éditeur à partir du mois de mai 2018. En consultant les données générées par ezPAARSE pour la même période, nous avons constaté qu’il n’y avait aucune augmentation et que la courbe était stable par rapport aux mois précédents.
La méthode que nous exposons ici est simple et ne s’adresse pas obligatoirement à un informaticien. Elle demande par contre un peu de pratique, une connaissance de l’environnement Linux et du logiciel ezPAARSE. N’hésitez pas à consulter l’équipe qui se fera un plaisir de vous aider si vous souhaitez la tester !
1) Vérifications au préalable
Comme mentionné dans l’introduction, nous avons d’abord vérifié que les consultations de type ARTICLE HTML et PDF étaient bien reconnues par ezPAARSE grâce à l’outil ezLOGGER. Nous avons pour cela balayé l’ensemble de la plateforme Nature dans un navigateur web en vérifiant dans ezLOGGER que les consultations étaient bien prises en charge par le parseur dédié.
Une fois les consultations validées, vous pouvez passer à l’étape suivante.
2) Dans Linux ou ubuntu
Dans l’environnement Linux, vous devez pouvoir accéder aux fichiers de logs de votre établissement.
Vous allez utiliser uniquement une partie des logs en filtrant sur la plateforme Nature. Cette opération va permettre de réduire le nombre de lignes de log et la taille du fichier à traiter. Dans notre test, nous avons travaillé sur le mois de mai 2018.
Pour récupérer les lignes avec la chaîne « nature » dans tous les fichiers « .log » du dossier courant, utilisez la commande grep :
grep nature *.log > nature.log
Si vos fichiers sont compressés :
zcat *.gz | grep nature > nature.log
Le fichier nature.log ne contiendra que des logs avec la chaîne de caractères « nature ».
Concrètement, la majeure partie du fichier contiendra les logs de la plateforme Nature, avec quelques logs d’autres plateformes qui contiennent cette chaîne de caractères. Mais l’opération permet de réduire considérablement la taille du fichier.
3) Traitement du fichier Nature.log dans ezPAARSE
Dans l’interface de votre instance locale (mise à jour au préalable) vous insérez le fichier log ainsi obtenu.
Dans les paramètres, veillez à vérifier que le prédéfini de votre établissement est bien sélectionné.
L’objectif de ce traitement est d’obtenir les fichiers des logs rejetés et les domaines inconnus.
Pour cela, il faut ajouter un « Header » dans la partie « Headers (avancé) » en sélectionnant « Reject-files », et lui attribuer la valeur « all » (qui demande à ezPAARSE de générer tous les fichiers de rejets).
A la fin du traitement, vous pouvez télécharger les fichiers de rejets des domaines inconnus et des ECs non qualifiés dans l’onglet « Rapport ». Vous y retrouverez tous les lignes logs qui ne sont pas traitées dans ezPAARSE car non prises en charge par le parseur :
4) Bonnes pratiques pour utiliser un fichier de rejets
Pour ouvrir un fichier de rejet contenant des logs, nous vous conseillons d’utiliser un éditeur de texte spécialisé, comme Vim, Emacs ou Notepad ++ (utilisable depuis un ordinateur sous Windows).
Ce fichier peut contenir des milliers de lignes, donc il est préférable de procéder par élimination. C’est-à- dire supprimer tous les logs qui s’avèrent ne pas être des consultations. Dans le jargon informatique, on les appelle des « assets ». Pour résumer, les assets sont les composantes (ressources) à l’élaboration d’une page web et ne sont donc pas des documents consultés à proprement parler.
Vous pouvez facilement les reconnaître car les URLs contiennent les éléments suivants (liste non exhaustive) :
/static/
/css/
/fonts/
/verify/
/status/
/search/
/jquery/
/login/
/js/
Dans notre exemple de fichier, vous pouvez retrouver tous ces éléments. L’objectif du traitement est de supprimer toutes ces lignes de log pour arriver à un fichier contenant potentiellement des logs de consultations non analysées dans analogIST.
Il peut y avoir aussi des logs avec des URL déjà analysées mais non reconnues par le parseur car un caractère de l’identifiant (DOI par exemple) n’est pas décrit dans l’expression régulière. Cela peut être un « . » ou « – » ou « / ». Nous avons remarqué que certains éditeurs n’avaient pas uniformisé leurs identifiants. Et ces caractères spéciaux n’avaient pas été détectés dans l’analyse. C’est le cas de la plateforme Nature.
Le travail de recherche dans les lignes de log a donc permis de mettre à jour le parseur en ajoutant les caractères spéciaux à l’expression régulière de départ, et d’ajouter des exemples de ces URLs :
4-a) les domaines inconnus
Ce deuxième fichier contient les URLs avec des domaines inconnus dans ezPAARSE.
De la même manière que le fichier précédent, vous pouvez chercher si certains logs contiennent des domaines non pris en charge dans ezPAARSE.
Les URLs de ces logs ne doivent pas non plus contenir d’assets pour être potentiellement exploitables.
Si vous trouvez à la fin du traitement des URLs (ou domaine) correspondant à des consultations de documents « fulltext « non détectées dans ezPAARSE, vous pouvez procéder à une analyse dans analogIST et ajouter un commentaire dans la carte Trello se rapportant à la plateforme.
5) Conclusion
Ce travail d’analyse des fichiers de rejets de logs permet de compléter les tests d’un parseur avec ezLOGGER.
Il permet aussi d’éliminer chaque problème potentiel :
- mauvaise analyse d’URL
- analyse incomplète
- parseur trop restrictif (identifiants non uniformisés d’une plateforme)
- un domaine non détecté
Mais il permet aussi de confirmer une certitude dans le comptage des consultations via un reverse-proxy.
Si ezPAARSE reconnaît parfaitement une plateforme mais qu’il y a une différence avec les statistiques (en faveur de l’éditeur), il est peut-être intéressant pour le négociateur de demander à l’éditeur de préciser sa manière de calculer et de dédoublonner les consultations sur sa plateforme.
Bonne journée.
Frédéric Truong pour ezTEAM