Outils pour utilisateurs

Outils du site


public:specs_concordance

Ceci est une ancienne révision du document !


Fonctionnalité Concordances

Objectif

Les éléments constituant toute concordance sont les suivants :

Pour chacun d'eux, on peut avoir besoin :

  • de paramétrer leur affichage
  • de paramétrer leur tri
  • de trier

Les fonctions de recherche et de sélection sont également spécifiées.

Recherche

Pour rechercher, l'UI propose plusieurs possibilités :

  • en passant par l'assistant de requêtes qui produit une requête CQL
  • en saisissant une requête CQL directement, voir en détail les possibilités de définir les limites d'une séquence d'une séquence à rechercher dans le corpus

Affichage

Tailles des colonnes

En vrac, proposer une stratégie pour répondre aux points suivants :

  • manipulation des tailles de colonnes
    • conserver ou pas. ou jusqu'à quand (par ex: réinitialiser les tailles quand la CQL à changé)
    • freezer la colonne des référence
  • taille initiale des colonnes et proportion des colonnes entres elles
  • centrage sur le pivot
  • Texte dans les colonnes :
    • alignement du texte dans les colonnes
    • coupure du texte : à gauche ou à droite

Édition (retour au texte)

Lorsque l'on double clic sur une ligne de concordance :

  • la page d'édition contenant le pivot sélectionné est affichée
  • le pivot est mis en évidence dans cette page
  • les pivots de la page courante de concordance sont mis en évidence avec une couleur plus légère

On peut déjà double-cliquer sur un autre pivot pour actualiser la page de l'éditeur d'édition ouvert.

Il serait intéressant d'avoir aussi plusieurs nouveaux boutons de navigation :

  • première occurrence
  • occurrence précédente
  • occurrence suivante
  • dernière occurrence

Il peut être intéressant aussi de ne naviguer que dans une partie des occurrences de la concordance à l'aide d'un critère. Par exemple, est annoté ou pas.

Index

Dans certains cas d'usages, par exemple quand la Concordance sert à annoter par la délimitation de ses pivots, il peut être intéressant d'avoir directement la synthèse des valeurs du pivot - dans le cas de requêtes complexes, on n'a pas à parcourir toute la Concordance pour vérifier les pivots. Ceci peut se faire par le calcul de l'Index de la requête de la concordance, en utilisant les propriétés affichées dans le pivot.

Proposition : ajouter la commande “Envoyer vers l'Index” au menu contextuel de la Concordance. Paramètres : requête, propriétés affichées du pivot.

Si la Concordance et l'Index entretiennent une relation synchrone, ce dernier pourrait se mettre à jour automatiquement en cas d'édition de la requête dans la Concordance.

Remarque 1 : la possibilité de supprimer des lignes de Concordances va rendre plus complexe cette fonctionnalité. Qui n'a pas forcément à en tenir compte dans un premier temps (elle peut rester utile même si elle ne reflète pas exactement les pivots réels de la Concordance).

Remarque 2 : si l'utilisateur commence par affiner sa requête dans un Index avant d'en lancer la Concordance, on obtient le scénario inverse. Dans ce cas la question de la relation synchrone entre l'Index et la Concordance reste pertinente.

Édition de la concordance

Suppression de lignes

Pouvoir supprimer des lignes de concordance pour faciliter la sélection, pour par exemple :

  • exporter
  • annoter

Une concordance recharge ses lignes à partir de son object “queryResult” de type “QueryResult” (requête nommée CQP) et de sa méthode “getMatches(from, to)” qui interroge directement CQP. Il faudrait être capable de retirer des matchs du résultat de la requête nommée des objets CQP.

Il existe déjà dans CQP :

  • l'opérateur “delete” qui permet de retirer des matchs d'un sous-corpus.
  • l'opérateur “diff” pour faire la différence entre un sous-corpus A et un sous-corpus B
  • des fonctions internes dans “range.c” pour manipuler les sous-corpus mais pas forcement interfacé avec CQL

Plus d'info sur CQP à la page de Documentation C pour CQP

Analyse du code pour cette problématique :

SLH:

J'ai été regarder ranges.c à partir de ma vieille SDK 0.7.2 qui "fonctionne" toujours.
La première fonction de ce fichier int delete_interval(CorpusList *cp, int nr) positionne un match d'un sous-corpus correspondant à une concordance pour la suppression (inutilisée dans CQP).
La deuxième fonction de ce fichier int delete_intervals(CorpusList *cp, Bitfield intervals, int mode) positionne des matchs d'un sous-corpus correspondant à une concordance pour la suppression. Elle utilise des bitfields pour savoir quelles lignes positionner en suppression.
Puis, plus loin, la fonction int RangeSetop(CorpusList *corpus1, RangeSetOp operation, CorpusList *corpus2, Bitfield restrictor) peut réaliser les suppressions effectives quand l'opérateur demandé est RReduce.

La fonction delete_intervals() est notamment mobilisée par la fonction supérieure do_delete_lines() de parse_actions.c, qui génère des bitfields.

do_delete_lines() est utilisée dans parser.tab.c par deux opérateurs CQL :
- do_delete_lines((yyvsp[(2) - (4)].cl), (yyvsp[(4) - (4)].field), SELECTED_LINES)
qui correspond à l'opérateur CQL 'source' (EXEC_SYM) d'après parser.l
- do_delete_lines((yyvsp[(2) - (4)].cl), (yyvsp[(4) - (4)].field), UNSELECTED_LINES)
qui correspond à l'opérateur CQL 'cut' (pour tronquer à n une liste de matchs)
D'après parser.y (le source de parser.tab.c), l'opérateur 'source' lance un do_exec() :
ExecCmd:          EXEC_SYM STRING       { do_exec($2); }
D'après parse_actions.c do_exec() n'est pas implémentée -> "The source statement is not yet supported"
(c'est sensé lire des lignes de commandes CQL dans un fichier j'imagine)
Je ne vois pas le rapport entre faire exécuter des lignes CQL et lancer un do_delete_lines()
mais de toute façon c'est un cul de sac.

do_delete_lines() est également utilisée dans parser.y par l'opérateur CQL 'delete' selon trois formes différentes :

Delete:           DELETE_SYM OptionalCID WITH_SYM FIELD
                                        {
                                          if ($2 && generate_code) {
                                            do_delete_lines($2, $4, SELECTED_LINES);
                                          }
                                        }
                | DELETE_SYM OptionalCID WITHOUT_SYM FIELD
                                        {
                                          if ($2 && generate_code) {
                                            do_delete_lines($2, $4, UNSELECTED_LINES);
                                          }
                                        }
                | DELETE_SYM OptionalCID LineRange
                                        {
                                          if ($2 && generate_code) {
                                             do_delete_lines_num($2, $3.mindist, $3.maxdist);
                                           }
                                         }
                ;

et on voit que do_delete_lines() mentionne dans ses contrôles d'arguments :
"\"delete ... with[out] match/matchend\" does not make sense."
ce qui veut dire que l'opérateur delete, associé à with ou without et match ou matchend
est capable de supprimer certains matchs d'un sous-corpus de matchs.
Bref, je propose de l'utiliser pour SUB.
On pourrait même ajouter un nouvel opérateur CQL : SUB(named-subcorpus1, named-subcorpus2) = corpus1-corpus2

Sinon j'ai trouvé dans ranges.c deux fonctions cool qui pourront nous aider plus tard :
- SortSubcorpusRandomize : pour mélanger des matchs, puis couper à n, pour échantillonner des concordances
- SortSubcorpus : pour calculer des index rapidos
Il y a des opérateurs CQP qui donnent accès à ces fonctionnalités, mais on doit également pouvoir les mobiliser en faisant appel à des fonctions supérieures.

MD:

En farfouillant la doc de CQP, je ne trouve pas vraiment ce que je veux (y'a bien dump et undump pour sauver recharger un corpus, y'a bien aussi l'opérateur diff entre 2 sous-corpus). Mon problème est que je n'arrive pas a créer de sous-corpus en donnant des positions à CQP (à part en faisant un truc du genre : undump B < ~/TXM/results/fichier.tbl généré juste avant avec une ligne par match à supprimer).


En farfouillant le code de CQP, on peut retrouver le code d'union, inter etc dans ranges.c

en pompant un peu je pourrais faire une nouvelle fonction dans CQi (ou ranges.c et CQI) :
/**
 * remove matches from a subcorpus
**/
public void remove_matches(char* corpusname, int* idxToStarts, int* idxToEnds) {
    CorpusList *corpus1 = cqi_find_corpus(corpusname);
    int i = 0;
    int j = 0;
    while (i < corpus1->size) {
     if (corpus1->range[i].start < idxToStarts[j])
            i++;
          else if (corpus1->range[i].start > idxToStarts[j])
            j++;
          else {

            if (corpus1->range[i].end == idxToEnds[j]) {
              corpus1->range[i].start = -1;
              i++;
              j++;
            }
            else {
              if (corpus1->range[i].end < idxToEnds[j])
                i++;
              else
                j++;
            }
          }
    }

    /* remove ranges marked for deletion */
    RangeSetop(corpus1, RReduce, NULL, NULL);
    touch_corpus(corpus1);
} 

Ajout/retrait de colonne

Il serait pratique de pouvoir rajouter des colonnes à la volée dans le résultat des concordances. La colonne “Annotation” est une ébauche de ce qui est possible. On peut aussi envisager d'autre colonnes :

  • référence : au lieu de concaténer les référence dans une chaine avec des “_”
  • propriété de mot : de même au lieu de concaténer les propriétés de mots du pivots (ou des colonnes de contexte), pouvoir ajouter une colonne à la suite de la colonne pivot
  • propriété de structure : à mi-chemin d'une colonne de référence et de propriété de mot, on devrait pouvoir ajouter des colonnes de propriété de structure qui éviteraient de devoir projeter des propriété de structure dans des propriétés de mots
    • La colonne annotation s'apparente à cette colonne car elle va chercher exactement des valeurs de propriétés de structures pour les lignes de concordances affichées.

Annotation

Voir plus spécifiquement les fonctionnalités d'annotation dans la section dédiée

Concordance syntaxique

L'intégration d'un moteur de recherche d'annotations syntaxiques comme TIGER Search est l'occasion d'étendre les concordances aux annotations syntaxiques.

Une première implémentation a été réalisée en scripts Groovy ou Python et en XSL et intégrée sous forme d'export au portail TXM.

Cette implémentation dispose d'un tutoriel et d'une communication à un congrès.

Clés de Tri

Si on révise l'interface de la concordance (bureau et portail), alors il faudrait essayer de prendre en compte ceci :

  • La propriété d'affichage est liée à l'affichage (elle est associée à chaque colonne de la concordance).
  • La propriété de tri (propriété d'analyse) est à associer à chaque clé de tri.

Notamment, il faudrait pouvoir trier deux fois sur la même colonne, une première fois avec une clé A, et une seconde fois avec une clé B, un autre tri pouvant s'être intercalé entre ces deux tris.

Méthode

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

État de la plateforme

Stabilisé depuis un certain temps. La spécification de fonctionnalités d'annotation à partir de la concordance est en cours, voir cette section

Avancement dans l'élaboration de la solution

Solution

État de l'art

Éléments de solution

Prototypes

Version finale

Documentation

Utilisateur

Développeur

Recette

Protocole de test

Alpha

Beta

État courant

Qui Quand Quoi

public/specs_concordance.1526544916.txt.gz · Dernière modification: 2018/05/17 10:15 par benedicte.pincemin@ens-lyon.fr