You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Les bases JORF et LEGI sont liées : la première est la version officielle, juridiquement contraignante, la seconde sont les versions consolidées ultérieures. Ainsi, très souvent (moins vrai pour les textes anciens), un article avec un numéro donné est au moins dans JORF (avec un numéro JORFARTI) puis sa vie future est dans LEGI (avec des numéros LEGIARTI).
Après quelques recherches, j’ai trouvé dans le XML d’un LEGIARTI sa correspondance avec son JORFARTI (le LEGIARTI000031012495, extraire ce dossier de la livraison 20191011-102231 (*)). Dans les balises ARTICLE → VERSIONS → VERSION* → LIEN_ART, il y a la liste des articles de même numéro dans LEGI (ce qui est également intéressant) mais surtout l’article de même numéro dans JORF (JORFARTI000002469313 en l’occurrence).
Je propose de rajouter cette information dans la base LEGI SQLite, au moins la correspondance LEGIARTI → JORFARTI, mais éventuellement plus largement « la version précédente d’un LEGIARTI donné » ce qui permettrait un chaînage.
Sans cette information, la meilleure façon de lier LEGI et JORF est de s’appuyer sur les numéros d’articles (3, 6 bis, etc), mais cela est probablement moins robuste à cause du manque de normalisation des numéros d’articles (même si cela a beaucoup été amélioré par @Changaco). Au moins, cela ferait un lien possible supplémentaire, les deux approches pouvant même être comparées.
(*) tar xfz Freemium_Legi_global_20191011-102231.tar.gz legi/global/code_et_TNC_en_vigueur/TNC_en_vigueur/JORF/TEXT/00/00/00/87/44/JORFTEXT000000874463
The text was updated successfully, but these errors were encountered:
L’idée de la version précédente était que sinon, dans la colonne id_initial, tous les articles de même numéro auront la même donnée du JORFARTI, et y mettre la version précédente n’occuperait pas plus de place et pourrait être utile.
En même temps, la logique de « version précédente » est sujette à définition (y met-on les articles modifiés morts-nés ?), donc c’est peut-être aussi bien de ne pas s’aventurer sur ce terrain et laisser les réutilisateurs utiliser leur propre logique, d’autant que mettre un JORFARTI dans id_initial fait une clé pour regrouper les articles de même numéro.
Les bases JORF et LEGI sont liées : la première est la version officielle, juridiquement contraignante, la seconde sont les versions consolidées ultérieures. Ainsi, très souvent (moins vrai pour les textes anciens), un article avec un numéro donné est au moins dans JORF (avec un numéro JORFARTI) puis sa vie future est dans LEGI (avec des numéros LEGIARTI).
Après quelques recherches, j’ai trouvé dans le XML d’un LEGIARTI sa correspondance avec son JORFARTI (le LEGIARTI000031012495, extraire ce dossier de la livraison 20191011-102231 (*)). Dans les balises ARTICLE → VERSIONS → VERSION* → LIEN_ART, il y a la liste des articles de même numéro dans LEGI (ce qui est également intéressant) mais surtout l’article de même numéro dans JORF (JORFARTI000002469313 en l’occurrence).
Je propose de rajouter cette information dans la base LEGI SQLite, au moins la correspondance LEGIARTI → JORFARTI, mais éventuellement plus largement « la version précédente d’un LEGIARTI donné » ce qui permettrait un chaînage.
Sans cette information, la meilleure façon de lier LEGI et JORF est de s’appuyer sur les numéros d’articles (3, 6 bis, etc), mais cela est probablement moins robuste à cause du manque de normalisation des numéros d’articles (même si cela a beaucoup été amélioré par @Changaco). Au moins, cela ferait un lien possible supplémentaire, les deux approches pouvant même être comparées.
(*)
tar xfz Freemium_Legi_global_20191011-102231.tar.gz legi/global/code_et_TNC_en_vigueur/TNC_en_vigueur/JORF/TEXT/00/00/00/87/44/JORFTEXT000000874463
The text was updated successfully, but these errors were encountered: