Refondre Archéo Lex et le format sous-jacent

[Seb35]

Depuis quelque temps j’ai dans la tête de refondre Archéo Lex en prenant avantage de l’expérience accumulée jusque là, et cela passerait entre autres sur une formaliation de la spec du format utilisé et, dans mon idée, une réécriture de Archéo Lex en JavaScript.

La formalisation de la spec du format a déjà vu une tentative dans le fichier doc/format.md qui est plus ou moins une photographie du format actuel d’Archéo Lex, mais j’aurais bien d’autres éléments à ajouter pour prendre en compte :

• affirmer le rôle pragmatique d’une telle spec : son but premier ne serait pas d’être une base de données exhaustive du corpus législatif (cela est plutôt dévolu aux bases sources de la DILA et à leurs versions SQL (via legi.py par exemple)) mais plutôt un format pratique pour permettre d’autres traitements : diffusion plus pratique, interopérabilité, intégration avec de nombreux outils et écosystèmes, exploitation dans d’autres traitements (metslesliens, DuraLex, comptage facilité des alinéas, autres traitements NLP, création d’outils de visualisation facilitée, etc.), caractère immutable des objets Git.
• créer un format polymorphe : les débats passés et le but pragmatique montrent qu’il est compliqué de définir un format qui réponde à l’ensemble des contraintes et des objectifs : en conséquence je trouve qu’il serait plus sage de définir une famille cohérente de formats adaptée aux différentes situations.
  Par exemple d’un côté un repo Git avec l’ensemble des lois dans le dossier principal (ou dans des sous-dossiers par nature), et d’un autre côté un repo Git avec seulement un code par branche. Par exemple le premier pourrait servir à de la recherche plein texte dans tout ou partie des versions actuelles des textes (quoique pas forcément très efficace) ou à de la veille législative, et le deuxième à la création d’analyses statistiques sur la fréquence de modification de chaque code. Chacun de ces découpages "par texte puis temporel" versus "temporel puis par texte" aurait un intérêt, selon les objectifs, pour prioriser des traitements lourds selon si l’on s’intéresse à toute l’histoire de certains textes ou surtout à l’histoire récente.
  Selon les usages, on peut vouloir tout ou partie du corpus législatif et réglementaire (voir par exemple Export Git de tout les textes dans un seul dépôt #64 en opposition avec le format actuel d’un texte par repo Git).
  Je ne discute pas ici plus avant des différentes options sur les formes, mais cela a à voir avec les objectifs poursuivis et les ressources et la technicité qu’on est prêt à y engager.
• créer un format extensible : je n’ai pas d’idées arrêtées, mais je me dis qu’on peut imaginer utiliser par exemple git-notes pour enrichir les données. Par exemple, on pourrait vouloir attacher à chaque commit un CSV avec les liens vers d’autres textes (localisation du lien dans le texte + destination).
• faciliter la définition des références légistiques : les textes sont très fortement liés au sens juridique avec d’une part les liens entre textes et d’autres part les actions modificatrices des textes récents sur les textes plus anciens : il serait souhaitable que le format facilite autant que faire se peut la création de références afin de naviguer facilement dans le corpus des textes.
  Même si in fine il faut s’appuyer sur des algorithmes pour localiser tel mot de tel alinéa dans tel article de tel code, le format global devrait être conçu de façon à faciliter le plus possible ces algorithmes, notamment avec des conventions de nommage claires : comment gère-t-on les titres, comment gère-t-on les annexes (par ex. État A/B/C/… des lois de finances, tableaux, code annexé à une ordonnance de codification, etc), comment gère-t-on les articles non-nommés ou lorsque deux articles ont le même nom [sic], conventions de nommage sur les textes non-numérotés (arrêtés, circulaires, textes anciens, etc.), etc.
  Les URIs ELI peuvent avoir leur utilité pour une grande partie des textes récents, mais il y a d’autres cas plus particuliers ou plus anciens. Cette problématique se pose également s’il s’agissait de gérer des textes en projet (projets/propositions de loi, projets de décrets, etc.), des textes réglementaires spéciaux (par ex. des décisions d’AAIs (CNIL, AMF, CADA, ASN, etc.) ou « extra-réglementaires » (cahiers des charges des AOCs par ex.).
• gérer le caractère évolutif de la spec : cela est assez standard que les specs évoluent, mais celle-ci pourrait évoluer relativement souvent pour prendre en compte de nouveaux cas particuliers pour les références, l’ajout de nouveaux domaines juridiques (une nouvelle AAI, l’ajout de la législation européenne, italienne, marocaine, etc.)

À noter que le format Git permet de pouvoir stocker dans un même repo, à bas coût, plusieurs formes similaires des textes et de distribuer ensemble ou indépendemment ces formes, ceci de part ses caractéristiques internes (stockage d’objets, compressés et avec compression delta dans les packfiles) et externes (distribution de branches). Lors de la génération du/des repos Git, il serait de bonne programmation que d’écrire les différentes formes demandées en même temps, par exemple écrire la branche "tous textes" et les branches de chaque texte indépendant en même temps vu qu’on introduit des commits ayant les mêmes objets Git (les textes).

En lien avec cette formalisation, j’ai dans l’idée de réécrire Archéo Lex en JavaScript afin d’avoir le même langage que metslesliens et DuraLex-JS afin que Archéo Lex ait un rôle de coordinateur dans la production des dépôts Git et de versions alternatives enrichies de ces deux librairies (je précise toutefois pour ces deux librairies que je souhaite qu’elles conservent une version secondaire en Python via un portage partiel des grammaires PEG.js vers les grammaires Parsimonious/Python étant donné la similarité des dialectes). Mais c’est aussi que j’ai personnellement tendance à préférer désormais le JavaScript au Python, même si cela est subjectif.

Dans cette nouvelle version d’Archéo Lex, j’aurais comme objectifs sur son architecture :

• la performance : en gérant au mieux la mémoire, le CPU et le disque, afin d’être le plus rapide possible pour la mise à jour quotidienne d’un grand nombre de textes
• la modularité : en essayant de ne pas faire trop obstacle à la performance, pour pouvoir utiliser des parties de l’ensemble sans trop d’inter-dépendances internes et pouvoir ainsi ajouter de nouvelles extensions (métadonnées sur les liens, etc.) ou domaines juridiques (législation européenne, etc.)