Compatibilité avec l’architecture UIMA

1.

Principes d’UIMA

UIMA (Ferrucci D., Lally A., 2004) est l’un des efforts les plus aboutis pour rendre interopérables des composants de TAL. Cette architecture est née d’un besoin interne d’IBM Research, qui comptait plus de 200 personnes travaillant sur des sujets très variés de TAL : recherche d’information, détection d’entités nommées, classification de documents, traduction automatique, questions-réponses… D’une part, cette diversité a poussé différentes équipes à réfléchir au meilleur moyen de partager leurs résultats. D’autre part, la possibilité de réutiliser et de combiner des résultats d’analyse grâce à une architecture commune et un cadre logiciel robuste est de nature à permettre d’intégrer plus rapidement les résultats des équipes de R&D dans les produits logiciels d’IBM. Ces besoins ont conduit à l’élaboration d’UIMA (Unstructured Information Management Architecture, architecture de

36 traitement des informations non structurées), qui offre des capacités de recherche d’information et une plate-forme de développement, de composition et de déploiement de moteurs d’analyse. UIMA propose un cadre technique de référence, centré sur l’annotation de documents. Son objectif est de décrire les étapes de traitement d’un document de type texte, image ou vidéo afin d’en extraire de façon automatique des informations structurées. En revanche, UIMA ne décrit ni comment ces informations doivent être extraites, ni la façon de s’en servir. Cette architecture reste donc à un niveau très générique sur la notion d’annotation et ne propose pas de modèle de référence destiné à stocker les résultats des différents types d’analyses. Plusieurs composants annoteront donc successivement (ou en parallèle) des textes, mais ils ne pourront pas facilement partager les intermédiaires de calcul déjà effectués s’il n’y a pas de définition préalable d’un « CAS » (Common Analysis System) standard.

IBM a créé une implémentation de référence open source d’UIMA en C++ et en Java, avant de la transférer à la fondation Apache. L’ambition d’UIMA est de s’imposer en tant que standard industriel et norme ; UIMA a d’ailleurs été approuvée par l’OASIS en 2009.

2.

Intégration d’Antelope à l’architecture UIMA

Antelope a des objectifs moins universels qu’UIMA et ne traite que l’analyse de documents textuels, orientée vers l’extraction de connaissances. Le modèle unifié d’Antelope est conçu sur mesure pour assurer cette tâche ; il ne s’agit donc pas d’un métamodèle, comme c’est le cas dans UIMA. On peut souligner une similarité d’architecture entre UIMA et Antelope : dans les deux cas, la conception est orientée composants et s’appuie sur un modèle de programmation par interfaces, avec des structures extensibles.

(Chaumartin et al., 2009) présente en détail les modalités d’intégration d’Antelope à l’architecture UIMA. Une difficulté technique à résoudre était l’intégration des composants d’Antelope (conçus pour .NET) dans l’architecture UIMA, dont seules des implémentations C++ et Java existent. Réécrire l’ensemble des composants d’Antelope dans ces langages était inenvisageable. Nous avons donc cherché comment créer un annotateur UIMA, fonctionnant en .NET et non en Java, capable d’être appelé depuis n’importe quel processus client UIMA. Nous avons d’abord essayé d’exposer un service Web, mais cette approche n’a pas abouti60_{. Nous avons ensuite exploré une solution de plus} bas niveau en utilisant un protocole d’appel entre sockets pour communiquer entre la machine virtuelle .NET et la machine virtuelle Java (JVM). Lors de ces essais, nous avons identifié un protocole standard d’UIMA, nommé Vinci, utilisant uniquement les sockets et des bibliothèques Java standards ; ce protocole était donc relativement facile à transposer en .NET. Nous avons utilisé IKVM pour convertir les bibliothèques UIMA (fichiers .jar) dans leur équivalent en .NET, ce qui nous permet au final d’invoquer les analyseurs d’Antelope. La figure 7 illustre cette architecture technique.

L’objectif de l’application SCRIBO (voir page 132) est l’extraction d’information à partir de dépêches de l’AFP. SCRIBO utilise plusieurs annotateurs en architecture UIMA, dont ceux d’Antelope.

60 _{Le protocole SOAP est censé permettre une telle interopérabilité. Néanmoins, des problèmes}

d’incompatibilité entre les services Web exposés par UIMA et leur mise en œuvre en .NET sont apparus. En effet, les services Web d’UIMA exposent certaines classes utilisant les bibliothèques Axis, qui ne peuvent pas être facilement traduites dans leur équivalent .NET.

Figure 7 : Architecture technique permettant l’appel d’analyseurs écrits en .NET à partir d’UIMA

I.

Composants de traitement jusqu’à l’analyse

syntaxique

1.

Nettoyage de documents (« templating »)

Le nettoyage de pages Web (templating ou scrapping en anglais) a pour objectif de diminuer le bruit dans les documents Web après leur collecte et avant leur analyse. En effet, les pages Web contiennent souvent des données qui « parasitent » l’élément principal de la page, comme les menus, les liens vers d’autres pages liées, ou encore des liens commerciaux. Le nettoyage permet de sauvegarder une copie locale « allégée » des pages Web (avec un volume stocké moins important) ; l’analyse de cette copie est plus pertinente. Nous avons exploré plusieurs pistes pour effectuer un tel nettoyage. Cette tâche n’étant toutefois qu’un préalable à celles du TAL, nous ne les décrirons pas plus en détail ici.

2.

Segmentation et traitement de l’enrichissement

typographique

Antelope traite des documents au format texte brut ou au format HTML. Dans ce dernier cas, un traitement préalable sépare le texte de son enrichissement typographique ; l’analyse des balises HTML permet un découpage du document en paragraphes. Ces paragraphes sont ensuite découpés en phrases en utilisant un ensemble de règles. L’information permettant de relier les mots, phrases et paragraphes aux balises est par la suite toujours disponible, ce qui permet :

 De déterminer si un paragraphe est un titre ou un élément d’une énumération61_.

 D’identifier les références quand le document contient des liens hypertexte62_.

61 _{Auquel cas, il nécessite peut-être un traitement particulier : « décapitalisation » des initiales pour un titre,}

analyse syntaxique de phrase averbale pour un élément d’énumération. Machine virtuelle Java Machine virtuelle .NET protocole VINCI IKVM Analyseurs d’Antelope Reconnaissance d’entités nommées Extraction de relations Fusion d’annotations

38

3.

Étiquetage morphosyntaxique, chunking ou analyse

syntaxique

En fonction de ses besoins de vitesse ou de précision, l’utilisateur peut choisir entre un étiquetage morphosyntaxique, un chunking ou une analyse syntaxique. Antelope utilise pour cela les composants externes présentés en section F.3. Dans les trois cas, le modèle unifié décrit en section III.C (page 23) est alimenté, mais seules les représentations concernées (RMorphS, RMorphP ou RSyntS) sont renseignées.

4.

Identification des expressions multi-mots

Antelope utilise le lexique sémantique pour identifier les expressions multi-mots. La forme de base de chaque mot est d’abord calculée par le module morphologique du lexique ; le composant teste la présence de n-uplets dans le lexique (n variant de cinq jusqu’à deux). Des règles supplémentaires permettent d’identifier aussi des expressions multi-mots non contigües, comme dans « Pierre and

Marie Curie », « Alabama and Mississippi Rivers » ou « the canon and civil law ».

Lors d’une analyse syntaxique (par opposition à un simple étiquetage morphosyntaxique), une contrainte supplémentaire de rattachement est appliquée. Les mots ne sont regroupés que s’ils appartiennent à un même sous-arbre. Comme le montre la figure 8, l’expression « Battle of

Gettysburg » est reconnue dans l’analyse syntaxique de gauche, mais pas dans celle de droite

(absence de tête commune). Cela contribue à lever certaines ambiguïtés syntaxique (ce point est décrit page 162 en section VII.B.6.c).

┌──prep>──┐ ├dobj┐ │ │ │ ├───pobj>──┐ ┌<nsub┤ │ │ ┌─<det┼prep>┬pobj>┐ │ │ │ │ │ │ │ │ … captured … during the Battle of Gettysburg

┌──────────prep>──────────┐ ├──prep>──┐ │ ├dobj┐ │ │ │ │ ├───pobj>──┐ │ ┌<nsub┤ │ │ ┌─<det┤ ├─pobj>┐ │ │ │ │ │ │ │ │ … captured … during the Battle of Gettysburg

Figure 8 : Identification de l’expression multi-mots « Battle of Gettysburg »