Différences

Ci-dessous, les différences entre deux révisions de la page.

--- public:specs_ajout_moteur_resolution_annotation [2017/10/25 11:51]
slh@ens-lyon.fr
+++ public:specs_ajout_moteur_resolution_annotation [2021/06/25 10:02] (Version actuelle)
matthieu.decorde@ens-lyon.fr
@@ Ligne 1: / Ligne 1: @@
-======= Ajout d'un moteur de résolution d'annotations =======
+======= Combinaison de moteurs de résolution de requêtes sur annotations =======
 ====== Objectifs ======
-Augmenter les fonctionnalités de TXM en ajoutant un nouveau moteur de résolution d'annotations.
+Augmenter les fonctionnalités de TXM en combinant des moteurs de résolution de requêtes sur annotations.
+Chaque moteur travaille sur son propre système d'annotation avec son propre langage de requête et le résultat est obtenu par combinaison des contraintes de sélection retournées par chaque moteur.
+L'intérêt pour l'utilisateur est de pouvoir utiliser les forces (potentiel, ergonomie) de chaque langage de requêtes et du moteur associé. Par exemple :
+  * CQP / CQL : rapidité d'extraction de propriétés de séquences de mots
+  * XQuery : finesse d'expression de contraintes sur les balises XML source ou pivot (gestion min/maj, accents, etc.), langage XPath de navigation dans l'arbre DOM
+  * TIGERSearch : langage de requête adapté à la syntaxe, assistant graphique de construction de requête
+  * URS
 Moteurs intégrables : TIGERSearch, XSLT, XQuery, SPARQL, SQL...
-Pour les fonctionnalités concernées :
+Fonctionnalités concernées, potentiellement toutes les fonctionnalités utilisant déjà CQL :
   * Index de sous-corpus et partition
   * Concordance
+  * etc.
-On ajoute des contraintes de sélection de positions (tokens) à l'aide du moteur supplémentaire.
+En amont, les annotations se trouvant dans les sources doivent être rapprochées au moment d'un import (il peut y avoir plusieurs import si on 'ajoute' par exemple des annotations syntaxiques TS à un corpus).
-====== Méthode ======
+En aval, les contraintes de sélection de positions (tokens) servent à unifier les sélections des différents moteurs.
+Si une requête de fait pas référence explicitement à des occurrences, il faut calculer les occurrences sous-jacentes au résultat retourné. Par exemple si on fait une requête XQuery pour construire un sous-corpus à partir de contraintes combinées sur différents niveaux de structures, il faut calculer quelles occurrences se trouvant dans les structures sélectionnées. Si ce n'est pas possible, il faudra que l'utilisateur exprime obligatoirement une requête se résolvant à des occurrences pour que le mécanisme fonctionne. Ceci peut être un premier mode de fonctionnement avant d'étendre au calcul automatique d'occurrences sous-jacentes.
+====== Solution ======
+===== Architecture des moteurs =====
+==== Architecture du code ====
+Une extension qui propose des services de recherche implémente les classes :
+  * "SearchEngine" : résout sous la forme d'une liste de "Match", une "Selection", une requête "Query" pour un corpus "CorpuBuild"
+  * "Query" : type la requête pour identifier le moteur à utiliser
+  * "Selection" : décrit une liste de "Match"
+  * "Match" : décrit un start, end et éventuellement un target
+Le SearchEngine doit être déclaré dans le fichier plugin.xml de l'extension.
+==== UI ====
+Pour pouvoir combiner l'usage simultané de plusieurs moteurs, on peut étendre les UI actuelles. Pour la zone de saisie de requête CQL actuelle, par exemple dans l'Index, cela peut donner :\\ {{:public:combinaison-de-moteurs-ui.png?600|UI de combinaison de moteurs}}
+  * A) la zone de saisie de base, composée :
+    * de la désignation du moteur de résolution concerné
+    * de la zone de saisie
+    * de contrôles de changement de taille de la zone de saisie
+    * d'ajout de requête supplémentaire
+  * B) on peut choisir à gauche le moteur de résolution correspondant à la requête saisie. Dans cet exemple on est passé du moteur CQP au moteur XQuery
+  * C) on peut augmenter ou réduire la taille de la zone de saisie. Certains langages de requêtes ont besoin d'espace pour la saisie
+  * D) on ajoute des requêtes pour combiner avec d'autres moteurs ou avec le même moteur avec un bouton [+]. Par défaut les requêtes sont combinées (&) mais peuvent être des alternatives (|). Un bouton [-] permet de supprimer une requête.
+Remarques :
+  * la possibilité D) permet d'étendre l'Index à n requêtes CQL -> il faut définir les fonctionnalités correspondantes, notamment en utilisant l'expression de l'alternative (|)
+  * l'interface d'ajout de requêtes ressemble à celle de la Progression, mais pour cette dernière il faut une double interface d'ajout (ajout de requêtes + ajout de requêtes par moteur)
+  * l'interface doit bien sûr comprendre le bouton d'accès à l'assistant de saisie de chaque moteur pour une requête donnée
+===== XSLT =====
+La plateforme TXM utilise le moteur XSLT 2 Saxon notamment dans les modules d'import XML et la macro ApplyXSL.
+L'idée est d'utiliser la transformation de la représentation XML pivot des textes d'un corpus en une liste d'id des mots des textes correspondants à une extraction donnée comme "moteur de recherche" : faisant correspondre une "requête" (une feuille XSL) à une "liste de matches" (de type CQP) interfaçable ensuite avec les commandes prenant en entrée des listes de matches CQP habituellement.
+La requête est soit :
+  * V1) un fichier XSL complet donné en paramètre ou son contenu édité dans un éditeur XML de TXM ;
+  * V2) un bout de la XSL saisi dans un champ de paramètre de macro ou de commande. La XSL est finalisée avant l'appel de la XSL ;
+  * V3) un bout de la XSL utilisant des fonctions XSL et des éléments de syntaxe XQuery (peut-être plus concis qu'une série de templates comme ci-dessus) saisi dans un champ de paramètre de macro ou de commande. La XSL est finalisée avant l'appel de la XSL ;
+La requête (XSL) s'applique soit :
+  * V1) à un fichier XML-TEI TXM de corpus binaire (contenant toutes les structures TEI d'origine + les mots avec @id et annotés) ;
+  * V2) à un répertoire 'txm' contenant les fichiers
+La XSL retourne la liste de tous les identifiants de mots correspondant à la requête d'extraction :
+  * soit sous forme XML : <matches><match><wRef id="ID1"/><wRef id="ID2"/>...</match>...<matches>
+  * soit sous forme TXT : un ID de mot par ligne
+Ensuite le contexte d'appel (une macro pour l'instant) transforme cette liste en requête CQL utilisant des ID ou des positions de mots (et donc avant il faut calculer la liste des matchs CQP équivalente ([start, end], [start, end]...), pour pouvoir faire ensuite une Concordance ou un Index.
+Dans une version ultérieure on verra comment pouvoir calculer la Concordance ou l'Index dans la foulée (voir aussi les exemples ci-dessous pour le cas TIGERSearch).
+On commence par faire une macro prototype appelée XSL2CQL :
+  * prenant comme paramètres :
+    * une sélection de corpus dans la vue Corpus ;
+    * un bout de requête XSL ou le chemin vers une feuille XSL complète
+  * retournant une CQL de sélection des mots dont la liste des IDs est retournée par la XSL
+===== TIGERSearch =====
 On s'appuie sur TIGERSearch (TS) pour démontrer la faisabilité.
@@ Ligne 75: / Ligne 149: @@
+==== Index ====
-===== Index =====
 Étant donnée la liste des terminaux matchés par TS, on fait l'intersection avec la liste des matchs du sous-corpus CQP sur lequel est construit l'index.
@@ Ligne 86: / Ligne 157: @@
 Une requête TS retourne une liste d'identifiants de mots (propriété de mot TS "id").
-==== V1 ====
+=== V1 ===
 On augmente l'extension TIGERSearch avec une version modifiée de la commande Index qui s'ouvre avec un champ de requête TIGERSearch à la place du champ CQL habituel (baguette + champ texte).
@@ Ligne 98: / Ligne 169: @@
   * si le nœud du match est un non-terminal, on utilise tous les terminaux qu'il domine. La séquence des terminaux correspondante n'est pas construite. (il faut donc, si nécessaire, faire attention aux décomptes de tokens dans l'Index dans les cas de séquences)
-==== V2 ====
+=== V2 ===
 Dans l'éditeur d'Index on ajoute des champs de recherche supplémentaires qui vont se combiner (intersection des matchs) en plus de l'intersection avec le sous-corpus à la base de l'Index : (CQL + TIGERSearch QL) + CQL sous-corpus.\\ -> (ce qui permet d'éviter d'avoir à construire des sous-corpus à durée de vie limitée)
-==== V3 ====
+=== V3 ===
 On ajoute la coloration TIGERSearch.
@@ Ligne 110: / Ligne 181: @@
 Les projections de propriétés d'objets TS (terminaux et non-terminaux) sont disponibles et mixables.
-===== Concordances =====
+==== Concordances ====
 Les principes de l'Index s'appliquent à la concordance.
-==== V1 ====
+=== V1 ===
 Correspond à KNIC 1 (concordance pivot).
-==== V2 ====
+=== V2 ===
 On peut marquer les mots non dominés de la séquence contiguë.
-==== V3 ====
+=== V3 ===
 Formes de retour au texte possibles :
@@ Ligne 132: / Ligne 203: @@
-===== TIGERSearch =====
+==== TIGERSearch ====
 Recherche de noeuds syntaxiques (terminaux ou non-terminaux) avec l'aide du moteur de résolution de requêtes syntaxiques TIGERSearch : [[https://groupes.renater.fr/wiki/txm-users/public/extensions_alpha#tigersearch]]
-===== XSLT =====
-La plateforme TXM utilise le moteur XSLT 2 Saxon notamment dans les modules d'import XML et la macro ApplyXSL.
+===== URS (Unité Relation Schema) =====
-L'idée est d'utiliser la transformation de la représentation XML pivot des textes d'un corpus en une liste d'id des mots des textes correspondants à une extraction donnée comme "moteur de recherche" : faisant correspondre une "requête" (une feuille XSL) à une "liste de matches" (de type CQP) interfaçable ensuite avec les commandes prenant en entrée des listes de matches CQP habituellement.
+Les débuts et fins des Unités correspondent exactement aux positions de mots ce qui rend l'alignement avec le corpus CQP direct. Le début d'implémentation URSQL (dans la classe AnalecUtils des macros) permet déjà de sélectionner certaines unités et de faire des intersections avec les match du corpus.
-La requête est soit :
+L'implémentation URSQL V0 ne permet pas de choisir sur quel type d'annotation (Unité ou Relation ou Schéma) la sélection se fera -> une première version ne travaillera que sur les unités.
-  * V1) un fichier XSL complet donné en paramètre ou son contenu édité dans un éditeur XML de TXM ;
-  * V2) un bout de la XSL saisi dans un champ de paramètre de macro ou de commande. La XSL est finalisée avant l'appel de la XSL ;
-  * V3) un bout de la XSL utilisant des fonctions XSL et des éléments de syntaxe XQuery (peut-être plus concis qu'une série de templates comme ci-dessus) saisi dans un champ de paramètre de macro ou de commande. La XSL est finalisée avant l'appel de la XSL ;
-La requête (XSL) s'applique soit :
+Le moteur "URS" est disponible depuis TXM 0.8.2 pour les commandes Concordances et Index.
-  * V1) à un fichier XML-TEI TXM de corpus binaire (contenant toutes les structures TEI d'origine + les mots avec @id et annotés) ;
-  * V2) à un répertoire 'txm' contenant les fichiers
-La XSL retourne la liste de tous les identifiants de mots correspondant à la requête d'extraction :
-  * soit sous forme XML : <matches><match><wRef id="ID1"/><wRef id="ID2"/>...</match>...<matches>
-  * soit sous forme TXT : un ID de mot par ligne
-Ensuite le contexte d'appel (une macro pour l'instant) transforme cette liste en requête CQL utilisant des ID ou des positions de mots (et donc avant il faut calculer la liste des matchs CQP équivalente ([start, end], [start, end]...), pour pouvoir faire ensuite une Concordance ou un Index.
-Dans une version ultérieure on verra comment pouvoir calculer la Concordance ou l'Index dans la foulée (voir aussi les exemples ci-dessous pour le cas TIGERSearch).
-On commence par faire une macro prototype appelée XSL2CQL :
-  * prenant comme paramètres :
-    * une sélection de corpus dans la vue Corpus ;
-    * un bout de requête XSL ou le chemin vers une feuille XSL complète
-  * retournant une CQL de sélection des mots dont la liste des IDs est retournée par la XSL
 ===== XQuery =====
@@ Ligne 186: / Ligne 237: @@
 ==== Étape 1 ====
-On pourrait commencer par faire une macro ApplyXQuery qui prend en paramètres :
+=== Objectif ===
+On commence par faire une macro ApplyXQuery qui prend en paramètres :
   * une sélection de corpus dans la vue Corpus
   * une sélection de chemin de script .xq, comme celui ci-dessus (il faudra penser à créer un répertoire 'xq' à côté du répertoire 'xsl' dans le répertoire $TXMHOME)
@@ Ligne 192: / Ligne 245: @@
 Et qui affiche l'output dans la console ou dans le fichier de sortie.
+=== Solution ===
+Voir une des trois [[http://www.saxonica.com/html/documentation/using%2Dxquery/api%2Dquery|API XQuery Java de SAXON]].
+Macro [[davs://sharedocs.huma-num.fr/dav.php/@Shares/(948)%20Cactus/(3780)%20Projets/Textométrie/TXM/scripts-et-macros/applyxquery|ApplyXQueryMacro.groovy]]
 ==== Étape 2 ====
@@ Ligne 272: / Ligne 331: @@
     - SRCMFMADRID1 : 1 ou 0. avec 1=présence et 0=absence
     - SRCMFMADRID2 : 1 ou 0. avec 1=présence et 0=absence
+===== URS=====
+==== V0 - TXM 0.8.2 ====
+Préparation :
+  * Activer la possibilité de choisir le moteur de résolution dans la page de préférence : TXM > Avancé > SearchEngine
+  * annoter quelques Entity avec le corpus VOEUX dans les textes 0001 et 0002
+Faire des recherches "Entity" en Concordance ou Index sur VOEUX et VOEUX/0001 (les résultats ne devraient contenir que les annotations sur le texte 0001)
 ===== XSLT =====

Le wiki de la liste txm-info

Outils pour utilisateurs

Outils du site

Différences

Outils de la page