Outils pour utilisateurs

Outils du site


public:specs_ajout_moteur_resolution_annotation

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
public:specs_ajout_moteur_resolution_annotation [2017/10/25 11:53]
slh@ens-lyon.fr
public:specs_ajout_moteur_resolution_annotation [2019/05/23 11:32] (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 ====== ====== 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... 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   * Index de sous-corpus et partition
   * Concordance   * 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é. 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. É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"​). 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). ​ 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)   * 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) 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. 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. 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. Les principes de l'​Index s'​appliquent à la concordance.
  
-==== V1 ====+=== V1 ===
  
 Correspond à KNIC 1 (concordance pivot). Correspond à KNIC 1 (concordance pivot).
  
-==== V2 ====+=== V2 ===
  
 On peut marquer les mots non dominés de la séquence contiguë. On peut marquer les mots non dominés de la séquence contiguë.
  
-==== V3 ====+=== V3 ===
  
 Formes de retour au texte possibles : 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]] 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 facile. Le début ​d'implémentation URSQL (dans la classe AnalecUtils ​des macrospermet ​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é/Relation/Schema) 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 : +
-  * 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'​instanttransforme 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 ===== ===== XQuery =====
Ligne 186: Ligne 235:
 ==== Étape 1 ==== ==== É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 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)   * 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 243:
  
 Et qui affiche l'​output dans la console ou dans le fichier de sortie. 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]]. 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 ==== ==== Étape 2 ====
public/specs_ajout_moteur_resolution_annotation.1508925201.txt.gz · Dernière modification: 2017/10/25 11:53 par slh@ens-lyon.fr