Vous pouvez ajouter ici toute proposition d'amélioration et d'évolution de la plateforme TXM. Une structuration est proposée. N'hésitez pas à la modifier si besoin.

Générales

  • Appeler la graphie “graphie” ou “forme” plutôt que “word”.
  • Indiquer clairement le volume global des résultats de chaque requête.
  • filtre de mots (“mots vides”, ponctuations…) ? cf. Bédécarrats sur txm-users 19/10/2011 : “On pourrait réfléchir à en avoir une “bibliothèque” de listes de terme à exclure dans TXM (sur un modèle similaire aux modèles Treetagger qu'on utilise lors de l'import) que les utilisateurs pourraient choisir d'utiliser le cas échéant. L'idéal serait que chacun puisse créer, mémoriser et échanger ses propres listes. J'ai trouvé mention de quelque chose s'en rapprochant dans le descriptif d'un package de R (p. 16 http://cran.r-project.org/web/packages/lsa/lsa.pdf). Peut-être est-ce que ce n'est pas trop compliqué à mettre en oeuvre, à vous de juger.”

Vue Corpus

  • ne pas multiplier les entrées dans l'arborescence dès qu'on modifie la requête.
  • ordre pas clair
    • à l'intérieur d'un corpus, l'ordre actuel est : partitions, sous-corpus, résultats, chacun des sous-groupes est trié par date de création)
    • entre les corpus, l'ordre est celui de la chronologie de l'import ou du chargement du corpus, sauf que quand on installe une nouvelle version de TXM l'ordre change et n'est pas clair (ce n'est ni chronologique, ni alphabétique). Ce qui serait bien, c'est d'avoir par défaut un ordre chronologique, qu'on puisse éditer et modifier cet ordre, et que cet ordre soit maintenu dans la récupération des corpus par une nouvelle version.
  • Pouvoir renommer un corpus, un sous-corpus ou une partition
  • Pour chaque objet (corpus, partition, sous-corpus, résultat), avoir la possibilité d'éditer et de consulter une description libre, et de consulter une description automatique (quels paramètres utilisés pour la création de cet objet, date de création) (voire possibilité d'éditer une nouvelle instance de la description automatique pour relancer la création d'un nouvel objet à partir de la modification d'un objet déjà créé ; voire aussi sauvegarder les paramètres pour pouvoir relancer le calcul dans une autre session.)
  • Lors de la suppression d'un corpus, permettre à l'utilisateur de choisir de supprimer le corpus dans la vue et de façon optionnelle, avec une case à cocher par exemple, de supprimer le binaire associé. (SJ : à la suppression d'un corpus proposer les éléments que l'on veut exporter avant la suppression puis supprimer les binaires mais également les .svg, etc. ? A ce propos les .svg devraient peut-être être nommés plus explicitement et stockés dans les répertoires de leurs corpus respectifs ?)
  • visualiser/organiser la succession de résultats par un 'chemin de fer' montrant le parcours interprétatif

Graphiques

  • ce serait bien de pouvoir iconifier les graphiques dans une vue spécialisée pour les graphiques
  • cette vue contiendrait les icones des graphiques et le détail en flyover ou en légende
  • elle serait affichable aussi sous forme de lignes détaillées
  • elle serait triable par date de création ou par d'autres propriétés
  • en fait ça aurait les fonctionnalités d'explorateurs comme Windows ou Linux
  • les différents types de résultats (Index, Concordances, etc.) gagneraient à être iconifiés dans des vues spécialisées - pour s'y retrouver quand on en a beaucoup
  • ou/et : une Vue type explorateur sur les résultats. Colonnes (triables) : commande, nom, chemin, autres paramètres (focus, propriété…), tableau/graphique, date, etc.

Vue Fichier

  • Rajouter la commande “Renommer” dans le menu contextuel.

Défauts

  • Expliciter l'ordre de tri par défaut

Interface utilisateur

  • Pouvoir agrandir la taille des caractères
  • Pouvoir figer des colonnes de tableau (typiquement la 1ère)
  • Pouvoir réordonner des colonnes de tableau
  • Généraliser l'affichage des paramètres du calcul dans le flyover d'un onglet résultats (par ex. cela manque pour l'AFC).
  • Pouvoir mettre en évidence les mots dans un résultat (comme une concordance) ou une page d'édition à partir de ses propriétés. Pour cela, utiliser une table de correspondance éditable facilement mettant en relation des combinaisons de valeurs de propriétés de mots (des CQL) et un style de rendu correspondant (mise en gras, italique, couleur particulière, ne pas afficher - remplacer par des blancs ou rien - etc.). [BP : Noter que cette fonctionnalité a des éléments en commun avec celle des “zones” pour la concordance ou l'index.]

Navigation hypertexte

  • Prendre comme focus non pas simplement la valeur sur la ligne, mais aussi les conditions imposées par la requête CQL. Exemple sur le retour aux concordances depuis un index : c'est un peu perdant de partir d'un mot indexé précis (ex. Lyon encodé en placeName) et de faire un retour aux concordances qui renvoie à une recherche appauvrie : Lyon en tant que forme graphique. La requête qui correspond à une ligne de l'index devrait croiser la valeur de la propriété d'analyse correspondant à la ligne et la requête initiale. C'est assez délicat à implémenter parce que ça pourrait générer assez facilement des requêtes fausses. Peut-être qu'on saurait le faire sans trop de difficulté pour une requête ne portant que sur une position : [nouvelles_contraintes] = [anciennes_contraintes & ancienne_propriété_analyse=valeur_sur_la_ligne_sélectionnée]. Sur plusieurs positions, il faudrait solliciter l'aide de l'utilisateur ?? Mais c'est vrai que cette navigation hypertexte plus précise correspond à un besoin, le fonctionnement simplifié actuel étant contre-intuitif (on est obligé de bien prévenir les utilisateurs).
    • SH (2013-06-17) : actuellement le lien hypertexte d'une entrée de liste de résultats d'Index vers sa Concordance est réalisé à partir d'informations propres à cette entrée - mais partielles - car la CQL à l'origine de la liste n'est pas utilisée. Il s'ensuit une CQL sous contrainte qui produit une concordance plus générale que celle qui combinerait la CQL d'origine contrainte avec les informations correspondant à l'entrée de la liste des résultats. En attendant de pouvoir combiner la CQL d'origine avec des contraintes supplémentaires, il faut 1) documenter le comportement - limité - actuel 2) faire en sorte que l'utilisateur en soit conscient.

Exports

  • Les boites de dialogue d'export tableau et graphique doivent mettre une extension au fichier sauvegardé si l'utilisateur n'en a pas mis
  • Avoir un contenu identique au résultat visualisé dans TXM :
    • format des nombres
    • colonnes, avec leur intitulé et dans le même ordre
    • tri (ordre des lignes)
    • filtrage des lignes (ex. Vmax)
  • Minimiser le nombre d'opérations à faire pour que le fichier créé par l'export s'ouvre bien dans un tableur (actuellement il y a pas mal de paramètres à revoir, sous OpenOfficeCalc par exemple il faut sélectionner le séparateur tab et tab uniquement, changer ce qui concerne les guillemets, typer les colonnes de spécifs en US pour ne pas avoir de nombres interprétés comme des dates, pouvoir paramétrer le séparateur de décimale (virgule ou point))
    • MD (2012-10-01) : Nous allons opter pour le format TSV avec l'encodage Unicode UTF-8 pour tous les exports pour RCP et WEB
  • Export de corpus : pouvoir choisir quels fichiers exporter
    • AL (2012-10-16) : par défaut, il faut exporter uniquement les dossiers nécessaires pour un corpus binaire. Pourquoi pas ajouter une fonctionnalité (ou une préférence) “Optimiser le corpus binaire”. Ça peut sauver pas mal de place sur le disque
  • Export de corpus : sous-corpus et partitions
    • AL (2013-03-06) : Actuellement, pour qu'un corpus binaire exporté contienne des sous-corpus et des partitions, il est nécessaire de fermer et de rouvrir TXM après les avoir créé et avant de faire l'export. Il faudrait que le fichier “import.xml” soit actualisé et enregistré au moment où on fait l'export de corpus
  • pouvoir exporter les métadonnées des textes d'un corpus dans un CSV (pratique quand la source est XML) → peut-être depuis la fonction Description, cf. cette section.

Corpus mutable

  • correction d'annotations
  • ajout d'annotations

Environnement de travail

  • pouvoir enregistrer et réouvrir une session de travail
  • enregistrement systématique de toutes les commandes avec leurs paramètres et des indications de contexte (ex. date&heure), pour pouvoir les retrouver et les relancer.
  • pour les corpus, état ouvert (= disponible) ou fermé (= archive minimisant les ressources consommées, par exemple au moment du démarrage les partitions et sous-corpus ne sont pas construits).

Initialisation

(SLH 2013-01-03)

  • lancer un script Groovy prédéfini au démarrage de TXM : par exemple 'startup.groovy' éditable par l'utilisateur.
    • ce script peut servir à réaliser tout type de réglages personnalisés : paramètres par défaut, réglages d'interface, raccourcis clavier personnels, ménage dans les sous-corpus…
      • c'est un lieu privilégié d'exposition de l'API de la toolbox
      • il pourrait également être le lieu de choix des plugins à charger dans la plateforme (comme pour le fichier de démarrage '.emacs')
    • ajouter une option de lancement de TXM 'sans exécution du script de démarrage' (pour palier les bugs potentiels du script de démarrage)
  • lancer un script Groovy prédéfini à la fermeture de TXM : par exemple 'shutdown.groovy' éditable par l'utilisateur (moins prioritaire).
    • ce script peut servir à réaliser tout type de travaux personnalisés (sauvegarde de résultats, ménage dans les sous-corpus…)
  • ajouter un paramètre de lancement de TXM permettant d'exécuter un script Groovy (au lancement)
    • cela peut aider les installations en masse sur parc de PCs

Commandes

Informations

  • pouvoir afficher toutes les métadonnées des textes du corpus et les exporter (CSV et R)
  • pour les sous-corpus, avoir aussi une description des structures (comme pour les corpus)

(GL 2013-12-18)

  • le compte-rendu de la commande Information (Description - Dimensions) pourrait être complété, outre le nombre d'occurrences, par : vocabulaire, nombre d'hapax, fréquence maximale, etc.
  • ceci pourrait être répété pour les sous-corpus et partitions définis sur le corpus

Edition

  • page de garde (p.0) pour les métadonnées
  • Accès direct à une structure (texte), ou/et :
  • avoir une vue sommaire : on choisi les structures et propriétés qui la construisent, c'est une arborescence que l'on déplie, en cliquant sur une structure à n'importe quel niveau on a un accès direct à la page de l'édition correspondante, ou à la vue interne à ce point-là du corpus. Lorsque l'on navigue dans l'édition, le point correspondant est dynamiquement mis en évidence dans la vue structure (de la sorte on a une indication de la localisation de la page qu'on est en train de visualiser).
  • histogramme marginal lié à la fonctionnalité de recherche d'un motif dans l'édition.
  • pouvoir visualiser les structures textuelles intermédiaires dans l'édition
  • Transcriber :
    • sections :
      • commencer chaque section sur une nouvelle page, avec une titre : Section n°N : thème de la section
      • avoir en page 0 un sommaire des sections permettant un accès direct à une section donnée
    • indices de temps :
      • de la forme MM:SS pour les temps inférieurs à 1h, ex. 00:03, 04:00, 37:10
      • de la forme H+:MM:SS pour les temps supérieurs à 1h, ex. 2:05:02, 11:17:36, 102:56:03.
    • avoir dans une propriété de u un temps noté de la même forme que le temps vu dans l'édition, ce serait commode pour l'affichage des références ou la recherche d'occurrences.
    • homogénéiser l'édition des marquages alternatifs par notation et par balise :
      • ^^ et lex=^^orthographe incertaine
      • astérisque et pron=*prononciation erronée
  • allumer des mots ou des occurrences de CQL dans une page d'édition par glisser-déposer lexique-index/édition

Vue interne

  • pouvoir l'exporter
  • avoir un accès ± direct (vs séquentiel) sur une structure qui ne soit pas la première :
    • interface de navigation dans l'arborescence des structures ;
    • liens hypertextes, notamment depuis la concordance et depuis l'édition (cf. point sur les hyperliens ci-après).
  • Ajouter des hyperliens
    • depuis la Vue interne :
      • double-clic sur une ligne → édition de la page HTML et mise en évidence de l'occurrence ; quand l'édition est déjà ouverte (au dessus par exemple), on se déplace dedans.
      • menu contextuel
        • ouvrir édition (avec focus sur l'occurrence)
        • index de la propriété correspondant à la colonne
        • concordance de la valeur de la propriété correspondant à la colonne
        • export
    • depuis la concordance : Un double-clic de ligne de concordance peut aller vers la page d'édition avec mise en évidence OU vers la phrase de navigation avec mise en évidence (une option permet de régler le choix édition/navigation, à partir de la concordance).
    • depuis l'édition : menu contextuel → ouverture de la phrase dans la vue interne avec mise en évidence de l'occurrence située sous la souris
    • autre navigation : ce serait bien d'offrir aussi une navigation à travers la liste des occurrences d'un match (comme ce qui est déjà fait pour

l'édition HTML du portail). Par exemple à partir d'un Index par menu contextuel. [à préciser]

  • Ce serait bien d'afficher le “chemin XML” des balises parentes jusqu'à celle de la structure affichée.

Lexique

  • numéroter les lignes
  • dans l'interface, en haut à droite renommer “Propriétés” en “Affichage”.
  • avoir un accès direct à la page contenant un rang, une fréquence, une forme
  • ajout d'une colonne avec le % cumulé (fréquence relative x100 de l'ensemble des occurrences correspondant aux lignes pour lesquelles la fréquence est supérieure ou égale à la ligne considérée. Rq. : cette valeur est donc la même pour toutes les lignes où la fréquence est identique).
  • pouvoir construire un lexique sur une structure, pour une propriété donnée : on liste alors les valeurs prises par cette propriété, et le nombre d'occurrences de la structure (et non pas de mots dans la structure) pour chacune des valeurs. Prévoir le cas où la propriété n'est pas définie.

Sous-corpus

  • lorsque le corpus est issu de l'interrogation d'une base (ex. europress), il serait utile de pouvoir facilement retirer les textes non pertinents : création d'une sorte de sous-corpus dynamique dont on pourrait retirer des textes à tout moment ? interface aidant à parcourir les textes et à indiquer les non pertinents à retirer du sous-corpus ?
  • revoir l'assistant de création de sous-corpus (OU implicite entre différentes valeurs d'une même propriété, ET entre différentes propriétés)

Partition

Création d'une partition

  • gestionnaire de propriétés : en fait plus général que partitions, mais utile tout particulièrement pour créer des partitions en croisant des propriétés.
  • Pouvoir ordonner les parties d'une partition, par exemple par une propriété de structure (du même niveau ou de niveau supérieur à celle qui a servi à construire la partition)
  • Mode assisté : l'interface n'est pas adaptée si on a besoin de + de 20 parties, voire même simplement d'une dizaine.
  • Mode assisté : avoir un moteur de recherche pour sélectionner des valeurs à affecter.

Edition d'une partition

  • Aperçus des N premiers mots des parties d'une partition (ou : revoir édition d'une partition)

Dimensions d'une partition

  • avoir l'indication du nombre de mots de chaque partie
  • pouvoir exporter une table donnant le nombre de mots et le nombre de textes par partie (en plus du graphique de l'histogramme)

Requête

  • Revoir l'assistant de requête :
    • pouvoir supprimer une occurrence de mot
    • ajouter une checkbox pour la casse et les diacritiques
    • (possibilité d'exprimer un mot sans contraintes ([]))
    • liste des valeurs possibles ?
  • Pouvoir écrire une requête sur plusieurs lignes
  • Pouvoir paramétrer la stratégie de résolution (MatchingStrategy) depuis l'interface de TXM, et avec prise d'effet immédiate (sans redémarrage de session) ; attention cependant aux interférences avec les sous-corpus et partitions au démarrage d'une session.
  • Pouvoir faire des requêtes XPath sur les sources XML-TEI P5 TXM avec un scénario identique à celui du moteur Tiger Search
  • Pouvoir faire des requêtes XQuery sur les sources XML-TEI P5 TXM avec un scénario identique à celui du moteur Tiger Search

Index

  • dans l'interface, à droite du champ de recherche renommer “Propriétés” en “Affichage”.
  • dans les propriétés disponibles pour l'analyse/affichage, avoir également des propriétés de structure (option -par défaut on ne les voit pas). Une ligne spéciale est à prévoir pour les occurrences hors de la structure, et une pour les occurrences dans la structure mais pour lesquelles la propriété n'a pas de valeur définie.
  • possibilité d'avoir plusieurs colonnes si on a sélectionné plusieurs propriétés
  • visualisations graphiques : treemap, nuage de mots… Une treemap peut être à plusieurs niveaux d'emboîtement si les valeurs d'unités sont hiérarchiques (ex. pos).
  • sur un index de partition, avoir (en option ?) une colonne après celle des fréquences totales avec un indice de dispersion, à savoir le nombre de parties contenant le mot (une sort de “fréquence en textes/parties”). Avoir la possibilité de filtrer (en min et max) sur cet indice, et de faire les tris multiples Dispersion puis Fréquence (ou en d'autres termes Fréquence en textes puis Fréquence en mots) et également Fréquence puis Dispersion.
    • MD : je propose que cette fonctionnalité prenne la forme, dans un premier temps, d'un script groovy qui utilise la table lexicale ou index en cours de sélection dans la vue Corpus pour calculer pour chaque ligne de la table l'indice de répartition.
  • GL : Les erreurs de syntaxe dans une requête CQL ne sont pas toujours détectées. Exemple : [word=”?”] ne retourne aucun résultat. Dans d'autres cas, une erreur Java est retournée.

Table lexicale

  • améliorer l'ergonomie de la sauvegarde de table lexicale
  • éventuelles options pour sauver les tables ou au moins l'environnement R au moment de quitter TXM
  • dupliquer une table lexicale
  • clic sur entête de colonne = sélection (pour suppression par exemple)
  • pouvoir explicitement trier les lignes selon l'ordre d'apparition des mots dans le corpus (par exemple pour observer les mots qui apparaissent pour la première fois dans chacune des parties).

Concordances

  • dans l'interface, à droite du champ de recherche renommer “Pivot” en “Affichage”.
  • zones
  • Pouvoir créer un sous-corpus à partir du résultat d'une concordance [Rq. on peut déjà le faire “à la main”, en construisant un sous-corpus avancé avec comme requête celle du pivot + un expand to ou un nombre de [] correspondant à la taille du contexte ; la demande de fonctionnalité concerne donc une aide à la création automatique du sous-corpus]
  • Pouvoir ignorer les ponctuations dans le tri (à généraliser avec la notion de corpus actif ?)
  • Lien vers la Progression, pour visualiser la position des occurrences dans le déroulement du corpus
  • Lien vers les Références, pour avoir une vue synthétique de la répartition des occurrences dans le corpus, notamment pour des corpus n'ayant pas une organisation linéaire (et pour lesquels la visualisation en Progression est inadaptée).
  • Lien vers l'index (index du pivot avec la même propriété d'affichage) et synchronisation entre les lignes de l'index et celles de la concordance (double-clic sur une ligne de l'index → positionnement de la concordance sur la première occurrence correspondante, mise en valeur typographiquement).
  • retours réunion GGHF octobre 2010 :
    • pouvoir supprimer des lignes de concordances ;
  • Pouvoir réimporter un export de concordance

Spécificités

  • retours réunion GGHF octobre 2010 : la littérature de diachronie fait usage de diagrammes à barres avec usage de couleurs pour les proportions. Les barres peuvent être verticales, ou horizontales pour les proportions. (cf dictionnaires de D. Biber). [A préciser.]
  • avoir non seulement une indication de la fréquence du mot dans la partie, mais aussi du nb de textes où est présent le mot dans la partie (qu'on peut appeler par exemple dispersion), ainsi que la proportion de ces textes dans la partie (%dispersion ou dispersion relative). En effet, dans les corpus pas très grands (ex. enquêtes auprès de qq dizaines de personnes, collection de qq dizaines de textes), un mot spécifique à une partie peut en fait être propre à un seul texte, pour des raisons thématiques ou idiosyncrasiques.
  • retour au texte : un clic sur une fréquence f (celle d'un mot dans une partie) conduit à une concordance des occurrences du mot dans la partie.
  • construction de différentes tables à partir du tableau des spécificités :
    • tableau du vocabulaire de base : sélection de toutes les lignes pour lesquelles le score de spécificité reste toujours en deçà d'un seuil donné, ajout d'une colonne avec l'indication du score maximal atteint et l'indication du score moyen.
    • tableau du vocabulaire spécifique : sélection de toutes les lignes comprenant au moins un score de spécificité supérieur à un seuil donné (+ conditions éventuelles sur les dispersions, ex. dispersion >1 ou %dispersion >40) ou/et des lignes faisant partie des N lignes les plus spécifiques pour au moins une partie (sans compter les lignes avec une dispersion insuffisante) ; peut-être seuillage possible aussi sur la fréquence
  • représentation alternative des résultats du type de celle du portail TXM (listes des mots spécifiques pour chaque partie) (avec éventuellement des filtrages un peu fins comme ci-dessus, réglables dans les préférences).
  • gestion du dépassement des capacités de représentation :
    • distinguer typographiquement la valeur symbolique donnée au max
  • indiquer la p-value correspondant à une spécificité ? ou/et aider à la percevoir derrière les scores de spécificité (qui sont le Log de la probabilité)
  • affichage alternatif en fréquences relatives (revoir alors le nom de la fonction, ou réorganiser, par exemple avec une métafonction Distribution qui se scinde en Spécificités et Fréquences ?). Plus généralement, faire de la mesure un paramètre et implémenter une sélection de mesures populaires (écart-réduit, etc.)
  • aide au repérage et à la fusion contrôlée de lignes avec des profils analogues (avec par ex. : des lignes ont des profils analogues si pour chacune des colonnes soit leurs spécificités sont toutes positives, soit elles sont toutes négatives, soit elles sont toutes strictement inférieures à 3 en valeur absolue).
  • pouvoir contraster deux corpus ? (à préciser)
  • tris multiples dans le tableau de résultats
  • avoir une représentation graphique de la distribution et la position du point concerné dans cette distribution (cf. weblex)
  • pouvoir calculer la spécificité pour quatre valeurs données (f,F,t,T).

Cooccurrences

  • n'afficher que les cooccurrents avec un score positif ; permettre l'affichage des cooccurrents négatifs par un réglage dans les préférences (par défaut, pas d'affichage des cooccurrents négatifs).
  • affichage pour chaque cooccurrent de deux diagrammes en bâtons montrant la distribution de l'effectif syntagmatiquement. Histogramme 1 : global : le contexte est divisé en 10 tranches. Histogramme 2 : local : 10 mots avant et 10 mots après.
  • Possibilité de filtrage des cooccurrents par une équation CQL. En revanche, s'agit-il d'un filtrage amont (corpus actif) ou aval (focalisation), c'est à réfléchir.
  • Affichage en graphe (récursif)

Cooccurrences mots-mots

Analyse Factorielle des Correspondances

  • exporter non seulement le graphe mais aussi les tableaux de l'AFC (tableau affiché au format csv ou fichier de sortie factomineR : cela peut être une option dans les préférences)
  • pouvoir changer l'échelle des axes (grosso modo, il s'agit d'avoir un “vrai zoom” dans le graphique : zoomer doit permettre d'agrandir la distance entre les points pour mieux voir les positions dans le détail, actuellement le zoom grossit tout en même temps -la taille/diamètre des points eux-mêmes, les chaînes de caractères étiquetant les points, etc.- donc n'apporte pas grand'chose)
  • pouvoir retourner un axe (au sens d'échanger les coordonnées négatives et positives)
  • lien entre les tableaux d'informations et le graphique
    • clic sur une ligne → sélection de la ligne et mise en évidence du point correspondant
    • clic sur un point → sélection mettant en évidence la ligne correspondante, tout en basculant au passage sur l'onglet correspondant (ex. si point colonne alors affichage dans la partie des tableaux de l'onglet Infos colonnes)
  • double-clic sur un point :
    • point colonne : affichage d'un tableau des lignes les plus spécifiques
    • point ligne : affichage d'un tableau des colonnes les plus spécifiques
    • Rq. pouvoir fermer/ouvrir facilement des tableaux de spécificités à comparer entre eux
  • la sélection de points (dans le graphique) ou de lignes (dans un tableau) peut être multiple (ctrl ; dans le tableau : shift aussi ; dans le graphe : aussi sélection par rectangle ou lasso) et elle donne accès à un menu contextuel avec les commandes suivantes :
    • pour les colonnes seulement :
      • création du sous-corpus correspondant et calcul des spécificités de ce sous-corpus
      • informations : tableau des métadonnées dont les colonnes sont choisies par un paramètre
    • pour tous (lignes ou colonnes) :
      • passer en élément supplémentaire
      • supprimer
  • filtrage des points qui ont, dans le plan courant, une qualité inférieure à un certain seuil (le filtrage consiste à simplement ne plus afficher, ce n'est pas une suppression qui relancerait le calcul)
  • afficher des labels ou autres informations supplémentaires de points par survol avec la souris
  • coloriage des axes et des points pour mettre en évidence les principales contributions
  • pouvoir relier un point à ses N plus proches voisins dans l'espace entier : entrée supplémentaire dans le menu contextuel de sélection de points ou/et activation d'une propriété de l'affichage qui fait que quand on survole un point on le relie à ses plus proches voisins.
  • vue géodésique (Viprey)
  • AFC sur cooccurrences (Viprey)
  • zooms, séquences dynamiques, etc. (Leblanc)
  • prévoir la possibilité de mettre des éléments en “supplémentaires”, soit par un choix manuel, soit par filtrage;

Progression

  • Il serait très utile de pouvoir choisir l'ordre dans lequel sont prises en compte les occurrences des divers éléments du corpus : pour le moment, on n'a que l'ordre d'enregistrement de départ ; on aimerait bien pouvoir choisir un des champs définissant ces éléments (si par exemple on a des champs date ou période).
  • Pouvoir demander une progression sur un sous-corpus.
  • Affichage en courbe du nombre d'occurrences dans des tranches de tailles égales (nombre de tranches fixé par défaut en fonction du confort d'affichage et réglable dans les préférences). Si on affiche une structure, alors la frontière des tranches coupées par la structure pourrait être déplacée à la frontière de la structure, et un facteur correctif visualisable pour les fréquences dans les deux tranches modifiées.
    • Dans ce mode, affichage simultané et synchronisé sur deux échelles ou trois échelles (échelle fixée par défaut en fonction du confort d'affichage et réglable dans les préférences).
  • Proposer aussi une solution pour la comparaison de l'évolution de motifs dont la fréquence n'est pas du même ordre de grandeur.
  • Lien hypertexte, d'un point sur une courbe au passage textuel correspondant dans l'édition (avec mise en évidence des occurrences éventuelles correspondant à la courbe).

Macros

  • Afficher les macros disponibles dans le menu principal. Ce menu est créé dynamiquement à partir des macros existantes dans le répertoire de macros.

Imports

  • Pouvoir associer une feuille CSS aux éditions produites par les modules d'import en plus d'une feuille CSS par défaut pour chaque module.
  • Pouvoir activer ou non le segmenteur de phrase.
  • ajouter une sélection des fichiers à importer en plus de la sélection par dossier
  • ajouter l'option d'import qui permet d'importer un ensemble de textes en un seul fichier (corpus en un répertoire / corpus en un fichier).
    • dans le cas du module XML/w+CSV, il s'agirait d'ajouter dans les paramètres d'import :
      1. une option exclusive 'corpus en un répertoire (défaut) / corpus en un fichier', dont la seconde option ouvrirait
      2. une option 'xpath de sélection de chaque texte au sein du fichier' (typiquement un élément 'TEI')
      • cette option ferait qu'il y aurait une phase préalable de découpage du xml en autant de fichiers xml que nécessaire, puis lancement des phases d'import ultérieures habituelles (avec un petit réglage pour désigner facilement les métadonnées “à la mode BFM”)
    • dans le cas du module TXT+CSV, il s'agirait d'ajouter dans les paramètres d'import :
      1. une option exclusive 'corpus en un répertoire / corpus en un fichier', dont la seconde option ouvrirait
      2. une option 'regexp de recherche des lignes de délimitation des textes au sein du fichier' (typiquement les lignes étoilées à la Alceste)
        • cette option serait secondée par une autre à sélection exclusive : ligne de délimitation en début de texte (défaut) / ligne de délimitation en fin de texte
        • et une autre : garder la ligne de délimitation dans le texte importé : oui (défaut) / non
  • ajouter une option d'import de type 'définition du hors texte'
    • dans le cas du module XML/w+CSV par exemple, il s'agirait d'ajouter dans les paramètres d'import :
      • une option qui demanderait une liste (extensible) de xpaths de ce qu'il faut retirer de la source avant de la traiter (pour neutraliser les <TEIheader> et <note> par exemple)
  • au moment d'un import ou d'un chargement, on enregistre des informations permettant de garder une trace de la source du corpus produit et des paramètres d'import (cf. fichier import.xml ajouté dans le répertoire source) ; ce qu'on peut encore souhaiter :
    • dans les informations “automatiques” : ajouter l'heure/minutes/secondes
    • pour la zone de commentaire libre : la préremplir dans le formulaire si un import précédent a déjà été fait : en effet, le commentaire est censé changer mais souvent en reprenant une base commune et en ajoutant une précision.

(SLH 2012-11-02)

  • reconcevoir la structure de persistance dense au niveau de l'unité textuelle (relation texte / édition / fiche / page / mot)
  • utiliser la description du corpus fournie à l'import dans la fonctionnalité “Informations”
  • tout import doit construire une fiche bibliographique du corpus qui comprend :
    • la description
    • la version de TXM (et éventuellement du format de corpus binaire)
    • la date de création du corpus (et éventuellement le nom/login de la personne l'ayant créé)
    • la sortie de la fonction “informations”
  • les fiches de textes et les fiches de corpus sont construits au même moment et avec les mêmes outils

(LBe 2012-11-14)

  • proposer un loader TEI-All ou au moins TEI-Lite
  • en fonction du loader choisi, avoir une étape de validation (sur la base d'un RNG ou DTD ? donc une DTD BFM par exemple) qui listerait les balises à nettoyer : ex, <persName> n'est pas permis > import impossible. Ce qui permettrait de construire intelligemment son filtre XSL.
  • générer un ODD en fonction du corpus importé (vu que le pack tei est là)

Préparation de corpus

  • créer un script/macro simple de transformation TXT → XML : & → &amp, < → &lt;, préambule XML, balise début, balise fin, changement extension de fichier en '.xml'

Tokenization

  • normaliser les apostrophes en ”'” et le rendre optionnel (par défaut la normalisation est active)
  • Gestion des majuscules : intégrer une partie de la chaine de traitement de post tokenization de Charles Minc ?

TreeTagger

  • Pourvoir paramétrer par texte la langue à utiliser. En rajoutant une colonne “lang” dans le fichier metadata.csv
  • Pouvoir appliquer plusieurs fois TreeTagger lors d'un import. (proposition : en mettant plusieurs langue dans le paramèter “lang” du fichier metadata.csv.
  • Remplacer les '@card@' de TT par la forme du nombre (optionnel)

Import TXT+CSV

  • il faudrait ajouter (en annexe par exemple) dans la doc de la version 0.5 quelques exemples de fichiers de métadonnées (metadata.csv). Par exemple en s'appuyant sur DISCOURS et en faisant comme si ce corpus était au départ un dossier de fichiers texte brut, comment devrait se présenter le fichier metadata.csv pour obtenir la structuration accessible dans la version téléchargeable de TXM_0.5 ? En bref, cela reviendrait à enrichir la section 7.9 du manuel avec un exemple.

Import XML/w

  • projeter sur les mots le numéro de page (pb_id ?)
  • le préambule des fichiers XML '<?XML version=“1.0”?>' ne semble pas nécessaire pour le module d'import 'XML/w+CSV' : documenter cela, et peut-être rendre obligatoire ce préambule.

Import XML Transcriber

  • import transcriber : dans une propriété de <u>, avoir un temps noté de la même forme que le temps vu dans l'édition, ce serait commode pour l'affichage des références.
  • possibilité d'afficher dans les éditions la valeur d'autres attributs que “id” pour l'élément “topic”.

Import Transana

Import Alceste

  • prendre en compte les sections (notation : -*thematiqueA) : créer une structure (par exemple “section” ou “div” ?) et une propriété (par exemple “type” ?) dont les valeurs reprendraient la chaîne de caractères suivant le ”-*”. L'intérêt serait notamment d'augmenter la compatibilité avec les corpus traités par Iramuteq pour faciliter l'articulation des deux logiciels.

Nouvelles commandes à ajouter

Segments répétés (ou motifs)

Spécificités chronologiques

  • Pour analyser la progression thématique
  • plus simplement, il pourrait être intéressant aussi de pouvoir lister pour chaque période d'un corpus chronologique les formes qui apparaissent pour la première fois dans cette partie. (Cela peut se voir actuellement dans une table lexicale, si les lignes-mots sont dans l'ordre du corpus, mais il faudrait que cet ordre du corpus soit explicite et puisse être rétabli après d'autres tris.)

Inventaire distributionnel

R (SLH)

interface TXM / R

  • voir commencer passer des paramètres à un script R et le documenter
  • clarifier/homogénéiser/simplifier+documenter toutes les structures de données transférées à R
  • mieux documenter a) comment exécuter une ligne R depuis Groovy b) comment lancer un script R depuis Groovy
  • aligner les fonctionnalités de la console R sur celle de la console habituelle (nettoyer, copier/coller, etc.)
  • clarifier ce qui est affiché dans la console R et dans la console : le contenu de la console n'est pas très clair/utile quand on est dans la perspective R
  • améliorer la scénarisation de lancement d'une session R (bouton new Session pas très intuitif), c'est à dire comment offrir une zone où saisir du code R à exécuter immédiatement (voir comment faire ça de façon similaire pour Groovy aussi). Faire un 'new session'automatique, quand il n'y en a pas déjà, quand on bascule dans la perspective R serait peut-être déjà utile
  • améliorer la place et l'aspect du bouton Submit (du genre des boutons 'Refresh variables')
  • à quoi sert 'Show eval logs' ?
  • dans la toolbar d'un éditeur, les boutons d'exécution (comme les raccourcis clavier) sont ambigus (entre Groovy et R)
  • je me demande si la vue variables R est très utile : on passe son temps entre la vue corpus qui indique que l'objet est passé dans R (point rouge) et la vue R variables qui ne dit pas grand chose de plus → si la vue corpus montre, par exemple en flyover, le nom de la variable R ça peut suffire car la vue Corpus est facilement accessible depuis la perspective R
  • quand une variable R contenant un objet transféré a été supprimée, on devrait mettre à jour les vues variables R et corpus pour indiquer que l'objet n'est plus transféré
  • pourrait on mettre le résultat d'un “summary(X)” R dans le flyover de la vue variables R ?
  • pour les graphiques générés par un script R, ce serait bien d'aider à légender l'onglet avec des informations utiles (important quand on a plus d'un graphique)
  • ce serait bien de pouvoir sauvegarder ces graphiques également
  • quand on compare les graphiques, ce serait bien d'avoir de l'aide pour faire le lien avec les Index ou autres résultats à l'origine des graphiques (en fait il y a une hiérarchie de relations à partir d'une racine de corpus, mais il y en a d'autres quand certains résultats sont envoyés vers R et utilisés pour créer d'autres résultats que l'on manipule dans l'interface)

Volumétrie

public/demande_de_fonctionnalites.txt · Dernière modification: 2014/02/20 08:54 par benedicte.pincemin@ens-lyon.fr