\documentclass{article}

% Langue
\usepackage{polyglossia}
\usepackage[autostyle=true]{csquotes}
\setmainlanguage{french}
\usepackage{microtype}
\usepackage[
    output-decimal-marker={,},
    group-separator={\,},
]{siunitx}

\makeatletter
\newcommand{\nospace}[1]{{\nofrench@punctuation#1}}
\makeatother

% Police
\usepackage{fontspec}
\usepackage{xunicode}

\setmainfont[Mapping=tex-text]{Linux Libertine O}
\setsansfont[Mapping=tex-text]{XCharter}

\usepackage[raggedright, sf]{titlesec}
\titleformat{\paragraph}[runin]{\bfseries\normalsize}{\theparagraph}{1em}{}

% Listes
\usepackage{enumitem}
\setlist[itemize]{itemsep=0pt, leftmargin=16pt}

% Figures
\usepackage[export]{adjustbox}
\usepackage{rotating}
\usepackage{tikz}
\usetikzlibrary{positioning}

\tikzset{
    agent/.style={
        draw,
        align=center,
        inner sep=10pt,
        thick,
    },
    system/.style={
        agent,
        rounded rectangle,
    },
    link/.style={
        shorten >=10pt,
        shorten <=10pt,
        ->, thick,
        >=latex,
    },
    link label/.style={
        font=\scshape\small,
        align=center,
        inner xsep=0pt,
        outer xsep=0pt,
    },
    node distance=3.2cm,
}

\usepackage{forest}
\useforestlibrary{edges}
\graphicspath{{./figures/}}

% Tables
\usepackage{booktabs}
\usepackage{multirow}

% Bibliographie
\usepackage[
    style=numeric,
    maxbibnames=4,
    maxcitenames=3,
    backend=biber
]{biblatex}

\addbibresource{references.bib}
\renewcommand*{\nameyeardelim}{\addcomma\addspace}

\DefineBibliographyStrings{french}{%
    urlseen = {consulté le},
    techreport = {Rapport technique},
}

% Hyperliens
\usepackage{hyperref}

% Métadonnées
\title{Conception et réalisation d’un système de recherche sémantique de maladies}
\author{Rémi \textsc{Cérès} \and Mattéo \textsc{Delabre}}
\date{19~décembre~2019}

\begin{document}

\makeatletter
{\centering
\LARGE\parbox{.8\textwidth}{\centering\@title}

\vspace{1em}
\Large Rapport de projet de session

\large\textcolor{black!80}{GLO-7001 --- Conception de systèmes intelligents}

\vspace{1em}
\begin{tabular}{ll}\@author\end{tabular}

\vspace{1em}
\@date

}
\makeatother

\tableofcontents

\section{Introduction}

Afin de mettre en pratique les connaissances acquises en suivant les cours de conception de systèmes intelligents, nous avons eu l’opportunité de réaliser un projet en rapport avec Wikimedica\footnote{\url{https://wikimedi.ca/}}.
Cette plate-forme, lancée en~2017 et gérée par une OBNL, est une ressource basée sur le principe du \emph{wiki}, placée sous licence libre~\cite{cc-by-sa-4-0}, qui rend disponible à toutes et à tous des informations médicales théoriques, cliniques et pédagogiques.
Destinée en priorité aux professionnels de la santé et aux étudiants en médecine, elle leur permet de partager leurs connaissances et d’en améliorer collectivement les données~\cite{larose-2018-wiki}.
Sa particularité est d’être un wiki de type sémantique, dont les différentes pages sont connectées par des métadonnées exploitables par un programme informatique.
Notre projet consiste à mettre au point un outil permettant d’assister à la réalisation de diagnostics différentiels en naviguant parmi les maladies renseignées dans le wiki sur la base des propriétés sémantiques qui les lient à leurs signes et symptômes.

Ce rapport se compose de trois parties, commençant par une étude du contexte du projet, de ses différents acteurs et actions souhaitées. La suite du rapport s’intéresse à la conceptualisation des connaissances nécessaires à la réalisation du projet et aux moyens de communication entre ses agents. Enfin, la dernière partie présente les détails de conception et d’implémentation d’un premier prototype du système.

\section{Étude du contexte du projet de système~de~recherche}

\subsection{Intelligence artificielle en médecine et projet~Wikimedica}

Dans le cadre de leur pratique, les médecins sont régulièrement amenés à prendre des décisions informées relatives à leurs patients, basées sur la considération méticuleuse d’un ensemble d’indices et en s’appuyant sur les consensus scientifiques existants ainsi que sur leur expérience.
La quantité d’information à caractère non-structuré à la disposition des professionnels de médecine fait qu’il leur est difficile de s’assurer de prendre en compte en tout temps tous les cas possibles et les dernières bonnes pratiques.
Une façon d’exploiter plus efficacement ces données est d’utiliser des machines pour reproduire le raisonnement des médecins sur les problématiques qui leur sont présentées; autrement dit, il s’agit de construire des systèmes d’intelligence artificielle~\cite{russell-2010-artificial}.
En médecine, comme dans les autres champs d’application critiques de l’intelligence artificielle, de tels systèmes font face à la contrainte supplémentaire de fiabilité, de transparence et de reddition de comptes.
Ces contraintes n’empêchent pas le domaine d’être l’objet de plus en plus de recherches, de projets et financements~\cite{buch-2018-artificial}, dans la mesure où ces systèmes ont un large potentiel d’application, avec à l’horizon la réduction du nombre d’erreurs médicales, le recentrage de l’activité des praticiens sur l’écoute et l’accompagnement des patients, ou encore la réduction des consultations inutiles permettant le désengorgement des services médicaux.

L’un des objectifs du projet Wikimedica est de recenser et fournir des données structurées sous la forme d’une ontologie exploitable par des machines.
De par cet objectif, ce wiki a pour vocation de devenir une source de données utile à la réalisation d’applications en intelligence artificielle médicale.
Une application possible est la réalisation de diagnostics différentiels, une activité du médecin consistant à établir une liste de maladies qui pourraient plausiblement être la cause de signes et de symptômes exprimés par un patient.
Cette liste ne doit exclure aucune possibilité, en particulier les plus graves et les plus probables, sous peine de mettre potentiellement en danger le patient et d’engager pénalement la responsabilité du médecin~\cite{acpm-2018-diagnostic}.

\emph{Comment les techniques d’intelligence artificielle peuvent-elles être combinées aux données de Wikimedica pour aider à poser un diagnostic différentiel?}

L’objectif de notre projet est d’apporter des éléments de réponse à cette question en concevant un système capable d’assister un médecin dans l’établissement de diagnostics différentiels pour ses patients qui lui permette de naviguer parmi les différentes possibilités correspondant aux données dont il dispose sur leur situation.

\subsection{Tâche de recherche sémantique de maladies}

Le médecin utilise le système avec pour but d’identifier une maladie, à savoir une \enquote{altération de la santé caractérisée par des causes, des symptômes, une évolution et des possibilités thérapeutiques propres}~\cite{wiki-2019-maladie}, correspondant à la situation de son patient.
Remarquons que les requêtes formulées par le médecin dans le système sont toujours des conjonctions de termes et jamais des disjonctions.
La difficulté de cette tâche réside dans le fait que le médecin cherche à obtenir un diagnostic à partir des signes~(constatés objectivement sur le patient par un observateur), symptômes~(perçus et décrits par le malade), facteurs de risque~(variables associées à un risque accru de contracter une maladie) et antécédents de son patient, alors que les connaissances du wiki décrivent plutôt ces informations à partir de chaque maladie.
En inversant cette relation, le résultat comportera en effet souvent plusieurs maladies possibles dans la mesure où beaucoup d’entre elles ont des présentations qui se recoupent.
Par conséquent, le système doit être interactif: après un retour d’une liste initiale de candidats, le médecin peut choisir de tester des signes supplémentaires ou d’interroger le patient sur la présence éventuelle d’autres symptômes pour éliminer des maladies incompatibles.
Après récupération de ces nouvelles données, l’utilisateur soumet une nouvelle requête modifiée au système et la procédure reprend du début.
Cette interaction est représentée conceptuellement dans la figure~\ref{fig:task-model}.

\begin{figure}[htbp]
    \makebox[\textwidth][c]{\input{figures/task-model}}
    \caption{Vue conceptuelle de la tâche de recherche sémantique de maladies impliquant le médecin, le patient et le système de recherche.}
    \label{fig:task-model}
\end{figure}

Wikimedica offre déjà un formulaire permettant de rechercher parmi les maladies qui sont y référencées\footnote{\url{https://wikimedi.ca/wiki/Spécial:RunQuery/Recherche_de_maladies}}.
Nous avons utilisé cette page existante comme base pour concevoir notre système.

\subsection{Médecin et base de connaissances, agents du système}

Les bases de connaissances ne constituent pas par elles-mêmes des systèmes de recherche adaptés pour les utilisateurs humains car elles foisonnent de données et ne leur permettent pas de se focaliser précisément sur leur activité de recherche.
Le système de recherche de maladies par signes et symptômes se place donc comme un intermédiaire entre le médecin et la base de connaissances offerte par Wikimedica renfermant de la connaissance académique sur différents aspects de la médecine.

Les médecins utilisateurs du système sont des professionnels de santé possédant une formation et des connaissances de base comprenant notamment le vocabulaire médical nécessaire et la capacité de réaliser un diagnostic différentiel.
Ils communiquent d’une part avec leurs patients physiquement au travers de consultations, et d’autre part avec le système de recherche en utilisant un ordinateur connecté à Internet.

La base de connaissance est constituée des pages de Wikimedica et de leurs relations telles que maintenues par les contributeurs du projet, qui sont des professionnels de santé reconnus comme tels par le Collège des médecins du Québec.

\section[Conception du système de recherche basé sur les données\\de Wikimedica et Wikidata]{Conception du système de recherche basé sur les données de Wikimedica et Wikidata}

\subsection{Modèle et sources de connaissances médicales}

Le système doit connaître d’une part des informations sur les maladies que le médecin est susceptible de rechercher, et d’autre part les liens qui existent entre ces maladies et leurs signes, symptômes, facteurs de risque et antécédents éventuels.
En outre, puisque le nombre de maladies possibles pour un ensemble de symptômes peut être grand, le système doit orienter le diagnostic sur les éléments les plus importants en priorité.
Pour ce faire, l’application doit pouvoir évaluer la gravité et la probabilité d’occurrence chez un patient donné de chaque maladie et trier les résultats par gravité et probabilité décroissantes.

\paragraph{Sources de connaissances médicales}
À terme, la source de données principale sera Wikimedica, cependant son ontologie est en encore cours de construction et ne contient présentement que 157~maladies, signes et symptômes, ce qui n’est pas suffisant pour notre application.
Nous combinons donc les informations structurées de Wikimedica avec celles de Wikidata.
En outre, bien que les deux wikis précédents disposent de données épidémiologiques pour chaque maladie (par exemple, sur Wikidata, les propriétés \href{https://www.wikidata.org/wiki/Property:P1193}{P1193}, \href{https://www.wikidata.org/wiki/Property:P1603}{P1603} et \href{https://www.wikidata.org/wiki/Property:P2844}{P2844} décrivent respectivement la prévalence, l’incidence et le nombre de cas d’une maladie) qui pourraient être utilisées pour évaluer sa probabilité d’occurrence, ces données sont pour le moment trop éparses pour pouvoir être utilisables.
Nous avons choisi transitoirement de baser le critère d’importance sur des données de nature différente, à savoir le flux de visites sur la page Wikipédia associée\footnote{Accessibles et librement réutilisables depuis l’adresse \url{https://dumps.wikimedia.org/other/pageviews/readme.html}.}.
Ces données apportent une information nettement moins objective et beaucoup plus approximative sur l’importance relative des différentes maladies, mais nous considérons cette première approximation comme raisonnable car elle sert uniquement à ordonner les résultats.
En outre, le flux de visite d’une page est variable en fonction de l’année, ce qui permet de refléter dans une certaine limite l’évolution de l’importance de maladies aux symptômes similaires au cours de l’année~(voir la figure~\ref{fig:pageview-flow-criterion}).

\begin{figure}[htb]
\input{figures/grippe-coup-soleil.pgf}
\caption{Nombre de visites au cours de l’année sur les articles du Wikipédia francophone \enquote{Coup de soleil} et \enquote{Grippe}, deux conditions pouvant présenter des symptômes similaires. Ce nombre de visite est la moyenne des visites sur les années 2015--2019 lissée par un noyau gaussien d’écart-type dix jours.}
\label{fig:pageview-flow-criterion}
\end{figure}

\paragraph{Modèle unifié de connaissances du domaine}
Chaque maladie et chaque signe, symptôme ou facteur de risque est caractérisé par un nom, une courte description, une image d’illustration, un lien vers un l’article de wiki qui le décrit et un facteur d’importance calculé comme décrit précédemment.
Les maladies sont reliées à leurs signes, symptômes ou facteurs de risque (qui peuvent être d’autres maladies) par une propriété qui regroupe sans distinction tous ces types de relation.
La correspondance entre ces structures de connaissances et les deux sources utilisées est donnée par la table~\ref{tab:source-knowledge-mapping}.

\begin{table}[htb]
\makebox[\textwidth][c]{
\begin{tabular}{llrlr}
    \toprule
    \multirow{2}{*}{\textbf{Classes d’éléments}}
        & \multicolumn{2}{c}{\bfseries Wikimedica}
        & \multicolumn{2}{c}{\bfseries Wikidata} \\
        & Classe & Instances
        & Classe & Instances \\

    \midrule
    Maladie  & \href{https://wikimedi.ca/wiki/Wikimedica:Ontologie/Maladie}{Maladie}        & 66
             & \href{https://www.wikidata.org/wiki/Q12136}{Q12136}                          & 23\,785 \\
    Signe    & \href{https://wikimedi.ca/wiki/Wikimedica:Ontologie/Signe}{Signe}            & 69
             & \href{https://www.wikidata.org/wiki/Q1441305}{Q1441305}                      & 576 \\
    Symptôme & \href{https://wikimedi.ca/wiki/Wikimedica:Ontologie/Sympt\%C3\%B4me}{Symptôme} & 22
             & \href{https://www.wikidata.org/wiki/Q169872}{Q169872}                        & 1\,076 \\

    \midrule
    \textbf{Propriétés}
        & Propriété & Utilisations
        & Propriété & Utilisations \\

    \midrule
    Signe    & \href{https://wikimedi.ca/wiki/Attribut:Signe}{Signe}                        & 41
             & \multirow{2}{*}{\href{https://www.wikidata.org/wiki/Property:P780}{P780} et \href{https://www.wikidata.org/wiki/Property:P1542}{P1542}}
                                                                                            & \multirow{2}{*}{4\,125} \\
    Symptôme & \href{https://wikimedi.ca/wiki/Attribut:Sympt\%C3\%B4me}{Symptôme}             & 30
             & & \\
    Facteur de risque
             & \href{https://wikimedi.ca/wiki/Attribut:Facteur_de_risque}{Facteur de risque} & 42
             & \href{https://www.wikidata.org/wiki/Property:P5642}{P5642}                    & 407 \\

    \bottomrule
\end{tabular}
}
\caption{Correspondance entre le modèle de connaissance du système et ceux des sources de données Wikimedica et Wikidata.}
\label{tab:source-knowledge-mapping}
\end{table}

\paragraph{Inférences réalisées pour répondre aux requêtes}

À partir d’un ensemble de signes et symptômes indiqué par le médecin, le système sélectionne toutes les maladies ayant une relation avec chacun des termes saisis par l’utilisateur.
Cette relation est considérée de façon transitive~: si un symptôme d’une maladie~$M_1$, qui est elle-même le symptôme d’une autre maladie~$M_2$, est saisi, la maladie $M_2$ est également sélectionnée.
Enfin, tous les autres symptômes des maladies ainsi sélectionnées sont également renvoyés, puisqu’ils constituent des éléments pouvant être testés par le médecin pour raffiner son diagnostic.

\subsection{Interactions entre le médecin et le système de recherche}

Notre projet se place dans le cadre des systèmes de recherche sémantique, qui utilisent les connaissances du domaine cible afin de comprendre et de répondre aux requêtes de l’utilisateur.
Ils s’opposent aux systèmes de recherche lexicale qui tentent de mettre en correspondance chaque requête avec des documents par des techniques statistiques~\cite{wiki-2019-semantic-search}.
Le modèle de communication du système s’intéresse par conséquent aux interactions entre l’utilisateur (le médecin) et la base de connaissances (issue de Wikimedica et Wikidata) telles que spécifiées en figure~\ref{fig:communication-model}.
Il s’inscrit dans le domaine des interfaces personnes--machines et plus spécifiquement dans le contexte des interfaces de recherche d’information.

\begin{figure}[htb]
    \makebox[\textwidth][c]{\input{figures/communication-model}}
    \caption{Synthèse des interactions entre les différents agents du système lors de la réalisation d’une tâche de recherche de maladie.}
    \label{fig:communication-model}
\end{figure}

\paragraph{Contraintes sur l’interface utilisateur}
Dans la conception de l’interface, nous devons nous efforcer de respecter les principes fondamentaux des interfaces personne--machine pour les systèmes de recherche~\cite[p.~258]{baeza-1999-modern}~:

\begin{enumerate}
\item \emph{Donner un retour d’information à l’utilisateur.}
    Au cours de l’utilisation du système, l’interface doit s’efforcer d’afficher prioritairement les informations pertinentes pour la poursuite de la recherche.
    Les relations enentre les différentes maladies retournés et les signes et symptômes recherchés doivent être clairement explicités.
\item \emph{Réduire la charge sur la mémoire de travail de l’utilisateur.}
    Le système doit rappeler à l’utilisateur les choix qu’il a fait au cours du processus de recherche et lui permettre de revenir en arrière sur certains choix et d’essayer de nouvelles stratégies.
    Il peut aussi suggérer à l’utilisateur des façons de poursuivre la recherche actuelle.
    Pour ce faire, lorsque l’utilisateur saisit un terme de recherche dans le système, celui-ci doit suggérer les signes, symptômes et maladies les plus proches dans l’ontologie, en s’efforçant d’ôter toute ambiguïté entre plusieurs sens d’un même terme.
    Par exemple, à la saisie de \enquote{hypot}, le système doit suggérer, dans l’ordre, \href{https://wikimedi.ca/wiki/Spécial:URIResolver/Hypotension}{Hypotension}, \href{https://wikimedi.ca/wiki/Spécial:URIResolver/Hypotonie}{Hypotonie} et \href{https://wikimedi.ca/wiki/Spécial:URIResolver/Hyponatrémie}{Hyponatrémie}, car ce dernier terme est plus distant de la saisie que les premiers.
\item \emph{Être adapté aussi bien aux novices qu’aux experts.}
    Dans le contexte de notre application, nous considérons en priorité l’utilisation par un professionnel de la santé expert du domaine, mais une utilisation par un patient non-initié qui recherche une maladie spécifique est envisageable à terme.
\end{enumerate}

Enfin, de façon générale, \enquote{lorsqu’un système interactif est bien conçu, l’interface disparaît quasiment et permet aux utilisateurs de se concentrer sur leur travail, leur exploration ou leur loisir}\footnote{\emph{\enquote{When an interactive system is well-designed, the interface almost disappears, enabling users to concentrate on their work, exploration, or pleasure.}}, traduction personnelle~\cite{shneiderman-2016-designing}.}.

\paragraph{Solution proposée}
% - Solution proposée (incluant maquettes).
Pour tenter de répondre à ces critères, nous envisageons une interface dotée d’un champ de recherche et montrant en tout temps une visualisation d’un sous-graphe de l’ontologie, mis à jour dynamiquement au fur et à mesure que l’utilisateur ajoute des termes pour préciser sa requête~(voir figure~\ref{fig:maquette}).
Initialement, seuls les nœuds les plus importants (en terme de nombre de liens ou de pertinence générale) de l’ontologie et leurs relations sont affichées.
Pour formuler sa requête, l’utilisateur peut soit cliquer sur des éléments du graphe affiché, soit saisir des termes dans le champ de saisie (ces termes sont complétés en recherche approximative).

% https://en.wikipedia.org/wiki/Human–computer_information_retrieval
% https://en.wikipedia.org/wiki/Faceted_search

\begin{figure}[htb]
    \makebox[\textwidth][c]{
        \includegraphics[width=.7\textwidth, valign=t]{maquette-p1}
        \vrule\quad
        \includegraphics[width=.7\textwidth, valign=t]{maquette-p2}
    }
    \caption{Maquette d’interface pour le système de recherche. À gauche, suite à la saisie du symptôme \enquote{Fièvre} par le médecin dans la zone de recherche, le système affiche un graphe des trois maladies (nœuds rectangulaires) associées à ce symptômes. Les autres signes et symptômes (nœuds ovales) associés à ces maladies sont également affichés comme des liens entre les maladies. En cliquant sur le symptôme \enquote{Frissons}, ce nouveau symptôme est ajouté à la requête et le graphe mis à jour (à droite) pour filtrer les résultats en conséquence.}
    \label{fig:maquette}
\end{figure}

% - Justification de la solution par rapport aux contraintes.
Le champ de recherche permet à l’utilisateur de garder en vue l’évolution de son exploration du graphe et d’éditer sa requête pour éventuellement revenir sur ses pas.
Le graphe intègre simultanément les informations de résultats de la recherche, les liens entre les résultats et les termes de la recherche et des suggestions de poursuite de la recherche.

\section{Réalisation d’un prototype du système}

Cette partie explique les détails d’implémentation, les procédures techniques et les différents choix de technologies réalisés pour construire un premier prototype du système.

\subsection{Stratégie de récupération automatique des connaissances}

La première étape d'implémentation consiste à mettre en place un système permettant de récupérer automatiquement les connaissances décrites précédemment.
Ces connaissances sont issues de diverses sources. Les signes, les symptômes, les maladies et leurs relations sont obtenues depuis Wikimedica et Wikidata. Le facteur d’importance est dérivé des statistiques de visite des pages Wikipédia.
Chacune de ces sources mettent à disposition leurs données de façon qui leur est spécifique.

La récupération des données est programmée avec le langage de scripts Python. Ce langage jouit d’une communauté importante, de nombreuses bibliothèques ainsi que d’une documentation très complète.

\paragraph{Wikimedica}

Le site web Wikimedica dispose d’une fonctionnalité d’export des données structurées de son wiki décrites sous le formalisme \textit{Resource Description Framework}~(RDF) et la syntaxe RDF/XML.
Le~RDF est un modèle de graphe capable de décrire de façon formelle les ressources du web sémantique et leurs métadonnées de manière exploitable par des ordinateurs.
Ce formalisme a été développé par le \textit{Word Wide Web Consortium}~(W3C) en~1999 et est aujourd'hui à la base du Web sémantique.
Le RDF/XML est une syntaxe, également définie par le W3C, permettant de sérialiser une graphe~RDF comme un document~XML.
Pour récupérer les données des maladies, les signes et les symptômes de Wikimedica, le prototype télécharge directement les fichiers~RDF/XML nécessaires depuis le site.

\paragraph{Wikidata}
La base de connaissances Wikidata offre la possibilité d’accéder à ses données au travers d'un \textit{endpoint}~\textit{SPARQL Protocol and RDF Query Language} (ou simplement SPARQL). 
Le~SPARQL est un langage de requêtes permettant de décrire, de récupérer et de manipuler des ressources stockées au format RDF.
Un \textit{endpoint} SPARQL est un point d'accès disponible sur le Web permettant de répondre aux requêtes~SPARQL vis-à-vis d’un ensemble de ressources RDF d’un site, ici Wikidata.
Pour obtenir les données nécessaires depuis Wikidata, notre projet récupère les données en réalisant des requêtes HTTP vers cet \textit{endpoint}.

\paragraph{Statistiques de visites Wikipédia}

Wikimedia met à disposition ses statistiques des nombres de vues de pages Wikipédia au travers d'une API au style \enquote{Representational state transfer}~(REST) nommée \textit{pageview statistics}. REST est un style d'architecture d’interface de programmation suivant un ensemble de contraintes pour créer des services web.
Pour récupérer les informations sur le nombre de visites d'une page Wikipédia, le prototype s’adresse directement à cette API.

\subsection{Alignement des connaissances récupérées}

Une fois les données récupérées, la deuxième étape consiste à aligner les termes de Wikimedica sur ceux de Wikidata. 
Puisque Wikimedica est pour le moment une plus petite ontologie médicale que la partie de Wikidata considérée, nous avons décidé d’aligner les termes de Wikimedica sur ceux de Wikidata et non l’inverse.
Pour déterminer l’\emph{item} de Wikidata correspondant à un \emph{item} de Wikimedica, nous utilisons dans l’ordre l'algorithme suivant:

\begin{enumerate}
    \item Si le terme de Wikimedica possède la propriété \texttt{\nospace{property:Wikidata\_id}}, l'alignement est déjà renseigné manuellement.
    L’application se base donc exclusivement sur cette information.
    \item Si la propriété \texttt{\nospace{property:Wikidata\_id}} n'est pas présente, le script d'alignement réalise alors une recherche par nom dans la base de connaissances de Wikidata à l'aide d'une requête SPARQL. Si un seul résultat correspond, alors l'alignement est effectué avec cet item.
    \item Si aucun ou plusieurs résultats sont trouvés, l'alignement ne peut pas se faire automatiquement et l’intervention d’un opérateur est demandée.
\end{enumerate}

En ce qui concerne les relations entre les éléments de l’ontologie, nous avons choisi de les accumuler sans distinction.
Le script d'alignement a également été développé en Python.
Il parvient à aligner automatiquement près de la moitié des termes de~Wikimedica.
Sur~100~termes, 32~sont alignés à l'aide de la propriété \texttt{\nospace{property:Wikidata\_id}}, 18~par leur nom et les 43~restants à la main.

\subsection{Stockage durable des connaissances alignées}

Une fois les connaissances récupérées et alignées entre nos différentes sources, la troisième étape a pour objectif de les sauvegarder de manière pérenne et accessible dans une base de données.
Les format~RDF de données manipulé ici se présente sous forme de graphe.
Il semble donc naturel de sauvegarder les informations dans une base de type graphe.

Nous avons fait le choix d'utiliser la technologie de base de graphe~Neo4j.
Neo4j est un projet \textit{open-source} créé en~2007 et implémenté en~Java. C'est aujourd'hui la base de données de type graphe la plus populaire~\cite{db-engine-graph-database}.

\subsection{Algorithmes de recherche approximative}

Pour opérationnaliser cette définition, nous devons choisir une mesure de distance permettant de trier les différents termes candidats.
Dans notre cas, la saisie de l’utilisateur sera rarement un mot complet et plus souvent un préfixe voire un sous-mot du terme recherché.
Occasionnellement, cette saisie peut aussi contenir des fautes de frappe ou d’orthographe.
Plusieurs heuristiques peuvent être envisagées pour prendre en compte ces considérations, en ordre croissant de complexité~:

\begin{itemize}
    \item conserver les résultats commençant par le préfixe de recherche saisi, en normalisant la casse et les accents.
        Cette heuristique n’inclut pas les résultats dont le mot saisi est un sous-mot ou qui diffèrent de la saisie par quelques insertions ou délétions.
        Pour implémenter efficacement cette heuristique, un arbre des préfixes peut être utilisé.
    \item conserver les meilleurs résultats en triant les termes par ordre décroissant du nombre de lettres en commun avec la recherche.
        Implémentée ainsi, cette solution ne prend pas en compte l’ordre des lettres dans les termes ce qui est pourtant un élément important.
        Pour pallier cela, nous pouvons trier les résultats selon un score qui pénalise les lettres mal placées.
    \item filtrer les meilleurs résultats en triant les termes par distance de Levenshtein~\cite{levenshtein-1966-binary} croissante avec la recherche.
        Cette distance permet de mesurer l’éloignement entre deux mots complets en termes du nombre de caractères devant être insérés, supprimés ou substitués pour passer de l’un à l’autre.
        Des structures de données efficaces existent pour implémenter une recherche par distance de Levenshtein, notamment les BK-trees et les automates de Levenshtein.
        Pour adapter la distance aux spécificités du problème de recherche approximative, nous pouvons imaginer donner un poids de~0 pour l’ajout de lettres en début ou en fin de recherche et de~1 pour les autres opérations.
\end{itemize}

\subsection{Interface d’accès frontal aux connaissances}

La dernière étape de réalisation du prototype avait pour objectif d’implémenter un frontal réalisant les concepts d’interface établis à la section précédente.
Nous avons choisi d’implémenter ce frontal sur le web, pour le rendre accessible aisément à tous sans installation particulière et pour rester dans la philosophie des wiki qui sont entièrement basés sur le web.
Par ailleurs, le JavaScript, langage au cœur des technologies du web, est un langage pour lequel nous disposions déjà de connaissances et d’expérience.
Enfin, ce langage possède une large communauté très active, de nombreuses bibliothèques et une documentation très complète.

Pour créer la structure de l’application et définir les interactions, nous avons utilisé le cadre de travail~React\footnote{\url{https://reactjs.org/}}.
Cette bibliothèque \emph{open source} est développée par Facebook depuis 2013 et permet de simplifier la création d’applications très demandeuses en interactions. Elle s’appuie sur le principe de la programmation réactive et permet ainsi un code déclaratif et plus efficace et flexible que la programmation web classique.

Enfin, le graphe est affiché sous forme de nœuds reliés par des arêtes déplaçables par l’utilisateur.
La mise en forme du graphe est réalisée à l’aide d’un algorithme de simulation de force physique dans lequel les nœuds sont modélisés comme des masses ponctuelles et les liens comme des ressorts.
Nous avons utilisé pour réaliser cette simulation physique simple la bibliothèque Springy.js.

\section{Conclusion}

L’objectif du projet était d’explorer les différentes façons dont les techniques d’intelligence artificielle peuvent aider les médecins dans la réalisation de diagnostics différentiels.
Pour ce faire, nous avons conçu un système capable d’exploiter les données structurées de la plateforme Wikimedica afin de proposer une interface de recherche sémantique de maladies par signes, symptômes, antécédents et facteurs de risque.
Cette interface se présente sous la forme d’un graphe interactif, montrant au médecin les relations existant entre les résultats obtenus et lui proposant par là même des suggestions de poursuite de sa recherche.
Pour illustrer plus précisément notre concept, nous avons décidé de construire un prototype d’application qui réalise les fonctionnalités de base du système\footnote{Voir \url{https://matteo.delab.re/projects/wikimedica-disease-search}.}.
La figure~\ref{fig:prototype-screenshots} montre quelques impressions d’écran de ce prototype.
Après présentation de ce prototype aux responsables de la plateforme Wikimedica, nous sommes convaincus qu’il a le potentiel de devenir un système d’aide poussé à la réalisation de diagnostics différentiels et également de servir d’illustration à la puissance des techniques du web sémantique appliquées à la médecine.

\begin{figure}[htb]
    \makebox[\textwidth][c]{%
        \includegraphics[width=.7\textwidth, valign=t]{1-recherche-vide.png}%
        \includegraphics[width=.7\textwidth, valign=t]{3-recherche-vomissement.png}%
    }\\[-1pt]
    \makebox[\textwidth][c]{%
        \includegraphics[width=.7\textwidth, valign=t]{4-recherche-auto-toux.png}%
        \includegraphics[width=.7\textwidth, valign=t]{5-recherche-toux.png}%
    }%
    \caption{Capture d'écran illustrant le fonctionnement du projet. En haut à gauche, l'état initial de l'application où le champ de recherche est vide est le graphe affiché au complet. En haut a droite, le terme \enquote{Vomissement} est recherché, le graphe est mis à jour en conséquence. En bas à gauche, l'utilisateur est en train de saisir le préfixe \enquote{T} et le système lui propose plusieurs termes correspondants à sa saisie. Enfin, en bas à droite, l'utilisateur complète sa recherche avec le mot \enquote{Toux}.}
    \label{fig:prototype-screenshots}
\end{figure}

\printbibliography

\end{document}
