Le projet Wikilex https://wikilex.seb35.fr est une base de données des lois françaises (pour l’instant) sur un site Wikibase – le logiciel faisant fonctionner Wikidata. C’est encore expérimental mais je pense entrer dans une phase de “production” d’ici un à deux mois.
Données et synchronisation
L’essentiel des données provient de la base LEGI (~5000 textes de niveau législatif, 100 000 de niveau réglementaire), de bonne qualité pour, en gros, la Ve République mais la qualité chute (beaucoup de manques, quelques erreurs) pour les périodes plus anciennes. Aux données officielles venant de cette base pourront être ajoutées des données provenant de contributeurs, c’est tout l’intérêt du wiki.
Tel que je l’imagine, il ne serait pas possible de modifier les données officielles sur Wikilex, mais on pourrait les déclasser pour indiquer une erreur et encourager l’ajout d’une donnée de meilleure qualité. Par exemple si le titre de la loi indique “loi du 3 novembre 1967” mais la date dans la base de donnée indique “5 novembre 1967”, on déclasserait la donnée officielle et on ajouterait la valeur corrigée. Pour ensuite soumettre les possibles erreurs à la DILA, l’administration qui édite le JORF.
Avancement technique
J’ai commencé ce projet en août 2018 et j’y retravaille depuis août 2019. Le besoin provient :
- du fait que, suite à Archéo Lex, j’avais besoin d’avoir un “annuaire” des lois pour apporter un moteur de recherche des lois, par exemple toutes les ordonnances des années 1980, voir aussi ce post d’Emmanuel sur ce forum,
- je souhaitais mettre à disposition la base de données structurée des lois et même si sqlite.archeo-lex.fr fonctionne, ça n’est pas des plus pratiques,
- il peut être pratique de pouvoir mieux gérer les erreurs et manques dans les données officielles ; Changaco – qui a écrit le programme legi.py – le fait déjà sur un certain nombre de critères, mais ceux-ci sont uniquement des règles automatiques (qu’il faut programmer) et il n’est pas possible d’indiquer une erreur ponctuelle.
Pour être tout à fait transparent, cela me sert d’exemple réel pour mieux connaître le logiciel Wikibase puisque je suis consultant sur MediaWiki, le logiciel de wiki sous-jacent à Wikibase : ça me permet d’avoir un Wikibase en exploitation, d’avoir les problématiques d’import de données, etc. du dogfooding en somme.
Récemment, j’ai réécrit en nodejs le script qui transfère la base de données LEGI format SQLite vers Wikibase, après avoir essayé du PHP (pas de réelle différence entre les deux languages+librairies, c’est plus par volonté d’utiliser nodejs et cette librairie). La base LEGI format SQLite provient elle-même de la base LEGI officielle (format XML) après transformation par legi.py. La performance pour l’import initial est de 8 items/seconde, ça fait quelques heures pour l’import des titres des lois, 2 jours pour l’import des articles.
Je finalise le point du renommage des lois, où il y a plusieurs lignes correspondant à une même loi renommée (jusqu’à 11 renommages pour un décret). Je n’ai pas encore publié ce script encore à l’état expérimental, mais ça ne saurait tarder dès ce point terminé. Ensuite, j’effacerai les données sur le site actuel (pourri car j’ai fait plusieurs imports identiques pour tester la performance) pour repartir proprement, et au passage en mettant dans les premiers numéros des propriétés et items importants (éléments de l’ontologie et codes français, qui auront ainsi des petits identifiants).
Et après
Si vous voulez participer, vous êtes le bienvenue ! Entre autres choses à faire :
- comment organiser les liens entre textes et articles ? et notamment comment bien organiser ces liaisons sachant qu’il y a de multiples versions dans le temps ? J’y ai réfléchi mais n’ai pas d’avis définitif pour l’instant, et cela a des implications potentiellement très importantes en nombres d’items à gérer
- réfléchir aux “contraintes” qu’on peut mettre sur les données (contraintes ayant seulement une valeur indicative) pour repérer les problèmes possibles dans les données, par exemple si la date d’abrogation est avant la date d’entrée en vigueur (en fait, cet exemple est un piège car ça peut légitiment exister
) - discuter des propriétés : par exemple, est-il opportun de mettre toutes les valeurs de type de vigueur indiquées dans la base LEGI (vigueur, vigueur différée, abrogé, abrogé différé, périmé, annulé, modifié, modifié mort-né) ? faut-il ajouter un identifiant vers vie-publique.fr ? vers Wikipédia, vers Wikidata ? etc.
- corriger les données
- ajouter des données, notamment des identifiants vers d’autres sites
- exploiter les données, par exemple ce graphique du nombre de lois sur le XXe siècle (sachant que les données sont incomplètes)
- améliorer le site et sa communauté : discuter sur le nom et nom de domaine (à changer), discuter des règles d’édition, d’accueil des nouveaux, rédiger de la doc/des guides d’introduction…
Ou plus techniquement :
- on pourra aussi envisager de rajouter d’autres bases de données, notamment venant de la DILA et en premier lieu la base JORF qui complètera les données qui ne sont pas entrées dans la base LEGI, probablement car il n’y a pas de version consolidée, mais aussi KALI (conventions collectives), CONSTIT (décisions du Conseil constitutionnel), etc. et peut-être ajouter aussi les projets et propositions de lois pour faire les liens entre ppjl et lois.
- à moyen terme, connecter un bon DuraLex à Wikilex qui apportera des données sur les liens entre lois (tel article cite tel autre article, tel article amende tel autre article)
Liens avec Wikidata
J’ai longtemps hésité à mettre tout cela sur Wikidata. Pour l’instant je pense qu’il est préférable de faire un site Wikibase externe car :
- cela fait potentiellement beaucoup d’items (100 000 lois, 1,4 M d’articles) sachant que Wikidata commence à avoir des difficultés de performances sur ses 60 M d’items, et il faudrait vérifier que les textes, y compris les arrêtés, ont bien leur place sur Wikidata au niveau des critères d’admissibilité
- il faudrait importer plusieurs propriétés (quelques dizaines) [ceci n’est pas forcément bloquant, ça prendrait juste pas mal de temps de discussion]
- sur Wikidata, il n’est pas possible d’interdire en partie l’édition, or je pense que c’est bien conserver les données officielles, même fausses et déclassés, plutôt que de les supprimer
Et avec la fédération, en ajoutant les identifiants Wikidata, il est possible de lier les deux Wikibases avec des requêtes SPARQL fédérées, voire de transférer tout ou partie vers Wikidata à un moment donné.