Pourquoi ObligationFirst diffère de LegalRuleML et Akoma Ntoso

Note : cet article a été révisé lors de la publication de la v0.5.0, le 25 juillet

Lorsque nous avons présenté ObligationFirst, nous avons expliqué qu'il ne s'agissait pas de la première tentative de rendre le droit lisible par machine, mais qu'il s'agissait, à notre connaissance, de la première conçue pour des agents. C'est une affirmation facile à énoncer, plus difficile à démontrer. Cet article en constitue la démonstration, en s'appuyant sur la spécification actuelle (v0.5.0) plutôt que sur de simples intentions.

La comparaison porte sur les deux prédécesseurs les plus influents : Akoma Ntoso, la norme OASIS pour les documents juridiques, et LegalRuleML, la norme OASIS pour les règles que ces documents expriment. Toutes deux sont mâtures. Toutes deux fonctionnent bien pour les publics auxquels elles étaient destinées. Aucune n'a été conçue pour un système devant déterminer s'il peut agir maintenant, et cette différence se retrouve dans les choix de champs.

À quoi servent les prédécesseurs

Akoma Ntoso est un vocabulaire XML destiné aux documents législatifs et judiciaires : sections, articles, paragraphes, références, amendements, signatures. C'est une norme OASIS depuis 2018, utilisée en production par le Sénat italien, le Congrès brésilien et le Parlement kényan, entre autres. Elle excelle à représenter ce qu'est un document juridique et la manière dont ses composantes se relient à d'autres documents.

LegalRuleML est la norme OASIS pour représenter les normes juridiques, construite sur RuleML. Elle fournit des opérateurs déontiques explicites (obligation, permission, interdiction, réparation) et gère la défaisabilité via DefeasibleRule et des hiérarchies d'exceptions. C'est la couche de règles qui se situe, conceptuellement, au-dessus de la couche documentaire.

Ces normes sont mâtures et utiles. Là où ObligationFirst s'y rattache, nous tenons à le préciser explicitement. Là où il s'en écarte, cet écart est délibéré, et le public visé en constitue l'explication.

La différence de public

Akoma Ntoso a été conçu pour les parlements, les tribunaux et les outils juridiques opérés par des humains qui exploitent leurs données. La granularité en découle. Une section est une section. Un amendement est une modification tracée. La fidélité compte, car les utilisateurs sont des rédacteurs et des juristes.

LegalRuleML a été conçu pour les moteurs de raisonnement juridique et la communauté de recherche qui les développe. Il est expressif par nature : il peut coder des relations déontiques complexes, des règles défaisables et des hiérarchies d'exceptions, car ses utilisateurs doivent traiter les cas limites comme le ferait un juriste attentif.

ObligationFirst est conçu pour un agent devant décider s'il doit accomplir une action, et comment. Cet agent a besoin de savoir : ce devoir s'applique-t-il à moi, que requiert-il, est-il applicable aujourd'hui, et sur quoi repose la citation. Le budget d'expressivité est consacré aux champs opérationnels, pas au codage de chaque nuance qu'un futur moteur de raisonnement pourrait souhaiter.

Ce qu'ObligationFirst ne duplique pas

Le signal le plus clair de l'intention réside dans ce que le schéma refuse de posséder en propre.

Là où un encodage Akoma Ntoso faisant autorité existe, un enregistrement ObligationFirst y renvoie plutôt que de le reformuler. L'IRI de l'élément Akoma Ntoso figure dans l'enregistrement comme une correspondance typée akn_uri, jamais comme identifiant principal. eli_uri, urn_lex et citation remplissent le même rôle pour l'European Legislation Identifier, urn:lex et la citation conventionnelle. Les classes d'entités se rattachent à l'ontologie supérieure Semantic Arts gist plutôt que d'en inventer une nouvelle.

Akoma Ntoso modélise des documents. ObligationFirst modélise le contenu normatif que ces documents créent. La correspondance entre les deux est explicite quant à l'écart : pour of:Obligation, la colonne Akoma Ntoso indique « aucun équivalent direct », car Akoma Ntoso code du texte, tandis que les obligations sont dérivées du texte par interprétation. Cet écart constitue la raison d'être même du schéma.

Granularité, et son coût

Dans LegalRuleML, une seule disposition légale peut se décomposer en plusieurs règles, chacune dotée de son propre opérateur déontique, de ses conditions et de sa structure d'exceptions. C'est pertinent pour le raisonnement, mais malcommode pour un agent qui a besoin d'une réponse unique.

ObligationFirst conserve l'obligation comme unité de référence. Un devoir, un enregistrement, accessible à une IRI stable.

Nous en avons payé le prix réel, qui s'est récemment matérialisé. Considérer l'obligation comme unité tend à pousser à rendre cette unité trop grossière. Notre propre implémentation de référence a fait exactement cela : EveryAILaw a publié dix concepts larges (transparence, supervision humaine, prévention des biais, etc.) comme enregistrements d'obligations, si bien que 134 termes légaux se sont retrouvés réduits à dix. Les requêtes renvoyaient une catégorie là où elles auraient dû renvoyer un devoir.

La correction, livrée désormais dans la v0.5.0, a consisté à créer un second type plutôt qu'à assouplir le premier. of:ObligationCategory porte le concept neutre par rapport à la juridiction ; les obligations se rattachent à leur catégorie via skos:exactMatch. Une catégorie ne porte ni juridiction, ni titulaire du devoir, ni terme créateur, car personne ne peut se conformer à une catégorie. Deux lois de juridictions différentes restent comparables par la couche conceptuelle, tandis que la couche des devoirs demeure fidèle à ce que chaque loi exige réellement.

C'est le compromis dans sa forme honnête. La commensurabilité interjuridictionnelle est authentiquement précieuse, et elle mérite son propre type plutôt que d'être glissée subrepticement dans l'obligation.

Ce qu'aucun des deux prédécesseurs ne modélise du tout

La plus grande différence structurelle ne tient pas à un choix de champ. C'est un pan entier qui manque.

LegalRuleML modélise la règle, pas l'affaire juridique qui en dépend. Il n'existe aucune représentation formelle d'une procédure, d'une allégation ou d'une décision. Akoma Ntoso peut représenter le document de jugement produit par un tribunal, mais pas l'affaire qui l'a produit en tant qu'objet interrogeable.

ObligationFirst ajoute of:Proceeding, of:Allegation et of:Determination. La distinction entre allégué et déterminé est essentielle : une assertion dans une affaire juridique demeure alléguée tant qu'elle n'est pas tranchée, et la modéliser comme un simple indicateur de statut sur une même entité impose une classification prématurée. Trois types préservent cette distinction. Une allégation est ce qui a été affirmé. Une détermination est ce qui a été décidé. Une procédure accumule les deux tout au long de son existence.

C'est ce qui permet à une décision de se rattacher au devoir qu'elle interprète. Sur les trois implémentations actuellement en production, on dénombre 59 références croisées entre projets, toutes fonctionnelles.

État, cause, et l'étape supplémentaire

Une loi peut être en vigueur sur le papier tout en étant inapplicable dans les faits. Ces deux réalités comptent pour un agent.

ObligationFirst les répartit en deux champs distincts sur l'instrument. status porte l'état législatif (proposed, enacted, in-force, amended, sunset, repealed, superseded, withdrawn). enforcement_status indique si les devoirs peuvent actuellement être appliqués (routine, constrained, unsignaled). Ces champs sont indépendants, et toute combinaison est valide.

Ce que l'énumération ne porte délibérément pas, c'est la raison. Il n'existe ni stayed-by-court, ni enjoined, ni pending-rulemaking. La cause réside dans le volet des procédures, sous forme d'une détermination qui s'ancre à l'obligation concernée.

Cela impose une étape supplémentaire pour quiconque souhaite afficher « suspendu dans l'attente d'un règlement d'application » comme une phrase unique, et la spécification l'assume explicitement. Nous acceptons ce coût délibérément. Les causes de non-applicabilité sont ouvertes : ordonnances judiciaires, positionnement d'une agence, pauses législatives, action exécutive, déclarations d'urgence. Chaque nouvelle cause impliquerait sinon une extension de l'énumération et une migration pour chaque adoptant. Plusieurs causes peuvent également s'appliquer simultanément, alors qu'un champ scalaire ne peut en porter qu'une seule. Extraire la cause est aussi ce qui rend deux juridictions comparables, puisque toutes deux peuvent être constrained pour des raisons entièrement différentes.

Ce schéma s'est avéré pertinent en aval. PubLedge a, de façon indépendante, séparé ses propres enregistrements d'instruments en un statut légal status et un statut éditorial, et a ajouté un vocabulaire de cycle de vie au niveau de l'obligation incluant never-operative, pour un devoir promulgué mais dont l'instrument d'application a pris fin avant même d'entrer en vigueur. Aucun des deux prédécesseurs n'exprime cela de façon claire.

Supersession et défaisabilité

Akoma Ntoso gère le versionnage par le biais d'amendements et de versions consolidées, avec un graphe d'amendements fidèle au processus législatif. LegalRuleML le gère par des conditions temporelles sur la règle.

ObligationFirst sépare deux notions faciles à confondre. Le remplacement intégral d'un instrument est supersedes, asserté d'un instrument à un autre après promulgation, avec wouldSupersede pour le cas conditionnel avant l'entrée en vigueur. La substitution au niveau de la clause est defeats, assertée de terme à terme.

Cette seconde relation est celle où nous avons conservé davantage de LegalRuleML que ne le laisserait supposer une présentation en « schéma simplifié ». defeats comporte deux sous-propriétés, rebuts et undercuts, reprenant exactement la distinction de LegalRuleML : un terme réfutant affirme la conclusion opposée, un terme invalidant nie que la règle s'applique ici, sans la contredire ailleurs. Nous n'avons pas aplati la structure d'exceptions. Nous l'avons déplacée de l'intérieur d'une règle vers l'espace entre les termes, où un agent peut la parcourir.

Le Colorado en constitue l'exemple concret. Le SB 24-205 est enregistré comme n'étant plus opérant, remplacé par le SB 26-189, qui prend effet le 1er janvier 2027. La relation de succession est assertée, non déduite, et une requête filtrée par date renvoie le devoir qui était opérant à la date interrogée. Rien n'est écrasé sur place ; l'ancien enregistrement demeure accessible pour les plaideurs et les historiens.

Le problème qu'aucun des deux prédécesseurs n'avait

Les deux prédécesseurs supposent l'existence d'un document unique auquel on peut se référer directement. Une fédération de jeux de données juridiques publiés de façon indépendante soulève un problème qu'aucun des deux n'aborde : quel identifiant prévaut.

La réponse d'ObligationFirst est qu'aucun ne prévaut. Chaque identifiant d'enregistrement est local à l'adoptant, opaque et permanent, et les jointures entre jeux de données reposent sur des correspondances standardisées plutôt que sur des identifiants partagés. Chaque éditeur déclare sa propre grammaire d'identifiants dans un profil lisible par machine, à /.well-known/obligation-first-naming-profile.jsonld, précisant le modèle d'URI pour chaque type d'entité et les correspondances qu'il fournit. La spécification valide ce profil ; elle n'en prescrit jamais la grammaire.

C'est peu spectaculaire, mais c'est ce qui fait fonctionner le graphe. Trois jeux de données maintenus indépendamment, 579 enregistrements, aucun registre central, aucun renommage coordonné.

L'interopérabilité est l'objectif

Aucune de ces différences ne constitue un argument contre LegalRuleML ou Akoma Ntoso. Ce sont des arguments en faveur de la conception d'un schéma autour de son utilisateur.

Là où les données se recoupent, la correspondance entre en jeu et est déjà en partie rédigée. Le quatuor déontique s'aligne un à un avec les quatre opérateurs de LegalRuleML, et of:Reparation est maintenu comme sous-classe distincte spécifiquement pour préserver cet alignement. Les documents de correspondance transmettent la logique de règle d'un Term vers un encodage LegalRuleML via un champ lrml_encoded_as, même si nous devons être précis quant à son statut : ceci est documenté dans la correspondance, mais ne constitue pas encore un prédicat du schéma, et la question de sa formalisation reste ouverte dans la spécification. of:executableEncoding pointe déjà vers des encodages Catala, Blawx ou OpenFisca, de sorte que le travail de règles exécutables de cette communauté vienne compléter plutôt que concurrencer.

Deux limites honnêtes. of:Reparation compte, à ce jour, zéro instance dans l'ensemble des implémentations en production, si bien que l'alignement du quatrième opérateur est conçu mais pas encore éprouvé. Et les correspondances ne sont ni gratuites, ni toujours exemptes de perte.

Nous nous attendons à ce que les déploiements mâtures fassent fonctionner plusieurs schémas simultanément, chacun servant l'utilisateur pour lequel il a été conçu. ObligationFirst constitue la surface orientée agent. Les autres demeurent utiles en arrière-plan.

Ce que cela signifie pour vous

Si vous construisez un système destiné à opérer dans un environnement réglementé, un copilote de conformité, un pipeline d'audit, un tableau de bord destiné aux régulateurs, ObligationFirst est conçu pour vos requêtes. Commencez par là.

Si vous menez des travaux de recherche rigoureux en raisonnement juridique, ou si vous développez des outils pour les rédacteurs législatifs, LegalRuleML et Akoma Ntoso demeurent les outils principaux les plus adaptés. Utilisez ObligationFirst comme surface complémentaire là où des schémas de requête orientés agent sont nécessaires.

Si vous construisez une infrastructure destinée à être adoptée par d'autres, la coexistence de plusieurs schémas est un atout. Les points d'interopérabilité entre eux sont précisément là où l'écosystème accumule de la valeur, et les pull requests sur la couche de correspondance sont les bienvenues.

Le positionnement natif pour les agents constitue la contribution. L'interopérabilité est ce qui la maintient utile à mesure que l'écosystème évolue autour d'elle.

Des questions ? Contactez-nous ou consultez notre Politique de confidentialité.