Hyperliens dans le corps du texte

[Phyks]

Une autre idée en passant : Tant qu'à avoir le code numérisé, il pourrait être cool de faire des liens hypertextes entre les articles, lorsqu'ils sont référencés, pour naviguer facilement entre les articles. Et tant qu'à faire, on peut même imaginer mettre l'article référencé dans un title pour avoir tout le texte au survol de la référence :)

[tianyikillua]

Tout à fait faisable à l'aide des anchor une fois un .md généré pour chaque version de texte.

[Seb35]

Merci @tianyikillua pour la pull request, je n’ai pas encore testé mais ça a l’air bien.

Avant de l’intégrer, j’aimerais ajouter un switch pour créer telle ou telle sorte de dépôt Git, par exemple avec ou sans sommaire, avec ou sans hyperliens, avec tout le texte sur une page ou au contraire dans dans des sous-dossiers, en Markdown classique ou Markdown GitHub ou wikitexte ou etc. Depuis que j’ai commencé Archéo Lex, je vois des réutilisateurs intéressés par telle ou telle version, donc au lieu de n’en sélectionner qu’une seule, je préfère rendre le code modulaire pour contenter tout le monde. Cette orientation vient aussi du fait que les commits Git sont sensibles au moindre changement (par exemple rajouter des hyperliens va complètement réécrire l’historique Git) et j’ai eu des demandes d’utiliser les historiques Git créés par Archéo Lex comme des identifiants pérennes de tel ou tel changement de la loi. Je viens de créer #20 pour détailler cette orientation.

[Seb35]

Voir aussi ce post pour un moteur plus général de création de liens.

[Changaco]

La détection des liens dans le corps d'un texte sera dans la prochaine version de legi.py. https://github.com/Legilibre/legi.py/issues/4

[Seb35]

Et quelle est ta méthode ? Expressions rationnelles ? Voir aussi ces expressions chez Regards Citoyens et ce compte-rendu.

[Changaco]

Oui, des regexp. Elles sont similaires à ta grammaire PEG mais gèrent plus de cas.

[Seb35]

J’ai commencé une librairie dédiée avec la grammaire PEG, un peu améliorée pour l’occasion. C’est sur https://framagit.org/parlement-ouvert/metslesliens, et les résultats sont vraiment bons. J’ai vérifié à la main sur la loi 78-17 (100% de reconnaissance sans faux positifs (ni faux négatifs du coup)) et sur le début du code civil. Le CGI est l’épreuve du feu dans ce domaine.

En parallèle, j’ai fait une doc technique/légistique sur les noms d’articles en extrayant tous ceux-ci de legi.py -- cette doc a été faite avec des regex mais il faudrait désormais regarder avec la grammaire. En résumé, il est relativement facile de capturer 90% des noms d’articles, mais il y a une marche pour faire plus, du moins si on ne veut pas trop augmenter le nombre de faux positifs (notamment lorsque les noms d’articles ont des lettres "A", "B", "AC", "a", "b", il faut alors limiter le nombre de caractères pour ne pas capturer tout le reste de la phrase) et en vérifiant que les performances restent correctes.

[fenollp]

J’ai regardé vite fait le PEG (je n’ai pas [encore] de compte framagit) et sans avoir autant d’expérience des textes: Est-ce qu’il n’est pas possible que les articles mentionnés soient parfois sans accents / avec majuscules / manque une espace ou en ont plus d’une ? Peut-être qu’un pre-processing pourrait normaliser ça un peut ? Y’a quoi comme mentions d’articles vraiment bizarres par exemple ?

[Seb35]

Résultats

Un petit showcase de résultats :

• loi 78-17
• code civil

Accents/majuscules/espaces

Effectivement, ça ne m’étonnerait pas que ça existe, mais je ne sais pas à quel point. Pour y répondre, il faudrait soit prendre quelques textes au hasard et chercher de tels cas, soit améliorer le programme pour prendre ça en compte.

Sur les espaces, j’ai essayé dans la grammaire de toujours utiliser les règles "espace" (un ou plusieurs espaces) ou "espacevide" (zéro ou plusieurs espaces), sauf dans la liste des codes qui reste vulnérable à ce problème du nombre d’espaces. La règle "espacevide" par exemple est nécessaire car il n’y a pas toujours d’espace après une virgule (cf exemple code civil). Sur les espaces, ça doit pouvoir se gérer, le plus difficile est les accents et majuscules.

À long terme, oui, je pense qu’il faudra à long terme gérer ces cas accents/majuscules, et je ne vois pas trop d’autre solution [efficace] que le pre-processing, en retirant les accents/majuscules (voire les doubles espaces). J’ai une petite crainte car il faudrait rajouter dans la règle les noms du type "article 3 bis AB" ou "article 3 ter ab" et pour capturer ça il faut absolument limiter le nombre de caractères du "AB" ou "ab" sinon ça va tout capturer, et éventuellement le fait qu’il y ait des majuscules peut aider à la reconnaissance (les cas "ab" sont assez minoritaires).

Éventuellement, lors de tests, on peut appliquer une grammaire "normale" et une grammaire "normalisée" et vérifier les différences de reconnaissance.

Articles vraiment bizarres

En fin de la doc légistique il y a quelques exemples choisis. J’ai mis au bout de ce lien la liste exhaustive des exceptions.

[Changaco]

La suppression des espaces redondantes est déjà dans le nettoyeur HTML de legi.py, il n'est donc pas nécessaire de les prendre en compte lors de la détection des liens.

[Seb35]

Ok, merci. Par contre, cette librairie pourrait être utilisée dans d’autres contextes que Archéo Lex/legi.py, notamment sur des propositions/projets de loi (rien de réellement prévu pour l’instant, mais je me dis que ça pourrait être utilisé utile pour des dossiers similaires à celui-ci où les liens avaient été fait en partie à la main).

[Changaco]

Mon commentaire était centré sur legi.py mais en fait la suppression des espaces redondantes devrait toujours être traitée avant (pre-processing).

[Changaco]

Beau boulot @Seb35. Je bosse un peu sur la détection des liens dans legi.py aujourd'hui, ce que tu as fait me permet de vérifier et d'améliorer ce que j'avais déjà.

[Changaco]

Il va falloir ajouter une étape de nettoyage des numéros d'article. Il va même falloir faire du découpage en fait, parce qu'un article "28 à 30" (legifrance) ce n'est évidemment pas correct.

[Changaco]

Tickets pour le nettoyage des numéros d'articles et le découpage de certains articles : https://github.com/Legilibre/legi.py/issues/35 et https://github.com/Legilibre/legi.py/issues/34.

[Seb35]

Dans la librairie metslesliens elle-même, je ne touche pas au texte afin de conserver les index du texte original et ne pas avoir à gérer des décalages. En revanche, bien sûr, si les textes peuvent être nettoyés avant l’étape de liens, c’est mieux.

Sur les fautes d’orthographe, je n’ai pas encore d’idées arrêtées sur le sujet, soit il est possible de faire une grammaire laxiste, soit faire deux grammaires, une normale et une laxiste, et on fait tourner les deux pour faire ressortir les erreurs (orthographe, casse, accents…).

[Seb35]

Cette issue est en partie résolvable par la librairie metslesliens mais je suis embêté par deux voire trois problèmes sur l’ajout effectif de liens en syntaxe Markdown :

1. l’ajout de liens changerait les numéros de hash/condensat Git alors que je parti dans l’idée d’essayer de les rendre le plus stable possible dans le temps sur une version minimaliste du texte (donc sans liens) ; cela pourrait se résoudre de deux façons :

   1. d’une part utiliser le système des "git notes" pour attacher aux commits une liste (en JSON j’imagine) listant les liens détectés, cela ne serait donc pas d’utilisation immédiate mais serait une aide pour les réutilisateurs (par exemple le site archeo-lex.fr), [git notes crée une référence refs/notes/commits contenant des fichiers du nom du hash/condensat du commit Git auquel est associé la note],
   2. d’autre part ajouter un flag pour que ceux qui veulent absolument des liens puissent le faire en activant le flag, mais il restera les deux problèmes suivants à décider

2. quoique la reconnaissance des expressions de liens est désormais un problème (quasi-)résolu, la destination du lien est assez fortement dépendante de l’environnement (logiciel) où est affiché ou utilisé le texte Archéo Lex, d’abord pour les liens internes au texte mais surtout pour les liens externes ; par exemple, pour les liens internes, certains logiciels de visualisation du Markdown vont faire une ancre #Article_3 alors que d’autre pourraient faire #Article3 ou #article3 (ce dernier cas pour GitList) et c’est encore pire pour les sections ayant des noms à rallonge et/ou avec des accents, et pour les liens externes s’ajoute le fait qu’il faut savoir où pointer (ce qui dépend de la configuration site-par-site) ; l’ensemble de ce point rend compliqué une résolution générique (ou alors il faudrait implémenter chacun des comportements possibles en ajoutant un certain nombre de paramètres, rendant l’utilisation d’Archéo Lex plus compliquée),

3. selon les goûts, il peut y avoir plusieurs tendances sur ce qu’il faut lier : par exemple pour l’expression « les mêmes articles 3 à 7 » on peut : soit mettre un lien sur chaque nombre pointant vers chaque article, soit mettre un seul lien sur "3 à 7" vers l’article 3, soit un seul lien sur "articles 3 à 7" vers le 3 (choix de Légifrance), soit deux liens sur "articles 3" (→3) "à 7" (→7), sur toute l’expression "les mêmes articles 3 à 7" avec une grosse infobulle qui affiche les articles 3 à 7, soit sur toute l’expression avec un scénario (en Javascript) qui ouvre les articles 3 à 7 en les colorant, etc.

Pour toutes ces raisons, je m’oriente vers le point 1. i. qui délègue au réutilisateur les différents choix des points 2 et 3. Éventuellement, à plus long terme, il peut aussi être possible de créer un système de plugins pour que le réutilisateur implémente sa propre classe Python avec ses choix pour générer directement des dépôts Git avec des liens dans le texte (quoique cela briserait les hash/condensats Git par rapport à la version sans liens).

[Phyks]

Mes deux centimes : Pour le point 2, il est normalement valide d'utiliser du HTML dans du Markdown. Du coup, il serait possible de forcer les ids à utiliser soit en remplaçant les titres en Markdown par des titres HTML avec un attribut id fixé (au prix d'une petite perte de lisibilité), soit en ajoutant un paragraphe / span inutile (et vide) avec l'id. À tester dans différents logiciels de rendu, mais ça pourrait peut être fonctionner.