la programmation logique (PL) avec les logiques de descriptions (LD) est étudiée depuis plus de 30 ans. L'objectif est de profiter des atouts des deux approches, et de pallier leurs inconvénients respectifs, tout en conservant la décidabilité et l'efficacité des raisonnements associés. Le tableau 1 présente un résumé des avantages et inconvénients de la LP et des LD.

Dans cette problématique, on peut classer les approches existantes en deux catégories : celles proposant une intégration de type fusion, qui consistent à n'exécuter qu'un seul raisonnement sur les connaissances modélisées sous forme de règles et d'axiomes ontologiques, et celles proposant une intégration de type API, qui consistent à faire diologuer deux raisonneurs (un pour les règles et l'autre pour les axiomes ontologiques) via des interfaces fonctionnant comme des API.

**Hybridation par fusion.** Ces approches "sur étagère" permettent à l'utilisateur (ingénieur des connaissances) l'usage d'un seul raisonnement; ce qui a comme avantage de lui simplifier le travail en se concentrant sur la modélisation des connaissances et n'a très peu, voire aucun code anexe supplémentaire à créer pour exécuter le raisonnement. La contrepartie est que les systèmes associés sont moins flexibles et qu'il est souvent difficile voire impossible de les étendre afin de construire un raisonneur personnalisé. Par ailleurs, comme l'explique bien [19], l'intégration de type fusion est un vrai défi dès lors que l'on veut assurer la décidabilité du raisonnement et son efficacité, et que l'on veut définir une sémantique rigoureuse qui ne soit pas limitante par rapport aux sémantiques respectives des règles et des axiomes ontologiques, c'est-à-dire qui permette un enrichissement réciproque des connaissances et qui gère de manière claire l'interaction entre les hypothèses du monde ouvert et du monde fermé (qui sont respectivement les hypothèses des LD et de la PL).

Un des premiers travaux d'intégration de type fusion est décrit dans [16], où les auteurs proposent de combiner des clauses de Horn sans fonction avec des ontologies exprimées avec la LD ALCN*. Le formalisme obtenu, appelé CARIN, est utilisé pour permettre la médiation entre des requêtes d'utilisateurs et des sources de données hétérogènes. Le raisonnement associé, appelé "expansion de requêtes", utilise conjointement les règles et axiomes ontologiques pour réécrire la requête donnée en entrée en requêtes exécutables sur les sources. Cependant, les auteurs montrent que même avec deux formalismes séparément décidables, la fusion peut être indécidable. Plus récemment, [19] propose le formalisme MKNF+, basé sur la logique de la connaissance minimale et la négation par échec fini (logic of minimal knowledge and negation as failure). Les auteurs proposent des contraintes nécessaires à la décidabilité, des algorithmes de raisonnement pour vérifier si un atome clos est vrai dans tous les modèles de la base de connaissance, et des bornes pour la complexité de ce raisonnement. Ils montrent comment MKNF+ permet de raisonner avec des axiomes ontologiques et des programmes ASP, en permettant de choisir de raisonner en monde ou-

vert ou fermé pour chaque prédicat utilisé. Au niveau théorique, ce travail apparaît comme un cadre commun possible pour d'autres approches comme DL+log [20], disjunctive dl-programs [18], dl-programs [7], ou encore pour des approches basées sur différentes logiques du premier ordre, comme la logique auto-épistémique [5], un langage de requête du premier ordre orienté logiques de description [3], et la logique des défauts [1]. Tous les détails sont donnés dans [19]. On peut enfin citer le système DLog [17] qui est un raisonneur pour les LD basé sur l'inférence prolog. Cela permet un traitement bien plus efficace des raisonnements assertionnels impliquant de très grands ensembles de données.

**Hybridation par API.** Les approches d'intégration de type API sont des approches plus personnalisables. Le principe est que l'utilisateur modélise son problème avec un langage de PL et que sa résolution utilise en plus une ontologie du domaine en LD pour enrichir l'inférence. La personnalisation tient en ce que l'utilisateur a une certaine latitude pour choisir le raisonneur LD (et donc le raisonnement et la LD sous-jacents), alors que le raisonneur PL est le programme principal. Les deux raisonneurs communiquent en général dans les deux sens via une interface qui s'utilise comme une API. Les raisonnements sur les règles de PL et sur les connaissances ontologiques, dites "externes", peuvent être entrelacés, mais les raisonnements restent séparés. L'utilisateur peut avoir à programmer lui-même quelques scripts permettant la communication entre les raisonneurs, mais cela ne requiert pas d'être spécialiste des langages de KRR sous-jacents.

Ces dernières années, les approches de type API ont principalement utilisé ASP<fnref n="3" /> en tant que formalisme de PL. En particulier, les systèmes DLVHEX et HEXLite [6–8,21,22] implémentent le langage HEX<fnref n="4" />, qui augmente les programmes ASP avec des atomes externes<fnref n="5" /> afin de les enrichir avec plusieurs types d'informations externes. Ces dernières peuvent être des informations stockées (comme des données de sources externes ou des connaissances stockées dans des ontologies), mais aussi des informations calculées (comme des données issues de requêtes et des connaissances issues de raisonnements). Par ailleurs ces atomes externes permettent aussi l'envoi de données aux sources externes, leur permettant d'effectuer leurs calculs. Ainsi, le

<footnote n="3">3. Answer Set Programming est un langage logique complet permettant un raisonnement non monotone, l'usage de négations (par défaut et classique/forte), conjunctions, disjonctions entre clauses et l'ajout de contraintes. Le principe de raisonnement standard ASP se déroule toujours en deux étapes : 1) ground qui consiste à instancier les variables et 2) solve qui résout ce programme transformé en propositions par un algorithme SAT. Les solveurs ASP à l'état de l'art académique et industriel sont les systèmes Clingo (https://potassco.org/) et DLV (https://www.dlvsystem.it/dlvsite/).</footnote>

<footnote n="4">4. Higher-order logic with EXternal atoms. L'implémentation de référence est le solveur dlvhex dont le langage principal est C++ (http://www.kr.tuwien.ac.at/research/systems/dlvhex/). Hexlite est une implémentation légère en Python [22] d'un fragment de HEX et utilise Clingo comme backend ASP.</footnote>

<footnote n="5">5. L'ajout d'atomes externes nécessitent toujours une extension syntaxique + sémantique d'ASP, ainsi qu'une couche additionnelle de préprocessing pour insérer ces atomes externes dans les étapes ground+solve.</footnote>
<table><caption>TABLE 1 – Avantages (+) et inconvénients (-) de la programmation logique et des logiques de description.</caption><thead><tr><th>Programmation logique (programmes faits de règles prolog, ASP, ...)</th><th>Logiques de description (ontologies faites d'axiomes ontologiques exprimés en OWL2)</th></tr></thead><tbody><tr><td>+ Pratique et populaire pour modéliser les aspects dynamiques d'un système</td><td>+ Pratiques et populaires pour modéliser et raisonner sur la connaissance statique d'un domaine</td></tr><tr><td>+ Inférence non monotone</td><td>+ Langages standardisés par le W3C</td></tr><tr><td>+ Implémentations matures et efficaces (XSB prolog, SWI prolog, ...)</td><td>+ De nombreux résultats de complexité</td></tr><tr><td>+ Accès direct à la programmation par contrainte (CLP, ASP, CHR, ...)</td><td>+ Des outils disponibles : Protégé pour la modélisation et des raisonneurs puissants (HermiT, Pellet, ...)</td></tr><tr><td>+ Raisonnement en monde fermé : liens naturels avec les bases de données</td><td>+ Modélisation et raisonnement sur deux niveaux : TBox (axiomes terminologiques, i.e. les concepts) et ABox (axiomes assertionnels, i.e. les données)</td></tr><tr><td>- Par défaut, pas de raisonnement terminologique, focus sur le problème de répondre à des requêtes</td><td>+ Intégration facile avec des bases de données graphes</td></tr><tr><td>- Raisonnement en monde fermé : pas de représentation de connaissances incomplètes et donc difficulté à raisonner sur des domaines infinis</td><td>- OWL2 nécessite une certaine expertise</td></tr><tr><td>- Pas toujours 100% déclaratif</td><td>- Raisonnement en monde ouvert pas toujours adapté</td></tr><tr><td>- Attention à la décidabilité en présence de fonctions</td><td>- Des manques au niveau expressivité (restriction à des prédicats unaires et binaires, pas de réelle jointure)</td></tr><tr><td></td><td>- Complexité des raisonnements qui augmente vite avec l'expressivité de la logique choisie</td></tr><tr><td></td><td>- Problème possible de passage à l'échelle si ABox grande</td></tr><tr><td></td><td>- Impossibilité de modéliser des exceptions (axiomes non toujours vrais)</td></tr></tbody></table>

moteur ASP interne résout un programme Hex en pilotant les appels au raisonneur utilisant l'ontologie, ainsi que les transferts de connaissances du programme à l'ontologie et vice versa. Il est important de remarquer que DLVHEX et HEXLite sont faits pour qu'un développeur non spécialiste d'ASP puisse facilement relier un programme Hex avec une ontologie. Le système Clingo [10] permet aussi l'importation de faits provenant de prédicats définis par des utilisateurs, comme les concepts d'une ontologie. Cela est permis par la présence de fonctions personnalisables dans le grounder Gringo de Clingo, implémentées en Lua ou Python. De plus, depuis sa version 5, Clingo permet d'intégrer des théories personnalisées dans le processus de résolution ASP [9]. Cet enrichissement de la résolution de problèmes ASP revient à une intégration à un bas niveau de capacités de raisonnement sur des théories et des applications utilisateurs. Le raisonnement ASP de base via les étapes de grounding et solving est impacté de manière importante. Pour certaines LD et sous certaines hypothèses, cette fonctionnalité peut être utilisée pour intégrer le raisonnement ontologique au sein de la résolution ASP. Avec cette fonctionnalité, Clingo se rapproche donc d'un système proposant une intégration de type fusion. Cependant, la résolution de théorie de Clingo 5 nécessite de bien connaître les différentes étapes de la résolution ASP, et est destinée principalement aux utilisateurs experts qui souhaitent développer leur propre raisonneur ASP personnalisé plutôt que simplement enrichir leurs problèmes ASP avec des sources externes.

Bien que les approches d'intégration de type fusion aient abouti à de nombreux résultats théoriques, les systèmes basés sur ces dernières sont peu nombreux et n'ont pas (encore) atteint la popularité des raisonneurs LD ou PL. Une des explications possibles tient sans doute en la difficulté à développer un tel système. Par ailleurs, les performances des raisonneurs existants LD et PL rendent très attractives

les approches d'intégration de type API. Par leurs résultats théoriques importants, les approches de type fusion tendent à définir de nouveaux langages de représentation de connaissances et de raisonnement, alors que les approches de type API permettent plus naturellement l'extension de langages existants. Néanmoins, au-delà de leurs spécificités respectives, les approches de type fusion et API s'influencent mutuellement pour faire avancer le domaine vers des langages et systèmes plus expressifs et performants.

## 3 Utilisation de l'extension OWLAPI d'HexLite

Pour proposer une solution pleinement déclarative à ORALoOS, nous présentons ici un retour d'expérimentation avec le système récent HexLite [23]. Ce dernier propose une interface bidirectionnelle entre une ontologie OWL et un programme HEX (extension ASP). OWLAPI est une interface Java de programmation d'ontologies ; celle-ci est développée dans un plugin écrit en Java pour Hexlite et qui utilise comme backend ASP le système Clingo écrit en Python.

### 3.1 Les principes fonctionnels

Pour des raisons de concision, nous limitons notre présentation aux fonctionnalités et renvoyons le lecteur à l'article de P. Schüller pour les définitions formelles.

#### Les atomes ASP de modifications d'une ontologie.

- Insertion d'assertions dans une ABox : addc(C,I), addop(OP, I1, I2), adddp(DP, I, D).

- Suppression d'assertions d'une ABox : delc(C,I), delop(OP, I1, I2), deldp(DP, I, D).

où C, OP et DP sont les classes OWL, les propriétés objet et les propriétés de données OWL respectivement. Les variables I représentent des individus/instances OWL et D une valeur de données (int, string, bool...).
<table><caption>TABLE 1 – Avantages (+) et inconvénients (-) de la programmation logique et des logiques de description.</caption><thead><tr><th>Programmation logique (programmes faits de règles prolog, ASP, ...)</th><th>Logiques de description (ontologies faites d'axiomes ontologiques exprimés en OWL2)</th></tr></thead><tbody><tr><td>+ Pratique et populaire pour modéliser les aspects dynamiques d'un système</td><td>+ Pratiques et populaires pour modéliser et raisonner sur la connaissance statique d'un domaine</td></tr><tr><td>+ Inférence non monotone</td><td>+ Langages standardisés par le W3C</td></tr><tr><td>+ Implémentations matures et efficaces (XSB prolog, SWI prolog, ...)</td><td>+ De nombreux résultats de complexité</td></tr><tr><td>+ Accès direct à la programmation par contrainte (CLP, ASP, CHR, ...)</td><td>+ Des outils disponibles : Protégé pour la modélisation et des raisonneurs puissants (HermiT, Pellet, ...)</td></tr><tr><td>+ Raisonnement en monde fermé : liens naturels avec les bases de données</td><td>+ Modélisation et raisonnement sur deux niveaux : TBox (axiomes terminologiques, i.e. les concepts) et ABox (axiomes assertionnels, i.e. les données)</td></tr><tr><td>- Par défaut, pas de raisonnement terminologique, focus sur le problème de répondre à des requêtes</td><td>+ Intégration facile avec des bases de données graphes</td></tr><tr><td>- Raisonnement en monde fermé : pas de représentation de connaissances incomplètes et donc difficulté à raisonner sur des domaines infinis</td><td>- OWL2 nécessite une certaine expertise</td></tr><tr><td>- Pas toujours 100% déclaratif</td><td>- Raisonnement en monde ouvert pas toujours adapté</td></tr><tr><td>- Attention à la décidabilité en présence de fonctions</td><td>- Des manques au niveau expressivité (restriction à des prédicats unaires et binaires, pas de réelle jointure)</td></tr><tr><td></td><td>- Complexité des raisonnements qui augmente vite avec l'expressivité de la logique choisie</td></tr><tr><td></td><td>- Problème possible de passage à l'échelle si ABox grande</td></tr><tr><td></td><td>- Impossibilité de modéliser des exceptions (axiomes non toujours vrais)</td></tr></tbody></table>

moteur ASP interne résout un programme Hex en pilotant les appels au raisonneur utilisant l'ontologie, ainsi que les transferts de connaissances du programme à l'ontologie et vice versa. Il est important de remarquer que DLVHEX et HEXLite sont faits pour qu'un développeur non spécialiste d'ASP puisse facilement relier un programme Hex avec une ontologie. Le système Clingo [10] permet aussi l'importation de faits provenant de prédicats définis par des utilisateurs, comme les concepts d'une ontologie. Cela est permis par la présence de fonctions personnalisables dans le grounder Gringo de Clingo, implémentées en Lua ou Python. De plus, depuis sa version 5, Clingo permet d'intégrer des théories personnalisées dans le processus de résolution ASP [9]. Cet enrichissement de la résolution de problèmes ASP revient à une intégration à un bas niveau de capacités de raisonnement sur des théories et des applications utilisateurs. Le raisonnement ASP de base via les étapes de grounding et solving est impacté de manière importante. Pour certaines LD et sous certaines hypothèses, cette fonctionnalité peut être utilisée pour intégrer le raisonnement ontologique au sein de la résolution ASP. Avec cette fonctionnalité, Clingo se rapproche donc d'un système proposant une intégration de type fusion. Cependant, la résolution de théorie de Clingo 5 nécessite de bien connaître les différentes étapes de la résolution ASP, et est destinée principalement aux utilisateurs experts qui souhaitent développer leur propre raisonneur ASP personnalisé plutôt que simplement enrichir leurs problèmes ASP avec des sources externes.

Bien que les approches d'intégration de type fusion aient abouti à de nombreux résultats théoriques, les systèmes basés sur ces dernières sont peu nombreux et n'ont pas (encore) atteint la popularité des raisonneurs LD ou PL. Une des explications possibles tient sans doute en la difficulté à développer un tel système. Par ailleurs, les performances des raisonneurs existants LD et PL rendent très attractives

les approches d'intégration de type API. Par leurs résultats théoriques importants, les approches de type fusion tendent à définir de nouveaux langages de représentation de connaissances et de raisonnement, alors que les approches de type API permettent plus naturellement l'extension de langages existants. Néanmoins, au-delà de leurs spécificités respectives, les approches de type fusion et API s'influencent mutuellement pour faire avancer le domaine vers des langages et systèmes plus expressifs et performants.

## 3 Utilisation de l'extension OWLAPI d'HexLite

Pour proposer une solution pleinement déclarative à ORALoOS, nous présentons ici un retour d'expérimentation avec le système récent HexLite [23]. Ce dernier propose une interface bidirectionnelle entre une ontologie OWL et un programme HEX (extension ASP). OWLAPI est une interface Java de programmation d'ontologies ; celle-ci est développée dans un plugin écrit en Java pour Hexlite et qui utilise comme backend ASP le système Clingo écrit en Python.

### 3.1 Les principes fonctionnels

Pour des raisons de concision, nous limitons notre présentation aux fonctionnalités et renvoyons le lecteur à l'article de P. Schüller pour les définitions formelles.

**Les atomes ASP de modifications d'une ontologie.**

- Insertion d'assertions dans une ABox : addc(C,I), addop(OP, I1, I2), adddp(DP, I, D).

- Suppression d'assertions d'une ABox : delc(C,I), delop(OP, I1, I2), deldp(DP, I, D).

où C, OP et DP sont les classes OWL, les propriétés objet et les propriétés de données OWL respectivement. Les variables I représentent des individus/instances OWL et D une valeur de données (int, string, bool...).
Les modifications autorisées par cette extension HexLite ne concernent pas la création ou la suppression de nouveaux concepts (Classe ou Propriété) dans l'ontologie.

**Les atomes externes.** La syntaxe des atomes externes Hexlite est la suivante : `&atom[in](out)`. Le contenu 'in' est une liste de paramètres d'entrée sous la forme de variables comme T, C, ... ou de littéraux représentant des constantes comme onto ou des prédicats comme delta. Le contenu 'out' est une liste de paramètres de sortie de l'atome externe. L'extension OWLAPI Hexlite définit plusieurs atomes externes pour interagir avec une ontologie, en écriture :

- `&dLC[onto,delta,T,C](I)` : récupère les individus de la classe C.

- `&dIOP[onto,delta,T,OP](I1,I2)` : récupère les individus I1 (Domain) et I2 (Range) de la propriété objet OP.

- `&dIDP[onto,delta,T,DP](I,D)` : récupère l'individu I (Domain) et la valeur D (Range) de la propriété de donnée DP.

- `&dIConsistent[onto,delta,T]()` : vérifie la consistance de l'ontologie.

Les atomes qui interagissent en lecture seule sont :

- `&dICro[onto,C](I)` : Requête les individus I de la classe C.

- `&dIOPro[onto,OP](I1,I2)` : requête les individus Domain (I1) et Range (I2) de la propriété objet DP.

- `&dIDPro[onto,DP](I,D)` : requête la propriété de donnée DP pour lire la valeur D pour l'individu Domain I.

Le paramètre onto est une constante référençant l'ontologie. Pour les atomes externes en écriture : `delta` est un prédicat contenant les atomes de modifications *add* et *del* ci-dessus, *T* représente un pas de temps ou une étape de raisonnement sous la forme d'un entier. De plus, il faut comprendre que les modifications sont effectivement propagées en amont au moment de l'interrogation de l'ontologie par un atome externe en écriture. Le type d'atome externe C, DP, OP et le temp T permettent de filtrer les bonnes informations dans le delta qui est définit en extension.

Ces atomes externes nécessitent une extension sémantique d'ASP et il faut aussi partitionner les atomes externes à interpréter au moment de l'étape ground de ceux à interpréter au moment du solve ASP. De notre compréhension des articles [23] et [22], la formalisation du partitionnement n'est pas définie de la même façon, ce qui introduit une difficulté dans l'usage d'HexLite.

## 3.2 Feedback ORALOoS en HexLite

Malgré des efforts importants, nous n'avons pas réussi à installer nativement l'extension OWLAPI d'Hexlite à cause d'un conflit de librairies Java utilisées par le plugin. Par ailleurs, il existe bien un packaging Docker mais ce dernier reste difficile à configurer pour notre problématique.

Nous avons donc décidé d'écrire un nouveau plugin en Python qui utilise le module `Owlready2` pour s'interfacer avec une ontologie OWL en remplacement du plugin Java et de l'API OWLAPI. Par contre, ce nouveau plugin ne concerne

uniquement que les atomes externes en lecture définis dans OWLAPI Hexlite, auxquels nous avons rajouté un atome externe d'accès au type/classe d'un individu de l'ontologie : `&dGetType[onto,I](C)`.

**Encodage HexLite.** La figure 3 présente le code déclaratif du feedback ORALOoS avec notre adaptation de l'extension OWLAPI HexLite. La structure du programme ASP est : (i) une phase d'initialisation d'atomes ASP à partir d'atomes externes HEX de lecture de l'ontologie (lignes 3 à 12); (ii) le calcul ASP des prédicats usable() en tenant compte du domaine du défi courant, l'usage de la négation par défaut (not) pour éliminer ce dernier et ne pas considérer les défis déjà joués (forbids) par l'utilisateur courant (lignes 14 à 17); (iii) la dernière étape du usable consiste à retenir parmi les défis candidats uniquement ceux dont les conditions d'activations sont validées (lignes 19 à 25); et (iv) la dernière partie du programme (lignes 27 à 35) concerne la transcription déclarative en atomes ASP des 3 règles pédagogiques, après avoir récupéré dans l'ontologie le niveau de difficulté du défi évalué ainsi que les niveaux des défis candidats usable().

Malgré une adaptation limitée<fnref n="6" /> du plugin `owlapi` en Python de HexLite, notre programme logique déclaratif permet bien de remplacer le code Python + les règles SWRL présentés en section 2.1.

**Intégration Hexlite.** Après avoir comparé des exécutions indépendantes des programmes ORALOoS et HexLite sur les mêmes données d'entrée et obtenu les mêmes résultats, nous avons cherché à intégrer ces deux programmes. La documentation, plutôt lacunaire, du dépôt Git et les différents articles sur HexLite expliquent que les deux applications peuvent interagir uniquement à travers un échange par fichier : le passage des paramètres d'entrée (identifiant de l'individu OWL feedback) se fait par lecture d'un fichier Json par Hexlite, et les résultats du feedback HexLite (les atomes ASP `reinforce_level`, `remedy_level`, `same_level`) sont retournés à ORALOoS via un fichier Json.

Le synoptique d'intégration est le suivant. D'abord ORALOoS est responsable, via le module `Owlready`, de charger et de réifier en objet une ontologie applicative OWL2. A chaque demande de feedback, Oraloos crée un individu Feedback dans l'ontologie, lui associe les différentes propriétés, en particulier le défi et l'utilisateur concernés par ce retour. Oraloos doit le sauvegarder dans le fichier Owl, écrire le fichier Json de paramétrage du feedback, lancer le script HexLite de calcul. Ensuite Hexlite charge le fichier Owl de l'ontologie, via `Owlready`, le réifie dans un objet spécifique. Hexlite charge ensuite le programme ASP étendu et effectue son calcul en fonction du paramétrage feedback. Au final, il écrit les résultats dans un fichier Json connu d'ORALOoS. Enfin, ORALOoS doit se synchroniser sur ce fichier pour enregistrer les résultats dans l'ontologie, lancer un raisonnement OWL qui classifie le feedback en FB+ ou FB-. Ce processus nous semble difficile à synchroniser entre les différentes lectures/écritures des fichiers par les deux programmes.

<footnote n="6">6. Interface unidirectionnelle OWL -> ASP.</footnote>
Les modifications autorisées par cette extension HexLite ne concernent pas la création ou la suppression de nouveaux concepts (Classe ou Propriété) dans l'ontologie.

**Les atomes externes.** La syntaxe des atomes externes Hexlite est la suivante : `&atom[in](out)`. Le contenu 'in' est une liste de paramètres d'entrée sous la forme de variables comme T, C, ... ou de littéraux représentant des constantes comme onto ou des prédicats comme delta. Le contenu 'out' est une liste de paramètres de sortie de l'atome externe. L'extension OWLAPI Hexlite définit plusieurs atomes externes pour interagir avec une ontologie, en écriture :

- `&dLC[onto,delta,T,C](I)` : récupère les individus de la classe C.

- `&dIOP[onto,delta,T,OP](I1,I2)` : récupère les individus I1 (Domain) et I2 (Range) de la propriété objet OP.

- `&dIDP[onto,delta,T,DP](I,D)` : récupère l'individu I (Domain) et la valeur D (Range) de la propriété de donnée DP.

- `&dIConsistent[onto,delta,T]()` : vérifie la consistance de l'ontologie.

Les atomes qui interagissent en lecture seule sont :

- `&dICro[onto,C](I)` : Requête les individus I de la classe C.

- `&dIOPro[onto,OP](I1,I2)` : requête les individus Domain (I1) et Range (I2) de la propriété objet DP.

- `&dIDPro[onto,DP](I,D)` : requête la propriété de donnée DP pour lire la valeur D pour l'individu Domain I.

Le paramètre onto est une constante référençant l'ontologie. Pour les atomes externes en écriture : `delta` est un prédicat contenant les atomes de modifications *add* et *del* ci-dessus, *T* représente un pas de temps ou une étape de raisonnement sous la forme d'un entier. De plus, il faut comprendre que les modifications sont effectivement propagées en amont au moment de l'interrogation de l'ontologie par un atome externe en écriture. Le type d'atome externe C, DP, OP et le temp T permettent de filtrer les bonnes informations dans le delta qui est définit en extension.

Ces atomes externes nécessitent une extension sémantique d'ASP et il faut aussi partitionner les atomes externes à interpréter au moment de l'étape ground de ceux à interpréter au moment du solve ASP. De notre compréhension des articles [23] et [22], la formalisation du partitionnement n'est pas définie de la même façon, ce qui introduit une difficulté dans l'usage d'HexLite.

## 3.2 Feedback ORALOoS en HexLite

Malgré des efforts importants, nous n'avons pas réussi à installer nativement l'extension OWLAPI d'Hexlite à cause d'un conflit de librairies Java utilisées par le plugin. Par ailleurs, il existe bien un packaging Docker mais ce dernier reste difficile à configurer pour notre problématique.

Nous avons donc décidé d'écrire un nouveau plugin en Python qui utilise le module `Owlready2` pour s'interfacer avec une ontologie OWL en remplacement du plugin Java et de l'API OWLAPI. Par contre, ce nouveau plugin ne concerne

uniquement que les atomes externes en lecture définis dans OWLAPI Hexlite, auxquels nous avons rajouté un atome externe d'accès au type/classe d'un individu de l'ontologie : `&dGetType[onto,I](C)`.

**Encodage HexLite.** La figure 3 présente le code déclaratif du feedback ORALOoS avec notre adaptation de l'extension OWLAPI HexLite. La structure du programme ASP est : (i) une phase d'initialisation d'atomes ASP à partir d'atomes externes HEX de lecture de l'ontologie (lignes 3 à 12); (ii) le calcul ASP des prédicats usable() en tenant compte du domaine du défi courant, l'usage de la négation par défaut (not) pour éliminer ce dernier et ne pas considérer les défis déjà joués (forbids) par l'utilisateur courant (lignes 14 à 17); (iii) la dernière étape du usable consiste à retenir parmi les défis candidats uniquement ceux dont les conditions d'activations sont validées (lignes 19 à 25); et (iv) la dernière partie du programme (lignes 27 à 35) concerne la transcription déclarative en atomes ASP des 3 règles pédagogiques, après avoir récupéré dans l'ontologie le niveau de difficulté du défi évalué ainsi que les niveaux des défis candidats usable().

Malgré une adaptation limitée<fnref n="6" /> du plugin `owlapi` en Python de HexLite, notre programme logique déclaratif permet bien de remplacer le code Python + les règles SWRL présentés en section 2.1.

**Intégration Hexlite.** Après avoir comparé des exécutions indépendantes des programmes ORALOoS et HexLite sur les mêmes données d'entrée et obtenu les mêmes résultats, nous avons cherché à intégrer ces deux programmes. La documentation, plutôt lacunaire, du dépôt Git et les différents articles sur HexLite expliquent que les deux applications peuvent interagir uniquement à travers un échange par fichier : le passage des paramètres d'entrée (identifiant de l'individu OWL feedback) se fait par lecture d'un fichier Json par Hexlite, et les résultats du feedback HexLite (les atomes ASP `reinforce_level`, `remedy-Level`, `same-Level`) sont retournés à ORALOoS via un fichier Json.

Le synoptique d'intégration est le suivant. D'abord ORALOoS est responsable, via le module `Owlready`, de charger et de réifier en objet une ontologie applicative OWL2. A chaque demande de feedback, Oraloos crée un individu Feedback dans l'ontologie, lui associe les différentes propriétés, en particulier le défi et l'utilisateur concernés par ce retour. Oraloos doit le sauvegarder dans le fichier Owl, écrire le fichier Json de paramétrage du feedback, lancer le script HexLite de calcul. Ensuite Hexlite charge le fichier Owl de l'ontologie, via `Owlready`, le réifie dans un objet spécifique. Hexlite charge ensuite le programme ASP étendu et effectue son calcul en fonction du paramétrage feedback. Au final, il écrit les résultats dans un fichier Json connu d'ORALOoS. Enfin, ORALOoS doit se synchroniser sur ce fichier pour enregistrer les résultats dans l'ontologie, lancer un raisonnement OWL qui classifie le feedback en FB+ ou FB-. Ce processus nous semble difficile à synchroniser entre les différentes lectures/écritures des fichiers par les deux programmes.

<footnote n="6">6. Interface unidirectionnelle OWL -> ASP.</footnote>
<figure><img src="image_60.png" /><figcaption>FIGURE 3 – Extrait du feedback en Hexlite.</figcaption></figure>

## 3.3 Conclusions sur HexLite

Fonctionnellement, l'interface bidirectionnelle entre une ontologie OWL et un programme ASP augmenté par Hexlite proposé dans [23] est très prometteur. Nous avons montré que cette approche permet bien de remplacer des régles SWRL + du code impératif et augmente sensiblement l'expressivité déclarative d'une application.

Cependant, la mise en œuvre de bout en bout de l'extension OWLAPI d'Hexlite reste très difficile :

- Installation native du package Hexlite + OWLAPI impossible à mener à son terme.

- Incompréhension sur comment sont partitionnés les atomes externes entre les étapes "ground" et "solve" de l'exécution ASP.

- Documentation à minima au travers d'exemples dans le dépôt Git et les différents articles HexLite; le code github ne semble plus maintenu.

- Problème d'intégration Hexlite avec une application tierce comme ORALooS.

De plus, notre plugin d'interface en Python ne contient pas d'atome externe permettant de modifier l'ontologie à partir d'une solution ASP. Après plusieurs mois de travaux avec Hexlite et pour pallier les limitations ci-dessus, nous avons décidé de développer une nouvelle librairie combinant OWL2 et ASP fonctionnellement similaire à Hexlite.

# 4 Vers une hybridation OWL et ASP opérationnelle

Notre solution alternative prend la forme d'une librairie Python, nommée Exialis, utilisant Clingo comme backend ASP et Owlready2 pour s'interfacer avec des ontologies OWL2. L'objectif d'Exialis est d'avoir une interface bidirectionnelle entre une ontologie OWL2 et un programme ASP. Pour cela nous utilisons les fonctionnalités natives de

Clingo : fonctions externes, Multi-Shot Solving (MSS) et Incremental Solving (IS). Nous utilisons cette librairie pour résoudre notre problème de feedback dans le contexte applicatif ORALooS et des problèmes de type planification où les dimensions temporelle et incrémentale du raisonnement sont prégnantes.

## 4.1 Fonctionnalités natives Clingo

### 4.1.1 Fonctions externes

Définies dans [14], elles nous servent pour définir les opérations de lecture et d'écriture dans l'ontologie. Ces fonctions externes doivent être encapsulées dans un atome ASP name(@function(X, Y))<fnref n="7" />. Les fonctions externes Exialis de lecture d'une ontologie sont les suivantes :

- @dlCro(C, (X,Y), onto) : requête les individus de la classe C.

- @dlPro(P, (X,Y), onto) : requête la propriété P (objet ou donnée) dans l'ontologie onto.

- @dlTro(I, (X,Y), onto) : requête le(s) classe(s) auquel appartient l'individu I.

Le deuxième paramètre des fonctions est un tuple qui permet de filtrer la requête; il peut être vide. Les fonctions externes Exialis de modification d'une ontologie sont :

- @addC(C, I, onto) : écrit dans l'ontologie l'individu I de type C.

- @addOP(P, I1, I2, onto) : ajoute dans l'ontologie la propriété objet P avec l'individu I1 comme Domain et l'individu I2 comme Range.

- @addDP(P, I, V, onto) : ajoute dans l'ontologie la propriété de donnée P avec l'individu I comme Domain et la valeur V comme Range.

- @dlConsistent(onto) : effectue un raisonnement sur l'ontologie et permet de vérifier la consistance de

<footnote n="7">7. Dans un premier temps, les noms sont proches des atomes HexLite, mais nous allons les renommer pour assurer une homogénéité.</footnote>
<figure><img src="image_60.png" /><figcaption>FIGURE 3 – Extrait du feedback en Hexlite.</figcaption></figure>

## 3.3 Conclusions sur HexLite

Fonctionnellement, l'interface bidirectionnelle entre une ontologie OWL et un programme ASP augmenté par Hexlite proposé dans [23] est très prometteur. Nous avons montré que cette approche permet bien de remplacer des régles SWRL + du code impératif et augmente sensiblement l'expressivité déclarative d'une application.

Cependant, la mise en œuvre de bout en bout de l'extension OWLAPI d'Hexlite reste très difficile :

- Installation native du package Hexlite + OWLAPI impossible à mener à son terme.

- Incompréhension sur comment sont partitionnés les atomes externes entre les étapes "ground" et "solve" de l'exécution ASP.

- Documentation à minima au travers d'exemples dans le dépôt Git et les différents articles HexLite; le code github ne semble plus maintenu.

- Problème d'intégration Hexlite avec une application tierce comme ORALooS.

De plus, notre plugin d'interface en Python ne contient pas d'atome externe permettant de modifier l'ontologie à partir d'une solution ASP. Après plusieurs mois de travaux avec Hexlite et pour pallier les limitations ci-dessus, nous avons décidé de développer une nouvelle librairie combinant OWL2 et ASP fonctionnellement similaire à Hexlite.

# 4 Vers une hybridation OWL et ASP opérationnelle

Notre solution alternative prend la forme d'une librairie Python, nommée Exialis, utilisant Clingo comme backend ASP et Owlready2 pour s'interfacer avec des ontologies OWL2. L'objectif d'Exialis est d'avoir une interface bidirectionnelle entre une ontologie OWL2 et un programme ASP. Pour cela nous utilisons les fonctionnalités natives de

Clingo : fonctions externes, Multi-Shot Solving (MSS) et Incremental Solving (IS). Nous utilisons cette librairie pour résoudre notre problème de feedback dans le contexte applicatif ORALooS et des problèmes de type planification où les dimensions temporelle et incrémentale du raisonnement sont prégnantes.

## 4.1 Fonctionnalités natives Clingo

### 4.1.1 Fonctions externes

Définies dans [14], elles nous servent pour définir les opérations de lecture et d'écriture dans l'ontologie. Ces fonctions externes doivent être encapsulées dans un atome ASP name(@function(X, Y))<fnref n="7" />. Les fonctions externes Exialis de lecture d'une ontologie sont les suivantes :

- @dlCro(C, (X,Y), onto) : requête les individus de la classe C.

- @dlPro(P, (X,Y), onto) : requête la propriété P (objet ou donnée) dans l'ontologie onto.

- @dlTro(I, (X,Y), onto) : requête le(s) classe(s) auquel appartient l'individu I.

Le deuxième paramètre des fonctions est un tuple qui permet de filtrer la requête; il peut être vide. Les fonctions externes Exialis de modification d'une ontologie sont :

- @addC(C, I, onto) : écrit dans l'ontologie l'individu I de type C.

- @addOP(P, I1, I2, onto) : ajoute dans l'ontologie la propriété objet P avec l'individu I1 comme Domain et l'individu I2 comme Range.

- @addDP(P, I, V, onto) : ajoute dans l'ontologie la propriété de donnée P avec l'individu I comme Domain et la valeur V comme Range.

- @dlConsistent(onto) : effectue un raisonnement sur l'ontologie et permet de vérifier la consistance de

<footnote n="7">7. Dans un premier temps, les noms sont proches des atomes HexLite, mais nous allons les renommer pour assurer une homogénéité.</footnote>
celle-ci.

Ces fonctions externes sont implémentées via un module Python clingo, cf. §4.2 dans [14]. A la différence des atomes externes d'HexLite, ces fonctions ne nécessitent pas une extension de la sémantique ASP.

## 4.1.2 Multi-shot solving

Rappelons que la résolution standard d'un problème en ASP se fait en une étape (single-shot) : Ground(P) → solve(P'), où P est un programme ASP contenant des variables et P' est la transformation en logique propositionnelle. La résolution 'multi-shot' Clingo [11] permet de partitionner le programme ASP en différents sous-programmes qui peuvent être "Ground" séparément et s'intercaler dans différentes étapes de "Solve".

La déclaration d'un sous-programme Clingo dans l'encodage ASP se fait via la directive : #program n(p1 ..., pk où n est le nom du sous-programme et pi les paramètres. Il existe un sous-programme par défaut avec le nom réservé et sans paramètre : #program base. Toutes les règles ASP non précédées d'une directive #program sont allouées à base. Le contrôle des étapes "Ground" et "Solve" est géré par l'API Clingo via une instance d'un objet Control avec lequel on peut gérer le chargement des fichiers ASP (ctl.load()), le "Ground" d'un sous-programme ASP :ctl.ground() et son "Solve" par :ctl-solving().

A noter que la portée d'un "ground" s'applique uniquement aux sous-programmes donnés en argument, tandis qu'un "solve" déclenche un raisonnement par rapport à tout ce qui a été "ground+solve" précédemment, cf. [14].

## 4.2 Feedback ORALOoS en Exialis

**Encodage Exialis.** Nous illustrons l'usage des fonctions externes et du "multi-shot solving" de Clingo en présentant l'encodage du Feedback ORALOoS :

- La figure 4 est le sous-programme, par défaut, base de Clingo. C'est une initialisation générale par lecture dans l'ontologie des propriétés (DP et OP) des conditions via la fonction externe dlPro().

- La deuxième partie de l'encodage ASP effectue des lectures de l'ontologie contextualisées par un individu Feedback spécifique passé en paramètre du sous-programme step; lignes 7 à 15 de la figure 5. Soulignons dans la ligne 9, l'usage dans la fonction externe dlCro d'un tuple qui filtre parmi tous les défis de l'ontologie uniquement ceux qui sont du même domaine du défi courant. Les lignes 17 à 39 sont l'encodage ASP du calcul des prédicats usable() et du partitionnement selon le niveau de difficultés des défis candidats.

- Le figure 6 est le sous-programme d'écriture dans l'ontologie pour assigner les résultats à l'individu feedback.

**Intégration Exialis.** A la différence d'HexLite, Exialis est une librairie Python que l'on peut importer dans une application tierce en Python, ce qui est le cas d'ORALOoS. Le synoptique d'intégration est le suivant :

- ORALOoS est responsable, via le module Owl-

ready, de charger et de réifier en objet une ontologie applicative OWL2.

- A chaque demande de feedback, ORALOoS créé un individu Feedback dans l'ontologie, lui associate les différentes propriétés, en particulier le défi et l'utilisateur concernés par ce retour. ORALOoS délègue ensuite le calcul du feedback à une instance d'Exialis qui est contextualisé/construit avec l'objet onto et l'individu feedbackID. L'objetctl = Control() de l'API Clingo permet le raisonnement en mode "Multi-Shot Solving" après chargement du programme ASPctl.load("feedback-exialis.lp") :

-ctl.ground([("base", [])]) +ctl.solving()

-ctl.ground([("step", [String feecbackId))]) +
 ctl.solving()

-ctl.ground([("update", [String (feedbackId))]) +
 ctl.solving()

- Une fois le retour synchrone de l'instance Exialis effectué, ORALOoS reprend la main en effectuant un raisonnement OWL (classification du feedback). Si les modifications ASP laissent l'ontologie consistante, ORALOoS peut la sauvegarder.

L'intégration et l'utilisation Exialis par ORALOoS est plus facile qu'avec le programme HexLite.

## 4.3 Généralisation d'Exialis

Le cas d'usage d'Exialis pour ORALOoS est plutôt spécifique : il n'y a pas de dimension temporelle ni d'instanceation multiple d'un contrôleur Clingo. Cela ne permet pas de l'utiliser sur des problèmes comme la planification de robots décrit dans [23] ou des systèmes de configuration de produits industriels [4]. La fonctionnalité IS proposée nativement par le système Clingo depuis sa version 4 [11] permet d'ajouter une dimension temporelle dans les étapes de résolution ASP au moyen de sous-programmes spécifiques. IS est donc une forme spéciale du MSS de Clingo et correspond au modèle déclaratif ASP suivant :

- Un programme base qui modélise les connaissances statiques du problème.

- Un programme step(t) qui capture les connaissances évoluant au cours d'un temps discret (une étape de résolution).

- Un programme check(t) qui permet de vérifier l'atenteinte de l'objectif final du problème à chaque étape de résolution.

Un exemple de ce modèle est l'encodage incrémental des tours de Hanoï de [14]. Inclure les fonctions externes Exialis dans ce modèle permet de mettre en oeuvre une interface bidirectionnelle et incrémentale combinant ASP et OWL2.

## 4.4 Conclusions sur Exialis

Les principaux objectifs d'Exialis sont atteints :

- Avoir une interface bidirectionnelle entre OWL2 et ASP pour traiter le feedback ORALOoS "à la Hexlite". L'usage du "multi-shot solving" et de l'API Control de Clingo permet bien de propager les calculs et les modifications dans l'ontologie pour chaque entité feedback.
celle-ci.

Ces fonctions externes sont implémentées via un module Python clingo, cf. §4.2 dans [14]. A la différence des atomes externes d'HexLite, ces fonctions ne nécessitent pas une extension de la sémantique ASP.

## 4.1.2 Multi-shot solving

Rappelons que la résolution standard d'un problème en ASP se fait en une étape (single-shot) : Ground(P) → solve(P'), où P est un programme ASP contenant des variables et P' est la transformation en logique propositionnelle. La résolution 'multi-shot' Clingo [11] permet de partitionner le programme ASP en différents sous-programmes qui peuvent être "Ground" séparément et s'intercaler dans différentes étapes de "Solve".

La déclaration d'un sous-programme Clingo dans l'encodage ASP se fait via la directive : #program n(p1 ..., pk où n est le nom du sous-programme et pi les paramètres. Il existe un sous-programme par défaut avec le nom réservé et sans paramètre : #program base. Toutes les règles ASP non précédées d'une directive #program sont allouées à base. Le contrôle des étapes "Ground" et "Solve" est géré par l'API Clingo via une instance d'un objet Control avec lequel on peut gérer le chargement des fichiers ASP (ctl.load()), le "Ground" d'un sous-programme ASP : ctl.ground() et son "Solve" par : ctl-solving().

A noter que la portée d'un "ground" s'applique uniquement aux sous-programmes donnés en argument, tandis qu'un "solve" déclenche un raisonnement par rapport à tout ce qui a été "ground+solve" précédemment, cf. [14].

## 4.2 Feedback ORALOoS en Exialis

**Encodage Exialis.** Nous illustrons l'usage des fonctions externes et du "multi-shot solving" de Clingo en présentant l'encodage du Feedback ORALOoS :

- La figure 4 est le sous-programme, par défaut, base de Clingo. C'est une initialisation générale par lecture dans l'ontologie des propriétés (DP et OP) des conditions via la fonction externe dlPro().

- La deuxième partie de l'encodage ASP effectue des lectures de l'ontologie contextualisées par un individu Feedback spécifique passé en paramètre du sous-programme step; lignes 7 à 15 de la figure 5. Soulignons dans la ligne 9, l'usage dans la fonction externe dlCro d'un tuple qui filtre parmi tous les défis de l'ontologie uniquement ceux qui sont du même domaine du défi courant. Les lignes 17 à 39 sont l'encodage ASP du calcul des prédicats usable() et du partitionnement selon le niveau de difficultés des défis candidats.

- Le figure 6 est le sous-programme d'écriture dans l'ontologie pour assigner les résultats à l'individu feedback.

**Intégration Exialis.** A la différence d'HexLite, Exialis est une librairie Python que l'on peut importer dans une application tierce en Python, ce qui est le cas d'ORALOoS. Le synoptique d'intégration est le suivant :

- ORALOoS est responsable, via le module Owl-

ready, de charger et de réifier en objet une ontologie applicative OWL2.

- A chaque demande de feedback, ORALOoS créé un individu Feedback dans l'ontologie, lui associate les différentes propriétés, en particulier le défi et l'utilisateur concernés par ce retour. ORALOoS délègue ensuite le calcul du feedback à une instance d'Exialis qui est contextualisé/construit avec l'objet onto et l'individu feedbackID. L'objet ctl = Control() de l'API Clingo permet le raisonnement en mode "Multi-Shot Solving" après chargement du programme ASP ctl.load("feedback-exialis.lp") :

- ctl.ground([("base", [])]) + ctl.solving()

- ctl.ground([("step", [String feecbackId)])] + ctl.solving()

- ctl.ground([("update", [String feedbackId])]) + ctl.solving()

- Une fois le retour synchrone de l'instance Exialis effectué, ORALOoS reprend la main en effectuant un raisonnement OWL (classification du feedback). Si les modifications ASP laissent l'ontologie consistante, ORALOoS peut la sauvegarder.

L'intégration et l'utilisation Exialis par ORALOoS est plus facile qu'avec le programme HexLite.

## 4.3 Généralisation d'Exialis

Le cas d'usage d'Exialis pour ORALOoS est plutôt spécifique : il n'y a pas de dimension temporelle ni d'instanceation multiple d'un contrôleur Clingo. Cela ne permet pas de l'utiliser sur des problèmes comme la planification de robots décrit dans [23] ou des systèmes de configuration de produits industriels [4]. La fonctionnalité IS proposée nativement par le système Clingo depuis sa version 4 [11] permet d'ajouter une dimension temporelle dans les étapes de résolution ASP au moyen de sous-programmes spécifiques. IS est donc une forme spéciale du MSS de Clingo et correspond au modèle déclaratif ASP suivant :

- Un programme base qui modélise les connaissances statiques du problème.

- Un programme step(t) qui capture les connaissances évoluant au cours d'un temps discret (une étape de résolution).

- Un programme check(t) qui permet de vérifier l'atenteinte de l'objectif final du problème à chaque étape de résolution.

Un exemple de ce modèle est l'encodage incrémental des tours de Hanoï de [14]. Inclure les fonctions externes Exialis dans ce modèle permet de mettre en oeuvre une interface bidirectionnelle et incrémentale combinant ASP et OWL2.

## 4.4 Conclusions sur Exialis

Les principaux objectifs d'Exialis sont atteints :

- Avoir une interface bidirectionnelle entre OWL2 et ASP pour traiter le feedback ORALOoS "à la Hexlite". L'usage du "multi-shot solving" et de l'API Control de Clingo permet bien de propager les calculs et les modifications dans l'ontologie pour chaque entité feedback.
<figure><img src="image_61.png" /><figcaption>FIGURE 4 – Base du feedback avec Exialis.</figcaption></figure>

<figure><img src="image_62.png" /><figcaption>FIGURE 5 – Step du feedback avec Exialis.</figcaption></figure>

— Proposer une solution facilement intégrable et utilisable avec une application tierce.

Le dernier objectif de généraliser la librairie Exialis aux problèmes nécessitant une dimension temporelle est atteignable en utilisant la résolution incrémentale nativement présente dans Clingo.

Par rapport à la catégorisation définie dans la section 2.2, la bibliothèque Exialis se positionne comme une approche d'intégration de type API. Elle permet l'utilisation conjointe de Clingo pour la résolution de programmes logiques ASP, et un raisonneur HermiT ou Pellet pour la partie logiques de description, les deux dialoguant grâce à l'API Owlready2.

# 5 Conclusion et perspectives

Dans l'optique d'apporter une solution complètement déclarative, nous proposons de combiner (hybrider) un langage logique avancé (ASP) avec les logiques de description (OWL2). Nous abordons cette problématique par une démarche pragmatique et opérationnelle, à finalité industrielle. En première approche, nous utilisons la proposition récente OWLAPI HexLite. Si cette proposition donne de bons résultats pour l'aspect déclaratif, plusieurs difficultés de mise en oeuvre nous ont contraint à développer une solution alternative. La librairie Exialis est fonctionnementnellement similaire à HexLite, 100% Python, opérationnelle

pour notre contexte applicatif et généralisable à d'autres problèmes.

Si à court terme, la généralisation d'Exialis reste à finaliser, il serait intéressant d'établir un benchmark d'Exialis par rapport à la solution actuelle ORALOoS (SWRL + Python). De plus, un travail plus théorique reste à accomplir afin d'éclairer quelques différences avec HexLite et d'évaluer l'impact sur la sémantique du raisonnement. Enfin, l'ambition finale de nos travaux est de proposer à la communauté la librairie Exialis en code ouvert, documentée et maintenue.

## Remerciements

Ce travail a été réalisé dans le cadre du contrat UCA-Jeolis référence DRV_VALO_2021431 et ANR_ANR21-PRRD-0009-01_ETP, financé conjointement par la société Jeolis Solutions et l'Agence Nationale de la Recherche via le plan France Relance "Préservation des emplois R&D".

## Références

[1] Franz Baader and Bernhard Hollunder. Embedding defaults into terminological knowledge representation formalisms. *Journal of Automated Reasoning*, 14:149–180, 1995.

[2] Adrien F. Baranes, Pierre-Yves Oudeyer, and Jacqueline Gottlieb. The effects of task difficulty, novelty
<figure><img src="image_61.png" /><figcaption>FIGURE 4 – Base du feedback avec Exialis.</figcaption></figure>

<figure><img src="image_62.png" /><figcaption>FIGURE 5 – Step du feedback avec Exialis.</figcaption></figure>

— Proposer une solution facilement intégrable et utilisable avec une application tierce.

Le dernier objectif de généraliser la librairie Exialis aux problèmes nécessitant une dimension temporelle est atteignable en utilisant la résolution incrémentale nativement présente dans Clingo.

Par rapport à la catégorisation définie dans la section 2.2, la bibliothèque Exialis se positionne comme une approche d'intégration de type API. Elle permet l'utilisation conjointe de Clingo pour la résolution de programmes logiques ASP, et un raisonneur HermiT ou Pellet pour la partie logiques de description, les deux dialoguant grâce à l'API Owlready2.

# 5 Conclusion et perspectives

Dans l'optique d'apporter une solution complètement déclarative, nous proposons de combiner (hybrider) un langage logique avancé (ASP) avec les logiques de description (OWL2). Nous abordons cette problématique par une démarche pragmatique et opérationnelle, à finalité industrielle. En première approche, nous utilisons la proposition récente OWLAPI HexLite. Si cette proposition donne de bons résultats pour l'aspect déclaratif, plusieurs difficultés de mise en oeuvre nous ont contraint à développer une solution alternative. La librairie Exialis est fonctionnementnellement similaire à HexLite, 100% Python, opérationnelle

pour notre contexte applicatif et généralisable à d'autres problèmes.

Si à court terme, la généralisation d'Exialis reste à finaliser, il serait intéressant d'établir un benchmark d'Exialis par rapport à la solution actuelle ORALOoS (SWRL + Python). De plus, un travail plus théorique reste à accomplir afin d'éclairer quelques différences avec HexLite et d'évaluer l'impact sur la sémantique du raisonnement. Enfin, l'ambition finale de nos travaux est de proposer à la communauté la librairie Exialis en code ouvert, documentée et maintenue.

## Remerciements

Ce travail a été réalisé dans le cadre du contrat UCA-Jeolis référence DRV_VALO_2021431 et ANR_ANR21-PRRD-0009-01_ETP, financé conjointement par la société Jeolis Solutions et l'Agence Nationale de la Recherche via le plan France Relance "Préservation des emplois R&D".

## Références

[1] Franz Baader and Bernhard Hollunder. Embedding defaults into terminological knowledge representation formalisms. *Journal of Automated Reasoning*, 14:149–180, 1995.

[2] Adrien F. Baranes, Pierre-Yves Oudeyer, and Jacqueline Gottlieb. The effects of task difficulty, novelty
41 #program update (feedback).
42 delta (@addOP("reinforceLevel", feedback, Challenge, onto)) :- reinforce_level (Challenge).
43 delta (@addOP("remedyLevel", feedback, Challenge, onto)) :- remedy_level (Challenge).
44 delta (@addOP("sameLevel", feedback, Challenge, onto)) :- same_level (Challenge).

<caption>FIGURE 6 – Update du feedback avec Exialis.</caption>

and the size of the search space on intrinsically motivated exploration. *Frontiers in Neuroscience*, 8:317, 2014.

[3] Diego Calvanese, Giuseppe De Giacomo, Domenico Lembo, Maurizio Lenzerini, and Riccardo Rosati. Eql-lite: Effective first-order query processing in description logics. In *International Joint Conference on Artificial Intelligence*, pages 274–279, 2007.

[4] Richard Comploi-Taupe, Giulia Francescutto, and Gottfried Schenner. Applying incremental answer set solving to product configuration. *26th ACM International Systems and Software Product Line Conference*, B:150–155, 2022.

[5] Jos de Bruijn, David Pearce, Axel Polleres, and Agustín Valverde. Quantified equilibrium logic and hybrid rules. In *Web Reasoning and Rule Systems*, pages 58–72, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.

[6] Thomas Eiter, Giovambattista Ianni, Thomas Krennwallner, and Axel Polleres. *Rules and Ontologies for the Semantic Web*, pages 1–53. Springer Berlin Heidelberg, Berlin, Heidelberg, 2008.

[7] Thomas Eiter, Giovambattista Ianni, Thomas Lukasiewicz, Roman Schindlauer, and Hans Tompits. Combining answer set programming with description logics for the semantic web. *Artificial Intelligence*, 172(12):1495–1539, 2008.

[8] Thomas Eiter, Tobias Kaminski, Christoph Redl, Peter Schüller, and Antonius Weinzierl. Answer set programming with external source access. In *Reasoning Web*, 2017.

[9] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, Max Ostrowski, Torsten Schaub, and Philipp Wanko. Theory Solving Made Easy with Clingo 5. In *Technical Communications of the 32nd International Conference on Logic Programming (ICLP 2016)*, volume 52 of *OpenAccess Series in Informatics (OASICS)*, pages 2:1–2:15, Dagstuhl, Germany, 2016. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik.

[10] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. Clingo = asp + control : Preliminary report, 2014.

[11] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. Multi-shot asp solving with clingo. *Theory and Practice of Logic Programming*, 19(1):27–82, 2019.

[12] André Giordan. Éducation thérapeutique du patient : les grands modèles pédagogiques qui les sous-tendent.

*Médecine des maladies métaboliques*, 4(3):305–311, 2010.

[13] Xavier Goblet and Christophe Rey. Suivi thérapeutique intelligent par recommandation à base d'onto logie et de règles. *Conférence Nationale sur les Applications Pratiques de l'Intelligence Artificielle, Afia (Ed)*, pages 50–57, 2020.

[14] Roland Kaminski, Javier Romero, Torsten Schaub, and Philipp Wanko. How to build your own asp-based system?! *Theory and Practice of Logic Programming*, page 1–63, 2021.

[15] Jean-Baptiste Lamy. Owlready : Ontology-oriented programming in python with automatic classification and high level constructs for biomedical ontologies. *Artificial Intelligence in Medicine*, 80:11–28, 2017.

[16] Alon Y. Levy and Marie-Christine Rousset. Combining Horn rules and description logics in CARIN. *Artificial Intelligence*, 104(1):165–209, 1998.

[17] Gergely Lukácsy and Péter Szeredi. Efficient description logic reasoning in Prolog : The DLog system. *Theory and Practice of Logic Programming*, 9:343–414, 05 2009.

[18] Thomas Lukasiewicz. A novel combination of answer set programming with description logics for the semantic web. In Enrico Franconi, Michael Kifer, and Wolfgang May, editors, *The Semantic Web: Research and Applications*, pages 384–398, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.

[19] Boris Motik and Riccardo Rosati. Reconciling description logics and rules. *J. ACM*, 57(5), jun 2010.

[20] Riccardo Rosati. DL+log : Tight integration of description logics and disjunctive datalog. In *Proceedings of the Tenth International Conference on Principles of Knowledge Representation and Reasoning (KR 2006)*, pages 68–78, 2006.

[21] Peter Schüller. The hexlite solver - lightweight and efficient evaluation of hex programs. In *European Conference on Logics in Artificial Intelligence*, 2019.

[22] Peter Schüller. The Hexlite Solver. In Francesco Calimeri, Nicola Leone, and Marco Manna, editors, *Logics in Artificial Intelligence*, pages 593–607, Cham, 2019. Springer International Publishing.

[23] Peter Schüller. A new OWLAPI interface for HEX-programs applied to explaining contingencies in production planning. In *New Foundations for Human-Centered AI, Workshop at ECAI*, 2020.
41 #program update fe (feedback).
42 delta(@addOP("reinforceLevel", feedback, Challenge, onto)) :- reinforce_level (Challenge).
43 delta(@addOP("remedyLevel", feedback, Challenge, onto)) :- remedy_level (Challenge).
44 delta(@addOP("sameLevel", feedback, Challenge, onto)) :- same_level (Challenge).

<caption>FIGURE 6 – Update du feedback avec Exialis.</caption>

and the size of the search space on intrinsically motivated exploration. *Frontiers in Neuroscience*, 8:317, 2014.

[3] Diego Calvanese, Giuseppe De Giacomo, Domenico Lembo, Maurizio Lenzerini, and Riccardo Rosati. Eql-lite : Effective first-order query processing in description logics. In *International Joint Conference on Artificial Intelligence*, pages 274–279, 2007.

[4] Richard Comploi-Taupe, Giulia Francescutto, and Gottfried Schenner. Applying incremental answer set solving to product configuration. *26th ACM International Systems and Software Product Line Conference*, B :150–155, 2022.

[5] Jos de Bruijn, David Pearce, Axel Polleres, and Agustín Valverde. Quantified equilibrium logic and hybrid rules. In *Web Reasoning and Rule Systems*, pages 58–72, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.

[6] Thomas Eiter, Giovambattista Ianni, Thomas Krennwallner, and Axel Polleres. *Rules and Ontologies for the Semantic Web*, pages 1–53. Springer Berlin Heidelberg, Berlin, Heidelberg, 2008.

[7] Thomas Eiter, Giovambattista Ianni, Thomas Lukasiewicz, Roman Schindlauer, and Hans Tompits. Combining answer set programming with description logics for the semantic web. *Artificial Intelligence*, 172(12):1495–1539, 2008.

[8] Thomas Eiter, Tobias Kaminski, Christoph Redl, Peter Schüller, and Antonius Weinzierl. Answer set programming with external source access. In *Reasoning Web*, 2017.

[9] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, Max Ostrowski, Torsten Schaub, and Philipp Wanko. Theory Solving Made Easy with Clingo 5. In *Technical Communications of the 32nd International Conference on Logic Programming (ICLP 2016)*, volume 52 of *OpenAccess Series in Informatics (OASICS)*, pages 2:1–2:15, Dagstuhl, Germany, 2016. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik.

[10] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. Clingo = asp + control : Preliminary report, 2014.

[11] Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. Multi-shot asp solving with clingo. *Theory and Practice of Logic Programming*, 19(1):27–82, 2019.

[12] André Giordan. Éducation thérapeutique du patient : les grands modèles pédagogiques qui les sous-tendent.

*Médecine des maladies métaboliques*, 4(3):305–311, 2010.

[13] Xavier Goblet and Christophe Rey. Suivi thérapeutique intelligent par recommandation à base d'onto logie et de règles. *Conférence Nationale sur les Applications Pratiques de l'Intelligence Artificielle, Afia (Ed)*, pages 50–57, 2020.

[14] Roland Kaminski, Javier Romero, Torsten Schaub, and Philipp Wanko. How to build your own asp-based system?! *Theory and Practice of Logic Programming*, page 1–63, 2021.

[15] Jean-Baptiste Lamy. Owlready : Ontology-oriented programming in python with automatic classification and high level constructs for biomedical ontologies. *Artificial Intelligence in Medicine*, 80:11–28, 2017.

[16] Alon Y. Levy and Marie-Christine Rousset. Combining Horn rules and description logics in CARIN. *Artificial Intelligence*, 104(1):165–209, 1998.

[17] Gergely Lukácsy and Péter Szeredi. Efficient description logic reasoning in Prolog : The DLog system. *Theory and Practice of Logic Programming*, 9:343–414, 05 2009.

[18] Thomas Lukasiewicz. A novel combination of answer set programming with description logics for the semantic web. In Enrico Franconi, Michael Kifer, and Wolfgang May, editors, *The Semantic Web : Research and Applications*, pages 384–398, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.

[19] Boris Motik and Riccardo Rosati. Reconciling description logics and rules. *J. ACM*, 57(5), jun 2010.

[20] Riccardo Rosati. DL+log : Tight integration of description logics and disjunctive datalog. In *Proceedings of the Tenth International Conference on Principles of Knowledge Representation and Reasoning (KR 2006)*, pages 68–78, 2006.

[21] Peter Schüller. The hexlite solver - lightweight and efficient evaluation of hex programs. In *European Conference on Logics in Artificial Intelligence*, 2019.

[22] Peter Schüller. The Hexlite Solver. In Francesco Calimeri, Nicola Leone, and Marco Manna, editors, *Logics in Artificial Intelligence*, pages 593–607, Cham, 2019. Springer International Publishing.

[23] Peter Schüller. A new OWLAPI interface for HEX-programs applied to explaining contingencies in production planning. In *New Foundations for Human-Centered AI, Workshop at ECAI*, 2020.
# Prévention et auto-rééducation de pathologies ostéoarticulaires assistées par intelligence artificielle

Dr Laurent Cervoni<fnref n="1" />, Dr Julien Brasseur<fnref n="1" />, Dr Med. Mehdi Roudesli<fnref n="2" />

laurent.cervoni@talan.com, julien.brasseur@talan.com, m.roudesli@skeewai.com

## Résumé

Les pathologies ostéo-articulaires et tout particulièrement les lombalgies ou les entorses de cheville sont un enjeu de santé publique. Les données décrivant l'impact des traitements sur l'évolution des pathologies sont insuffisantes pour imaginer un processus d'auto-apprentissage. Nous avons donc conçu une application basée, notamment, sur des règles de consensus médicales capable de générer des séances d'exercices adaptées à la pathologie du patient et à son évolution. Nous avons retenu une approche qui, partant de l'entorse de cheville, a pu être généralisée à 12 pathologies et a donné lieu à une application opérationnelle. Recov'up, issue de ces travaux, est disponible sous forme de WebApp (https://recovup.com).

## Mots-clés

Troubles musculo-squelettiques, Intelligence Artificielle, Santé, Programmation Logique, Règles de consensus

## Abstract

Osteoarticular pathologies, particularly low back pain and ankle sprains, are a public health issue. The data describing the impact of treatments on the evolution of pathologies are insufficient to imagine a self-learning process. We have therefore designed an application based, in particular, on medical consensus rules capable of generating exercise sessions adapted to the patient's pathology and its evolution. We selected an approach that, starting from ankle sprains, could be generalized to 12 pathologies and resulted in an operational Web application. Recov'up, resulting from this work, is available as a WebApp (https://recovup.com)

## Keywords

Musculoskeletal disorders, Artificial Intelligence, Health, Logical Programming, Consensus rules

## 1 Introduction

Les pathologies ostéoarticulaires des membres inférieurs représentent 25 % de l'ensemble des pathologies

ostéoarticulaires. La cheville, avec près de 6000 personnes atteintes [1] par jour en France, représente, à elle seule, 7 à 10 % des urgences hospitalières et plus d'un quart des pathologies des membres inférieurs. Il s'agit d'un problème de Santé publique dont le coût est estimé à 1.2 millions d'euros par jour. Le coût total annuel, pour la société, des entorses de cheville a même été estimé approximativement à 40 millions d'euros par million d'habitants.

Le chiffre des récidives est éloquent : 30 % des gens présentent un problème persistant au-delà de 1 an. ([2] et [3]). D'autres études pointent des séquelles encore plus importantes. Ceci souligne l'importance de la prévention et de traitements rapide, notamment par la mise en œuvre d'exercices de rééducation ([4]).

**La prise en charge se fait, généralement, sur la base de « règles de consensus » médicales qui permettent d'évaluer la gravité de la pathologie.** Les approches par proprioception, par exemple, ont entraîné une réduction de 50 % des récidives [5]. Il est aussi mis en avant la place de l'auto-rééducation dans la stratégie de rééducation.

La comparaison d'une rééducation supervisée par un praticien et une auto-rééducation à domicile tend à montrer des résultats fonctionnels similaires pour la cheville. On observe une meilleure observance, notamment pour le respect des rendez-vous médicaux et un meilleur résultat de suivi du programme de soin.

Les lombalgies constituent aussi un enjeu de santé publique similaire, 80% de la population étant susceptible de souffrir de lombalie au cours de sa vie, et plus de la moitié de la population française déclare un épisode de mal de dos sur une année<fnref n="1" />. En première intention, une autogestion et des exercices ciblés sont recommandés par la HAS. Pour cette pathologie aussi plusieurs études ont cherché à démontrer l'intérêt des soins en autonomie éventuellement assistés par une application ([6] et [7]).

Il paraît donc pertinent de pouvoir autonomiser le patient dans la réalisation de tests fonctionnels seuls ou assistés par

<footnote n="1">¹ Centre de Recherche et d'Innovation de Talan, Paris, France</footnote>

<footnote n="2">² Centre de l'appareil locomoteur de l'estuaire, Le Havre</footnote>

<footnote n="1">¹ https://www.ameli.fr/medecin/sante-prevention/pathologies/lombalgies/enjeu-sante-publique</footnote>
# Prévention et auto-rééducation de pathologies ostéoarticulaires assistées par intelligence artificielle

Dr Laurent Cervoni<fnref n="1" />, Dr Julien Brasseur<fnref n="1" />, Dr Med. Mehdi Roudesli<fnref n="2" />

laurent.cervoni@talan.com, julien.brasseur@talan.com, m.roudesli@skeewai.com

## Résumé

Les pathologies ostéo-articulaires et tout particulièrement les lombalgies ou les entorses de cheville sont un enjeu de santé publique. Les données décrivant l'impact des traitements sur l'évolution des pathologies sont insuffisantes pour imaginer un processus d'auto-apprentissage. Nous avons donc conçu une application basée, notamment, sur des règles de consensus médicales capable de générer des séances d'exercices adaptées à la pathologie du patient et à son évolution. Nous avons retenu une approche qui, partant de l'entorse de cheville, a pu être généralisée à 12 pathologies et a donné lieu à une application opérationnelle. Recov'up, issue de ces travaux, est disponible sous forme de WebApp (https://recovup.com).

## Mots-clés

Troubles musculo-squelettiques, Intelligence Artificielle, Santé, Programmation Logique, Règles de consensus

## Abstract

Osteoarticular pathologies, particularly low back pain and ankle sprains, are a public health issue. The data describing the impact of treatments on the evolution of pathologies are insufficient to imagine a self-learning process. We have therefore designed an application based, in particular, on medical consensus rules capable of generating exercise sessions adapted to the patient's pathology and its evolution. We selected an approach that, starting from ankle sprains, could be generalized to 12 pathologies and resulted in an operational Web application. Recov'up, resulting from this work, is available as a WebApp (https://recovup.com)

## Keywords

Musculoskeletal disorders, Artificial Intelligence, Health, Logical Programming, Consensus rules

## 1 Introduction

Les pathologies ostéoarticulaires des membres inférieurs représentent 25 % de l'ensemble des pathologies

ostéoarticulaires. La cheville, avec près de 6000 personnes atteintes [1] par jour en France, représente, à elle seule, 7 à 10 % des urgences hospitalières et plus d'un quart des pathologies des membres inférieurs. Il s'agit d'un problème de Santé publique dont le coût est estimé à 1.2 millions d'euros par jour. Le coût total annuel, pour la société, des entorses de cheville a même été estimé approximativement à 40 millions d'euros par million d'habitants.

Le chiffre des récidives est éloquent : 30 % des gens présentent un problème persistant au-delà de 1 an. ([2] et [3]). D'autres études pointent des séquelles encore plus importantes. Ceci souligne l'importance de la prévention et de traitements rapide, notamment par la mise en œuvre d'exercices de rééducation ([4]).

**La prise en charge se fait, généralement, sur la base de « règles de consensus » médicales qui permettent d'évaluer la gravité de la pathologie.** Les approches par proprioception, par exemple, ont entraîné une réduction de 50 % des récidives [5]. Il est aussi mis en avant la place de l'auto-rééducation dans la stratégie de rééducation.

La comparaison d'une rééducation supervisée par un praticien et une auto-rééducation à domicile tend à montrer des résultats fonctionnels similaires pour la cheville. On observe une meilleure observance, notamment pour le respect des rendez-vous médicaux et un meilleur résultat de suivi du programme de soin.

Les lombalgies constituent aussi un enjeu de santé publique similaire, 80% de la population étant susceptible de souffrir de lombalie au cours de sa vie, et plus de la moitié de la population française déclare un épisode de mal de dos sur une année<fnref n="1" />. En première intention, une autogestion et des exercices ciblés sont recommandés par la HAS. Pour cette pathologie aussi plusieurs études ont cherché à démontrer l'intérêt des soins en autonomie éventuellement assistés par une application ([6] et [7]).

Il paraît donc pertinent de pouvoir autonomiser le patient dans la réalisation de tests fonctionnels seuls ou assistés par

<footnote n="1">¹ Centre de Recherche et d'Innovation de Talan, Paris, France</footnote>

<footnote n="2">² Centre de l'appareil locomoteur de l'estuaire, Le Havre</footnote>

<footnote n="1">¹ https://www.ameli.fr/medecin/sante-prevention/pathologies/lombalgies/enjeu-sante-publique</footnote>
informatique, afin que les praticiens aient accès à davantage d'informations pour personnaliser le parcours de soins.

L'intelligence artificielle peut donc jouer un rôle significatif dans l'accompagnement des rééducations des pathologies ostéoarticulaires et cette stratégie d'autonomisation. Toutefois, si l'IA connaît un nombre croissant d'applications médicales, la plupart d'entre-elles portent sur l'aide au diagnostic ou l'imagerie et beaucoup plus rarement sur la thérapeutique. Une des raisons majeures à cela réside dans le caractère sensible des données médicales. Aussi, dans bien des cas, il n'existe aucune base de données disponible, ce qui est le cas des pathologies ostéoarticulaires.

Dans cet article, nous présentons un cas pratique (Recov'Up) conçu dans le cadre d'une collaboration entre la start-up Skeewai et le Centre de Recherche et d'Innovation du groupe Talan. Celle-ci repose principalement sur des règles de consensus, les recommandations de la Haute Autorité de Santé<fnref n="2" /> et la mise en pratique de l'expertise de praticiens (médecins du sport et kinésithérapeutes) exprimée sous forme de règles « logiques ».

## 2 Genèse et contexte des travaux

Au coût total pour la société, et pour les entreprises privées, de la prise en charge des pathologies telles que l'entorse de cheville et des arrêts de travail qui en découlent, s'ajoute le risque de récidive. Une re-mobilisation rapide dans le cadre de l'entorse de cheville semble être favorable à la réduction des risques de récidives [8] et [9].

Pourtant, seuls 50 % des cas font l'objet d'un suivi médical. Une large proportion des patients risque donc de développer une instabilité chronique de la cheville. ([10] et [11]).

Il n'existe pourtant pas de méthode médicale universelle « déterministe » pour traiter l'entorse de cheville. Cette situation n'est pas surprenante au regard du nombre de facteurs qui entrent en jeu dans la pathologie et l'essence même de la pratique médicale qui doit être la plus personnalisée.

Le site Ameli précise, concernant la rééducation, que « Le nombre de séances préconisés est de 10 pour une entorse de cheville récente. La rééducation n'est pas systématique, et se propose en fonction des besoins estimés par le médecin. »

Ainsi, il existe des recommandations sur avis d'experts dont la réalisation de tests d'évaluation des déficiences sensorimotrices. Notamment, dans les travaux les plus récents et qui constituent la référence internationale en matière d'analyse de l'entorse de cheville, on observe que « Le comité exécutif de l'International Ankle Consortium est parvenu à un consensus sur les recommandations pour une évaluation clinique structurée des lésions latérales aiguës de l'entorse de la cheville. Les recommandations sont fournies sur la base d'une évaluation clinique diagnostique initiale. L'International Ankle Consortium ROAST [...] met l'accent sur l'évaluation des déficiences mécaniques et sensorimotrices connues pour être associées à une instabilité chronique de la cheville. » (Source Clinical assessment of acute lateral ankle

sprain injuries (ROAST): 2019 consensus statement and recommendations of the International Ankle Consortium).

L'absence de démarche « algorithmique » ou simplement formelle conduit à envisager des approches expérimentales qui ne peuvent s'appuyer sur une programmation informatique traditionnelle.

L'absence de base de données de patients avec les suivis thérapeutiques associés évoquée précédemment vient s'ajouter aux motivations de retenir un système à base de règles pour proposer un accompagnement thérapeutique.

Le projet RecovUp a donc été initié sur la base de ces constats, début 2020. L'équipe médicale (1 kiné, 1 médecin du sport) a collecté l'ensemble des exercices utilisés par les praticiens et disponibles dans la littérature, utilisant ou non du matériel simple. La liste des exercices varie d'une vingtaine à plus de cinquante selon les pathologies prises en compte par l'application.

La mise en œuvre des exercices dans le parcours de soin a été définie par l'équipe médicale au regard du bénéfice apporté selon la date initiale de la pathologie, de sa nature, de la capacité du patient à effectuer certains tests fonctionnels simples et de réponses sur l'évolution de la douleur, notamment. Le développement du moteur modélisant les exercices et l'interface associé s'est étalé sur un an environ avant la mise en situation réelle.

## 3 Complexité de la génération d'exercices d'auto-rééducation

Dans le traitement de la cheville, nous avons retenu un panel de 30 exercices environ, classés dans différentes familles (sur la base notamment des recommandations de la Haute Autorité de Santé ([12]).

L'objectif est de proposer des séances de 3, 4 ou 5 exercices (le nombre étant fixé par les règles proposées par l'équipe médicales en fonction de l'évolution de la pathologie et en évitant la monotonie des séances afin de ne pas lasser le patient), choisis dans cette liste de 30 exercices.

L'espace complet pour 3 à 5 exercices est théoriquement

$$C_{30}^{3} + C_{30}^{4} + C_{30}^{5} = 4060 + 27405 + 142506 = 173971$$

Dans la pratique, l'espace réel est un peu plus complexe à calculer, certains exercices devant, selon les situations, être pris dans une famille ou une autre et le nombre d'exercices ayant été étendu. Certaines familles sont exclusives des autres ou au contraire être associées.

Si on introduit les notions de durées, l'espace est nettement plus important. La gestion des durées se traduit par l'ajout de répétitions afin de rentrer dans un intervalle de temps pour qu'une séance soit acceptable pour le patient avec une durée minimale efficace.

Si on souhaite « simuler », dans un domaine discret, la gestion des exercices, cela reviendrait à ajouter à la liste des exercices tous les cas de répétitions possibles. Comme les exercices peuvent être réalisés sur des séries de 8 à 15 répétitions, 3 à 5 fois chacun, il y aurait donc un espace de 40 à 75 représentants

<footnote n="2">² https://www.has-sante.fr/upload/docs/application/pdf/2019-04/fm_lombalie_v2_2.pdf et https://www.has-sante.fr/upload/docs/application/pdf/recosentors.pdf</footnote>
informatique, afin que les praticiens aient accès à davantage d'informations pour personnaliser le parcours de soins.

L'intelligence artificielle peut donc jouer un rôle significatif dans l'accompagnement des rééducations des pathologies ostéoarticulaires et cette stratégie d'autonomisation. Toutefois, si l'IA connaît un nombre croissant d'applications médicales, la plupart d'entre-elles portent sur l'aide au diagnostic ou l'imagerie et beaucoup plus rarement sur la thérapeutique. Une des raisons majeures à cela réside dans le caractère sensible des données médicales. Aussi, dans bien des cas, il n'existe aucune base de données disponible, ce qui est le cas des pathologies ostéoarticulaires.

Dans cet article, nous présentons un cas pratique (Recov'Up) conçu dans le cadre d'une collaboration entre la start-up Skeewai et le Centre de Recherche et d'Innovation du groupe Talan. Celle-ci repose principalement sur des règles de consensus, les recommandations de la Haute Autorité de Santé<fnref n="2" /> et la mise en pratique de l'expertise de praticiens (médecins du sport et kinésithérapeutes) exprimée sous forme de règles « logiques ».

## 2 Genèse et contexte des travaux

Au coût total pour la société, et pour les entreprises privées, de la prise en charge des pathologies telles que l'entorse de cheville et des arrêts de travail qui en découlent, s'ajoute le risque de récidive. Une re-mobilisation rapide dans le cadre de l'entorse de cheville semble être favorable à la réduction des risques de récidives [8] et [9].

Pourtant, seuls 50 % des cas font l'objet d'un suivi médical. Une large proportion des patients risque donc de développer une instabilité chronique de la cheville. ([10] et [11]).

Il n'existe pourtant pas de méthode médicale universelle « déterministe » pour traiter l'entorse de cheville. Cette situation n'est pas surprenante au regard du nombre de facteurs qui entrent en jeu dans la pathologie et l'essence même de la pratique médicale qui doit être la plus personnalisée.

Le site Ameli précise, concernant la rééducation, que « Le nombre de séances préconisés est de 10 pour une entorse de cheville récente. La rééducation n'est pas systématique, et se propose en fonction des besoins estimés par le médecin. »

Ainsi, il existe des recommandations sur avis d'experts dont la réalisation de tests d'évaluation des déficiences sensorimotrices. Notamment, dans les travaux les plus récents et qui constituent la référence internationale en matière d'analyse de l'entorse de cheville, on observe que « Le comité exécutif de l'International Ankle Consortium est parvenu à un consensus sur les recommandations pour une évaluation clinique structurée des lésions latérales aiguës de l'entorse de la cheville. Les recommandations sont fournies sur la base d'une évaluation clinique diagnostique initiale. L'International Ankle Consortium ROAST [...] met l'accent sur l'évaluation des déficiences mécaniques et sensorimotrices connues pour être associées à une instabilité chronique de la cheville. » (Source Clinical assessment of acute lateral ankle

sprain injuries (ROAST): 2019 consensus statement and recommendations of the International Ankle Consortium).

L'absence de démarche « algorithmique » ou simplement formelle conduit à envisager des approches expérimentales qui ne peuvent s'appuyer sur une programmation informatique traditionnelle.

L'absence de base de données de patients avec les suivis thérapeutiques associés évoquée précédemment vient s'ajouter aux motivations de retenir un système à base de règles pour proposer un accompagnement thérapeutique.

Le projet RecovUp a donc été initié sur la base de ces constats, début 2020. L'équipe médicale (1 kiné, 1 médecin du sport) a collecté l'ensemble des exercices utilisés par les praticiens et disponibles dans la littérature, utilisant ou non du matériel simple. La liste des exercices varie d'une vingtaine à plus de cinquante selon les pathologies prises en compte par l'application.

La mise en œuvre des exercices dans le parcours de soin a été définie par l'équipe médicale au regard du bénéfice apporté selon la date initiale de la pathologie, de sa nature, de la capacité du patient à effectuer certains tests fonctionnels simples et de réponses sur l'évolution de la douleur, notamment. Le développement du moteur modélisant les exercices et l'interface associé s'est étalé sur un an environ avant la mise en situation réelle.

## 3 Complexité de la génération d'exercices d'auto-rééducation

Dans le traitement de la cheville, nous avons retenu un panel de 30 exercices environ, classés dans différentes familles (sur la base notamment des recommandations de la Haute Autorité de Santé ([12]).

L'objectif est de proposer des séances de 3, 4 ou 5 exercices (le nombre étant fixé par les règles proposées par l'équipe médicales en fonction de l'évolution de la pathologie et en évitant la monotonie des séances afin de ne pas lasser le patient), choisis dans cette liste de 30 exercices.

L'espace complet pour 3 à 5 exercices est théoriquement

$$C_{30}^{3} + C_{30}^{4} + C_{30}^{5} = 4060 + 27405 + 142506 = 173971$$

Dans la pratique, l'espace réel est un peu plus complexe à calculer, certains exercices devant, selon les situations, être pris dans une famille ou une autre et le nombre d'exercices ayant été étendu. Certaines familles sont exclusives des autres ou au contraire être associées.

Si on introduit les notions de durées, l'espace est nettement plus important. La gestion des durées se traduit par l'ajout de répétitions afin de rentrer dans un intervalle de temps pour qu'une séance soit acceptable pour le patient avec une durée minimale efficace.

Si on souhaite « simuler », dans un domaine discret, la gestion des exercices, cela reviendrait à ajouter à la liste des exercices tous les cas de répétitions possibles. Comme les exercices peuvent être réalisés sur des séries de 8 à 15 répétitions, 3 à 5 fois chacun, il y aurait donc un espace de 40 à 75 représentants

<footnote n="2">² https://www.has-sante.fr/upload/docs/application/pdf/2019-04/fm_lombalie_v2_2.pdf et https://www.has-sante.fr/upload/docs/application/pdf/recosentors.pdf</footnote>
de chaque exercice.

Dans ce cas, l'espace total dépasse plusieurs millions de combinaisons possibles (dans le pire des cas) puisqu'il faudrait calculer toutes les associations de répétitions.

## Définition des règles

Nous avons structuré la génération des exercices en 4 catégories de règles :

1) Des règles générales :

* Une séance doit comporter entre 3 et 5 exercices (selon l'évolution du patient et la pathologie)

* Les règles de progressivité qui précisent l'évolution du nombre d'exercices et de séries d'un exercice doivent toujours être respectées

* Une séance doit débuter par une mesure de la douleur au de repos, Echelle Visuelle Analogique (EVA), et terminer par une EVA post-séance

* La rééducation se déroule sur une durée minimale (celle-ci pourra varier selon d'autres pathologies que la cheville) et ne s'achève que si un certain nombre de critères est atteint.

2) Des règles de progressivité dont un échantillon est :

* Les exercices proposés doivent être issus d'au moins 2 familles différentes (celles-ci étant, par exemple, proprioception, renforcement, excentrique, etc...)

* Avant J5 (ie dans les 5 jours qui suivent la blessure), appliquer le protocole « Glaçage, Repos, Elévation Compression » (GREC)

* Aucun exercice des familles médicalement considérées comme peu efficaces, après J15

* Aucun exercice de sur-sollicitation avant J15

* Ne jamais proposer moins de 2 exercices de certaines familles à partir de J21

* Etc...

3) Des règles d'irritabilité comme, par exemple :

* Si l'EVA post-séance est supérieure à l'EVA de repos de plus de 20% alors ne pas suivre la règle de progressivité pour la séance suivante.

4) Des règles « de cause à effet » :

* Des familles d'exercices différentes sont proposées en fonction de tests fonctionnels réalisés et auto-évalués par le patient.

* Selon le résultat de scores (comme le Limb Symmetry Index), les exercices sont adaptés en intégrant aussi le fait que le patient dispose ou non du matériel nécessaire (élastique, coussin instable).

## Etude de complexité

Considérons, à titre d'exemple, la règle "avant le cinquième jour, ne faire que des exercices de type A (dans la modélisation les familles d'exercices sont numérotées par des lettres), et jamais après". Cette dernière peut s'écrire sous la forme :

$$L_{\text{prog}}^{(1)} := \left( \bigwedge_{k \le 5} \text{NbEx}(A, 1, k) \wedge \bigwedge_{j \in A} \overline{\text{Exer}(j, k)} \right) \wedge \left( \bigwedge_{k > 5} \overline{\text{NbEx}(A, 1, k)} \right).$$

Ici, Exer(j,k) est un booléen qui est actif lorsqu'un exercice de type j est réalisé au jour k, et NbEx(A,1,k) est un booléen, construit à l'aide de Exer(j,k), dont la définition formelle est :

$$\text{NbEx}(A, 1, k) := \bigvee_{\substack{A \subseteq \Omega \\ \#(A \setminus A) \ge 1}} \bigwedge_{j \in A} \text{Exer}(j, k)$$

où A correspond à l'ensemble des exercices de type A et Ω à l'ensemble de tous les exercices. Autrement dit, NbEx(A,1,k) est un booléen qui est actif lorsque l'on réalise au moins 1 exercice de type A au jour k.

L'ensemble des règles peuvent s'exprimer sous Forme Normale Conjontive de manière analogue. Une fois ceci réalisé, l'on peut alors déduire la complexité mathématique de notre modèle.

En effet, le problème est exprimable sous forme booléenne, via

$$L_{\text{cheville}} := L_{\text{règles}} \wedge L_{\text{progressivité}} \wedge L_{\text{Questions-tests}}$$

où L<sub>règles</sub>, L<sub>progressivité</sub> et L<sub>Questions-tests</sub> sont, respectivement, des clauses logiques regroupant l'ensemble des règles régissant (1) les règles générales et d'irritabilité (regroupés par commodité), (2) les règles de progressivité et, enfin, (3) les règles de cause à effet des questions fonctionnelles.

Notons que, par construction de L<sub>règles</sub>, L<sub>cheville</sub>, se réécrit :

$$L_{\text{cheville}} = C \wedge L' \text{ où } C := \bigvee_{k=28}^{70} \text{Fin}(k),$$

pour une certaine formule logique L' et avec Fin(k), k ∈ [28,70] (intervalle de durée des soins), vrai si l'utilisateur peut sortir de rééducation au jour k (dans la version en ligne la durée de soins peut-être prolongée mais cela ne modifie pas le raisonnement).

Comme L' peut toujours se réécrire sous forme normale conjontive, on peut supposer, sans perte de généralité qu'elle est sous cette forme.

Comme la clause C comporte 42 termes ; il vient que $L_{\text{cheville}}$ est équivalent à un λ-SAT avec $\lambda \ge 42$.

## 4 Structure générale de Recov'Up

Le moteur de génération d'exercices correspond à la modélisation des règles exprimées par les médecins et kiné impliqués dans le projet et à la recherche d'un n-uplet satisfaisant ces règles.

L'objectif est de disposer d'un outil « intelligent » capable de construire des séances identiques à celles qu'un praticien pourrait les proposer en disposant d'un mécanisme d'explicabilité du raisonnement et en étant plus « imaginatif » qu'un humain par l'agrégation de différentes catégories d'exercices.

Prolog a été retenu pour sa facilité à représenter les contraintes descriptives de la situation, sa capacité à inférer sur celles-ci pour déterminer si une séquence d'exercices pouvait être proposée et sa lisibilité pour les médecins. Le déroulement du programme et les solutions sont explicables ce qui permet d'ajouter ou de faire évoluer des règles pour être au plus près des situations réelles des patients.

En outre, l'application est parfaitement conforme à la gestion des données privées, aucune donnée personnelle n'étant nécessaire pour générer des séances (en effet, le genre, l'âge ou le poids, par exemple, n'apporte en réalité aucune information médicalement utile quand on dispose des réponses aux questions posées). Cette approche permet donc de construire cette base de données inédites à partir de laquelle l'algorithme pourra devenir encore plus pertinent dans ses propositions d'exercices.

La structure des termes Prolog a été imaginée en anticipant la
de chaque exercice.

Dans ce cas, l'espace total dépasse plusieurs millions de combinaisons possibles (dans le pire des cas) puisqu'il faudrait calculer toutes les associations de répétitions.

## Définition des règles

Nous avons structuré la génération des exercices en 4 catégories de règles :

1) Des règles générales :

* Une séance doit comporter entre 3 et 5 exercices (selon l'évolution du patient et la pathologie)

* Les règles de progressivité qui précisent l'évolution du nombre d'exercices et de séries d'un exercice doivent toujours être respectées

* Une séance doit débuter par une mesure de la douleur au de repos, Echelle Visuelle Analogique (EVA), et terminer par une EVA post-séance

* La rééducation se déroule sur une durée minimale (celle-ci pourra varier selon d'autres pathologies que la cheville) et ne s'achève que si un certain nombre de critères est atteint.

2) Des règles de progressivité dont un échantillon est :

* Les exercices proposés doivent être issus d'au moins 2 familles différentes (celles-ci étant, par exemple, proprioception, renforcement, excentrique, etc...)

* Avant J5 (ie dans les 5 jours qui suivent la blessure), appliquer le protocole « Glaçage, Repos, Elévation Compression » (GREC)

* Aucun exercice des familles médicalement considérées comme peu efficaces, après J15

* Aucun exercice de sur-sollicitation avant J15

* Ne jamais proposer moins de 2 exercices de certaines familles à partir de J21

* Etc...

3) Des règles d'irritabilité comme, par exemple :

* Si l'EVA post-séance est supérieure à l'EVA de repos de plus de 20% alors ne pas suivre la règle de progressivité pour la séance suivante.

4) Des règles « de cause à effet » :

* Des familles d'exercices différentes sont proposées en fonction de tests fonctionnels réalisés et auto-évalués par le patient.

* Selon le résultat de scores (comme le Limb Symmetry Index), les exercices sont adaptés en intégrant aussi le fait que le patient dispose ou non du matériel nécessaire (élastique, coussin instable).

## Etude de complexité

Considérons, à titre d'exemple, la règle "avant le cinquième jour, ne faire que des exercices de type A (dans la modélisation les familles d'exercices sont numérotées par des lettres), et jamais après". Cette dernière peut s'écrire sous la forme :

$$L_{\text{prog}}^{(1)} := \left( \bigwedge_{k \le 5} \text{NbEx}(A, 1, k) \wedge \bigwedge_{j \in A} \overline{\text{Exer}(j, k)} \right) \wedge \left( \bigwedge_{k > 5} \overline{\text{NbEx}(A, 1, k)} \right).$$

Ici, Exer(j,k) est un booléen qui est actif lorsqu'un exercice de type j est réalisé au jour k, et NbEx(A,1,k) est un booléen, construit à l'aide de Exer(j,k), dont la définition formelle est :

$$\text{NbEx}(A, 1, k) := \bigvee_{\substack{A \subseteq \Omega \\ \#(A \setminus A) \ge 1}} \bigwedge_{j \in A} \text{Exer}(j, k)$$

où A correspond à l'ensemble des exercices de type A et Ω à l'ensemble de tous les exercices. Autrement dit, NbEx(A,1,k) est un booléen qui est actif lorsque l'on réalise au moins 1 exercice de type A au jour k.

L'ensemble des règles peuvent s'exprimer sous Forme Normale Conjunctive de manière analogue. Une fois ceci réalisé, l'on peut alors déduire la complexité mathématique de notre modèle.

En effet, le problème est exprimable sous forme booléenne, via

$$L_{\text{cheville}} := L_{\text{règles}} \wedge L_{\text{progressivité}} \wedge L_{\text{Questions-tests}}$$

où L<sub>règles</sub>, L<sub>progressivité</sub> et L<sub>Questions-tests</sub> sont, respectivement, des clauses logiques regroupant l'ensemble des règles régissant (1) les règles générales et d'irritabilité (regroupés par commodité), (2) les règles de progressivité et, enfin, (3) les règles de cause à effet des questions fonctionnelles.

Notons que, par construction de L<sub>règles</sub>, L<sub>cheville</sub>, se réécrit :

$$L_{\text{cheville}} = C \wedge L' \text{ où } C := \bigvee_{k=28}^{70} \text{Fin}(k),$$

pour une certaine formule logique L' et avec Fin(k), k ∈ [28,70] (intervalle de durée des soins), vrai si l'utilisateur peut sortir de rééducation au jour k (dans la version en ligne la durée de soins peut-être prolongée mais cela ne modifie pas le raisonnement).

Comme L' peut toujours se réécrire sous forme normale conjunctive, on peut supposer, sans perte de généralité qu'elle est sous cette forme.

Comme la clause C comporte 42 termes ; il vient que $L_{\text{cheville}}$ est équivalent à un λ-SAT avec $\lambda \ge 42$.

## 4 Structure générale de Recov'Up

Le moteur de génération d'exercices correspond à la modélisation des règles exprimées par les médecins et kiné impliqués dans le projet et à la recherche d'un n-uplet satisfaisant ces règles.

L'objectif est de disposer d'un outil « intelligent » capable de construire des séances identiques à celles qu'un praticien pourrait les proposer en disposant d'un mécanisme d'explicabilité du raisonnement et en étant plus « imaginatif » qu'un humain par l'agrégation de différentes catégories d'exercices.

Prolog a été retenu pour sa facilité à représenter les contraintes descriptives de la situation, sa capacité à inférer sur celles-ci pour déterminer si une séquence d'exercices pouvait être proposée et sa lisibilité pour les médecins. Le déroulement du programme et les solutions sont explicables ce qui permet d'ajouter ou de faire évoluer des règles pour être au plus près des situations réelles des patients.

En outre, l'application est parfaitement conforme à la gestion des données privées, aucune donnée personnelle n'étant nécessaire pour générer des séances (en effet, le genre, l'âge ou le poids, par exemple, n'apporte en réalité aucune information médicalement utile quand on dispose des réponses aux questions posées). Cette approche permet donc de construire cette base de données inédites à partir de laquelle l'algorithme pourra devenir encore plus pertinent dans ses propositions d'exercices.

La structure des termes Prolog a été imaginée en anticipant la
prise en compte d'une évolution vers d'autres pathologies ultérieures. L'interface utilisateur est conçue en PHP et la communication entre PHP et Prolog s'effectue via un JSON. Les exercices sont classés comme des faits Prolog standards et organisés par famille et leur éligibilité potentielle dépend du jour courant, de la présence ou non de matériel spécifique ou de la capacité du patient à effectuer certains tests physiologiques :

```
exoeligible(Patient,cheville, J, i1,_) :-
    J>=15,
    exercicesCumules(Patient, cheville, _,
        ListeExo),
    comptemembre(h, ListeExo, Num),
    Num >=3,
```

```
questiontest(Patient,cheville,J,coussin,_,o,_.)
```

```
exoeligible(Patient,cheville, J, ExoFamilleK,_) :-
    J >= 21,
```

```
questiontest(Patient,cheville,_,sport,_,o,_.)
```

```
questiontest(Patient,cheville,_,qf11,_,Repqf11,_.),
    Repqf11 \= a,
```

```
questiontest(Patient,cheville,_,qf12,_,Repqf12,_.),
    Repqf12 \= a,
```

```
questiontest(Patient,cheville,_,qf13,_,Repqf13,_.),
    Repqf13 \= a,
    exercice(cheville, k,_, ExoFamilleK,_,_.)
```

Le générateur d'exercices proprement dit exploite ensuite une « capacité de la logique d'ordre 2 » de Prolog en recueillant tous les exercices potentiellement éligibles avec une commande bagof :

```
bagof(Exo, exoeligible(Patient, Pathologie, Jour,
    Exo,_.), ListeExo)
```

Le prédicat « exoeligible » détermine les situations d'applicabilité d'un exercice et est ainsi déclenché par « bagof » qui remplit la ListeExo de tous les Exos correspondant à un Patient donné pour le Jour courant.

<figure><img src="image_63.png" /><figcaption>Figure 1: Exemples d'exercices proposés chez un patient peu douloureux avec évolution favorable de la douleur</figcaption></figure>

La série d'exercices considérés comme éligibles est ensuite filtrée par des règles supplémentaires (comme, par exemple, la non-monotonie pour éviter une succession d'exercices identiques d'un jour à l'autre) afin de générer une séquence qui est transmise via JSON au module d'interface qui affiche les exercices de la journée (voir Figure 1).

Dans l'extrait ci-dessus, on voit que la pathologie est déjà anticipée comme pouvant avoir une autre valeur que « cheville », le système ayant été étendu à 12 pathologies ostéoarticulaires.

Pour chaque pathologie, des jeux de données synthétiques ont été générées puis confrontés aux règles du moteur Prolog, les séquences d'exercices produites ayant été contrôlées par l'équipe médicale.

L'application mise à disposition des patients reste sous contrôle médical, le praticien prescripteur pouvant suivre via une interface dédiée l'évolution de la pathologie et le respect du protocole proposé. Dans les cas où la pathologie évoluerait défavorablement, l'application suggère une visite médicale.

## 5 Évolution vers d'autres pathologies et perspectives

Confrontés à des pathologies pour lesquelles il n'existe que peu de jeux de données permettant de construire des modèles précis d'évolution de celles-ci, nous avons adopté une approche consistant à implémenter des règles reconnues par les praticiens. Le moteur de génération d'exercices a été conçu tel que d'autres pathologies ont pu être aisément intégrées.

Prolog nous a permis d'avoir une démarche incrémentale en complétant ainsi progressivement le moteur de règles spécifiques à chaque pathologie en ayant la certitude ne de pas interférer avec les autres et en garantissant la stricte application de ces règles.

Le modèle mathématique sous-jacent confirme la complexité de la génération d'une séquence d'exercices, l'espace étant fortement combinatoire.

Recov'up propose donc une solution innovante pour la prise en charge de problèmes de santé publique. En exploitant des publications scientifiques et des règles médicales opérationnelles, nous avons conçu une application d'Intelligence Artificielle originale, frugale sur le plan de la donnée, dont l'explicabilité facilite l'adoption par les professionnels de santé.

L'expérience utilisateur a été pensée pour favoriser un usage régulier de l'application permettant ainsi le suivi de l'évolution de la pathologie. Cette collecte de données directement auprès du patient offre alors l'opportunité d'envisager des évolutions basées sur d'autres modèles d'Intelligence Artificielle.

## 6 Références

[1] Avis de la CMEDIPTS, 2018, https://www.hassante.fr/upload/docs/evamed/CEPP-5487_A2T_15_mai_2018_(5487)_avis.pdf.

[2] R. M. Van Rijn, A. G. Van Os, R. M. Bernsen, P. A. Luijsterburg, B. W. Koes, and S. M. Bierma-Zeinstra, What is the clinical course of acute ankle sprains? A systematic literature review, *The American journal of medicine*, Vol. 121, no 4, pp. 324-331, 2008.

[3] H. Polzer, K. G. Kanz, W. C. Prall, F. Haasters, B. Ockert, W. Mutschler, and S. Grote, Diagnosis and treatment of acute ankle injuries: development of an evidence-based algorithm, *Orthopedic reviews*, Vol. 4, no 1, 2012.
prise en compte d'une évolution vers d'autres pathologies ultérieures. L'interface utilisateur est conçue en PHP et la communication entre PHP et Prolog s'effectue via un JSON. Les exercices sont classés comme des faits Prolog standards et organisés par famille et leur éligibilité potentielle dépend du jour courant, de la présence ou non de matériel spécifique ou de la capacité du patient à effectuer certains tests physiologiques :

```
exoeligible(Patient,cheville, J, i1,_) :-
    J>=15,
    exercicesCumules(Patient, cheville, _,
        ListeExo),
    comptemembre(h, ListeExo, Num),
    Num >=3,
```

```
questiontest(Patient,cheville,J,coussin,_,o,_.)
```

```
exoeligible(Patient,cheville, J, ExoFamilleK,_) :-
    J >= 21,
```

```
questiontest(Patient,cheville,_,sport,_,o,_.)
```

```
questiontest(Patient,cheville,_,qf11,_,Repqf11,_.),
    Repqf11 \= a,
```

```
questiontest(Patient,cheville,_,qf12,_,Repqf12,_.),
    Repqf12 \= a,
```

```
questiontest(Patient,cheville,_,qf13,_,Repqf13,_.),
    Repqf13 \= a,
    exercice(cheville, k,_, ExoFamilleK,_,_.)
```

Le générateur d'exercices proprement dit exploite ensuite une « capacité de la logique d'ordre 2 » de Prolog en recueillant tous les exercices potentiellement éligibles avec une commande bagof :

```
bagof(Exo, exoeligible(Patient, Pathologie, Jour,
    Exo,_.), ListeExo)
```

Le prédicat « exoeligible » détermine les situations d'applicabilité d'un exercice et est ainsi déclenché par « bagof » qui remplit la ListeExo de tous les Exos correspondant à un Patient donné pour le Jour courant.

<figure><img src="image_63.png" /><figcaption>Figure 1: Exemples d'exercices proposés chez un patient peu douloureux avec évolution favorable de la douleur</figcaption></figure>

La série d'exercices considérés comme éligibles est ensuite filtrée par des règles supplémentaires (comme, par exemple, la non-monotonie pour éviter une succession d'exercices identiques d'un jour à l'autre) afin de générer une séquence qui est transmise via JSON au module d'interface qui affiche les exercices de la journée (voir Figure 1).

Dans l'extrait ci-dessus, on voit que la pathologie est déjà anticipée comme pouvant avoir une autre valeur que « cheville », le système ayant été étendu à 12 pathologies ostéoarticulaires.

Pour chaque pathologie, des jeux de données synthétiques ont été générées puis confrontés aux règles du moteur Prolog, les séquences d'exercices produites ayant été contrôlées par l'équipe médicale.

L'application mise à disposition des patients reste sous contrôle médical, le praticien prescripteur pouvant suivre via une interface dédiée l'évolution de la pathologie et le respect du protocole proposé. Dans les cas où la pathologie évoluerait défavorablement, l'application suggère une visite médicale.

## 5 Évolution vers d'autres pathologies et perspectives

Confrontés à des pathologies pour lesquelles il n'existe que peu de jeux de données permettant de construire des modèles précis d'évolution de celles-ci, nous avons adopté une approche consistant à implémenter des règles reconnues par les praticiens. Le moteur de génération d'exercices a été conçu tel que d'autres pathologies ont pu être aisément intégrées.

Prolog nous a permis d'avoir une démarche incrémentale en complétant ainsi progressivement le moteur de règles spécifiques à chaque pathologie en ayant la certitude ne de pas interférer avec les autres et en garantissant la stricte application de ces règles.

Le modèle mathématique sous-jacent confirme la complexité de la génération d'une séquence d'exercices, l'espace étant fortement combinatoire.

Recov'up propose donc une solution innovante pour la prise en charge de problèmes de santé publique. En exploitant des publications scientifiques et des règles médicales opérationnelles, nous avons conçu une application d'Intelligence Artificielle originale, frugale sur le plan de la donnée, dont l'explicabilité facilite l'adoption par les professionnels de santé.

L'expérience utilisateur a été pensée pour favoriser un usage régulier de l'application permettant ainsi le suivi de l'évolution de la pathologie. Cette collecte de données directement auprès du patient offre alors l'opportunité d'envisager des évolutions basées sur d'autres modèles d'Intelligence Artificielle.

## 6 Références

[1] Avis de la CMEDIPTS, 2018, https://www.hassante.fr/upload/docs/evamed/CEPP-5487_A2T_15_mai_2018_(5487)_avis.pdf.

[2] R. M. Van Rijn, A. G. Van Os, R. M. Bernsen, P. A. Luijsterburg, B. W. Koes, and S. M. Bierma-Zeinstra, What is the clinical course of acute ankle sprains? A systematic literature review, *The American journal of medicine*, Vol. 121, no 4, pp. 324-331, 2008.

[3] H. Polzer, K. G. Kanz, W. C. Prall, F. Haasters, B. Ockert, W. Mutschler, and S. Grote, Diagnosis and treatment of acute ankle injuries: development of an evidence-based algorithm, *Orthopedic reviews*, Vol. 4, no 1, 2012.
[4] J. Wagemans, C. Bleakley, J. Taeymans, et al., Rehabilitation strategies for lateral ankle sprain do not reflect established mechanisms of re-injury: A systematic review, *Physical Therapy in Sport*, 2023.

[5] M. D. Hupperets, E. A. Verhagen, and Van W. Mechelen, Effect of unsupervised home based proprioceptive training on recurrences of ankle sprain: randomised controlled trial, *Bmj*, Vol. 339, 2009.

[6] F. Fatoye, T. Gebrye, C. Fatoye, et al., The Clinical and Cost-Effectiveness of Telerehabilitation for People With Nonspecific Chronic Low Back Pain: Randomized Controlled Trial, *Journal of Medical Internet Research mHealth uHealth*, Vol. 8, no 6, 2020

[7] N. Itoh, H. Mishima, Y. Yoshida, et al., Evaluation of the Effect of Patient Education and Strengthening Exercise Therapy Using a Mobile Messaging App on Work Productivity in Japanese Patients With Chronic Low Back Pain: Open-Label, Randomized, Parallel-Group Trial, *Journal of Medical Internet Research mHealth uHealth*, Vol. 10, no 5, 2022

[8] E. T. Chen, K. C. Mcinnis, and J. Borg-Stein, Ankle sprains: evaluation, rehabilitation, and prevention, *Current sports medicine reports*, Vol. 18, no 6, pp. 217-223, 2019.

[9] M. C. Hoch, J. Hertel, P. A. Gribble, et al., Effects of foot intensive rehabilitation (FIRE) on clinical outcomes for patients with chronic ankle instability: a randomized controlled trial protocol, *BMC Sports Science, Medicine and Rehabilitation*, Vol. 15, no 1, pp. 1-13, 2023.

[10] A.C. Pijnenburg, C. N. Van Dijk, P. M. Bossuyt, and R. K. Marti, Treatment of ruptures of the lateral ankle ligaments: a meta-analysis, *J Bone Joint Surg Am*, Vol. 82, no 6, pp. 761-73, 2000.

[11] P.A. Gribble, et al., 2016 consensus statement of the International Ankle Consortium: prevalence, impact and long-term consequences of lateral ankle sprains, *British journal of sports medicine*, Vol. 50, no 24, pp. 1493-1495, 2016.

[12] Actualisation 2004 de la conférence de consensus l'entorse de cheville au service d'urgence, 5ème conférence de consensus, https://www.sfmu.org/upload/consensus/actualisation_entorse.pdf.
[4] J. Wagemans, C. Bleakley, J. Taeymans, et al., Rehabilitation strategies for lateral ankle sprain do not reflect established mechanisms of re-injury: A systematic review, *Physical Therapy in Sport*, 2023.

[5] M. D. Hupperets, E. A. Verhagen, and Van W. Mechelen, Effect of unsupervised home based proprioceptive training on recurrences of ankle sprain: randomised controlled trial, *Bmj*, Vol. 339, 2009.

[6] F. Fatoye, T. Gebrye, C. Fatoye, et al., The Clinical and Cost-Effectiveness of Telerehabilitation for People With Nonspecific Chronic Low Back Pain: Randomized Controlled Trial, *Journal of Medical Internet Research mHealth uHealth*, Vol. 8, no 6, 2020

[7] N. Itoh, H. Mishima, Y. Yoshida, et al., Evaluation of the Effect of Patient Education and Strengthening Exercise Therapy Using a Mobile Messaging App on Work Productivity in Japanese Patients With Chronic Low Back Pain: Open-Label, Randomized, Parallel-Group Trial, *Journal of Medical Internet Research mHealth uHealth*, Vol. 10, no 5, 2022

[8] E. T. Chen, K. C. Mcinnis, and J. Borg-Stein, Ankle sprains: evaluation, rehabilitation, and prevention, *Current sports medicine reports*, Vol. 18, no 6, pp. 217-223, 2019.

[9] M. C. Hoch, J. Hertel, P. A. Gribble, et al., Effects of foot intensive rehabilitation (FIRE) on clinical outcomes for patients with chronic ankle instability: a randomized controlled trial protocol, *BMC Sports Science, Medicine and Rehabilitation*, Vol. 15, no 1, pp. 1-13, 2023.

[10] A.C. Pijnenburg, C. N. Van Dijk, P. M. Bossuyt, and R. K. Marti, Treatment of ruptures of the lateral ankle ligaments: a meta-analysis, *J Bone Joint Surg Am*, Vol. 82, no 6, pp. 761-73, 2000.

[11] P.A. Gribble, et al., 2016 consensus statement of the International Ankle Consortium: prevalence, impact and long-term consequences of lateral ankle sprains, *British journal of sports medicine*, Vol. 50, no 24, pp. 1493-1495, 2016.

[12] Actualisation 2004 de la conférence de consensus l'entorse de cheville au service d'urgence, 5ème conférence de consensus, https://www.sfmu.org/upload/consensus/actualisation_entorse.pdf.