Testeur de fichier CSV / TSV pour import dans GarganText


(Anne Laure Thomas Derepas) #1

Bonjour à tous,

Nous sommes en train de développer un petit outil qui vous permettra de tester vos fichiers CSV / TSV afin de vous faciliter la mise dans le bon format.
Plusieurs d’entre-vous nous on dit qu’ils rencontraient des difficultés pour cela. Le message d’erreur actuel au sein de GarganText étant restreint au fait que le format n’est pas respecté, l’idée est de proposer en amont un utilitaire qui testera et vous indiquera des corrections à faire - voire pourra les faire (à voir).

Certains d’entre-vous auraient-ils des fichiers CSV / TSV à nous partager qu’ils ont conçus dans le format recommandé mais qu’ils n’ont pas réussi à importer ? Si oui nous sommes preneurs de vos exemples pour tester que l’utilitaire permettre de détecter et proposer des corrections facilement.

Bel été à tous
Anne-Laure


(Cécile) #2

Bonjour Anne-Laure,
Le message est ancien… mais je ne trouve pas la réponse.
Je teste un fichier csv (issu de HAL) pour faire la carte des productions de mon laboratoire. J’ai commencé avec une petite partie (moins de 300 références). Mais ça ne marche pas (error 500).
Y a-t-il un modèle pour que je m’en inspire?
A bientôt
Cécile


(Anne Laure Thomas Derepas) #3

Bonjour @CecileMeadel

Voilà un petit outil qui permet de tester le fichier CSV et de voir ce qu’il faut corriger dedans pour qu’il passe dans GarganText : https://gargtools.iscpif.fr/
Il s’agit de Clean CSV to TSV.
Pour mémoire,la documentation de la structure du CSV est présente ici

En espérant que cela permettra d’avoir un fichier tout pret pour l’import

Anne-Laure


(A.-V. Szabados) #4

Bonjour,

Nous sommes en train de déposer des textes en les préparant grâce à Gargantools (transformation txt > tsv).

Cela nous crée plusieurs questionnements:

  1. Comment prendre en compte, dans les analyses, la date de publication? Si on modifie le contenu de la cellule de l’année (“2023”) avec une autre date directement dans le tsv, cela ne change rien lors du dépôt. La date de dépôt semble privilégiée. Comment peut-on ajouter la date de publication ?

  2. Il y a quelques jours, un dépôt de 2 textes avait généré automatiquement une liste de termes (me semble-t-il… puisqu’il y a une belle liste de termes). Le processus de dépôt choisi est celui proposé par la “fleur” au niveau du dossier Corpus -> upload. La liste des termes n’est plus générée avec nos dépôts de samedi et d’aujourd’hui (il y a 0 termes dans l’un des corpus). Ces derniers dépôts sont des ajouts dans des dossiers corpus existants et ayant déjà au moins un dépôt.Faut-il forcément passer par le dépôt d’une liste de termes prédéfinie?

  3. Le découpage dans le tsv multiplie l’occurrence du titre du document (répété en début de chaque extrait généré par le découpage-tsv), or nombre de nos titres contiennent un ou plusieurs termes pertinents pour le graphe. Il me semble que cela multiplie la présence du terme par rapport à la réalité du texte, voire crée des relations de proximité inopportunes entre des termes. Est-ce effectivement le cas? Et si oui, y a-t-il moyen de dé-sélectionner cette informations?

Je vous remercie par avance pour vos aide,
Bien à vous,
Anne-Violaine


(Anne Laure Thomas Derepas) #5

Bonjour Anne Violaine,

Merci de vos questions. Je vais essayer d’y répondre au mieux.

1- Je viens d’aller voir le code python et je crois que vous avez raison, le code ne prend pas la date du txt mais celle du jour. J’ai plusieurs collègues qui s’y connaissent en python je vais essayer de trouver comment solutionner ca et de vous dire si j’arrive à trouver une solution. En attendant, une fois le TSV créé, meme si j’ai conscience que ce n’est pas agréable s’il y a bcp de ligne vous pouvez aller le modifier avant import (j’ai conscience que ce n’est faisable qu’à petite échelle).

2- Sur quelle instance travaillez vous ? En pratique, nous recommandons si vous avez plusieurs sources de créer autant de corpus que de sources puis d’extraire les documents et d’importer dans un corpus unique tous les documents avant de créer une liste de termes. Quand on ajoute massivement des documents à un corpus déjà existant j’ai aussi rencontré des difficultés à regénérer proprement une liste de termes.
Si vous le souhaitez on peut regarder ensemble comment faire cela c’est en réalité assez rapide.

3- Pour le titre effectivement s’il est mis tel quel à chaque ligne cela fausse les calculs d’occurrence / cooccurence. J’aurais tendance (mais cela dépend aussi de votre nombre de livres ou de fichier txt) à mettre en titre le nom de l’auteur ou rien selon votre corpus.

Mais clairement à vous lire, il y a plein de cas auxquels on n’a pas pensé cet été lorsque les stagiaires étaient là pour développer Gargtools et qui méritent qu’on ajuste les développements. On va y travailler.
N’hésitez pas à me dire si vous voulez qu’on échange 30 minutes par visio pour voir comment maintenant avancer le temps qu’on ait mieux à proposer

Cordialement
Anne-Laure


#6

le code ne prend pas la date du txt mais celle du jour

Plus précisément, le premier janvier de l’année où le fichier est envoyé sur le site Web.
Et de ce que je peux voir le problème n’est pas limité à TXT_to_TSV.py :

$ git grep 'date\.today'
Conversion/ToTSV/IsTexToGarganText/Istex2ggtx.py:            temp["publication_year"]=article.get("publicationDate", datetime.date.today().year)
Conversion/ToTSV/ZoteroToGarganText/ZoteroToGarganText.py:        pdate = str(date.today().year) + '\t1\t1'
Conversion/ToTSV/isidoreToTSV/IsidoreAPIToGarganText.py:        pdate = str(date.today().year) + '\t01\t01'
Conversion/ToTSV/risCorpusToTSV/risCorpusToTsv.py:                              year = str(date.today().year)
Streamlit/pages/Clean_CSV_to_TSV.py:                    return success, str(date.today().year), errorMessage
Streamlit/pages/Istex_To_GarganText.py:                    temp["publication_year"] = datetime.date.today().year
Streamlit/pages/PDF_to_TSV.py:                              str(date.today().year), "1", "1", watermark)
Streamlit/pages/Ris_To_GarganText.py:                    year = str(date.today().year)
Streamlit/pages/Ris_To_GarganText.py:                year = str(date.today().year)
Streamlit/pages/TXT_to_TSV.py:    year = str(date.today().year)
Streamlit/pages/TXT_to_TSV.py:    year = str(date.today().year)
Streamlit/pages/YTB_to_TSV.py:                                         author, title, str(date.today().year))
Streamlit/pages/YTB_to_TSV.py:                                            author, title, str(date.today().year))
Streamlit/pages/Zotero_To_GarganText.py:        pdate = str(date.today().year) + '\t1\t1'

Une solution plus fiable serait de rajouter un champ demandé à l’utilisateur·rice, comme le titre ou les auteur·rices actuellement. Voire suggérer une date si on en trouve dans le nom du fichier ou dans le corps du texte.

Une solution aussi fiable mais plus reproductible serait de regarder si le .txt contient des entêtes (charge à l’utilisateur·rice de les y mettre) comme il est courant d’en trouver pour les fichiers Markdown, Exemple :

---
title: Lorem ipsum
author: Jane Doe
date: 2020-11-14
---

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sit amet vehicula lorem. Integer elementum libero vel quam aliquet tempor.

Dans le cas de PDF_to_TSV.py il semble par contre pertinent d’utiliser la méta-donnée ModDate du .pdf. Exemple :

$ pdfinfo ~/docs/climatologie/communique-nappes-eau-souterraine-2023-10-carte.pdf 
Creator:         Adobe InDesign 18.5 (Windows)
Producer:        Adobe PDF Library 17.0
CreationDate:    Sun Oct  8 18:25:09 2023 CEST
ModDate:         Sun Oct  8 18:25:10 2023 CEST
[...]

Mes deux centimes :slight_smile:


#7

J’ai lu un peu le script basé sur streamlit ce matin, et fait un rapide packaging avec nix pour le faire tourner en local (juste par curiosité, je n’ai aucune affinité avec Python).

Une question de contexte me vient toutefois, quelles ont été les contraintes qui ont mené à la conception de cet outil hors de haskell-gargantext ? Je veux dire, y a-t-il une raison technique, du genre parce que vous vouliez absolument une bibliothèque de l’écosystème Python ? comme streamlit ? youtube-transcript-api ? googletrans ? langdetect ? ou bien était-ce principalement des raisons de familiarité des dévs avec Python ? Ce qui serait tout à fait compréhensible, mais du coup donnerait sujet à discussion pour savoir à quel point il ne serait pas plus pertinent de faire certaines choses en interne dans haskell-gargantext.

Je vois par ailleurs que pour les fonctionnalités d’import de documents depuis divers formats (PDF, ODT, DOC), haskell-gargantext semble prévoir de s’appuyer sur l’outil (très complet) Pandoc, ce qui me semble intéressant à explorer (Pandoc n’étant rien de moins que la première raison qui m’a poussé à m’intéresser à Haskell :P).

Enfin, naïvement, je me dis qu’il semblerait préférable qu’un outil d’export vers un format de Gargantext réutilise le code même d’haskell-gargantext au lieu d’une réimplémentation, mais là aussi ça peut prêter à discussion, avec un format d’échange correctement spécifié, ça peut aussi être intéressant d’avoir plusieurs implémentations de référence dans des langages différents.

Bref, je n’ai (encore) qu’une vision très partielle du code de gargantexternal-tools et de haskell-gargantext, je fais juste part d’où j’en suis dans ma compréhension de ce que vous faites =)


(Anne Laure Thomas Derepas) #8

Bonjour @julm
En fait tu as tout à fait cerné la raison pour laquelle on a pris streamlit. Très peu de formations enseignent Haskell en France, on a d’ailleurs contacté plusieurs universités pour proposer de créer ce type de formation mais pour l’instant sans suite.
Du coup, prendre des stagiaires court (ici 6 semaines) pour espérer les faire entrer dans l’environnement de gargantext et leur permettre de sortir quelque chose pour soutenir leur mémoire de master n’était pas envisageable alors qu’en python c’était faisable.
A terme gargantexternaltools a vocation à disparaitre car les fonctionnalités devraient être dans GT mais ça nous permet déjà de voir quels sont les usages les plus forts (du coup de nous aider à prioriser) et quelque part à spécifier un peu ce qui est important pour les utilisateurs qui ont des sources très différentes. Et surtout ça rend service à plein d’utilisateurs de gargantext le temps qu’on intègre cela dans GT.

Bref, c’est une phase temporaire mais dont aujourd’hui avec les moyens de développement que l’on a pourrait durer quand même un peu…

Pour Pandoc je ne sais pas te répondre, mais j’imagine que justement @delanoe a investigué Pandoc car ca doit venir on le sait bien.

Bref, l’idée était de rendre service rapidement à plein d’utilisateurs qui nous demandent de les aider à importer depuis des sources diverses et de rendre service à 2 jeunes en fin de master qui avaient besoin d’un stage pour le valider.

J’espère que ma réponse est claire :wink: (meme si longue)

A bientôt
Anne-Laure


(A.-V. Szabados) #9

Bonjour Anne-LaAure,

Je renvoie mon mail de réponse car j’ai fait la bêtise de réponse via mon mail (et ça a bloqué).
Entre temps, j’ai bien lu les différents échanges… et mes commentaires sont peut-être un peu obsolètes.

Pour le point 1 - (la date) : j’ai testé en changeant la date, pour chaque extrait, directement dans le tsv avant import mais c’est l’année de dépôt qui est retenue.
Un champ à saisir lors du dépôt, comme auteur, titre serait commode pour les textes déposés rapidement.

2 – « créer autant de corpus que de sources puis d’extraire les documents et d’importer dans un corpus unique tous les documents » : L’instance est celle de la formation. Les textes déposés sont des txt provenant de Gallica ou Wikipedia : ils passent donc de mon disque dur vers GarganText. Je n’ai pas encore essayé avec HAL, Isidore… Avec Istex, il vaut mieux cibler finement notre corpus en amont car on a trop de réponses indésirables (homonymies dans les termes de la requête : les biologistes ont trop nommé leurs animacules divers et variés avec des noms de divinités classiques !)).
J’ai créé des dossiers « thématiques », chacun correspondant à une problématique. Chacun reçoit plusieurs publications et nos publications peuvent être longues, volumineuses, et générer beaucoup d’extraits.
Vaudrait-il mieux, par ex., déposer une publication dans un dossier qui lui est propre (pour réduire le contenu du dossier), générer les termes puis déplacer les textes vers le dossier thématique ; puis pour les termes, faire une fusion de deux listes de termes (la nouvelle et celle du corpus commun) , ce que j’ai vu proposé dans les fonctionnalités-fleur" dees dossiers Terms.
Pour nous, une piste intéressante serait aussi l’import de notre “vocabulaire pertinent” ou sa fusion avec le vocabulaire du texte ( import par la “onctionnalité-fleur” de Terms) : on n’a pas encore testé…

3 – le titre : je vais suivre vos conseils : nous avons un id court propre au projet ( de type MTAL_00001) pour chaque publication/document, qui est inclus dans la notice bibliographique gérée dans notre instance Zotero. Cet id pourrait aller dans le champ Titre, ce qui pourrait créer un lien intéressant pour le graphe (le terme – la publication).
J’ai pu voir les statistiques sur les rubriques “auteur”… : le rallongement de l’information avec l’ajout du titre de la publication dans le champ “auteur” change un peu la donne car la statistique sera faite sur la publication et non l’auteur (qui peu avoir plusieurs publications), mais c’est peut-être intéressant dans certains cas.
Une piste de réduction du biais : peut-être créer une entrée de Terms sous la forme du titre, et l’interdire (stop terms) --> si ça marche, c’est-à-dire si les termes du segemnts textes ne sont pas pris en compte dans ce segment texte mais qu’en même ailleurs (pas encore testé), cela permettrait de varier le paramètre quand on veut.
par exemple : titre = “Dissertations sur les statues de Vénus”
stop Terms pour “Dissertations sur les statues de Vénus” mais “statues de Vénus” dans d’autres segments que celui-là est quand même repéré si on l’a dans les Map terms.

Je continue les tests et je reviens vers vous pour une petite visio.

Je vous remercie vivement pour votre réponse et ce que vous et votre équipe nous proposez.

Anne-Violaine