Fork me on GitHub

Outils pour utilisateurs

Outils du site


platforms:contribute:parser

Comment écrire un nouveau parseur (en javascript)

S'appuyer sur l'outil de génération d'une nouvelle platforme

La première chose à faire est de prévenir les autres contributeurs d'ezPAARSE que vous vous lancer dans l'écriture d'un parseur et pour cela de vous inscrire sur la liste epaarse-contribute.

Les autres contributeurs et l'équipe pourront ainsi vous donner des conseils.

Le langage javascript est utilisé pour écrire un parseur. La création d'un nouveau parseur consiste essentiellement à adapter les expressions régulières présentes dans le fichier parser.js généré (voir-ci-dessous).

Un outil de génération d'une nouvelle plateforme, ''platform-init'' est disponible. Cette commande permet, en répondant à quelques questions, de générer les fichiers nécessaires. Les réponses aux questions posées par platform-init sont dans la page d'analyse de la plateforme correspondante disponible sur le wiki AnalogIST. Les principales questions concernent les domaines couverts par le parseur, s'il utilise une base de connaissance et ce qu'il est capable de reconnaître.

Ecrire un nouveau parseur en javascript consistera donc à :

  • utiliser platfom-init qui crée tous les fichiers nécessaires
  • adapter et enrichir le fichier test conformément à la page d'analyse de la plateforme
  • adapter et enrichir le parseur pour que sa sortie soit conforme au fichier test (voir ci-dessous)
  • lancer les tests de validation (voir ci-dessous)

Une fois les tests valides, le parseur peut être intégré à github.

Chaque dossier est nommé d'après la plateforme traitée par son parseur, par exemple "cairn" ou "springer".

Les principaux types de parseurs

En fonction de la structure découverte pendant l'analyse d'une nouvelle plateforme et des similitudes probables avec une plateforme déjà analysée, vous pouvez vous appuyer sur un parseur déjà existant :

  • parseur pour plateforme sans base de connaissance : un identifiant normalisé est disponible dans l'URL (exemple de ScienceDirect)
  • parseur pour plateforme avec base de connaissance : un identifiant interne est utilisé (exemple de Springer)
  • parseur pour plateforme mono-revue, i.e. une plateforme correspond à une revue, mais les plateformes utilisent le même logiciel de mise en ligne (exemple de EDP)
  • parseur pour plateforme mono-revue, i.e. une plateforme correspond à une revue, utilisant le même logiciel de mise en ligne mais aussi des identifiants internes (exemple de BMC)

Le contenu d'un parseur

Vous remarquerez que chaque parseur se présente sous la forme d'un dossier, qui contient :

  • un fichier nommé parser.js, que nous analysons dans la partie ci-dessous
  • un fichier nommé manifest.json dans lequel figurent les informations descriptives du parseur
  • un dossier test/
    • un fichier *platform_name*.version.csv contenant les informations permettant de valider le parseur

Le fichier parser.js

C'est dans ce fichier que se trouve la partie variable (c'est-à-dire différente d'un éditeur à l'autre) du code source d'un parseur. La partie générique du parseur se trouve en début de fichier, sous la forme d'un appel de module.

Voir la page Parseur générique pour plus de détails sur la partie générique.

analyseEC : la fonction qui doit être adaptée

La fonction analyseEC est passée en argument du constructeur du Parser :

module.exports = new Parser(function analyseEC(parsedUrl) {
//c'est ici que le code propre à la plateforme est écrit
}

et ses variables sont à réutiliser telles quelles :

function analyseEC(parsedUrl) {
  var result    = {};
  var param     = parsedUrl.query;
  var path      = parsedUrl.path;
  var match;

Depuis l'url passée en argument, on récupère différents éléments comme :

  • le path (/resume.php?ID_ARTICLE=ARSS_195_0012 pour une url comme http://www.cairn.info/resume.php?ID_ARTICLE=ARSS_195_0012)
  • les paramètres tels ID_REVUE=ARSS&ID_NUMPUBLIE=ARSS_195&AJOUTBIBLIO=ARSS_195_0012 sous forme d'un objet javascript (structure JSON)
    {ID_REVUE: 'ARSS', ID_NUMPUBLIE: 'ARSS_195', AJOUTBIBLIO: 'ARSS_195_0012'}

Tous les détails sont disponibles dans la documentation des modules URL et Query String

En fonction de la façon dont la plateforme analysée est organisée, vous pouvez adopter plusieurs stratégies pour caractériser les événements de consultation à reconnaitre et utiliser :

  1. le pathname : voir la ligne 18 du parser squelette.
  2. le(s) attribut(s) de la requête présents dans l'URL (param ligne 20)
  3. une expression régulière, voir les lignes 27 ou 37 du parser squelette.

Remarques, trucs et astuces

Pour tester le parseur, aller dans le répertoire /platforms d'ezpaarse et s'inspirer de la commande

. ../../bin/env #chargement de l'environnement
cat ./test/*.csv | ../../bin/csvextractor --fields="in-url" -c --noheader | ./parser.js

qui donne comme résultat :

{"rtype":"ARTICLE","mime":"PDF","title_id":"document-123456-test.pdf","unitid":"123456"}
{"rtype":"ARTICLE","mime":"HTML","title_id":"document-78910-test.html","unitid":"78910"}

Valider l'intégration

Vous avez écrit le parseur, et il fonctionne en ligne de commande (en le lançant via la commande ci-dessus). C'est le moment de valider son intégration dans l'ensemble du code ezPAARSE.

  1. une fois que le parseur fonctionne, pensez à invoquer la commande
    make jshint

    pour s'assurer que les règles de codage de l'équipe ezPAARSE sont respectées. Cette commande se lance à la base du répertoire où vous avez téléchargé ezPAARSE. Jshint délivre un certain nombre de messages qui signalent les règles de codage qui ne sont pas respectées, ils sont suffisamment explicites pour les corriger facilement.

  2. une fois les règles de codage respectées, il est possible de lancer les tests spécifiques aux parseurs. Il faut qu'ezPAARSE soit en cours d'exécution (grâce à la commande make start) et lancer ensuite
    make test-platforms-verbose

    (ou make test-platforms pour minimiser les messages). ezPAARSE vérifie que chacun des parseurs est constitué des éléments attendus (présence des fichiers de test, du manifest.json…) et produit bien les résultats attendus.

  3. lorsque ces tests passent, le parseur est prêt à être partagé avec la communauté via github. Pour cela :
    • ajoutez les nouveaux fichiers avec la commande
      git add ...
    • puis commitez votre travail en local la commande suivante
      git commit -a

      (pensez à indiquer un petit commentaire an anglais si possible)

    • et publiez votre travail sur github avec la commande
      git push
platforms/contribute/parser.txt · Dernière modification: 2015/06/16 10:17 par porquet