Outils pour utilisateurs

Outils du site


public:specs_construction_partition

Ceci est une ancienne révision du document !


Spécifications de la construction 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.

Méthode

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 ?

Remarque : compléter un peu l'exemple, pour le moment je (bp) ne vois pas bien comment cela marche.

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

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.

La macro prend 2 paramètres : le nom de la structure et les propriétés à croiser. 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.1396969698.txt.gz · Dernière modification: 2014/04/08 17:08 par matthieu.decorde@ens-lyon.fr