Outils pour utilisateurs

Outils du site


public:annotation:specs_manual_annotation:specs_store_annotation

Spécification de l'enregistrement des annotations

On part du principe qu'exploiter les annotations repose sur les outils de TXM.

Cette exploitation peut être réalisée grâce à :

  • Scénario 1) l'usage des outils actuels s'appuyant sur CQP et les éditions (c'est-à-dire le 'modèle de données de TXM' ou la 'version interne du corpus') [V1]
    • de ce fait, avant de pouvoir exploiter une annotation, il faut que celle ci soit rendu disponible depuis CQP et les éditions par une phase de “mise à jour du corpus” déclenché par un “commit”.
  • Scénario 2) une autre possibilité est d'augmenter les outils actuels en faisant vendre/évoluer le modèle de données de TXM (CQP+éditions). Par exemple en augmentant CQP ou en ajoutant des composants supplémentaires à CQP.

Ainsi l'annotation est divisée en 2 phases séparées par le commit :

  1. l'affectation d'annotation sur le corpus se reposant sur une sauvegarde temporaire dans la session de travail
  2. une opération de commit qui rend disponible les annotations
  3. l'exploitation d'annotation du corpus reposant sur une nouvelle version interne du corpus

1) Annotation sur le corpus reposant sur une sauvegarde temporaire, avant commit

La sauvegarde des annotations peut être temporairement prise en charge avant d'être prise comme un véritable “commit”, une mise à jour du corpus, avec les possibilités d'export et d'exploitation.

Visualisations

Ce scénario implique une gestion des annotations en dehors de CQP. Il doit permettre d'exploiter un minimum les annotations pour :

  • visualiser les annotations en cours lors d'une recherche dans une concordance [V1] (voir spécification de l'annotation dans la concordance)
  • visualiser les annotations en cours dans l'édition
  • visualisation stylisée des annotations dans ces mêmes outils (par exemple coloration, gras, etc.)

Gestion des contraintes

La sauvegarde définitive (et l'exploitation des annotations) impose des contraintes sur l'architecture des annotations en cours :

  • Enchâssement : dans le cas d'enchâssement de structures de séquences de mots annotées avec une structure pré-existante ou en cours du corpus, l'interface d'annotation doit aider l'utilisateur à choisir les délimitations de séquences et de structures cohérents
    • scénario 1 : on informe l'utilisateur que les annotations correspondant à des structures enchâssées ont été réduites [V1] (voir spécification de l'annotation dans la concordance)
    • scénario 2 : une interface aide l'utilisateur à visualiser les enchâssements
      • version bacon deluxe : à déplacer les limites des structures pour qu'elles ne soient plus incohérentes
    • scénario 3 : semi-automatique où on propose de déplacer automatiquement les limites de structures pour éviter les enchâssements. En utilisant éventuellement un typage de structures/séquences 'à raboter à gauche', 'à raboter à droite', etc.).
  • Inclusion récursive : celle-ci est rendue possible par l'applatissement et la numérotation en profondeur de l'indexation CQP mais l'interrogation dans les outils de TXM reste pénible

Conservation

Les annotations temporaires sont stockées en base, leur cycle de vie peut être limité :

  • à la session de travail [V1]
  • à plusieurs sessions de travail

Solution

Voir la section dédiée API STA (sauvegarde temporaire des annotations) [V1]

2) Le commit

Le commit est le moment où l'utilisateur décide de sauvegarder pour de bon son travail. Il déclenche ainsi la mise à jour du corpus. Avant de déclencher la MAJ, un rapport peut être affiché avant validation.

Le commit - du corpus - peut être déclenché :

  • manuellement, après avoir fait plusieurs annotations :
    • à partir du menu contextuel du corpus dans la vue Corpus. Le nom du corpus sera assorti d'une étoile, dès lors qu'une ou plusieurs annotations ont été effectuées [V1]
    • à partir d'un bouton “enregistrer les annotations” dans la barre d'outils de TXM [V1]
    • à partir du menu principal “Corpus > Enregistrer les annotations” [V1]
  • automatiquement :
    • régulièrement (fréquence réglable et désactivable dans les préférences et à des moments particuliers de la session)
    • en fin de session de travail
      • à la fermeture de l'éditeur d'annotation si une annotation est en cours
      • à la fermeture de TXM si une annotation est en cours

3) Sauvegarde définitive, Mise à jour du corpus interne

Scénario 1 - à modèle constant

La mise à jour du corpus reconstruit :

  • les index CQP
  • les pages d'édition
Scénario A - patcher les index CQP et les éditions
Scénario B - reconstruire la représentation WTC à partir des index CQP et patcher les éditions
Scénario C - utiliser la représentation pivot XML-TXM présente dans le corpus binaire **[V1]**

Ré-entrance du module d'import

On utilise les dernières étapes d'un module d'import : “compiler” et “pager”. Cela correspond à un comportement de mise à jour de corpus (index CQP et pages d'édition).

Il faut créer un nouveau paramètre UPDATECORPUS au script du module d'import qui change son mode d'exécution pour ne faire que les étapes “compiler” et “pager”.

Ce paramètre est encodé dans la hash de l'objet “BaseParameter” qui stocke les paramètres supplémentaires dynamiques du script (qui n'habitent pas dans le fichier import.xml pour l'instant :-)).

Cela implique :

  • qu'un corpus importé sait avec quel module d'import il a été créé
  • soit :
    • a) un module est capable de ne rejouer que la fin du module d'import avec les bons paramètres. Il faudra alors figer un peu plus les étapes des modules import, au moins après que les fichiers soient au format pivot XML-TXM (tokenisé)
    • b) on peut facilement appeler le compiler et le pager de chaque module indépendament des modules eux-mêmes
    • c) on se limite à implémenter la stratégie dans le module 'XML-XTZ + CSV' [V1] Ticket #1548
Scénario D - reconstruire la représentation pivot XML-TXM à partir des index et patcher les éditions

La représentation XML-TXM peut être reconstruite en décompilant les index CQP sauf :

  • A) les milestones
  • B) les éléments ignorés (mais éventuellement mis en forme dans les éditions)
  • C) ?
  • etc.

Cette différence doit être précisée en faisant la synthèse de tous les workflows des modules d'import.

Les éditions ne peuvent pas être reconstruites à partir des index CQP à cause du hors-texte édité.

Les différences entre XML-TXM produits proviennent également des paramètres d'import de chaque module (il faut interpréter un fichier XML-TXM dans le contexte du fichier 'import.xml' (et des fichiers '.properties' pour certains) à l'origine de sa production).

Scénario E - utiliser les sources

Partir des sources et si retokenisées il faut s'appuyer sur les paramètres de tokenisation et d'annotation (pos, lemme) à l'import par exemple.

Codage des annotations dans les fichiers XML-TXM

L'exploitation des annotations se fait à l'aide de CQP, il faut transférer préalablement les annotations de la base temporaire vers les fichiers XML-TXM du corpus binaire [V1]

Les annotations de mots (point) peuvent être alors codées :

  • en propriétés lexicales
  • en propriétés de structure englobant un seul mot

Les annotations de séquences de mots peuvent être alors codées :

  • en propriétés lexicales posées au moins sur les mots de début et de fin de la séquence
    • + pas de problème de chevauchement
    • - l'inclusion d'une annotation de même type n'est pas évidente
    • - à l'exploitation : le matching strategy de CQP est non-greedy
    • - il faut gérer endehors de CQP la logique d’empan
  • en propriétés de structure englobant la séquence [V1]
    • + gestion intégrée d'empan
    • + permet de surcharger l'annotation d'informations secondaires comme l'auteur de la dernière modification et sa date de modification
    • - pas de chevauchement
    • - pas de récursion
      • si récursion, les requêtes CQL deviennent beaucoup plus compliquées il faut soit 1) fournir un assistant de requête 2) soit être un utilisateur expert CQL
Optimisations

La mise à jour des index du corpus est aujourd'hui couteuse car il faut refaire certaines étapes du module d'import.

Pour éviter d'attendre trop longtemps ou de gêner la session utilisateur un certain nombres d'optimisations peuvent être implémentées : (en attendant de mettre un lien vers la spec d'optimisation)

  • générer un fichier WTC par fichier XML-TXM puis les concaténer à l'appel de cwb-encode au lieu de régénérer un gros fichier WTC pour tout le corpus [V1]
  • ne pas mettre à jour les fichiers/textes qui ne sont pas concernés par les annotations et ne pas leur appliquer les étapes compiler et pager
    • on peut utiliser l'antériorité entre les dates de fichiers XML-TXM → WTC | HTML pour implémenter cette stratégie [V1]
  • Éviter de redémarrer tout le moteur, aujourd'hui recharger un corpus TXM consiste à couper le moteur de recherche puis le redémarrer
    • CWB est capable de gérer plusieurs chemin de dossier registry, il faut voir dans quelle proportions CQB gère l'ajout ou le retrait de registry.
  • lazy loading
Questions
  • Q1) CQP peut-il fonctionner en ayant une structure d'annotation concurrente avec les autres structure du corpus ?
  • Q2) Comment injecter dans les fichiers XML-TXM les annotations pour les cas suivants :
    • ajout d'une nouvelle annotation
    • ajout d'une nouvelle annotation qui englobe une autre annotation
    • mise à jour d'une annotation
    • suppression d'une annotation
Réponses
  • R1)
    • en faisant un corpus CQP à coté du principal qui ne contient que la structure d'annotation
    • cwb-encode se protège contre le chevauchement de structure, peut-être en modifiant à la main les index CQP ?
  • R2) Injection dans les fichiers XML-TXM des annotations :
    • Solution DOM [V1]
    • Solution StaX

Scénario 2 - en augmentant et combinant le modèle

Gestion des annotations multi-corpus

La sauvegarde concerne le corpus sélectionné ou objet de la commande.

Il faut vérifier que les annotations en cours de tous les corpus sont bien sauvegardées au moment de quitter TXM :

  • en cas d'annotations à sauvegarder, ouvrir une boite de dialogue avec une liste des corpus concernés ayant une colonne 'oui/non' pré-sélectionnée avec les boutons 'Enregistrer' ou 'Abandonner'

Gestion des annotations multi-utilisateur

Pour l'instant, la sauvegarde ne concerne que les corpus enregistrés localement sur la machine de l'utilisateur.

public/annotation/specs_manual_annotation/specs_store_annotation.txt · Dernière modification: 2016/01/20 18:44 par slh@ens-lyon.fr