Attempting a systematic approach

Time flies and it's been more than a year since our last blog post. In the meantime, we have (partially) updated the gross-to-net calculation, but otherwise our resources have been consumed by other commitments.

More recently, we've been working on making the layered core of Refli more concrete. The conceptual layers we introduced earlier were computations, data, and legislative texts, where each layer successively rests on top of the next one. Those layers can be seen in the following diagram, on the left half:

On the right half, we introduce similar layers, but with different names. They map the conceptual layers from the left to their concrete embodiements within Refli, displayed in yellow:

• Starting from the bottom layer, we see that the legislative texts exist within Refli as a mini site called Lex Iterata. We try to keep Refli URLs well organized; the corresponding URL here is /fr/lex. Lex Iterata, as presented on Refli, is essentially just a new rendition of texts available elsewhere (in particular on the web site of the Official Belgian Journal). But for us working with it, it also exists as files, database, and code to manipulate it, giving us extra possibilities to process it.
• Moving to the middle layer, we have a small knowledge base, called "Concepts". Its URL is predictably /en/concepts. The knowledge base records small bits of information about the data that a legislative text describes, and their relationship with other concepts ("computations", but also "documents").
• Finally, the top layer contains the implementation of computations described in the legislative texts. We group those computations and make them available in a mini site called "Playground", at the URL /en/playground.

While the purpose of Lex Iterata is easy to understand, we will expand on the two other layers in the next sections. To have something concrete to talk about, we'll use (one of the cases of) the computation of the social security contributions of freelancers.

Legislative texts

The computation of the social security contributions is described in the text xxx. Other texts appearing each year update some values used in the computation, while the overall description of the computation remains the same.

Concepts and their relationship

1

With the social security contributions of freelancers, we show how we put these ideas into practice:

Starting with the relevant legislative texts, we manually annotate them (providing the "data" part of the three layers), then draw formal connections between those texts, their annotations, the calculations they describe, and the variables the calculations require. From there, we can generate documentation and forms. We then need to manually implement the described computations.

Systematicity

The key insight of the presented approach, or at least that's our hope, is that we can use it to systematically implement the legislative texts relevant to Refli. In effect, implementing new legislative texts would require following these steps:

• Identify a legislative text that we want to implement, and add it to knowledge base.
• Identify related texts, and add them to the knowledge base.
• Identify, within the above texts, computations (and possibly different cases of those computations), variables, and documents the texts describe, and add them to the knowledge base.
• Given an updated knowledge base, we regenerate the "Concepts" mini site. (Diagrams and most of the specific web pages are derived automatically from the data in the knowledge base.)
• For each (sub)computation, we also write some notes. (They appear under the "Description" sections, near the top of the generated pages.)
• Write code to describe the forms associated to the computations. Basic forms can be generated automatically from the knowledge base, by deriving which variables are computation inputs but are not set to specific values by the legislative texts.
• Write code to present the computation results. Again, simple presentations of the results can be generated automatically.
• Finally, implement the computations themselves. This is the more challenging task, but is rendered slightly more easy with the above documentation.

2 Blabla négatif

Introduction possible: on pourrait penser que le point de départ le plus évident pour commencer à réaliser un logiciel de gestion des salaires est l'ensemble des textes législatifs publiés par le SPF justice sur son site web.

On pourrait également penser que, puisque l'état belge a argumenté et décidé que la seule distribution sur le web des textes lui permet de remplir son obligation de distribution à la population belge des textes de loi, ceux-ci seraient effectivement sous un format numérique approprié. Or, que ce soit le format HTML ou le format PDF, l'usage qui en est fait ne répond pas aux attentes légitimes que l'on pourrait avoir.

Malgré ces difficultés, c'est pourtant l'approche choisie par Refli: partir des textes législatifs, et progressivement, si possible avec une approche que l'on pourra répéter encore en encore, arriver à une implémentation qui couvre les différents cas existants.

3

Dans le blog post précédant, nous parlons de trois couches. Nous y remarquons que la couche Data n'est pas très précise. Dans ce blog post-ci, nous précisons cette couche en parlant d'une manière de lier de l'information aux textes légaux pour mieux décrire et faciliciter l'implémentation de la couche Computation.

En effet, un challenge majeur concernant l'implémentation d'un logiciel comme Refli est la grande quantité de textes, et de cas y décrits, mais aussi leur évolution dans le temps. Il est donc important de structurer une approche que l'on pourra, l'espère-t-on, réutiliser aisément.

The three layers (Texts, Data, Computations) exist under Refli behind three prefixes: `/en/lex`, `/en/concepts`, and `/en/playground`.

4

Il y a un an, l'idée (très floue) de la couche Data était simplement d'attacher à certains textes une liste, par exemple, de variables. Finalement, ce que nous avons fait est un peu plus général: nous avons créé une mini base de données où nous avons enregistré la relation "le texte t décrit la variable v".

Cette représentation est extrêmement simplem et en même temps facile à généraliser. Par exemple nous pouvons également dire "le document t présente la variable v", ou "le calcul c utilise la variable v" ou encore "le calcul c calcule la variable w".

Avec une telle mini base de données, il devient trivial de créer une représentation graphique de ces relations. On peut également en dériver d'autres informations intéressantes. Par exemple si l'on connait les variables présentées dans un document, quel calcul est nécessaire pour déterminer ces variables, et quel texte législatif décrit ces variables, on peut déterminer quels documents peuvent potentiellement être impactés lorsque ce texte change.

5

Notre travail sur Refli essaie d'intégrer à un seul object, le logiciel derrière `refli.be`, tout ce qui attrait à sa création, que ce soit la mini base de donnée de notre base de connaissance, la génération de diagrammes qui en sont dérivés, la odumentation des calculs ou leur utilisation.

On peut remarquer cette intégration poussée même sur cette page: le rendu des images ou la présentation des formulaires et résultats de calcul ne sont pas de simples captures d'écran copiées/collées dans ce blog post, mais sont affichés exactement de la même façon que vous pouvez les retrouver dans les mini sites Concepts et Playground.