Liste de liens :
Liste de liens :
A l'heure actuelle, il est possible de construire des partitions dans TXM de 4 façon différentes :
Proposer de nouvelles façon de construire des partitions dans TXM.
Permettre de créer depuis l'assistant des partitions “avancées” sur plusieurs propriétés ? Ex :
Pour un balisage du type (balisage 1) :
<text loc="DG" type="Allocution"></text> <text loc="DG" type="Conférence"></text> <text loc="Chirac" type="Allocution"></text>
pouvoir créer une partition avec des parties de type : DG_Allocution, DG_Conférence, Chirac_Allocution, etc.
Permettre de créer depuis l'assistant des partitions “avancées” sur plusieurs niveaux de structures ? Ex :
Pour un balisage du type (balisage 2) :
<text loc="DG"> <discours type="Allocution"></discours> <discours type="Conférence"></discours> </text> <text loc="Chirac"> <discours type="Allocution"></discours> </text>
pouvoir créer une partition avec des parties de type : DG_Allocution, DG_Conférence, Chirac_Allocution, etc.
La fonctionnalité est plutôt liée aux sous-corpus.
Pour mémoire :
<div1> <sp> <speaker></speaker> <lg></lg> </sp> </div1>
[div1 & !speaker]
permet par exemple de retourner les occurrences des div1 qui ne sont pas dans des speaker.
Notes :
[_.div1_n=“1” & lg] expand to lg
[text & !speaker]+
Proposer une interface ergonomique pour la sélection des structures et propriétés à prendre en compte pour la création de partition.
MD: est-ce-qu'il faudrait prévoir plutôt 2 interfaces distinctes pour simplifier l'usage ?
SJ: tu pensais à une interface pour les partitions multi-niveaux et une autre pour le croisement de propriétés d'une même structure ? Si oui, c'est peut-être dommage car cela empêcherait de mixer les 2 méthodes et donc de créer une partition profitant des 2 systèmes à la fois.
BP: si on crée à la fois un sous-corpus et une partition dans ce sous-corpus, alors pour que cela reste clair à moyen terme il faudrait créer d'emblée deux cubes dans la vue Corpus, un pour le sous-corpus et un pour la partition à l'intérieur du sous-corpus. Et donc aussi indiquer les deux noms correspondants.
SJ: effectivement je trouve aussi mais il faudrait dans ce cas revoir les 3 assistants déjà présent car ils permettent tous de créer des partitions sur des sous-corpus en passant directement par le corpus mère, rien que par sélection de structure non racine dans les combo boxes. Avec le système actuel, on a donc ensuite dans la vue corpus une partition directement liée au corpus mère alors qu'elle n'a en réalité été évaluée que sur un sous-corpus temporaire.
Pouvoir créer un sous-corpus à partir d'une sélection lexicale (CQL) étendue à une structure (eg. 'expand to div'). Un tel sous-corpus correspond à travailler dans les cooccurrents de la CQL.
Cette construction de sous-corpus peut être aussi appliquée pour construire les parties d'une partition (en donnant plusieurs CQL donc).
Interface Utilisateur : cela peut être une nouvelle option-alternative au mode assisté de l'assistant de création de sous-corpus (pour l'instant ce mode, non finalisé, n'aide à construire les sous-corpus qu'à partir de structures).
L'utilisateur donne les requêtes CQL et les noms des parties a créer.
L'interface est composée :
L'une des méthodes pourrait être de passer par des requêtes de ce type plutôt que d'utiliser la macro /region lors de la création des sous-corpus des parties :
[_.text_loc="DG" & _.text_type="Allocution"] expand to text [_.text_loc="DG" & _.text_type="Conférence"] expand to text etc.
dans le cas du balisage 1 et :
[_.text_loc="DG" & _.discours _type="Allocution"] expand to discours [_.text_loc="DG" & _.discours _type="Conférence"] expand to discours etc.
dans le cas du balisage 2.
Il s'agit ici de généraliser les requêtes et de 'expand' le résultat à la balise de la requête qui est la plus basse dans l'arbre. Cela faciliterait notamment la mutualisation avec du code permettant à l'utilisateur de spécifier lui-même sur quoi il veut 'expand' les résultats mais aussi potentiellement d'utiliser les conditions permettant de supprimer des balises/section d'un sous-corpus (ex. [div1 & !speaker]). Le script Groovy développé procède de cette manière.
Mais je me demande si la sémantique est équivalente ou si les résultats seraient les mêmes avec la macro /region qu'avec les requêtes généralisées ci-dessus dans le cas ou on a d'autres structures imbriquées dans les balisages.
Exemple balisage 1' :
<text loc="DG" type="Allocution"> <header>Titre</header> </text> <text loc="DG" type="Conférence"> <header>Titre 2</header> </text> <text loc="Chirac" type="Allocution"> </text>
Exemple balisage 2' :
<text loc="DG"> <header>Titre</header> <discours type="Allocution"></discours> <header>Titre 2</header> <discours type="Conférence"></discours> </text> <text loc="Chirac"> <discours type="Allocution"></discours> </text>
L'exemple 2 est un peu farfelu car a priori la balise “header” devrait être descendante des noeuds “discours” mais il y a peut-être des situtations où le cas 2 est viable. Dans ce cas, le “expand to discours” ne retourne pas les header et c'est peut-être problématique.
Une solution pour apporter une interface permettant à l'utilisateur de définir des partitions croisées sur plusieurs propriétés et multi-niveaux serait de passer par un arbre représentant l'arbre XML du corpus. Il s’agirait de créer l’arbre en fonction de la structure du corpus puis que l’utilisateur puisse cocher ce qui l’intéresse pour la création des partitions. Il pourrait y avoir des mécanismes de simplification de sélection, ex : pour une hiérarchie du type « text.discours.p.s », la sélection de « s » sélectionnerait automatique toute la branche.
Un rollover sur un noeud pourrait afficher les x premières valeurs de propriétés d'une structure afin que cela soit plus parlant.
BP: cette interface définit à la fois des sous-corpus et des partitions : cocher un élément participe à la définition d'un sous-corpus, et cocher un attribut/propriété participe à la définition d'une partition (type simple).
SJ: Oui, mais en fait comme les interfaces déjà présentes dans TXM. Lorsque l'on fait une partition sur une structure autre que racine, les parties sont des sous-corpus d'un niveau plus bas que les structures racines et la partition finale n'est évaluée que sur un sous-corpus et non pas sur le corpus mère.
BP: si on veut coder cela dans TXM, il faudrait être capables de définir un algorithme de construction (semi)automatique de l'arbre à partir de la représentation interne du corpus ?
SJ: Oui, je crois qu'on ne peut pas récupérer directement la structure via CWB mais le script Groovy proposé contient une méthode le faisant (méthode récursive potentiellement lourde, au besoin il faudrait peut-être le faire et le stocker une fois pour toutes quelque part avec le corpus).
<text loc="DG" type="Allocution"></text> <text loc="DG" type="Conférence"></text> <text loc="Chirac" type="Allocution"></text>
Interface générée :
<text loc="DG"> <discours type="Allocution" lang="fr"></discours> <discours type="Conférence" lang="en"></discours> </text> <text loc="Chirac"> <discours type="Allocution" lang="fr"></discours> </text>
Interface générée :
Interface générée :
Pour plus de clarté, dans cet exemple un rollover sur le noeud 'div1' pourrait afficher les x premières valeurs des propriétés, ex :
type "Act" name "ACTE I" type "Act" name "ACTE II" type "Act" name "ACTE III" ...
Voici une proposition d'interface par ensemble, l'idée est de permettre à l'utilisateur de pouvoir sélectionner visuellement les parties du corpus qui l'intéresse en sélectionnant au préalable les propriétés de structures dont il a besoin.
En fait ça marche aussi pour les sous-corpus, c'est génial nan ?
BP: Remarque : compléter un peu l'exemple, pour le moment je ne vois pas bien comment cela marche.
Scénario d'utilisation :
Exemple avec le corpus DISCOURS :
Script permettant la création de partitions sur plusieurs propriétés croisées de même niveau et de partitions sur plusieurs niveaux de structures. (en .zip car le serveur refuse l'extension .groovy)
Il faudrait retester/valider ce script.
Ticket #685
En prenant le script advancedpartition.zip, j'ai produit la macro CrossedPartitionBuilder (package org.txm.macro ds la TBX). Pour l'instant la macro ne gère que le cas avec un seul niveau de structure. Mais il est possible de dé-commenter certains paramètre pour pouvoir faire des partition multi niveau, ignorer certainesstructures, renommer les parties de la partition.
Pour fonctionner, la macro prend 2 paramètres :
Le nom de la partition est construit à partir des propriétés sélectionnées. Par exemple avec struture=text et propriétés=loc,type, alors nom=text_type x text_loc. Les parties prennent comme nom “valeur1 ∩ valeur2”. Par exemple : “DeGaulle ∩ Allocution”