Schéma SQL

[fgallaire]

@Seb35 et @Changaco
Il faudrait que les 3 projets Légilibre utilisant une base SQL se mettent d'accord sur un schéma commun.

[Changaco]

Le schéma utilisé dans legi.py n'est pas encore complet et stable.

Celui d'Archéo Lex ne tient pas compte du fait que la base LEGI contient des anomalies.

C'est quoi le 3e projet ?

[fgallaire]

https://github.com/Legilibre/legi-display en PHP utilise logiquement une base MySQL.

[Changaco]

Pour info j'ai rassemblé le schéma SQL de legi.py dans un fichier dédié schema.sql. Je précise que ce n'est qu'une "première" version encore susceptible de changer (je me demande notamment si je n'aurais pas dû rester avec (cid, id) en clés primaires pour les articles/sections/etc plutôt que id seul).

[Seb35]

Pour comparaison, le schéma de base actuellement utilisé par Archéo Lex, ça ressemble dans les grandes lignes, mais il est globalement moins complet que celui legi.py.

Je verais bien qu’on crée une bibliothèque commune qui gèrerait le téléchargement et les versions officielles de la base LEGI, qui contiendrait le schéma de la base de données commune (donc schéma avec "beaucoup" d’informations, probablement en grande partie issu du schéma de legi.py), et qui alimenterait cette base de données à partir de différentes sources. Les différentes sources pourraient être un peu comme des tags et branches Git : la branche officielle de la base LEGI et d’autres branches ou tags avec des "snapshots" de la base LEGI comme une base LEGI avec des propositions de modifications issues de legi.py ou des propositions d’ajouts de liens entre articles (cf Legilibre/Archeo-Lex#22 Legilibre/Archeo-Lex#2 Legilibre/legi.py#4).

J’avais commencé une telle bibliothèque en me focalisant dans un premier temps sur le téléchargement (elle peut donc être reprise d’autant que c’est sous WTFPL 2.0), mais il faudrait peut-être la revoir, surtout documenter les opérations et résultats, et peut-être optimiser la gestion des fichiers.

[Seb35]

Sinon on parle surtout de la base LEGI, mais il faut penser aussi aux autres bases. Au minimum il faudrait rajouter un paramètre "base" qui serait LEGI ou CNIL ou KALI ou SARDE, mais au fur et à mesure que des gens s’intéresseront à telle ou telle base, il faudra sûrement rajouter des colonnes pour satisfaire aux spécificités des autres bases. Par exemple, je sais que KALI (conventions collectives) a un type de données supplémentaire pour satisfaire aux variations d’une même convention collective (par exemple géographiques), et SARDE (classification des thématiques des lois) a probablement également des spécificités.

[Changaco]

Je ne pense pas que créer un troisième projet en python soit une bonne idée, d'autant que legi.py est déjà lui-même un module empaqueté (il reste juste à publier une première version).

Pour moi implémenter le téléchargement des archives en python est une optimisation, pas une fonctionnalité importante. Le README de legi.py montre comment télécharger les archives LEGI en une commande wget. Cependant si quelqu'un fait une Pull Request pour ajouter le téléchargement des fichiers à legi.py je l'intégrerai probablement.

En ce qui concerne les autres bases, je ne me suis pas encore penché sur le sujet. Il faut déterminer si tout mettre dans les mêmes tables SQL est une bonne ou une mauvaise abstraction, i.e. si elle résout plus de problèmes qu'elle n'en crée.

[Changaco]

J'ai publié la version 0.1 de legi.py. Détails dans Legilibre/legi.py#3 (comment).

[Changaco]

J'ai aussi créé une page sur le wiki : Format de la base LEGI officielle.

[Changaco]

@Seb35 Est-ce que l'idée de modifier Archeo-Lex pour déléguer la conversion des archives en base SQL à legi.py t'intéresse ? Les deux projets ne feraient plus doublon si l'un s'occupait de faire rentrer les données et l'autre de les exporter.

[Seb35]

Oui, j’y pensais tout à l’heure. Je n’avais pas remarqué, avant que tu le fasse remarquer sur l’issue d’Archéo Lex, que tu ne décompressais pas les tarballs, c’est une bonne idée.

Sur le schéma SQL, il faudrait comparer exactement s’il y aurait les données nécessaires pour les exports. En tous cas, vu de loin, Archéo Lex est mauvais sur la gestion des tarballs et pourrait être meilleur sur le SQL (je pense aux liens par exemple que legi.py gère) et legi.py est clairement bon sur ces deux points.

[Changaco]

Normalement toutes les données sont là pour l'export. La table textes connecte les différents id d'un texte entre eux. La table sommaires connecte les sections et articles aux textes (cid) auxquels ils appartiennent. La colonne position indique l'ordre d'affichage (l'ordre dans lequel les éléments étaient dans le fichier source). La colonne debut permet de savoir quand un élément rentre dans le texte, et la colonne fin quand il en est retiré.