Stage de Sylvain Wendel - IUT Schuman Illkirch- [3/09/18 au 8/06/18]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter Gilles

Sujet

• Proposition de stage

Stage (Avril - Juin 2018)

Avril

• 9, arrivée
• 9, séminaire d'accueil
• Jours 1, 2 et 3 :
  • Début des investigations. Je lis de la documentation pour pouvoir me familiariser avec mon environnement. Cette documentation est sur les DOI, le langage XML et sur les données que je dois générer. J'ai trouvé des informations intéressantes sur un des sites que m'a présenté mon tuteur : datacite. C'est sur ce site que nous devrons aussi envoyer nos données et c'est eux qui devront nous donner les préfixes des DOI que l'on aura pour nos fichiers XML. Tout d'abord il faut comprendre l'utilisation des DOI de datacite, il y a plusieurs raisons de citer des données :
    • Pour accorder des crédits à l'auteur quand on cite son travail
    • Présenter les données qui ont été utilisées pour arriver au résultat présenté dans l'article
    • Fournir un accès durable aux données
  • Et pour ce faire il faut :
    • Donner un identifiant à nos données
    • Et y insérer le PID
  • Le PID et les métadonnées :
    • Contient des informations en rapport direct avec l'objet
    • Présence de liens vers d'autres informations (compléments de données)
      • Vers des articles
      • Données en lien avec le sujet
    • Des vérifications et des informations sur les versions
    • Liens vers l'objet
    • Doit être maintenu à jour
  • Les métadonnées ont un certain potentiel et nous avons certains droits :
    • On peut faire des liens entre les objets de données et les informations et inversement et nous pouvons faire des liens avec d'autres objets de données aussi (il existe toute sortes de liens que nous pouvons faire entre nos données)
    • Nous pouvons combiner les métadonnées de pleins d'objets ou de sujets différents ce qui permet d'avoir un article plus riche pour la fouille de données, que si on devait travailler avec des articles un par un.
  • Il faut aussi savoir que les citations sont des éléments très importants et qui doivent être indiquées dans le fichier (en grande quantité si possible).
  • Définition : Un DOI est une chaîne de caractères alphanumériques assignée par un service de registration qui sera un lien vers un contenu, vers des données et qui permettra de chercher ces données sur internet. Ce qu'il faut savoir est que les liens DOI sont des liens persistants, c'est à dire qu'ils vont durer à perpétuitée donc c'est un engagement à prendre en compte et il faut bien être sur des données que l'on veut publier.
  • Les DOI peuvent être utilisés pour :
    • Citer des données
    • Formatter les citations de manière standard
    • De trouver les URL car un DOI -> une URL
    • Un moteur de recherche
    • Obtenir des statistiques d'utilisation
  • La découverte du site datacite. Datacite est un bon site pour la génération de DOI en rapport avec des objets ou des données astronomiques. Ils sont créés et alimentés par pleins d'institutions différentes. On peut aussi faire des citations logiciels ce qui est aussi très pratique.
  • Dans les DOI il faut mettre un lien vers la Landing Page (d'où l'interêt de la revisiter) car c'est très important pour les dossiers qui contiennent beaucoup de données et qui ont beaucoup de citations.
  • Il y a deux types de DOI :
    • Les DOI liés à des objets de données individuels
    • Les DOI liés vers des articles qui font références à des objets individuels
  • J'ai pu apprendre que les DOI permettent de faire des échanges d'expérience et d'idées. Ils permettent d'apprendre de nouvelles méthodes et de nouvelles pratiques, ils permettent de nous guider et de nous informer. C'est pour cela aussi qu'il faut des conventions car les DOI peuvent être de toute sorte et peuvent venir de partout dans le monde. Les noms de DOI sont découpé de la manière suivante : un préfixe qui sera alloué par datacite et un suffixe qui sera donné par le CDS. Les noms de DOI doivent être opaques mais nous avons choisi un solution semi-opaque.
  • Dans mes investigations j'ai aussi retenu les raisons d'utiliser datacite pour la génération de nos DOI plutôt qu'un autre site, et ces raisons sont les suivantes :
    • C'est un site stable et les PID sont fiables
    • Il y a une maintenance externe
    • Un accès pour tous
    • Bon ensemble de métadonnées
    • Accroit la découverte
  • Dans un DOI les publishers, les créateurs, les contributeurs et toutes les autres personnes qui ont contribuées de prêt ou de loin aux données peuvent être des personnes ou des institutions et peuvent être nommées ou indiquées par leurs identifiants.
  • Durant ces trois jours je me suis aussi familiarisé avec les données contenues dans Vizier, car ce sont des données de ce site que je devrais générer. Vizier contient un grand nombre de catalogues qui eux sont un ensemble de tables associées à une publication. Dans ces catalogues se trouvent des mots clés, des métadonnées enrichies UCDs pour chaque colonne, des coordonnées ... Les tables elles contiennent des positions et des informations sur les étoiles.
  • On peut considérer Vizier comme étant une base de données à valeur ajoutées, c'est à dire que Vizier est sans cesse alimenté en données. Une des raisons pour conserver toutes ces données est qu'elles sont utilisées pour la recherche puis elles sont archivées (la réutilisation des données est garantie par l'utilisation de standards). On garde les données car sur le long terme certaines choses vont changer et on peut comprarer les nouvelles données avec les archives. Elles sont sur Vizier donc elles sont en libre accès et il existe de nombreuses applications Web ou autre pour y accéder.
  • Dans la documentation qui m'a été fournie, j'ai pu savoir quelles données je devais récupérer pour les mettre dans le fichier XML que je devait générer. Pour la granularité des DOI dans Vizier, on peut faire des DOI :
    • Sur les services : site Web Vizier (voir pour les services associés FTP, Hips, ...)
    • Sur les catalogues : niveau de granularité actuel du registre de l'IVOA (consortium avec des partenaires)
    • Sur les tables : niveau de granularité que l'on souhaite aujourd'ui à l'IVOA (à développer peut être dans le futur)
  • Il faut maintenant donc faire le choix des méta-données à mettre.
    • Pour le DOI Vizier, il y aurait :
      • L'URL Vizier
      • Le bibcode
      • Le DOI de l'article de référence Vizier
      • Pages licence
      • Aknowledgment
    • Pour le DOI catalogue :
      • ORCID uniquement pour les auteurs principaux (first author)
      • pas de liens vers des services locaux ou externes (ils seront mis dans la Landing Page)
      • Le nom DOI sera indépendant du nom du catalogue
  • Maintenant que nous avons fait le point sur les données à fournir dans le fichier XML on peut voir ce qu'il faut mettre dans une Landing Page :
    • Données différentes de la page "Brief summary"
    • Gestion des services d'accès aux données
    • Titre du catalogue
    • Auteur principal avec son ORCID (si connu)
    • Auteurs secondaires (maximum 3)
    • Date d'ingestion dans Vizier et dernière modification
    • Identifiants :
      • Nom du catalogue Vizier (avec lien vers les données)
      • Bibcode et DOI de la publication
      • IVOID du VO
    • Section "description" du ReadMe (ou l'abstract)
    • Un lien vers la page de licence
    • Un lien vers les données associées s'il y en a
    • Eventuellement (en fonction du sujet) :
      • "Coverage map"
      • Texte Copyright ou Aknowledgment dédié
      • Lien vers le FTP
• Jour 4 :
  • Une fois que je savais quelles données mettre dans le fichier XML et que je me suis familiarisé avec mon environnement de travail, j'ai pu m'attaquer à la génération des fichiers XML en python. J'ai tout d'abord cherché comment je peux générer des fichiers XML en python et j'ai trouvé plusieurs manières de faire différentes. Globalement le point commun de toutes les manières différentes de générer des fichiers XML en python est d'utiliser une bibliothèque permettant de construire une arborescence XML avec une racine qui aura plus ou moins d'enfants. C'est à dire que à chaque fois que l'on veut créer un élément dans notre fichier XML il faut créer un tag qui sera un enfant de notre racine. Ces tags peuvent eux aussi avoir des enfants en fonction de la norme des fichiers XML et du modèle XSD donné par datacite (explication des XSD plus tard). Il existe plusieurs bibliothèques qui peuvent répondre à nos attentes et j'ai choisi d'utiliser la bibliothèque xml qui m'étais déjà fournit de base et cela m'évitais don d'en installer une. J'ai ensuite pu faire quelques tests avant de me lancer dans la génération de tout le document.
• Jour 5, 6, 7 :
  • Tout d'abord j'ai construit mon fichier XML avec des fonctions : une fonction par type de données à générer mais avec mon tuteur nous nous sommes rendus compte très rapidement que pour la compréhension du code par une vue extérieure il serait mieux de procéder avec des classes au lieu de fonctions. J'ai donc modifié mon code pour faire un système de classes avec un main qui me charge mes données et qui me les tris et ensuite qui m'appelle mes différentes classes.

• Jour 8 :

  • Après la mise en place du système de classes et de toutes les fonctionnalités de bases, j'ai pu m'attaquer aux requêtes en base pour récupérer l'identifiant du catalogue pour avoir ensuite la date de la dernière mise à jour. J'ai tout d'abord cherché comment fonctionnait le système de connexion à une base Postgres en python puis comment faire des requêtes. Il fallait que j'installe le module suivant : psycopg2 en utilisant la commande linux sudo apt-get install python3-psycopg2 mais ensuite le plus dur a été de trouver où le module a été installé pour pouvoir l'importer et l'utiliser dans mon fichier .py. Après de nombreuses recherches j'ai trouvé comment il fallait faire (module sys pour sys.modules["psycopg2"]), j'ai alors obtenu le chemin du fichier et donc le mettre dans le même dossier que mon fichier python. Après avoir réussi à trouver l'endroit où le module a été installé j'ai pu faire mes requêtes en base. J'ai donc cherché la date de la dernière mise à jour que j'ai trouvée à l'aide de l'identifiant du catalogue. J'obtiens en retour le nombre de secondes depuis 2000/01/01 et après calcul du nombre de secondes depuis 1970/01/01 j'ai obtenus ma date exacte à l'aide de la méthode timestamp (qui calcul une date en passant un nombre de secondes depuis 1970/01/01).

• Jour 9 :
  • Après cela j'ai eu l'idée de crypter le mot de passe pour accéder à la base de données car le mettre en dur dans le code n'est pas une sécurité, il serait récupérable par n'importe qui. Je le crypte à l'aide d'une méthode en python que j'ai trouvé. Après avoir crypté le mot de passe, j'ai mis à jour le fichier .status (fichier caché des catalogues) pour pouvoir récupérer les DOI des sites de références mais aussi certains ORCID des premiers auteurs de certains catalogues.
• Jour 10, 11 :
  • La dernière chose que je devais faire était de continuer les tests unitaires que j'avais déjà commencé, j'ai fait beaucoup de recherche pour savoir si on pouvait valider un fichier XML avec un modèle XSD. Le modèle XSD était le modèle fournit par datacite donc il était très important de savoir si le fichier que je génère est correct ou non. Après plusieurs heures de recherche, j'ai enfin réussi à tester les fichiers XML que je génère avec le model XSD de datacite. J'ai dû trouver le bon module à utiliser : lxml et le plus dur a été de trouver la bonne version du module lxml à utiliser car toutes ne fournissent pas les mêmes méthodes. J'ai créé un programme qui me vérifie mes fichiers XML et qui indique dans un fichier error_log_file les erreurs s'il y en a, sinon un message de validation s'affiche. J'ai aussi ajouté ma méthode de test dans mes tests unitaires pour que toutes les validations se fassent en même temps.
  • Il faut savoir que tester son code est très important, un test unitaire doit se concentrer sur un tout petit morceau de fonctionnalité et prouver qu'il est correct. Les tests unitaires sont donc indépendants les uns des autres. J'ai donc fait quelques tests mais le plus important de tous est celui que je viens de décrire ci-dessus.
  • J'ai donc terminé le programme de génération de fichiers XML, il ne manque plus que les préfixes des DOI que l'on aura de datacite lorsque l'on sera inscrit.
• Jour 12, 13, 14 :
  • Une fois que j'ai terminé le programme de génération de fichiers XML, j'ai pu m'attaquer à la Landing Page. Pour cela je dois apprendre à utiliser AngularJS qui est un Framework qui permet d'étendre notre code HTML pour le dynamiser, et est rapide à développer. J'ai donc commencé par lire beaucoup de documentation à propos d'AngularJS et j'ai fait quelques tests pour pouvoir me familiariser un peu plus avec ce langage.
  • Avec AngularJS on peut animer des pages Web. Les principes architecturaux sont les suivants :
    • Suit un modèle MVC (Modèle Vue Controleur)
      • La Vue : le HTML (et/ou la sortie générée), utilisation des données issues du Modèle pour mettre la Vue à jour.
      • Le Modèle : structure de données représentant une entité de l'application (parfois transmise en JSON).
      • Le Controleur : permet la communication entre le serveur et la Vue.
    • Injection de dépendances (qui rend la code plus modulable)
    • Le templating (utilisation du HTML)
    • Le binding (qui conciste à lier les objets ensembles entre eux) ex : un objet js avec un item graphique du template pour que toute mise à jour soit simultanée.
    • Utiliser des composants existants ou en créer de nouveaux.
  • On peut donc en comprend que AngularJS "impose" une certaine structure à implémenter pour le code.
  • Découverte des différents outils que l'on peut utiliser en AngularJS.

• Jour 15 :

  • Dans mes tests j'ai essayé de lier mon Controleur avec mon Modèle pour afficher dans ma Vue un tableau de personnes contenu dans le Modèle. J'ai eu beaucoup de mal pour trouver comment il fallait faire car aucune documentation n'en parle clairement si on met le Modèle et le Controleur dans deux fichiers différents (ce qui est mon cas). J'ai finit par trouver comment il fallait que je procède et c'est de la manière suivante : quand on déclare le module du controleur dans le Controleur, il faut lui indiquer le nom du module dans le Modèle pour lui dire quel Modèle il devra utiliser. Ce n'est pas suffisant, il faut encore déclarer le nom du type du module que l'on a utiliser dans le Modèle (si on a utilisé une Factory, config, service, ...) pour pouvoir récupérer toutes les données du Modèle (on déclare le nom du Modèle comme on déclare le $scope dans le Controleur). Après avoir fait tout ca on peut accéder aux fonctions et données qui se trouvent dans le Modèle depuis le Controleur.
  • Après ce dernier test, j'ai pu commencer la Landing Page en découvrant en même temps Bootstrap qui est un outil permettant de construire une page Web responsive et qui fonctionne avec le HTML, le CSS et le Javascript. J'ai commencé à faire le physique de la page en me reposant sur ce qu'on avait définit avec mon tuteur.
• Jour 16 :
  • Une fois que j'ai fait une sorte d'esquisse pour le physique de ma page j'ai pu essayer de récupérer les données des catalogues en fonction du nom du catalogue.Nous avons donc installé un serveur apache pour que je puisse récupérer les informations dont j'ai besoin et que je puisse mettre sur le serveur la page que je suis entrain de développer.

Mai

• Jour 17, 18 :
  • Mis en place des données des catalogues sur le site, récupération du nom du catalogue dans l'URL en javascript lors du lancement de la page (commande dans le body du html qui appelle la fonction qui devra se lancer). J'ai ainsi pu remplir ma Landing Page en fonction du nom du catalogue qui est donné dans l'URL. Ensuite j'ai rajouté les boutons pour pouvoir se rendre aux DATA, aux FTP, TAP, ReadMe etc. J'ai créé une fonction dans le modèle qui va me renvoyer chaque URL pour chaque bouton le lien correspondant et ensuite le controlleur va prendre ce début de lien et construire chaque lien final en fonction du nom du catalogue ou du bibcode.
• Jour 18 :
  • Nous avons remarqué un problème dans les données que nous avons récupéré dans le ReadMe concernant le ORCID du premier auteur du site. Si un ORCID est référencé, ce n'est pas forcément celui du premier auteur. Pour résoudre ce problème, je vais devoir créer pour mon programme de génération de fichiers XML, un test supplémentaire qui va interroger le site qui indique l'auteur de l'ORCID donné pour savoir si l'ORCID que nous avons récupéré est bien celui du premier auteur du catalogue. C'est donc un programme de test que je vais devoir rajouter.
  • J'ai donc 3 choses à faire dans les prochains jours :
    • Générer le bouton XMATCH de la Landing Page uniquement s'il y a des tables associées, et pour cela je vais devoir créer un nouveau fichier ReadMePlus.py pour pouvoir ajouter le nom du premier catalogue (s'il existe) pour pouvoir faire le lien de XMATCH. Je devrais aussi vérifier s'il existe des données associées au catalogue recherché.
    • Créer un programme qui me permet de vérifier le DOI que l'on a pour savoir si c'est celui du premier auteur
    • Continuer la Landing Page en récupérant les images (et/ou spectres) et les intégrer (s'il y a des images et/ou spectres) dans la page.
• Jour 19, 20 :
  • Je suis entrain de créer le fichier ReadMePlus.py qui me permettra de savoir si je dois générer le bouton XMATCH dans la Landing Page ou non. Je dois créer un nouveau fichier car j'ai besoin de faire des requêtes en base et il est préférable que je ne les fasses pas dans le fichier ReadMe normal. J'ai aussi du changer le nom du programme à générer dans le cgi pour pouvoir avoir dans le JSON le nom de la première table du XMATCH.
  • Dans le ReadMe du cgi je fais maintenant un import de mon ReadMePlus qui lui effectue les requêtes en base pour obtenir le nom de la table pour le XMATCH. J'ai donc 2 requêtes à faire : une requête pour obtenir le catid et une requête pour obtenir le nom de la table pour informer le XMATCH. On obtient notre information si le catalogue contient des positions (cooframe). Dans le cgi j'ai bien dû modifier tout ce qui avait un rapport avec l'ancien ReadMe pour que tout soit bien à jour. Le cgi (Common Gateway Interface) est un programme qui va me prendre en paramètre tout les paramètres qu'on lui donne dans l'url et qui va renvoyer une page en retour.
  • Après avoir obtenue le nom de la table, j'ai pu ajouter dans le json une nouvelle information : le xmatch. Ce xmatch me servira à savoir si je dois construire le bouton XMATCH dans la Landing Page ou non.
  • Rajout d'un renseignement dans le fichier json pour savoir si le catalogue contient des données associées ou non (images ou spectres). Je génère ensuite en fonction de cette information un bouton supplémentaire qui fait un lien vers les données associées.

• Jour 21 :

  • Recherche du foot print dans les données de l'image. Pour cela j'ai tout d'abord dû rajouter un accès aux images à notre serveur apache pour que je puisse rechercher ces images et les afficher dans la Landing Page. Il y a tout d'abord eu un problème de droits, mais après avoir rajouter les bons droits (le droit d'accès à www-data à nos images), on a eu un autre problème qui s'est résolu un peu plus tard, on a remarqué qu'il nous manquait une information dans la configuration Directory de apache. Après avoir rajouté l'information manquante, tout le code a fonctionné. Maintenant que j'ai accès aux images, la dernière chose que j'ai à faire est de prendre l'image en .png si elle existe sinon en .gif. Pour cela j'ai choisi de procéder de la manière suivante : je test la recherche de l'image en .png en donnant l'url d'accès à l'information, et si l'image existe en .png je la prend, sinon je prend l'image en .gif.

  • J'ai donc validé deux de mes objectifs sur les trois que j'avais énoncé dans la partie du jour 18.

• Jour 22, 23, 24, 25, 26 :
  • Je suis entrain de créer le programme de validation des DOI en python et je dois procéder par recherche avec API.
  • J'ai effectué un test d'ajout du ReadMe de la page VizieR dans la Landing Page mais il y a un problème d'affichage donc il faut que je choisisse entre une adaptation de l'affichage du ReadMe et alors supprimer le bouton qui fait un lien avec le ReadMe de VizieR ou alors je ne met pas le ReadMe dans la Landing Page et alors je garde le bouton.
  • Résolution du problème de la vérification de l'ORCID. J'ai réussi à trouver une api avec un token. Cette api me permettra de faire une requête sur le site de développement des ORCID https://pub.sandbox.orcid.org/v1.2/ grâce à une clé dont que j'ai eu. J'ai donc pu écrire mon programme python qui prend donc une liste d'ORCID et qui va me retourner pour chaque ORCID donné, le nom et le prénom de la personne à laquelle il appartient. J'ai donc mon url de base et ma clé, j'ai du rajouté des headers qui me permettend d'effectuer plusieurs actions différentes (comme choisir le format des données de sorties). Les données en sorties seront au format JSON. Pour récupérer les informations, il faut que l'on capte le status code qui est le code d'erreur qui sera renvoyé par la page quand on y accèdera. Le status code d'une recherche d'ORCID est 200, donc si le status code est 200, c'est que la requête a fonctionnée et donc que l'on peut récupérer les informations.
  • On peut récupérer deux types d'ORCID différents : ceux qui proviennent du site de développement https://pub.sandbox.orcid.org/v1.2/ et ceux qui proviennent du site ORCID https://pub.orcid.org/v1.2/, dans notre cas, nous avons besoin de faire une recherche des ORCID du site normal.
  • Amélioration de la Landing Page, les colonnes sont dans un bloc container qui est entièrement responsive (peut s'afficher sur tous les écrans) ce qui améliore la mise en forme de la page. Ajout des mots clés sur la Landing Page.
  • Rajout d'un bouton qui fera le lien entre la Landing Page et VizieR et ajout du foot print en dessous des mots clés. Une redirection est faite si on indique aucun catalogue dans l'url. La redirection se fait vers la page de garde de VizieR. Si la requête http vient de l'observatoire, on ajoute en plus dans les informations un lien Bibcode vers le site Simbad.
  • J'avais rajouté sur la Landing Page le ReadMe du catalogue, mais on a remarqué que la pour indiquer le ReadMe, le bouton ReadMe suffisait, j'ai donc enlevé de nouveau l'onglet ReadMe à côté de l'abstract.
  • J'ai complété mon fichier de création de document XML en python, maintenant il effectue le test de l'ORCID. Il va appeler la classe qui fait la requête API pour savoir si l'ORCID qui est indiqué est celui du premier auteur ou non.
  • Dans le fichier JSON qui se génère automatiquement grâce au fichier ReadMe.py, j'ai rajouté la date de la dernière modification pour pouvoir la renseigner dans la Landing Page. Pour cela j'ai donc rajouté une requête dans le fichier ReadMePlusPlus.py et cela va alors me rajouter une donnée supplémentaire dans le tableau de données du ReadMe.

• Jour 27, 28, 29 :

  • Grosse avancée dans la Landing Page, pour avoir le plus de données possibles dans la Landing Page j'ai du continuer à faire des rajouts dans le fichier ReadMe.py, car c'est dans ce fichier que sont récupérées les données du ReadMe des catalogues ainsi que des fichiers .status ou .Summary qui nous permettent d'avoir des informations telles le nombre de lignes des tables ou l'ORCID d'un auteur et autres. En lancant le cgi, je vais alors lanncer le fichier ReadMePlusPlus.py qui va alors me générer toutes mes données dans un fichier JSON. Il m'est alors très simple de récupérer les informations du catalogue concerné pour les afficher dans la Landing Page. Tout ca je le faisais déjà avant mais c'est écrit maintenant car j'ai enfin toutes les informations dont j'ai besoin.

  • Rajout d'un fichier custom.htx pour pouvoir écrire des messages fait par les documentalistes à propos des catalogues. Ces messages sont écrit en latex et dans la configuration d'apache nous les convertissons en html. Je suis entrain de voir comment je pourrais les afficher dans la Landing Page.

  • Pour l'affichage de la Landing Page, j'ai du rajouter des onglets "article origin" et "acknowledgment", pour que les données soient classées dans les bonnes catégories. J'ai donc 3 onglets : Abstract, qui va contenir l'abstract du catalogue, article origin qui va contenir le DOI de l'article, le titre long, l'auteur (avec son ORCID si référencé), le journal original et les mots clés. En dernier onglet j'ai donc les acknoledgment. Les informations générales seront mis à part et en vue directement quand on arrive sur la page.

  • Récupération du See also du ReadMe pour que les personnes qui visitent le site puissent aller voir les catalogues qui sont associés à celui qu'ils sont entrain de lire.

  • Rajout de souplesse dans l'url mais il y a un problème dans la configuration d'apache pour enlever le '?' de l'url.

  • Nous avons décidé de rajouter les message (le fichier custom.htx) au dessus du See also pour que ces messages puissent bien être mis en valeur car ils sont très important.

• Jour 30, 31 :

  • Préparation de la Landing Page pour pouvoir la présenter aux documentalistes lors d'une réunion. Modification du fonctionnement de l'affichage du ReadMe, maintenant je l'affiche dans une iframe qui va prendre la place des autres informations avec possibilité de retourner en arrière.
  • Différents tests pour savoir comment je pourrais récupérer le See also (les catalogues associés), j'ai réussi à les afficher à l'aide d'expressions régulières. Je divise le See also à l'aide de l'expression régulière comme séparateur puis je met les informations dont j'ai besoin dans le bon ordre dans un tableau et à l'aide d'une fonctionnalité très utile que propose angularJS (ng-repeat) je peux parcourir ce tableau et afficher ce qu'il contient sous forme de liste.
  • Je vais devoir changer quand même le fonctionnement de récupération du See also car j'ai besoin de deux expressions régulières différentes et je ne peux pas utiliser deux séparateurs différents pour diviser le See also qui est une chaine de caractères.

  • Réunion avec les documentalistes pour connaitre leur avis sur la Landing Page, ce que je pourrais changer et ce que je pourrais ajouter. J'ai fait une liste des choses que je vais devoir faire :

    • modifier l'emplacement des dates

    • mettre "insert into VizieR" pour la date d'ajout du catalogue dans VizieR

    • mettre la description à côté de l'abstract

    • mettre l'abstract dans la section "Article origin"

    • raccourcir l'affichage de l'abstract et mettre un "see more" pour voir la suite

    • ajouter les copyrights dans les acknowledgments

    • faire une iframe pour le browse

    • rajouter "Access to :" au dessus des boutons pour que les utilisateurs sâchent à quoi les boutons vont servir

    • enlever le bouton "go to VizieR"

  • Leproblème du See also est réglé, j'ai fait directement la modification dans le fichier ReadMe.py en python pour que quand je vais récupérer les données, elles soient déjà dans le bon format et sous la bonne forme. J'ai rajouté des sauts de lignes pour pouvoir utiliser l'expression régulière de saut de ligne comme séparateur de ma chaine de caractères.
  • On a réglé le problème de l'affichage du message personnel Custom.htx qui est un fichier qui sera écrit par les documentalistes pour ajouter des infos sur la Landing Page. Dans le cgi, nous indiquons que les fichiers en Latex devront être convertis en html et ce qui a résolut le problème d'affichage de ce fichier dans la Landing Page est de transformer le texte avec les balises html en html à l'aide de la propriété innerHTML en javascript.

Juin

• 8 (au plus tard), pré-soutenance de stage

Liens

• ...

Versions testables

• ...

Documentation

• ...

Travail post stage éventuel

• ...

Liste des améliorations à envisager

• ...

Bugs connus

• trouver le module installé pour pouvoir l'import dans le fichier python (sys.modules["moduleName"])
• tester mes fichiers XML avec le XSD fourni par datacite
• dans les tests unitaires pouvoir accéder aux enfants d'enfants, les accès ne sont pas évidents, il faut trouver la bonne manière de faire
• lien entre Modèle et Controleur pour AngularJS
• requête en base pour savoir si je dois générer le bouton XMATCH dans la Landing Page