Outils pour utilisateurs

Outils du site


public:specs_construction_partition

Spécifications de la construction de sous-corpus ou de partitions

A l'heure actuelle, il est possible de construire des partitions dans TXM de 4 façon différentes :

  • Simple : on choisi une propriété de structure et TXM va créer une partie par valeur de la propriété.
  • Assisté : l'utilisateur choisir une propriété de structure et choisi lui même : 1) le nombre de partie 2) comment affecter les valeurs de la structure aux parties
  • Avancé : l'utilisateur rentre lui même la requête pour chacune des parties souhaitées
  • Script : l'utilisateur exécute un script pour créer une partition

Objectifs

Proposer de nouvelles façon de construire des partitions dans TXM.

Partition sur plusieurs propriétés croisées

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.

Partition sur plusieurs niveaux de structures

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.

[TODO:] Omettre des sections dans les sous-corpus générés pour les parties

FIXME

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 :

  • a) repérage “éclaté” token par token avec une équation du type [text & !speaker]
  • b) extraction par segments, grâce à un expand sur une balise “qui le fait bien”, ex.

[_.div1_n=“1” & lg] expand to lg

  • c) passage en mode greedy avec une requête du type

[text & !speaker]+

Interface pour la création de ces types de partition

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.

Sous-corpus à partir d'une sélection lexicale (CQL)

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).

Méthode

Mode avancé

L'utilisateur donne les requêtes CQL et les noms des parties a créer.

L'interface est composée :

  • d'une liste de champs de parties composées de :
    • un champ texte pour nommer la partie
    • un champ requête pour régler la CQL
    • un bouton “+” pour ajouter/insérer une nouvelle partie
    • un bouton “-” retirer la partie
  • d'un bouton “Importer depuis un fichier properties…” pour charger les champs depuis une liste de requêtes nommées stockée dans un fichier properties
  • d'un bouton “Exécuter une macro…” pour exécuter une macro :
    • qui reçoit en paramètre le corpus, la partition, etc. et retourne une liste de listes de matches nommées ou une Partition

Requêtes généralisées et 'expand'

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.

Problème potentiel de la méthode

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.

Interface par arbre

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).

Exemple 1 - partition simple

<text loc="DG"></text>
<text loc="DG"></text>
<text loc="Chirac"></text>

Interface générée :

Exemple 2 - partition croisée

<text loc="DG" type="Allocution"></text>
<text loc="DG" type="Conférence"></text>
<text loc="Chirac" type="Allocution"></text>

Interface générée :

Exemple 3 - partition croisée et multi-niveaux

<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 :

Exemple 4 - corpus « complexe »

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"
...

Interface par ensemble

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.

Aperçus de début d'interface

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 :

  • L'utilisateur sélectionne plusieurs critères de sélection (ex: des valeurs de propriétés de structure)
  • S'affiche alors un disque par critère.
  • Chaque aire chevauchante représente la réalisation simultanée des critères des disques qui construisent l'aire
  • L'utilisateur peut alors sélectionner à la souris par activation/désactivation les réalisations qu'il souhaite. L'avantage de cette méthode est qu'il n'y a pas besoin de maitriser des opérateurs logiques : sélection en intention VS sélection en extension.

Exemple avec le corpus DISCOURS :

  • On ouvre l'assistant en sélectionnant les propriétés de structures suivantes :
    • text_type
    • text_loc
  • L'utilisateur sélectionne dans la liste des valeurs celles qui l’intéresse:
    • pour text_type : Allocution radiotélévisée et Entretien radiotélévisé.
    • pour text_loc : Pompidou et de Gaulle.
  • S'affiche alors l'écran de sélection des parties :
    • 4 disques de couleur différentes qui s'intersectent en créant 9 zones
  • TODO…

Solution

Script Groovy de partitionnement avancé

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)

advancedpartition.zip

Il faudrait retester/valider ce script.

Macro CrossedPartitionBuilder

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 structure et les propriétés à croiser.
  • Et il faut avoir sélectionner un corpus

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”

Protocole de test

Recette

Macro CrossedPartitionBuilder

Version sur un seul niveau de structure

  1. Sélectionner le corpus DISCOURS
  2. Dans le champ “structuralUnit” mettre “text”
  3. Dans le champ “structuralUnitPropertiesList” mettre “loc,type”
  4. Vérifier le nom de la partition = text_loc x text_type
  5. Sélectionner la partition et vérifier :
    1. Qu'il y a 6 parties
    2. Vérifier les noms de parties avec la commande “Informations”
public/specs_construction_partition.txt · Dernière modification : 30/11/2018 10:02 de slh@ens-lyon.fr