• Aucun résultat trouvé

Extraction d’information

2.6 Approches d’extraction d’information à base de règlesde règles

2.6.1 Formalismes de règles

Plusieurs formalismes ont été développés pour permettre d’écrire des règles d’ex-traction d’information. Nous pouvons par exemple citer :

— le langage CSPL (Common Pattern Specification Language) de Hobbs, Bear, Israel, et Tyson (1993) qui représente l’une des premières tentatives pour formaliser un langage de règles ;

— les éléments de patrons dans RAPIER (Califf & Mooney, 1998) ;

— les expressions régulières dans le système WHISK (S. Soderland et al., 1999) ; — les expressions SQL comme dans Avatar (Jayram, Krishnamurthy, Ragha-van, Vaithyanathan, & Zhu, 2006 ; Reiss, RaghaRagha-van, Krishnamurthy, Zhu, & Vaithyanathan, 2008) ;

Ra-32 Chapitre 2. Extraction d’information makrishnan, 2007) ;

— le langage JAPE (Java Annotations Pattern Engine) de Cunningham, May-nard, et Tablan (2000), dérivé de CSPL et introduit dans la plateforme GATE (Cunningham, 2002) afin d’extraire des informations en s’appuyant sur les annotations produites par cette plateforme ;

— ou encore plus récemment le langage Ruta (Atzmueller, Kluegl, & Puppe, 2008 ; Kluegl, Atzmueller, & Puppe, 2009) qui est en quelque sorte le pendant de JAPE pour la plateforme UIMA (Ferrucci & Lally, 2004).

Plusieurs langages d’extraction d’information déclaratifs dans la communauté des bases de données ont été développés comme AQL (Chiticariu, Krishnamurthy, et al., 2010 ; Li, Reiss, & Chiticariu, 2011), xLog (Shen et al., 2007), des extensions de SQL (Jain, Ipeirotis, & Gravano, 2009 ; Wang, Michelakis, Franklin, Garofalakis, & Hellerstein, 2010). Ces langages ont montré que des formalismes d’extraction d’in-formation à base de règles sont possibles (Fagin, Kimelfeld, Reiss, & Vansummeren, 2013). Ils restent cependant peu connus dans la communauté de TAL.

Chiticariu et al. (2013) pensent qu’il est temps d’établir un langage de règles standard pour l’EI qui s’inspire des propositions et des expériences des 30 dernières années. Pour ce faire, les chercheurs doivent répondre aux questions suivantes :

— quel est le modèle de données approprié pour exploiter le texte, les annota-tions du texte et leurs propriétés ?

— peut-on établir un langage de règles déclaratif standard extensible qui permet-tra de permet-traiter des données dans ce modèle avec un ensemble de constructions suffisamment expressives pour résoudre la plupart des tâches d’EI rencon-trées ?

Les auteurs s’inspirent, dans leur article nommé « Rule-based information ex-traction is dead ! Long live rule-based information exex-traction systems ! », du succès de SQL dans la communauté de bases de données pour proposer des instructions pour réduire l’écart entre le monde industriel où les systèmes d’EI à base de règles dominent et le monde académique où ces systèmes ont été délaissés au profit des systèmes à base d’apprentissage statistique.

Sarawagi (2008) propose une définition générique d’une règle d’extraction qui est la suivante :

Patron contextuel æ Action

Le patron contextuel est constitué d’une ou plusieurs expressions régulières dé-finies en s’appuyant sur les propriétés des tokens dans le texte ainsi que leurs contextes. L’action permet de décrire les différents types de marquage dans le texte :

— l’étiquetage d’une séquence de tokens ; — l’étiquetage d’une entité ;

— l’insertion d’une étiquette de début et de fin à une entité ; — l’attribution de multiples étiquettes à une entité ;

— l’étiquetage simultané de plusieurs entités ;

— l’étiquetage de relations en repérant les entités impliquées dans la relation à étiqueter, etc.

Dans certains langages évolués comme JAPE et Ruta, la partie action de la règle peut accéder aux différentes propriétés utilisées dans le patron contextuel et

2.6. Approches d’extraction d’information à base de règles 33 s’en servir pour ajouter de nouvelles propriétés au fragment de texte annoté qui, elles-mêmes, vont servir à d’autres règles par la suite.

JAPE Le langage JAPE (Java Annotation Patterns Engine) (Cunningham et al.,

2000) est une version du langage CSPL (Hobbs et al., 1993). Il fournit un transduc-teur à états finis sur les annotations qui s’appuie sur des expressions régulières.

La grammaire JAPE consiste en un ensemble de phases dont chacune est com-posée d’un ensemble de règles sous forme patron/action. Les phases s’exécutent séquentiellement et forment une cascade de transducteurs à états finis sur les an-notations fournies par la plateforme GATE (Cunningham, 2002). La partie gauche des règles (Left-Hand-Side, LHS) décrit un patron d’annotation et la partie droite (Right-Hand-Side, RHS) contient des instructions de manipulation d’annotations. La RHS peut référer à des annotations couvertes par la LHS à travers des étiquettes associées aux éléments du patron.

Considérons l’exemple suivant : 1 Phase: Jobtitle

2 Input: Lookup

3 Options: control= appelt bebug= true 4 5 Rule: Jobtitle1 6 ( 7 {Lookup.MajorType == jobtitle} 8 ( 9 {Lookup.MajorType == jobtitle} 10 )? 11 ) 12 :jobtitle 13 -->

14 :jobtitle.JobTitle = {rule = "JobTitle1"}

La LHS est la partie qui précède le signe –-> et la RHS est la partie qui le suit. La LHS spécifie un patron à appliquer sur un texte annoté avec la plateforme GATE alors que la RHS spécifie l’action à exécuter sur le texte couvert par le patron. Dans l’exemple donné, une règle nommée Jobtitle1 (ligne 5) cherche des correspondances dans un texte contenant des annotations de type Lookup avec un attribut MajorType égal à jobtitle (ligne 7), suivi optionnellement par un texte annoté avec le type Lookup avec un attribut MajorType égal à jobtitle (ligne 9). Une fois un segment de texte couvert par la règle est identifié, cette dernière lui attribue l’étiquette ou le label jobtitle (ligne 12). Dans la RHS, on trouve une référence au segment de texte concerné par le label jobtitle dans la LHS. Une annotation de type JobTitle est attribuée à ce segment de texte (ligne 14).

Dans la grammaire JAPE, on commence par donner un nom de phase à la gram-maire (Phase: Jobtitle (ligne 1), par exemple). Les gramgram-maires JAPE peuvent être cascadées, chaque grammaire étant ainsi considérée comme une phase. Le nom

34 Chapitre 2. Extraction d’information de phase fait partie du nom de la classe Java pour les actions RHS compilées7.

Une liste des types d’annotation utilisés dans la grammaire est également fournie. Dans le cas de l’exemple fourni précédemment, Input: Lookup (ligne 2) signifie que seul le type d’annotation Lookup est utilisé dans la LHS. Si aucune annotation n’est définie, toutes les annotations sont considérées.

Plusieurs options peuvent également être utilisées :

— Le contrôle (control) – Cette option définit la méthode de mise en corres-pondance de la règle (appelt dans l’exemple fourni).

— Le débogage (debug) – Quand cette option est fixée à vrai (true), si la gram-maire est utilisée dans un mode appelt et s’il y a plus d’une correspondance, les conflits sont affichés sur la sortie standard.

Une large panoplie de fonctionnalités peuvent être utilisées avec JAPE, ce qui en fait un système puissant.

Ruta Le langage Ruta (anciennement appelé TextMarker (Atzmueller et al., 2008 ;

Kluegl, Atzmueller, & Puppe, 2009)) est un langage de script générique qui ressemble au langage JAPE (Cunningham et al., 2000) mais qui repose sur la plateforme UIMA (Ferrucci & Lally, 2004) plutôt que GATE (Cunningham, 2002). Selon les expériences de certains utilisateurs, il est plus complet que JAPE qui est l’un des langages de règles les plus connus.

Ce langage est détaillé dans la section 4.3.