VI.6 Module de Normalisation
VI.6.1 Implémentation des opérations de normalisation
Nous décrivons ici les outils et techniques que nous avons intégrés dans SemEx ou qui pourront être intégrés pour faciliter les opérations de normalisation.
VI.6.1.1 Niveau lexical
Nous avons vu que la normalisation lexicale (voirV.3.1.1) consiste à stabiliser le vocabulaire métier utilisé dans les règles candidates conformément à l’ontologie descriptive du vocabulaire de domaine. L’idée est d’utiliser les termes métier qui désambiguïsent au mieux le vocabu-laire utilisé dans une règle candidate donnée. Comme chaque élément conceptuel (concepts, instances, relations) est associé à une liste de termes métier pouvant le désigner, et que l’un est choisi comme terme préférentiel, il s’agit d’utiliser les termes métier les plus précis dans une
Chapitre VI. Conception et développement de la plateforme SemEx
règle candidate. Pour cela, nous considérons les annotations des règles candidates au regard de l’ontologie et nous proposons dans SemEx deux façons de procéder :
– Une façon manuelle où l’expert choisit lui-même les termes métier qu’il juge plus précis.
Ce travail est effectué à partir de l’interface d’édition qui lui propose la liste des termes métier préférentiels associés à un élément conceptuel. Ce choix est mis en œuvre à travers un système d’auto-complétion. Ici, l’expert choisit l’emplacement de l’opération (insertion ou remplacement) et la normalisation consiste à contrôler le vocabulaire ajouté.
– Une façon automatique où nous implémentons un algorithme permettant de remplacer tous les termes métier utilisés par les termes préférentiels associés à leurs concepts (ins-tances ou relations) annotateurs. Cet algorithme permet de proposer à l’expert une nor-malisation lexicale complète qu’il peut accepter ou refuser. Il est intégré au module de normalisation, interroge le module MAD et ses résultats peuvent être visualisés directe-ment sur l’interface d’édition.
Dans les deux cas, il est nécessaire d’accéder à la liste des termes métier synonymes à un terme métier qui est annoté par un élément conceptuel donné. Ces informations sont disponibles à travers le module MAD dans lequel nous avons défini une requête SPARQL (voir VI.36) qui s’applique sur la structure d’index.
PREFIX schema: <http://lipn.univ-paris13.fr/RCLN/schema#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
select ?ts where {
?ec rdf:type schema:Concept.
?ec schema:realizeConcept <un-concept-donne>.
{?ec skos:prefLabel ?ts.} UNION {?ec skos:altLabel ?ts.}
}
Figure VI.36 – Cette requête retourne la liste des termes métier synonymes ?ts (terme préférentiel en tête) qui peuvent être annotés par un concept donné ”un−concept−donne”. Nous utilisons Instance et realizeInstance pour les instances, et Relation et realizeRelation pour les relations.
L’algorithme de normalisation lexicale (voir Algorithme1) fait aussi intervenir des requêtes SPARQL. Il prend en entrée la règle candidate à normaliser ainsi que l’ensemble des termes annotés de la règle candidate. Pour chacun de ces termes, nous identifions l’élément ontologique attaché (voirVI.37) et la liste des termes synonymes associés à celui-ci (voirVI.36).Tout terme métier différent du terme préférentiel de ”elOntAnnotateur” est remplacé par ce terme dans le contenu textuel de la règle candidate.
VI.6 Module de Normalisation
PREFIX schema: <http://lipn.univ-paris13.fr/RCLN/schema#>
select ?p ?q ?ec where
{
<RC> rdf:type schema:CandidateRule.
<RC> schema:annotatedBy ?textlink.
?textlink schema:startOffset <p>.
?textlink schema:endOffset <q>.
?textlink schema:defineResource ?ec.
?ec rdf:type schema:OntologyResource.
}
Figure VI.37 – Cette requête retourne la liste des termes métier annotée dans une ”RC” donnée, notamment leurs positions (?pet ?q) dans celle-ci, ainsi que leurs éléments ontologiques (concepts, relations ou instances) annotateurs.
VI.6.1.2 Niveau contextuel
Nous avons vu que la normalisation contextuelle (voirV.3.1.2) consiste à remplacer les mots ou symboles qui ont besoin du contexte pour être interprétés par les termes métier auxquels ils renvoient. Il s’agit notamment des mots grammaticaux, des clés de référence, des relations cachées ainsi que des termes métier génériques. Le rôle du module de normalisation est alors d’aider l’expert à la fois dans l’identification du contexte d’une règle candidate dans son texte d’origine mais aussi dans le remplacement de ces mots par les termes métier exacts. Chacune des ces deux tâches peut être effectuée de façon entièrement manuelle par l’expert métier mais le module lui propose des requêtes SPARQL applicables sur le graphe RDF de la structure d’index pour déterminer le contexte d’une règle candidate. On peut aussi envisager des outils de résolution d’anaphores pour rétablir le contexte. Toutefois, dans cette thèse, nous avons mis l’accent sur la conception de la plateforme et la méthodologie d’acquisition qu’elle permet de mettre en œuvre plutôt que sur l’étude de l’impact précis des outils de TAL et leur intégration effective.
Le contexte d’une règle candidate correspond à l’ensemble des phrases nécessaires à sa compréhension. Ces phrases sont généralement sa version originale, celles qui la précédent et celles qui la suivent. Mais il peut aussi s’agir de phrases éloignées dans le texte (par exemple quand deux phrases sont dans des paragraphes différents). La requête SPARQL (VI.38) répond au premier cas, à l’aide des relations ”before” et ”after” du schéma formel de la structure d’index. Des variantes de cette requête permettent d’obtenir un nombre donné de phrases apparaissant avant et après la règle candidate dans le texte.
Chapitre VI. Conception et développement de la plateforme SemEx
Procédure Normalisation lexicale(RC : Règle Candidate, TermesAnnotés : Ta-bleau[N])
i :entier;
Pour (i←0 ; i<N ; i++)faire
tm ←TermesAnnotés[i] ;//obtenu avec VI.37
elOntAnnotateur = annotéPar (tm) ;//l’élément ontologique annotateur obtenu avec VI.37
T = liste-termes (elOntAnnotateur) ;//T = tp, ts1, ts2, ..., tsm : liste des termes métier synonymes associés à l’ ”elOntAnnotateur” obtenue avec VI.36.
Si (tm <> tp)Alors
remplacer(RC,tm,tp) ; //Remplacer tm par tp dans la règle RC Fin Si
Fin Pour Fin
Algorithme 1 – Algorithme de normalisation lexicale.
PREFIX schema: <http://lipn.univ-paris13.fr/RCLN/schema#>
select DISTINCT ?s1 ?s ?s2 where
{
?s1 rdf:type schema:Sentence.
?s2 rdf:type schema:Sentence.
<RC> rdf:type schema:CandidateRule.
?s rdf:type schema:Sentence.
?s schema:annotatedBy ?textlink.
?textlink schema:defineRule <RC>.
optional{
?s1 schema:before ?s.
}
optional{
?s2 schema:after ?s.
} }
Figure VI.38 – Requête retournant les deux phrases qui entourent une règle candidate ”RC” donnée.
VI.6 Module de Normalisation
Ainsi, actuellement dans SemEx, pour chacun des cas de contextualisation (mots gramma-ticaux, clés de référence, relations cachées ou termes métier génériques), il appartient à l’expert d’ utiliser la requête la plus adaptée pour la normalisation d’un cas donné. Si les phrases qui entourent de très près une règle candidate ne suffisent pour faire ce travail, il faut agrandir la fenêtre ou utiliser d’autres critères de structure (titres, items) afin de visualiser les phrases les plus éloignées dans les textes.
VI.6.1.3 Niveau syntaxique
Les règles candidates subissent aussi une normalisation au niveau de leur structure syn-taxique, soit pour la réordonner ou pour la simplifier, soit pour la découper en sous règles candidates (indépendantes). Il s’agit d’une tâche très délicate qui peut facilement modifier la valeur sémantique d’une règle candidate. SemEx propose à l’expert une interface d’édition qui permet de faire ou de contrôler le travail. Nous avons testé dans ce module des outils pour accompagner le travail de l’expert. Nous nous sommes inspirés des travaux de simplification textuelle qui ont utilisé des patrons de transformation. Ceux-ci permettent de proposer à l’ex-pert une normalisation syntaxique calculée automatiquement qu’il peut valider via l’interface d’édition.
Nous nous appuyons sur les patrons définis dans [Chandrasekar et al., 1996] et dans
[Chandrasekar and Srinivas, 1997]. Nous n’avons pas adapté à notre contexte interactif l’acqui-sition automatique qu’ils ont expérimentée et nous nous sommes limité à tester une définition manuelle des ces patrons.
Les patrons de normalisation sont définis et appliqués sur des règles candidates analysées syntaxiquement. Techniquement nous utilisons l’analyseur syntaxique Stanford Parser, parce que nous l’avons testé dans le module d’identification des règles candidates et que nous disposons d’outils TAL, notamment de Tregex et Tsurgeon qui sont issus du projet de Stanford11, pour traiter la sortie de cet analyseur. Tregex reconnaît des nœuds conformes à une expression régulière d’arbre, et Tsurgeon transforme un arbre en modifiant un schéma donné. Les patrons sont alors définis manuellement à partir des arbres syntaxiques de règles candidates obtenus avec le Stanford Parser. Ils sont constitués de deux parties, une prémisse qui spécifie sur quel nœud de l’arbre syntaxique une modification doit être effectuée, et une conclusion qui spécifie l’opération de normalisation que doit subir cet arbre. Ainsi Tregex permet de retrouver la prémisse sur l’arbre syntaxique de la règle candidate et Tsurgeon applique l’opération sur ce même arbre pour modifier la règle candidate.
11. http ://nlp.stanford.edu/software/
Chapitre VI. Conception et développement de la plateforme SemEx
Tous ces outils sont implémentés en Java ce qui facilite leur intégration dans SemEx.
En pratique, nous avons mis tout cela en œuvre dans le module de normalisation suivant un procédé en plusieurs étapes que nous décrivons ci-dessous :
(i) Sélection d’exemples significatifs correspondant à un ensemble de couples de règles candi-dates complexes (non normalisées et nécessitant une normalisation) et normalisées (comme les exemples cités dans V.3.1.3). Ces exemples tests sont produits manuellement dans le module et proviennent des textes réglementaires qui sont nos cas d’usage, mais d’autres exemples tirés d’autres sources ne feraient qu’enrichir la méthode.
Considérons le couple (e, e’) tiré du corpus Aadvandage :
(e) Upgrades are void if sold for cash or other consideration.
(e’) If sold for cash or other consideration then upgrades are void.
Nous montrons ci-après le résultat de l’analyse syntaxique de (e) et la manière dont un patron de normalisation est construit. Dans ce couple, le normalisation syntaxique réalise un réordonnancement de la structure d’une règle candidate ; plus précisément, au patron B If A est substituéIf A then B.
(ii) Analyse syntaxique des couples d’exemples avec Stanford Parser. Chaque règle candidate complexe est analysée ainsi que l’ensemble de ses règles candidates normalisées. Cela permet de produire un arbre syntaxique pour chaque règle candidate analysée. L’analyse syntaxique du couple donné en exemple est représentée dans les figures VI.39 etVI.40.
(iii) Définition manuelle des patrons de normalisation à partir des couples d’arbres syntaxiques issus des couples (règle candidate complexe - règle candidate normalisée). Nous pouvons définir un patron de normalisation pour chaque couple qui traduit le passage d’une règle candidate complexe vers une règle candidate normalisée. La prémisse est définie à partir d’un arbre syntaxique et la conclusion du patron est à appliquer aussi sur un arbre syn-taxique. Le plus souvent, il y a besoin de plusieurs transformations successives pour un seul patron de normalisation syntaxique d’une règle candidate. Dans la figureVI.41, nous avons défini deux transformations pour transformere ene0. Elles constituent le patronp.
La première transformation t1 permet de déplacer après la conjonction ”If” la partie de l’arbre qui vient avant celle-ci. La prémisse de t1 (voir figure VI.42) permet de pointer sur le nœud à déplacer : il s’agit du nœud SBAR, supportant la conjonction ”If” via un nœud fils IN, avec la spécification qu’il est placé sous les nœuds successifs ADJP, VP, S. La conclusion de t1 permet de déplacer ce nœud pour l’installer comme le premier des nœuds fils de S. Vient ensuite la transformation t2 (voir figure VI.43). La prémisse de