Identification des caractéristiques de la question

6.4.2 Identification des caractéristiques de la question

Identification du type de la question

Nous identifions le type de la question (e.g. WH, Yes/No, Définition) en appliquant un ensemble de règles simples sur les questions des utilisa-teurs (e.g. premierMotDe(Q) = (How|What|Which|When) indique que la question Q est de type Wh).

Identification du type de la réponse attendue

Pour les questions WH, nous déterminons le type de la réponse atten-due en projetant des patrons lexicaux construits manuellement sur le texte original de la question. Un ensemble de patrons est construit pour chaque

6.4. Analyse et transformation des questions médicales en requêtes SPARQL 99

type de question. Ces patrons utilisent des pronoms interrogatifs, des mar-queurs syntaxiques et des mots génériques et identifient un ensemble de questions compatibles. Cependant, il arrive qu’une question ait plus d’un type de réponse attendue. Dans ce cas, nous gardons tous les patrons qui ont pu être projetés sur la question, même s’ils sont associés à des types de réponse différents (e.g. Traitement, Médicament, Test médical).

Construction de la forme affirmative de la question

Dans une deuxième étape, nous construisons la forme affirmative de la question en remplaçant les pronoms interrogatifs par le mot clé “ANS-WER”. Cette forme sera utilisée à l’étape d’extraction de relations. Nous construisons aussi une forme simplifiée de la question où la séquence de mots indiquant le type de réponse attendue est remplacée par le mot clé “ANSWER”. Cela permet d’éviter du bruit au moment de l’extraction des entités médicales.

Par exemple, dans la question : « What is the best treatment for hea-dache ? » le système de reconnaissance des entités médicales retourne “treatment” et “headache” comme entités, ce qui ne constitue pas une entrée précise pour la phase d’extraction de relation, car “treatment” est la catégorie de la réponse attendue et non une entité. La forme affirma-tive de la question « ANSWER is the best treatment for headache ? » permet d’abord d’expliciter les deux entités médicales de la question. Cependant l’erreur consistant à extraire “treatment” comme entité médicale est tou-jours susceptible de se produire. Simplifier la question à « ANSWER for headache » permet d’expliciter l’entité médicale recherchée et d’obtenir une extraction de relations plus efficace en identifiant les relations entre seulement l’entité ANSWER (qui est étiquetée comme étant de type “treat-ment”) et l’entité « headache ». L’intuition derrière cette approche est que les indicateurs du type de la réponse attendue peuvent constituer un bruit pour l’extraction de relation qui peut être évité en simplifiant la question. L’extraction de relations sémantiques est la dernière étape avant la construction de la requête SPARQL. Pour les questions de type Yes/No, le processus d’extraction de relation a des entrées explicites étant donné que toutes les entités médicales y sont complètement identifiées. Par contre, pour les questions de type Wh nous pouvons avoir plusieurs types de réponse attendues. Dans un tel cas, une méthode plus générique est né-cessaire.

Reconnaissance des entités médicales

Les résultats de la reconnaissance des entités médicales sont représen-tés en logique du premier ordre avec les prédicats category, value et position. Par exemple, la formule E1 (tableau 6.3) indique que le troi-sième token de la question (« aspirin ») est une entité médicale et que sa catégorie est TREATMENT.

Extraction de relations sémantiques

Les résultats de l’extraction de relations sont représentés en logique du premier ordre avec plusieurs prédicats indiquant le nom de la relation

E1 :

{category(#ME1,TREATMENT)

∧ value(#ME1,aspirin)

∧ position(#ME1,3)}

Table 6.3

(e.g. treats, causes). Par exemple, la formule E2 (tableau 6.4) indique que trois entités médicales sont reliées par deux relations sémantiques treats et patientHasProblem.

E2 :

{ treats(#ME1,#ME2)

∧ _{patientHasProblem(#ME3,#ME2) }}

Table 6.4

Cas où l’on a plusieurs types de réponses attendues (TRA)

Pour prendre en compte le cas de multiples TRA, nous construisons autant de questions que de réponses attendues. Ce processus complet est décrit dans le tableau 6.5.

1. Identifier le type de la question

2. Identifier les types de réponses attendues (TRA) pour les questions WH (m TRA)

3. Construire le forme simplifiée et affirmative des questions (nouvelle forme)

4. Identifier les entités médicales dans la nouvelle forme de la question - Pour (x=1, x++, x≤m)

5:x. Extraire les relations sémantiques [Entrées : (i) le TRA_x, (ii) les entités médicales, et (iii) la nouvelle forme de la question)]

6:x. Construire la requête SPARQL x

Table 6.5 – Processus complet en présence de TRA multiples

Pourquoi construire plusieurs requêtes ? Notons d’abord qu’il est pos-sible d’utiliser le langage SPARQL pour représenter la sémantique de la question et retrouver toutes les réponses attendues en construisant un seul patron de graphe RDF et une requête unique pour une question donnée. Cependant, cette méthode contraindrait le système à trouver une justi-fication commune dans le corpus textuel pour les différents TRAs. Par exemple, si la question est « How to diagnose and treat pressure ulcers ? », construire un seul patron de graphe RDF mènerait à rechercher un exa-men et un traiteexa-ment qui permettent de diagnostiquer et traiter la même entité médicale E. Alors que construire deux requêtes, pour cet exemple, permet de rechercher un traitement pour une entité médicale E1 de type pressure ulcers et un examen pour une entité médicale E2 qui est aussi de type pressure ulcers. Dans ce cas E1 peut aussi bien être égale à E2 (même entité dans le corpus) que non, ce qui évite la restriction posée

6.4. Analyse et transformation des questions médicales en requêtes SPARQL 101

par l’utilisation d’un seul patron de graphe. Une autre solution potentielle à ce point est d’utiliser la clause UN ION pour rechercher deux patrons de graphes RDF disjoints dans une même requête, nous avons cependant choisi d’écrire plusieurs requêtes différentes dans un souci de clarté.