Outils pour utilisateurs

Outils du site


Action disabled: source
public:specs_commande_queryindex

QueryIndex

Objectif

L'objectif de la fonctionnalité QueryIndex est de pouvoir dénombrer facilement le nombre de Match de requêtes CQL dans un Corpus ou une Partition.

Méthode

Description de la méthode de travail pour atteindre l'objectif

État de la plateforme

Avancement dans l'élaboration de la solution

Solution

État de l'art

Éléments de solution

Prototypes

Le premier prototype prend la forme d'une extension “QueryIndex” qui rajoute une commande “QueryIndex” qui ouvre un éditeur composé d'une zone formulaire et d'une zone résultat :

Formulaire :

  • L'utilisateur rentre ses requêtes les unes après les autres à l'aide de la touche “Entrée”.
  • Chaque requête peut être labellisée pour plus de lisibilité dans le tableau résultat
  • Si le label n'est pas renseigné, la requête est affichée telle quelle
  • L'utilisateur peut importer un jeu de requête depuis un fichier TXT dont chaque ligne contient une requête nommée
    nom=requête
    #commentaire
    nom2=requete2
  • Le nombre de résultats par page est par défaut 100
  • La navigation se fait par |< < > >|
  • sont affichés : t v fmin et fmax

Résultat :

  • Est un tableau paginé
  • la première colonne est le label de la requête
  • la 2e colonne est la fréquence de la requête dans le corpus
  • Si le QueryIndex est calculé sur une partition, les colonnes suivantes sont les fréquence dans chaqu'une des parties de la partition

Les usages possibles d'un QueryIndex sont :

  • La transformation vers une table lexicale (débranché)
  • la construction d'une matrice de cooccurrence de motifs (débranché)

Retours

BP

Si on avance sur le QueryIndex, je pense que ce serait intéressant d'aller (à court/moyen/long terme ?) vers une interface unifiée avec l'index, autrement dit ne pas avoir une fonctionnalité QueryIndex en tant que telle (en plus de la fonctionnalité Index), mais une fonctionnalité Index qui, dans ses paramétrages, donne accès au QueryIndex.

Cela aurait notamment l'intérêt de s'inscrire dans une certaine tradition textométrique :

  • dans Hyperbase, cf. la fonction Liste, avec après chaque requête une double question : le résultat de la requête (i) remplace ou est ajouté à la suite des lignes déjà présentes, (ii) est groupé sur une ligne ou détaillé (autant de lignes que de valeurs différentes pour la propriété dans laquelle est exprimée la requête).
  • dans Lexico 3, on se rapproche de la notion (assez populaire) de TGen. Ce que le TGen a en plus : la facilité pour supprimer une ou qq valeurs particulières ; en moins : il me semble qu'on ne manipule jamais qu'un seul TGen à la fois, c'est un objet de requête, pas de construction de tableaux.

La mise en scène dans TXM pourrait d'ailleurs s'inspirer de ces deux existants.

Propositions SJ
  • ajouter un moyen de voir les tokens retournés par les requêtes ? Ex. requête '[word=“fa.*”]' que l'on nomme FA_ ? Pouvoir afficher la liste de résultats (“faire”, “faisant”, etc.) avant de valider la fusion. Une fois validée, pouvoir revoir la liste complète de tokens non fusionnés à partir de la liste fusionnée ? (Un simple lien vers un nouvel onglet Index “classique” avec la requête d'origine pourrait suffire ?)
  • envoyer vers spécificités ? (D'ailleurs pour l'Index “classique” aussi ?)
  • ajouter dans l'Index “classique” un clic droit sur des lignes sélectionnées ⇒ menu contextuel ⇒ “Créer une liste nommée à partir de la sélection…” ⇒ pop up avec demande de nommage de la liste ?
  • ajouter un mémo dans Index “classique” avec les noms et les contenus des listes CQP créées ?
  • ajouter un champ “description” à ces listes ?

Version finale

Documentation

Utilisateur

Développeur

Recette

Protocole de test

Alpha

Beta

État courant

Qui Quand Quoi

public/specs_commande_queryindex.txt · Dernière modification: 2015/03/27 13:03 par sebastien.jacquot@univ-fcomte.fr