Cette page recense les différents éléments évoqués le 13/05/2014 à Orléans concernant l'exploitation avec TXM de corpus de transcriptions du LLL.
Elle doit servir à faire la liaison entre IHRIM et LLL et au suivi des développements de solutions.
Cette opération consiste à produire le répertoire de transcriptions et les métadonnées associées.
Dans le contexte d'ESLO, cela se fait à l'extérieur de TXM par l'utilisation de la base relationnelle de métadonnées et des répertoires de transcriptions.
→ une idée pourrait être d'ajouter un connecteur SGBDR à TXM pour aider à l'interrogation directe de la base relationnelle.
En attendant, il s'agit de produire le bon fichier 'metadata.csv' à associer aux transcriptions sélectionnées.
L'analyse d'un corpus issu des bases ESLO I et ESLO II repose sur l'usage a) de métadonnées de transcriptions et b) de métadonnées de locuteurs.
Actuellement le module d'import Transcriber+CSV de TXM gère directement le cas a) mais pas le cas b).
→ une idée pourrait être de faire évoluer ce module d'import pour gérer le cas b) également.
On pourrait par exemple ajouter un fichier 'loc_metadata.csv' (en plus de 'metadata.csv') dévolu au codage de métadonnées de locuteurs. Le module pourrait alors projeter au niveau des tours ou des segments ces informations, permettant de les manipuler dans TXM pour faire des sélections, sous-corpus ou partitions à l'aide de ces propriétés.
La procédure de correction et d'ajout de propriété passant par une importation d'une nouvelle version d'un corpus de transcriptions au moyen du module d'import XML-TXM ne permet pas :
→ une façon de répondre à ce besoin pourrait être de faire évoluer le
module d'import Transcriber+CSV en rendant optionnelle la phase 'IMPORTER'.
Dans ce cas
la procédure deviendrait :
Il s'agit de pouvoir projeter sur une transcription mise à jour les annotations lexicales encodées dans une version antérieure de la transcription.
Dans le cas de transcriptions ESLO, le travail de réalignement doit se faire sur la base de transcriptions au format XML (il faut préserver les informations supra et infra lexicales).
En admettant la production automatique d'annotations internes aux mots à l'aide d'outils. Il y a deux possibilités pour les manipuler dans TXM en même temps que les annotations habituelles :
<w pron="pʁɔ.pʁi.je.te" frppos="NOM">propriété</w>
<word pron="pʁɔ.pʁi.je.te" word="propriété" frppos="NOM"> <w>pʁɔ</w> <w>pʁi</w> <w>je</w> <w>te</w> </word>
On peut alors chercher ou compter les /pʁɔ/ se trouvant dans un nom : [word=“pʁɔ” & _.word_frppos=“NOM”]
Nous devons généraliser la projection des identifiants de locuteurs et de thèmes sur les structures des transcriptions (à la place des indentifiants internes de Transcriber).
La segmentation lexicale semble ne pas fonctionner de façon compatible avec TreeTagger pour l'anglais : “won't” → “won'” + “t”. Et du coup TreeTagger ne trouve pas les formes correspondant à son modèle pour l'anglais.
→ il faut vérifier si un changement de paramètre d'import de repérage des apostrophes ne résout pas le problème. Quelle modification à apporter ?
→ remplacer les n't par <w>n't</w> avant importation dans TXM
Peut-on importer une transcription annoté par treetagger ? Exemple du texte produit après annotation :
we PP we
do VBP do
n't RB n't
know VB know
Possibilité d'ajouter l'information de cette façon :
<w enpos=“PP” enlemma=“it”>it</w>
<w enpos=“VBZ” enlemma=“be”>'s</w>
Mais il ne prend pas en compte la propriété aux mots
L'importation XML-Transcriber ne permet pas d'importer un corpus arboré avec des sous-dossier
→ Pour l'instant aucun import de TXM permet d'importer un corpus arboré avec des sous-dossiers, le manuel et le logiciel ne sont pas synchros. Un début de spécification sera défini ici
on peut faire :
(a:[enpos="PP"] b:[]) :: ((a.enlemma="I" & b.enlemma!="mean|think") | (a.enlemma="you" & b.enlemma!="know"))
explications :
La création de sous corpus entraine une perte de “métadonnées”. En effet, depuis un corpus transcriber, on crée un sous corpus avec un locuteur X. Or, il manque des données à ce sous corpus, notamment, il n'a pas ce qu'il faut en terme de “text_id” et donc on n'a pas non plus toutes les métadonnées issues de notre metadata.csv puisqu'il se fie à text_id. –> une erreur du module ??