Différences

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

--- public:specs_ajout_moteur_resolution_annotation [2018/05/04 11:58]
slh@ens-lyon.fr
+++ public:specs_ajout_moteur_resolution_annotation [2019/05/23 11:32] (Version actuelle)
matthieu.decorde@ens-lyon.fr
@@ Ligne 11: / Ligne 11: @@
   * 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...
@@ Ligne 22: / Ligne 23: @@
 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 83: / Ligne 147: @@
   * à la main : en copiant les fichiers dans le binaire TXM
   * à l'aide d'une commande "Lier/Ajouter/Charger" lancé sur un corpus sélectionné dans la vue Corpus et une archive d'un corpus TIGERSearch.
-==== 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
-  * B)
-===== 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 99: / 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 111: / 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 123: / 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 145: / 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 facile. Le début d'implémentation URSQL (dans la classe AnalecUtils des macros) permet de sélectionner certaines unités et de faire des intersections avec les match du corpus.
-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 :
+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 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 =====

Le wiki de la liste txm-info

Outils pour utilisateurs

Outils du site

Différences

Outils de la page