Une chaîne UIMA pour l'analyse de documents de réglementation

Une chaîne UIMA pour l’analyse de documents de réglementation Samir Derdek∗,∗∗ , Adil El Ghali∗ IBM CAS France 9 rue de Verdun, BP 85, 94253 Gentilly, France adil.elghali@fr.ibm.com Institut Galilée - Université Paris 13 99 avenue J.-B. Clément, 93439 Villetaneuse, France samir.derdek@gmail.com Résumé. Cet article 1 présente une chaîne de traitement UIMA pour l’analyse des documents de réglementation. Cette chaîne incorpore un analyseur syntaxique et un résolveur d’anaphores, qui produisent des annotations exploitables pour détecter des règles et pour faciliter le processus de modélisation de règles. Cette chaîne est destinée à être utilisée par des experts métier pour améliorer la modélisation d’un système de règles à partir de textes. ∗∗ ∗ 1 Introduction Les documents de réglementation contiennent des règles auxquelles doivent se conformer les entreprises dans les processus de fabrication et de commercialisation de leurs produits. Il est donc vital pour celles-ci d’en tenir compte, voire de les intégrer à leurs processus. Ces processus sont, chez un nombre croissant d’industriels, formalisés et implantés dans des systèmes de gestion de règles métier (BRMS), il apparaît donc d’une grande utilité de pouvoir transformer les règles et les contraintes contenues dans les documents de réglementation en des règles formelles et exécutables dans un système de règles. L’approche que nous avons retenue consiste à analyser ces documents à l’aide d’outils d’analyse linguistique profonde afin de produire des annotations linguistiques pour les éléments composant le texte. Ces annotations sont ensuite exportées au format RDF permettant, d’une part, leur utilisation pour identifier des règles via des requêtes SPARQL traduisant les principaux schémas que respectent les règles dans les documents ; et d’autre part, la possibilité pour les analystes et les experts métier de naviguer dans les bases de documents réglementaires d’une manière efficace pour leur processus de modélisation et de formalisation de règles. La chaîne de traitement prend en entrée les sources réglementaires qui sont disponibles publiquement, et utilise d’autres sources ouvertes (vocabulaires, bases de données linguistiques, ...), elle peut par ailleurs tirer profit de toute ontologie du domaine existante. Le cadre dans lequel nous avons testé notre chaîne de traitement est celui du projet ONTORULE 2 , en parti1. Ce travail a été partiellement financé par le projet FP7 EU-IST Integrated Project 2009-231875 ONTORULE. 2. http://www.ontorule-project.eu Une chaîne UIMA pour l’analyse de documents de réglementation culier pour le scénario Audi où il fallait analyser des documents de réglementation européennes pour le test des composants d’un véhicule, et intégrer les règles provenant de ces documents dans une application métier à base de règles permettant de choisir la meilleure manière de tester des composants tout en respectant la réglementation. Cet article est organisé comme suit : dans la première section, nos décrivons la chaîne de traitement UIMA et ses différents composants, ensuite nous présentons les structures de données manipulées et les annotations RDF exportées. Enfin, nous donnons quelques exemples d’utilisation de ces annotations.. 2 Chaîne de traitement des textes de réglementations Le but de notre expérimentation est de produire à partir des textes en entrée une représentation qui puisse être utilisée par un module de raisonnement permettant (i) de transformer les informations linguistiques dans le texte en des données utilisables dans des modèles (ontologie ou modèle métier) décrivant le domaine métier, et (ii) d’identifier les passages du texte qui correspondent à des règles métier, Pour ce faire, notre approche consiste à effectuer une analyse linguistique profonde. Puis à réaliser un module de raisonnement effectuant l’identification et la formalisation des règles. Notre chaîne de traitement est composée de deux modules principaux d’analyse : un analyseur syntaxique en dépendance, et un résolveur d’anaphores. Elle permet de regrouper le résultat de ces analyses dans des annotations homogènes qui seront exploitables par le module d’extraction de règles ou par le module d’aide à la modélisation. De plus, notre approche se décline en deux modes de traitements. Le premier consiste à sélectionner le meilleur résultat de l’analyse linguistique et à le soumettre à son exploitation par les modules d’aide à la modélisation et d’extraction de règles. Le second consiste à conserver tous les résultats de l’analyse linguistique et à les soumettre aux modules, afin de laisser un choix de règles plus important à l’expert métier. Quelque soit le mode choisi, la validation de la pertinence des règles est faite par un expert métier. 2.1 Architecture Nous avons choisi Unstructured Information Management Application 3 (UIMA) Ferrucci et Lally (2004); Hernandez et al. (2010, 2009) pour encoder notre chaîne de traitement car ce framework permet de définir facilement une chaîne de traitement alliant flexibilité (UIMA s’appuie sur une architecture pilotée par les données où les modules de traitements peuvent être facilement remplacés par d’autres) et qualité (les chaînes produites permettent d’analyser un gros volume de données). De plus, il offre un environnement de développement puissant, incluant entre autres des interfaces de visualisation des résultats à chaque étape de l’analyse. L’architecture de la chaîne de traitement est présentée en figure 1. Les différents modules (analyseur syntaxique et résolveur d’anaphores) produisent des informations linguistiques (morphologiques, syntaxiques, ...) qui sont traduites en annotations UIMA. Ces annotations peuvent par la suite être exportées en RDF. 3. http://uima.apache.org/index.html S. Derdek et A. El Ghali F IG . 1 – Architecture de la chaîne UIMA. Dans l’implantation actuelle les modules utilisés sont le Stanford Parser et BART Anaphora, mais dans cette chaîne de traitement ceux-ci peuvent aisément être remplacés par d’autres modules fournissant des sorties équivalentes. 2.2 Les composants de la chaîne de traitements 2.2.1 Stanford Parser L’analyseur Stanford Parser Klein et Manning (2003a,b) est un analyseur statistique en dépendance qui offre un bon compromis entre rapidité et pertinence Cer et al. (2010), il permet d’extraire trois types d’informations : – les parties du discours pour les mots de la phrase, utilisant le jeu d’annotation du Penn Treebank Marcus et al. (1993), l’exemple ci-dessous donne un aperçu de l’étiquetage morpho-syntaxique de l’analyseur : A/DT complete/JJ safety-belt/JJ assembly/NN shall/MD be/VB positioned/VBN ... – l’arbre syntaxique en constituants permettant de faire les regroupements grammaticaux, ci-après un exemple : (ROOT (S (NP (DT A) (JJ complete) (JJ safety-belt) (NN assembly)) (VP (MD shall) (VP (VB be) (VP (VBN positioned) (PP (IN in) (NP (DT a) (NN test) (NN chamber))) (SBAR (IN as) (S (VP (VBN prescribed) (PP (IN in) (NP (NNP Annex) (CD 12))))))))))) – les dépendances i.e. des relations syntactico-sémantiques entre les mots d’une phrase, il utilise le jeu de dépendances typées de Marneffe et Manning (2008), permettant de Une chaîne UIMA pour l’analyse de documents de réglementation regrouper des dépendances élémentaires, comme dans l’exemple ci-dessous : prep(prescribed-13, in-14) → pobj(in-14, Annex-15) prep_in(prescribed-13, Annex-15) 2.2.2 BART Anaphora Le résolveur d’anaphores BART Anaphora Versley et al. (2008) utilise des méthodes statistiques, après une phase d’analyse syntaxique, pour la résolution d’anaphores. L’entraînement s’effectue sur des corpus annotés existants au format MMAX2 4 Müller et Strube (2006). Les performances du système peuvent être améliorées en l’entraînant sur des corpus de textes de réglementations. BART Anaphora produit en sortie des phrases annotées par des relations de co-références, permettant de lier des mots ou des groupes de mots. Comme le montre l’exemple ci-dessous : <coref set-id="set_2"> <w pos="dt">an</w> <w pos="nn">assembly</w> </coref> ... <coref set-id="set_2"> <w pos="dt">the</w> <w pos="nn">assembly</w> </coref> 2.3 Intégrations des composants dans UIMA Dans UIMA, le texte, une fois analysé, est chargé dans un Common Analysis System (CAS). Le CAS permet l’échange de données entre les différentes annotations que l’on a défini pour représenter les données linguistiques. Pour le module encapsulant le Stanford Parser, on a défini trois types correspondants aux métadonnées les plus pertinentes pour l’analyse des textes de règles : – le type Word représente chaque mot de la phrase et a pour attribut sa partie du discours – ce sont les métadonnées de la phase l’étiquetage morpho-syntaxique – ; – le type Constituant représente les groupements grammaticaux dans la phrase et ayant pour attribut les mots ou les constituants lui appartenant – ce sont les métadonnées issues de l’analyse syntaxique – ; – le type Dependent et Governor qui désignent les deux éléments qui composent une relation de dépendance, ils ont pour attributs le Governor (resp. Dependent) associé, ainsi que la relation de dépendance – ce sont les métadonnées pour l’analyse en dépendance –. Pour le module de résolution d’anaphore, les deux types nécessaires représentent respectivement la notion référencée et ses références : le type notion désigne la notion référencée, le type reference représente les références trouvées. Notons qu’une classe d’anaphore est une notion propre à BART qui permet de regrouper une liste de termes qui ont le même sens. On a défini également trois Analysis Engine (AE) afin de créer une chaîne de traitement permettant l’exécution des composants : 4. http ://mmax2.sourceforge.net S. Derdek et A. El Ghali StanfordAE il permet de définir le module qui encapsule le Stanford parser. Il se base sur les résultats du « SentenceAE » (qui traite le texte phrase par phrase) et produit les annotations de dépendances et de mots. BartAE définit le module qui encapsule BART. Il produit les annotations de notions et de références. Cet annotateur prend en entrée le texte dans son intégralité (une référence pouvant référer à une anaphore distante de plusieurs phrases). ParsingAE définit la chaîne d’exécution composée des AE définis précédemment. C’est un AE d’agrégation (cf Figure 2). F IG . 2 – Schéma de la chaîne d’exécution UIMA 3 Structures de données et annotations 3.1 Les structures de données Les structures de données utilisées permettent de formater les informations linguistiques extraites du texte avec le Stanford parser et BART pour qu’elles soient réutilisables de manière optimale par le module d’extraction de règles. Les marqueurs grammaticaux sont stockés dans une HashMap qui pour chaque mot (ayant un identifiant unique) fait correspondre un objet POS (objet ayant 4 attributs : le mot lui-même, le numéro de phrase à laquelle il appartient, le numéro de sa position dans la phrase, son marqueur grammatical). Les dépendances sont sous la forme de trois structures différentes adaptées à divers besoins. La première structure est une HashMap qui à tout type de relation trouvée dans le texte associe une liste de couple de mots qui interviennent dans le type de relation, comme le montre l’exemple ci-dessous, pour la relation aux (auxiliary), qui lie trois couple de mots : Rel: aux [Dep: (necessary, 8), Gov: (may, 6)] [Dep: (check, 14), Gov: (to, 13)] [Dep: (proceed, 25), Gov: (shall, 24)] Une chaîne UIMA pour l’analyse de documents de réglementation La deuxième structure est une HashMap qui associe à chaque gouverneur une liste de couples (relation, dépendant), permettant d’accéder à tous les dépendants d’un mot du texte, comme le montre l’exemple ci-après (pour le mot necessary) : Gov: (necessary, 8) [Reln : (nsubj);Dep [Reln : (aux);Dep : [Reln : (cop);Dep : [Reln : (dep);Dep : [Reln : (xcomp);Dep : (that, 5)] (may, 6)] (be, 7)] (for, 10)] : (check, 14)] La troisième structure est un graphe direct acyclique (DAG) qui permet d’organiser les dépendances d’une phrase donnée de façon optimale pour l’identification des règles. La figure 3 montre la représentation en DAG de la section 7.2.1 de la réglementation européenne sur les ceintures de sécurité (cf. section 4). Chaque arc représente une relation et a pour source le gouverneur de la relation et pour cible le dépendant. F IG . 3 – Graphe direct acyclique des dépendances de la section 7.2.1. 3.2 Annotations RDF Les informations linguistiques sont exportées sous format RDF, elle peuvent ainsi être exploitées dans le module d’aide à la modélisation via des requêtes SPARQL, mais aussi être réutilisées par les membres du consortium ONTORULE. Le schéma selon lequel sont définies les annotations RDF étend (cf. figure 4) le vocabulaire d’annotations 5 El Ghali et al. (2010), une classe brem:LinguisticAnnotation étend la classe annot:Annotation. Elle a pour sous-classes les classes correspondantes aux annotations UIMA. Les triplets produits sont une représentation des annotations UIMA en RDF. En voici quelques exemples 6 : – Les mots (annotations UIMA de type Word) s’exportent dans des instances RDF de la classe brem:Word comme le montre l’exemple suivant : 5. http ://vocamp.org/wiki/HypiosVoCampParisMay2010#Annotations_Ontology 6. Dans les exemples nous utilisons la notation N3. S. Derdek et A. El Ghali @prefix brem: <http://ontorule-project.org/ontologies/IBM/brem>. brem:W398764 brem:hasvalue brem:hasindex brem:hassentence brem:hasID brem:hasPOS brem:hasvalue brem:hasindex brem:hassentence brem:hasID brem:hasPOS "necessary"; 8; 3; 398764; brem:JJ . "may"; 6; 3; 308194; brem:MD . brem:W308194 – Les relations de dépendances sont, elles, exportées comme des instances de la classe brem:Dependency, l’exemple ci-dessous montre les triplets RDF pour une instance de la relation “ aux ” : @prefix brem: <http://ontorule-project.org/ontologies/IBM/brem>. brem:D245749 brem:hasID brem:hasdependent brem:hasgovernor brem:hastype 245749; brem:W398764. brem:W308194. brem:Aux. F IG . 4 – Ontologie d’annotations Une chaîne UIMA pour l’analyse de documents de réglementation 4 Exemples de résultats Pour effectuer nos tests, nous nous sommes basés sur des données fournies par Audi dans le cadre du projet ONTORULE. Ces textes traitent de réglementation sur les ceintures de sécurité dans les voitures. En voici un extrait : 7.2. Corrosion test 7.2.1. A complete safety-belt assembly shall be positioned in a test chamber as prescribed in Annex 12 to this Regulation. In the case of an assembly incorporating a retractor, the strap shall be unwound to full length less 300 ± 3mm. Except for short interruptions that may be necessary, for example, to check and replenish the salt solution, the exposure test shall proceed continuously for a period of 50 hours. 7.2.2. On completion of the exposure test the assembly shall be gently washed, or dipped in clean running water with a temperature not higher than 38◦ C to remove any salt deposit that may have formed and then allowed to dry at room temperature for 24 hours before inspection in accordance with paragraph 6.2.1.2. above. Pour la partie Anaphore on peut observer dans la figure 5 les notions et références trouvées par BART, telles qu’elles peuvent être visualisées dans l’interface UIMA. F IG . 5 – Notions visualisées dans l’interface UIMA La figure 6 montre un exemple d’annotations issues de l’analyse en dépendance. Le mot « assembly » (partie 7.2.2 dans le texte) est déterminé par l’article « the » qui est le septième mot de la phrase (le titre "7.2.2." compte pour un mot). F IG . 6 – Gouverneur d’une relation visualisée dans l’interface UIMA S. Derdek et A. El Ghali D’autre part, les annotations RDF peuvent être utilisées dans le module d’aide à la modélisation pour assister les analystes dans l’écriture de modèles et de règles. Pour ce faire, nous leur fournissons une batterie de requêtes SPARQL paramétrables, qui leur permettent d’interroger la base d’annotations, par exemple, pour retrouver toutes les relations potentielles dans lesquelles un Concept “Car” dans le modèle joue le rôle de sujet (les relations de dépendances sont représentées dans l’ontologie par les sous-classes de DepType, elles sont organisées dans une hiérarchie, par exemple, la classe DepSubj est la super-classe de NSubj, CSubj, XSubj), ils utiliseront la requête suivante pour pouvoir recupérer l’ensemble des relations possibles associées à la classe “Car” pour l’écriture des règles (voir ci-après). PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX annot: <http://vocamp.org/hyvoc/annotations#> PREFIX brem: <http://ontorule-project.org/ontologies/IBM/brem#> SELECT DISTINCT ?r WHERE { ?w a brem:Word . ?z a brem:Word . ?d brem:hasGovernor ?z . ?d brem:hasDependent ?w . ?d brem:hasValue ?r . ?d brem:hasType brem:DepSubj . ?w brem:hasValue ?r "Car" } 5 Conclusion Dans cet article, nous présentons une chaîne de traitement UIMA pour l’analyse de textes de réglementations. Cette chaîne comporte deux composants linguistiques principaux, d’une part, un analyseur syntaxique le Stanford Parser qui fournit des métadonnées morphologiques, syntaxiques et de dépendances, d’autre part, un résolveur d’anaphores BART Anaphora qui permet d’identifier les co-références dans le texte. Ces modules encapsulés dans le framework UIMA, produisent des métadonnées qui sont unifiées dans une structure homogène puis exportées en RDF pour être utilisées dans le module de détection de règles et d’aide à la modélisation. Références Cer, D., M.-C. de Marneffe, D. Jurafsky, et C. D. Manning (2010). Parsing to stanford dependencies : Trade-offs between speed and accuracy. In 7th International Conference on Language Resources and Evaluation (LREC 2010). de Marneffe, M.-C. et C. D. Manning (2008). The stanford typed dependencies representation. In COLING 2008 Workshop on Cross-framework and Cross-domain Parser Evaluation. El Ghali, A., D. Eynard, A. Guissé, et F.-P. Servant (2010). A vocabulary for annotations. http://vocamp.org/hyvoc/annotations#. HyVoc’2010, Paris, France. Ferrucci, D. et A. Lally (2004). UIMA : An architectural approach to unstructured information processing in the corporate research environment. Natural Language Engineering 10(3/4), 327–348. Une chaîne UIMA pour l’analyse de documents de réglementation Hernandez, N., F. Poulard, S. Afantenos, M. Vernier, et J. Rocheteau (2009). Apache UIMA pour le Traitement Automatique des Langues. 16ème conférence sur le Traitement Automatique des Langues Naturelles (TALN’09) - Session Démonstration. Hernandez, N., F. Poulard, M. Vernier, et J. Rocheteau (2010). Building a French-speaking community around UIMA, gathering research, education and industrial partners, mainly in Natural Language Processing and Speech Recognizing domains. In Workshop Abstracts LREC 2010 Workshop New Challenges for NLP Frameworks, La Valleta Malta. Klein, D. et C. D. Manning (2003a). Accurate unlexicalized parsing. In Proceeding in the 41 st Meeting of the Association for Computational Linguistics, pp. 423–430. Klein, D. et C. D. Manning (2003b). Fast extract inference with a factored model for natural language parsing. In Advances in Neural Information Processing System 15 (NIPS 2002), Cambridge, MA, pp. 3–10. MIT Press. Marcus, M. P., B. Santorini, et M. A. Marcinkiewicz (1993). Building a large annotated corpus of english: the penn treebank. Computational Linguistics - Special issue on using large corpora: II 19(2), 679–696. Müller, C. et M. Strube (2006). Multi-level annotation of linguistic data with MMAX2. In S. Braun, K. Kohn, et J. Mukherjee (Eds.), Corpus Technology and Language Pedagogy: New Resources, New Tools, New Methods, pp. 197–214. Frankfurt a.M., Germany: Peter Lang. Versley, Y., S. P. Ponzetto, M. Poesio, V. Eidelman, A. Jern, J. Smith, X. Yang, et A. Moschitti (2008). Bart: A modular toolkit for coreference resolution. In Proceedings of the ACL-08: HLT Demo Session, Columbus, Ohio, pp. 9–12. Association for Computational Linguistics. om Summary This paper 7 introduce a UIMA workflow for analyzing regulation documents. This workflow rely on a dependency parser and an anaphora resolver, producing annotations that can be used to identify business rules in the text, and also facilitate the modeling process from textual documents for business experts. 7. This work has been partially funded by the FP7 EU-IST Integrated Project 2009-231875 ONTORULE.
x

Log In

or reset password

Reset Password

Enter the email address you signed up with, and we'll send a reset password email to that address

Academia © 2012