Liste de liens :
Liste de liens :
Les éléments constituant toute concordance sont les suivants :
Pour chacun d'eux, on peut avoir besoin :
Les fonctions de recherche et de sélection sont également spécifiées.
Pour rechercher, l'UI propose plusieurs possibilités :
En vrac, proposer une stratégie pour répondre aux points suivants :
Lorsque l'on double clic sur une ligne de concordance :
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 :
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.
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.
Format des références
État de TXM 0.8.1
Les références sont construites à partir d'une sélection de propriétés de mots ou de structures et sont présentées sous la forme d'une liste de valeurs séparées par une virgule “, ”.
Pour TXM 0.8.2
Au lieu de formater en une simple liste, l'utilisateur pourrait exprimer le format d'affichage souhaité en s'appuyant sur un patron du type “%s: %s” où les valeurs sont injectés par un sprintf à la C (sprintf est intégré à Java sous la forme d'un Formatter).
L'interface de réglage de l'affichage des références de concordance évoluerait alors avec l'ajout d'un champ texte
Format [_____________]
:
Le corpus peut définir une référence par défaut avec :
Pouvoir supprimer des lignes de concordance pour faciliter la sélection, pour par exemple :
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 :
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); }
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 :
Voir plus spécifiquement les fonctionnalités d'annotation dans la section dédiée
L'intégration d'un moteur de recherche d'annotations syntaxiques comme TIGER Search est l'occasion d'étendre les concordances aux annotations syntaxiques :
Un premier prototype a été réalisé 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.
Il faudrait discuter le prototype KNIC pour définir une première cible pour l'ANR Profiterole.
Améliorer l'interface actuel des tris multiple
Éléments/moments d'UI :
A) Créer une clé : dans une boite de dialogue avec 3 champs
B) Choisir et ordonner les clés : fenêtre de dialogue actuelle de sélection multiple ordonnée
C) lancer le tri
[BP] Si on révise l'interface de la concordance (bureau et portail), alors il faudrait essayer de prendre en compte ceci :
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.
[SLH] j'ai du mal à comprendre la proposition de BP, du coup j'exprime ce que je comprends :
[MD] proposition d'interface (en cours de rédac)
Par défaut le tri de la concordance est le tri du corpus (= tri dans l'ordre des positions des mots). Il y a une seule clé.
[ corpus |↓|…|▼] (-) (+) [tri]
UI générale :
UI d'une clé :
Description de la méthode de travail pour atteindre l'objectif
Stabilisé depuis un certain temps. La spécification de fonctionnalités d'annotation à partir de la concordance est en cours, voir cette section
Éléments de solution
Qui Quand Quoi