Outils pour utilisateurs

Outils du site


public:chantier_injection_ponctuations

Injection des ponctuations, des non-phrases, des paragraphes et des lemmes dans le corpus Profiterole-UD-GOLD

Les fichiers CONNL-U du corpus https://gitlab.huma-num.fr/profiterole/srcmf-ud n'ont pas de ponctuations et ne contiennent pas les tokens des non-phrases SRCMF. Le chantier consiste à intégrer les ponctuations et les tokens de non-phrases du corpus PROFITEROLE-TXM V0. C'est à dire :

  • ajout de tokens de phrases averbales dont l'étiquetage syntaxique SRCMF a été perdu (il n'y a pas de verbe dans la phrase)
  • ajout de tokens de phrases lacunaires non étiquetés syntaxiquement par SRCMF (des mots étaient illisibles dans le manuscrit)
  • ajout de tokens de ponctuations
  • ajout des lemmes manquants
  • mise à jour des pos
  • mise à jour des formes graphiques
  • ajouts des paragraphes

Étapes :

  1. réaligner le corpus PROFITEROLE-UD-GOLD V2.6 avec les tokens du corpus PROFITEROLE-TXM V0
    1. injecter les xml:id de mots de PROFITEROLE-TXM V0 dans le corpus PROFITEROLE-UD-GOLD V2.6
      1. créer le fichier d'alignement : aligner les mots du gold avec les mots
      2. réaligner les identifiants : corriger l'alignement et injecter les identifiants dans le corpus GOLD
  2. produire le corpus PROFITEROLE-UD-GOLD V3 contenant les tokens de ponctuations et les tokens de non-phrases à partir du corpus PROFITEROLE-TXM V0 et du corpus PROFITEROLE-UD-GOLD V2.6 réaligné
    1. importer les annotations CoNNL-U du corpus PROFITEROLE-UD-GOLD V2.6 sur les tokens correspondants du corpus PROFITEROLE-TXM V0 (en faisant la jointure sur les xml:id)
    2. exporter le corpus PROFITEROLE-TXM V0 + annotations CoNNL-U dans un corpus PROFITEROLE-UD-GOLD V3
  3. créer les relations syntaxiques des ponctuations et des tokens de non-phrases
    • les ponctuations et les non-phrases ne sont pas rattachées à une phrase au départ

Objets :

  • corpus GOLD Profiterole = partie de SRCMF au format CONNL-u corrigé par SP

1- créer le fichier d'alignement

(IHRIM)

  1. récupérer les fichiers XML-TEI de la BFM
  2. lancer le script d'alignement de TMR

Voir alignement_tokens

résultat : fichier d'alignement

1.2- corriger les fichiers CONLL-U et injecter les identifiants

(IHRIM & ???)

  1. corriger les fichiers CONNL-U 2.6 d'après le tableau d'alignement
    • ajout des non phrases
    • corrections de tokens (ajout, retrait, fusion, split)
      • attention à l'identifiant
    • corrections de formes
    • corrections d'identifiants
  2. injecter les identifiants de mots BFM dans les fichiers connl-u-corr (script TMR)

Voir alignement_tokens

résultat : fichiers CONNL-U avec des identifiants BFM injectés. Les tokens (hors ponctuations) et les formes des mots sont synchronisés avec la BFM.

2- reconstruire le corpus GOLD avec les ponctuations et les tokens de non-phrases

(IHRIM)

Dans TXM :

  1. importer les annotations CONNL-U du corpus PROFITEROLE-UD-GOLD V2.6 dans le corpus PROFITEROLE-TXM V0 avec la nouvelle commande Import d'annotations CoNLL-U
  2. exporter le corpus PROFITEROLE-TXM V0 + annotations CONNL-U au format CONNL-U avec la nouvelle commande Export de corpus au format CoNLL-U
    • les tokens sont ceux du corpus PROFITEROLE-TXM V0
      • il peut donc y avoir des tokens en plus, par rapport au corpus CoNNL-U dont on a pris les annotations (les ponctuations et les tokens de non-phrases dans le cas du corpus PROFITEROLE-UD-GOLD V2.6)
    • les phrases sont encodées dans les propriétés CoNNL-U de mots TXM (les ponctuations et non-phrases nécessitent une numérotation UD des mots)

Gestion des tokens sans relation syntaxique

  • les tokens de ponctuations sont exportés, sans relations
    • il faut définir à quelle phrase CoNNL-U chaque token de ponctuation est rattaché
    • en particulier les ponctuations au sein d'une phrase UD, à la fin d'une phrase UD, précédent une phrase UD ou entre des phrases UD

Algorithme de rattachement des ponctuations aux phrases UD existantes et nouvelles

  • AL Proposition de règle :
    • si une ponctuation se trouve au milieu d'une phrase, aucun problème (car on n'indique pas la relation syntaxique à ce stade)
    • si une ponctuation se trouve entre le dernier mot d'une phrase et le premier mot d'une autre phrase, elle est
      • incluse dans la phrase suivante si elle correspond à la regexp suivante [\-–«‘“\(]
      • incluse dans la phrase précédente si non
        • N.B. le guillemet droit “ peut aussi bien faire partie de la phrase qui suit que de celle qui précède, il est difficile d'automatiser son traitement. Mais normalement tous les guillemets sont orientés («, “ et », ”) dans la BFM.
  • les phrases orthographiques de la BFM, encodées par une structure '<s>' dans CQP, peuvent aider à diagnostiquer les relations entre les ponctuations et les limites de phrases orthographiques et par extension de phrases UD
    • AL attention le balisage des <s> n'est pas systématique (il a été désactivé car il provoquait trop d'erreurs, mais certains textes ont été traités avant cette désactivation). Il n'est pas garanti qu'une ponctuation est correctement incluse à une phrase orthographique dans le cadre de ce balisage.
  • les tokens de non-phrases sont exportés, sans relations
    • il faut définir à quelle phrase chaque token de non-phrase est rattaché
      • AL une séquence de tokens (hors ponctuations) forme une phrase autonome au sens UD
    • en particulier si une séquence de tokens de non-phrase s'insère au milieu d'une phrase CoNNL-U
      • AL cela ne doit pas arriver, il faut abandonner l'opération avec le message d'erreur suivant si ça arrive :
        • SLH :
          ** tokens de non phrase situés au milieu de la phrase #X, tokens numéros #A-#B, formes fA, fA+1...
      • AL Il existe 2 types de non phrases
        • Type 1 : Unités syntaxiques sans verbe à la tête (interjections, oui/non, adverbes, réponses elliptiques), elles ont été annotées en SRCMF et doivent être ré-annotées en UD ;
        • Type 2 : Phrases ou segments lacunaires. Il manque des mots nécessaires à la structure syntaxique. Elles ne peuvent pas être annotées et doivent être signalées pour éviter toute confusion
          • SLH : tu veux dire que leurs tokens ne seront pas annotés UD et rattachés à une phrase ?
            • AL Oui, voir ci-dessous
        • les lacunes sont signalées en XML-TEI par la balise <gap/> et dans les éditions on trouve en général des points de suspension entre crochets […]
          • dans l'export CONLL les séquences de ces tokens formeront des “phrases” sans annotation. Pour aider l'annotateur à détecter ce cas de figure, une ligne de commentaire # gap sera insérée entre deux tokens séparés pas un <gap/> en xml.
            • AL alternative: remplacer # gap par une propriété MISC GapAfter= ?
            • AL Une proposition supplémentaire : ajouter des […] dans la ligne #text après les mots qui ont la propriété gap=“next”
            • Les mots du corpus équipés de la propriété de mot “gap” doivent indiquer la valeur “next” lorsqu'un mot est suivi d'un milestone gap

Spécification du format CoNNL-UD d'export

La définition de référence se trouve ICI.

Le format exporté doit vérifier toutes les contraintes exprimées dans le format de référence :

  • les tokens d'une phrase UD sont numérotés de 1 à N
  • etc.

Par contre les informations exportées ne seront constituées que :

  • des informations issues du corpus TXM exporté
  • des informations CoNNL-UD importées dans le corpus TXM auparavent

Les informations CoNNL-UD importées formeront la base des informations CoNNL-UD exportées.

Les formes contractées ne seront pas décontractées. Mais cela peut faire l'objet d'une option si l'algorithme de décontraction est défini.

Questions sur l'import et l'export CoNNL-U :

  • si les informations CoNNL-UD importées ne contiennent pas d'information, du type “SpaceAfter=No”, dans la colonne 10 (MISC), faut il que le CoNNL-UD exporté en contienne ?
    • faut t'-il importer&exporter le contenu de la colonne 10 (MISC) du corpus CoNNL-UD d'origine
    • LG Il me semble qu'on a rien pour l'instant dans cette colonne, mais il vaut mieux prévoir d'en faire l'import&export pour être plus général. Si on peut en plus y ajouter les SpaceAfter=No ce serait merveilleux !
      • MD & SLH on peut tout à fait exporter des SpaceAfter=No importés, mais il faudra produire les SpaceAfter=No des tokens insérés :
        • la production de SpaceAfter=No dépend d'une norme typographique (par langue) et d'exceptions au mot près
          • actuellement, dans TXM, on gère la norme (pour le français et l'anglais) mais pas les exceptions (ex : dans les contextes de concordance, les éditions, etc.).
          • Si il y a des exceptions dans le corpus Profiterole, on pourrait implémenter le mécanisme général combinant norme et exceptions dans TXM, puis on l'implémenterait dans l'export CoNLL-U
            • cela prendrait un certain temps mais est-ce-que ce serait pertinent à développer pour le corpus Profiterole ?
            • LG En fait je pense que les seuls tokens qui seraient concernés par SpaceAfter=No seraient ceux suivis pas de la ponctuation (j'imagine que ça rentre dans le cadre de la norme du coup), et si ça concerne d'autres tokens, c'est sûrement très marginal donc ajouter un mécanisme à TXM rien que ça, je ne pense pas que ce soit nécessaire.
              • AL Ça concerne aussi les tokens qui finissent par une apostrophe, les parenthèses, les crochets ouvrants, etc. Il ne doit pas y avoir de blancs autour de traits d'union (“va-t-elle”), mais normalement le trait d'union n'est pas utilisé dans les textes médiévaux. Dans la Quête du Graal, on balise des “agglutinations” (des mots “collés” dans le manuscrit), ils ont la propriété rend avec la valeur “aggl” ou “fgmt”.
  • faut il produire les lignes commentaires de séparation entre phrases ? (cela peut être re-construit par des outils externes ?)
    • LG En fait ce ne sont pas vraiment des lignes de commentaires, elles sont-quasi uniquement utilisées pour encoder des métadonnées sur l'arbre qui suit (c'est même contrôlé par le valideur UD) donc si possible il faut les laisser. A minima il faut conserver le sent_id qui permet de faire la jointure entre le corpus original et le corpus exporté.
      • MD & SLH OK, On garde les id d'origines des phrases transférées (voir ci-dessous la numérotation des nouvelles phrases)
  • faut-il importer&exporter les identifiants de phrases du corpus CoNNL-UD d'origine ?
    • LG Oui, voir plus haut. Pour les nouvelles phrases, on peut dans un premier temps leur donner des identifiants temporaires qui seraient juste les numéros qui suivent ceux déjà présents dans le corpus. Si plus tard on veut récupérer le fait que les id soient ordonnées comme les phrases du texte original on pourra toujours demander (à condition que ça corresponde à la politique UD)
      • [ALgo 1] MD & SLH OK on propose l'algo suivant pour les nouvelles phrases
        • nextSentId = nombre de phrases UD importées du texte +1:
        • pour chaque nouvelle phrase : sent_id = text@id + ”-“ + nextSentId++ + ”.new“
          • le ”.new“ permet de détecter les nouvelles phrases de l'export
      • [Algo 2] MD (obsolète) pour l'instant les phrases sont séparées par une ligne de commentaire 'sent_id' et numérotées à partir du début de chaque texte TXM
        • AL Qu'est-ce qui est obsolète ? Dans l'export du 5/10/20, c'est l'algo 2 qui est implémenté.
  • faut il produire les lignes commentaires de séparation entre paragraphes 'newpar id' ?
    • LG Si possible
      • MD & SLH OK, pour les textes Profiterole qui encodent des paragraphes, on produira une ligne commentaire “newpar”
        • AL Il faudrait ajouter newpar également au début de chaque <head> et de chaque <ab type=“gv”>. Ce sont des blocs de texte équivalents aux paragraphes. Avec le système actuel le titre d'une nouvelle division se rattache au paragraphe précédent.
  • faut il produire les lignes commentaires de séparation entre textes ? (si le corpus cible est tout le corpus PROFITEROLE)
    • faut-il importer&exporter les identifiants de texte du corpus CoNNL-U d'origine ?
    • MD (obsolète) pour l'instant les textes sont séparés par une ligne de commentaire 'newdoc id' et identifiés à partir de la métadonnée 'id' du texte TXM
      • MD & SLH on va récupérer les 'newdoc id' d'origine aussi
        • AL Dans l'export du 5/10/20, le “newdoc id” d'origine est récupéré pour les phrases existantes dans SRCMF-UD sauf en cas d'injection de tiret ou de guillemet ouvrant au début de phrase (cf. mon retour dans la recette). Puisque l'identifiant du texte est une constante dans un corpus composé d'un texte, je crois qu'on peut injecter l'identifiant d'origine SRCMF-UD à toutes les non phrases.
  • peut on produire des lignes commentaires de toutes les structures textuelles connues pertinentes ?
    • MD & SLH OK, nous ne génèrerons pas de ligne commentaire pour les autres structures
  • y'a t-il des propriétés de mots CQP à exporter ?
    • LG Dans un premier temps je pense que ce n'est pas nécessaire, sauf si c'est vraiment trivial. Si on veut ajouter de nouvelles infos aux tokens existants c'est encore un autre chantier, quand aux nouveaux tokens, soit il seront annotés à l'étape 4, soit algorithmiquement, soit à la main et je ne sais pas si les propriétés CQP aideraient.
      • MD & SLH La politique d'export de propriétés CQP proposée est la suivante :
        • nous exportons la propriété 'word' de CQP des nouveaux tokens dans la colonne “FORM”
        • + cas suivants :
          • defaultLemmaPropertyName : propriété CQP à utiliser si le 'LEMMA' ud n'est pas renseigné (“_”)
          • defaultUposPropertyName : propriété CQP à utiliser si la 'UPOS' ud n'est pas renseignée (“_”)
          • defaultXposPropertyName : propriété CQP à utiliser si la 'XPOS' ud n'est pas renseignée (“_”)
      • LG Oh, parfait, je pensais qu'on aurait à refaire tout ça à la main mais si c'est déjà là, tant mieux !
    • La question peut se poser dans les cas suivants :
      • des tokens dont certaines propriétés UD ne sont pas renseignés
      • des tokens de ponctuations nouvellement insérées
      • des tokens de non-phrases nouvellement insérées

3- créer les relations des ponctuations et annoter les non-phrases

(LATTICE)

  1. les ponctuations exportées ne sont pas rattachées à l'arbre syntaxique
    → (a) définir l'algorithme de rattachement
    • LG On applique directement les règles données par https://universaldependencies.org/u/dep/punct.html:
      • A punctuation mark separating coordinated units is attached to the following conjunct.
      • A punctuation mark preceding or following a dependent unit is attached to that unit.
      • Within the relevant unit, a punctuation mark is attached at the highest possible node that preserves projectivity.
      • Paired punctuation marks (e.g. quotes and brackets, sometimes also dashes, commas and other) should be attached to the same word unless that would create non-projectivity. This word is usually the head of the phrase enclosed in the paired punctuation.
    • LG On commence par répérer les ponctuations appariées, qu'on rattache à la racine du sous-arbre qu'elles encadrent
      • Les guillemets orphelins sont rattachés à la racine du sous-arbre à leur gauche pour les fermants et à leur droite pour les ouvrants
      • On peut repérer les virgules appariées parce qu'elles encadrent un sous-arbre dont la racine a la dep “appos”
    • LG Les virgules et point-virgules qui séparent deux sous-arbres reliés par une relation de conjonctions sont attaché à la racine de celui-de droite
    • LG Les autres ponctuations se rattachent à la racine de la phrase
  2. les non-phrases ne sont pas annotées en syntaxe
    → (b) définir l'algorithme de rattachement
    • LG À faire à la main
  3. implémenter et appliquer (a) et (b)
    1. dans TXM, dans l'outil d'export
    2. ou ailleurs
    • LG comme je ne suis pas familier avec le code de TXM, si ce sont des étapes qui ne servent que dans Profiterole, je réfère le faire dans un script à part, mais si ça ressert je peux prendre la peine de l'ajouter à l'outil d'export.

Recette V0.0

Fichiers de la recette

Production du fichier CoNLL-U exporté

[Cette opération n'est réalisée que par MD pour l'instant]

Préparation de TXM :

  • passer en niveau de mise à jour ALPHA (préférences : TXM > Avancée : Niveau des mises à jour)
  • lancer la vérification de mise à jour et mettre à jour TXM de numéro de version “0.8.1 20201023xxx” & l'extension TIGERSearch de numéro de version “20201023xxx”
  • charger le corpus AUCASSIN-2020-09-21.txm dans TXM
  • créer un répertoire, y copier le fichier “aucassin-ud-id-lemma.conllu” et le renommer en 'aucassin.conllu' (pour la jointure par texte)
  • importer les annotations 'aucassin.conllu' dans le corpus TXM “AUCASSIN” avec la commande “TS > Import CoNLL-U annotations…” du menu principal
    • paramètres :
      • conlluDirectory = le répertoire contenant le fichier 'aucassin.conllu'
      • propertiesPrefix = “ud-import-” (valeur par défaut)
  • Une fois le corpus mis à jour, vérifier la présence des propriétés CoNLL-U (celles précédées par “ud-import-”) avec la commande Propriété sur le corpus AUCASSIN
  • exporter le corpus AUCASSIN au format CoNLL-U (les ponctuations et les tokens de non-phrases sont inclus, sans leur relation syntaxique dans un premier temps)
    • paramètres:
      • conlluResultDirectory = le répertoire résultat où les fichiers CoNLL-U seront écrits, différent de conlluDirectory précédemment indiqué.
      • importedPropertiesPrefix = “ud-import-”
      • defaultFormPropertyName = word
      • defaultLemmaPropertyName = lemma
      • defaultUposPropertyName = ud-pos
      • defaultXposPropertyName = cattex-pos
      • defaultUfeatsPropertyName = ud-feats

Vérification du fichier CoNLL-U exporté

Opérations à réaliser avec les fichiers CoNNL-U résultats de l'étape précédente déposés dans le sharedocs Profiterole de chemin Cactus Data > Projets > Profiterole > corpus > alignement_bfm-srcmf-ud

  • aucassin-ud-with-ponct-non-phrase-lemma.conllu
  • aucassin-ud-with-ponct-non-phrase.conllu (sans les lemmes pour faciliter la comparaison)
  • dans les fichiers CoNLL-U exportés dans le répertoire résultat, vérifier que :
    • le validate.py UD passe
      • LG Ce serait surprenant parce que par construction les ajouts de poncutation et de non-phrases donnent des arbres incohérents (plusieurs racines), mais ce n'est pas un problème, ce n'est pas l'objectif à cette étape
    • tous les tokens de ponctuations sont présents
      • et insérés dans les bonnes phrases selon l'Algorithme de rattachement des ponctuations aux phrases UD existantes et nouvelles (voir la section ci-dessus)
        • AL Les tirets sont attachés correctement, la numérotation des tokens semble OK (sauf les dernière ponctuations devant les tirets, voir ci-dessous).
    • les phrases averbales et lacunaires (non-phrases) sont bien présentes
      • tous les tokens des non-phrases sont présents
      • ces tokens sont bien répartis dans les bonnes non-phrases
    • la taille du corpus est bien augmentée du total des nouveaux tokens (ponctuations + non-phrases)
    • la totalité des colonnes produites et en particulier :
      • ID : les numéros de tous les tokens (colonne 1 / ID) sont bien calculés, y compris pour les ponctuations et les non phrases
        • AL Le numéro (colonne 1) n'est pas bon pour les ponctuations de fin de phrase qui précèdent le tiret attaché à la phrase suivante.
          • MD la numérotation de ces ponctuations sont corrigés
      • HEAD : pour les tokens ayant la colonne 7 (HEAD) renseignée, les liens pointent vers les bons numéros de mots
        • AL parfois -1 persiste, par exemple ligne 3103.
          • MD corrigé
      • FEATS
        • LG pour la ponctuation insérée, la valeur est “|_|” au lieu de “_”
    • tous les gap des phrases lacunaires sont bien codés dans des lignes commentaires ”# gap“ et correspondent bien aux gaps du corpus PROFITEROLE
      • AL OK
      • AL Une autre proposition serait d'insérer qqch comme “GapAfter=Yes” dans la colonne 10 ?
        • LG J'ai un doute sur les gaps : est-ce qu'ils correspondent à des tokens qui sont présents dans la BFM ou pas ? Dans le deuxième cas, GapAfter me paraît une bonne idée
    • tous les paragraphes sont bien codés dans des lignes commentaires ”# newpar id“ et correspondent bien aux paragraphes du corpus PROFITEROLE
      • les newpar importés ne sont pas restitués dans l'export (non vérifiable pour aucassin)
        • AL Les newpar sont bien générés à partir du corpus TXM. Je propose de les ajouter également à tous les débuts des structures head et ab (cf. la spec ci-dessus)
    • les “newdoc” et “sent_id” ont été conservés
      • AL j'ai l'impression que l'identifiant de phrase d'origine est perdu lorsque tu insères in tiret au début. Voir par exemple la phrase sent_id = 15636 qui est devenue sent_id = aucassin-183.new ; idem sent_id = 15713 devenu sent_id = aucassin-263.new
        • MD corrigé, j'ai récupéré le sent_id de l'ancien premier mot de la phrase UD.
          • AL OK pout sent_id. En revanche, dans ces phrases avec des ponctuations initiales newdoc id est celui de la BFM (aucassin) et non de SRCMF-UD (Aucassin_early13_verse-prose), comme il devrait l'être (e.g. sent_id = 16142, ligne 11336 dans aucassin-ud-with-ponct-non-phrase-lemma.conllu)
    • les “newdoc” et “sent_id” des nouvelles phrases sont corrects
      • AL OK, avec l'algo 2 pour les non-phrases
    • la propriété “SpaceAfter=No” est affectée aux tokens qui ne sont pas suivi par un espace dans la phrase
      • la restitution des “SpaceAfter=No” (contenu de la colonne MISC) importés est correcte (non vérifiable pour aucassin)
      • les nouveaux tokens ont un “SpaceAfter=No” correct (l'interférence entre les SpaceAfter=No importés et générés n'a pas été vérifiée)
      • AL les différentes informations qu'on place dans la colonne 10 (MISC) doivent être séparées par des | et non par des blancs
        • MD corrigé, j'utilise “|” maintenant
          • AL OK

Recette V1.0

Fichiers de la recette

Production du fichier CoNLL-U exporté

Préparation de TXM :

  • passer en niveau de mise à jour ALPHA (préférences : TXM > Avancé : Niveau des mises à jour)
  • lancer la vérification de mises à jour et mettre à jour TXM & l'extension TIGERSearch
  • charger le corpus AUCASSIN-2020-09-21.txm dans TXM
  • créer un répertoire, y copier le fichier “aucassin-ud-id-lemma.conllu” et le renommer en 'aucassin.conllu' (pour la jointure par texte)
  • importer les annotations 'aucassin.conllu' dans le corpus TXM “AUCASSIN” avec la commande “TS > Import CoNLL-U annotations…” du menu principal
    • paramètres :
      • conlluDirectory = le répertoire contenant le fichier 'aucassin.conllu'
      • propertiesPrefix = “ud-import-”
      • normalize_word_ids: cocher la case
  • Une fois le corpus mis à jour, vérifier la présence des propriétés CoNLL-U (celles précédées par “ud-import-”) avec la commande Propriété sur le corpus AUCASSIN
  • exporter le corpus AUCASSIN au format CoNLL-U (les ponctuations et les tokens de non-phrases sont inclus, sans leur relation syntaxique dans un premier temps)
    • paramètres:
      • conlluResultDirectory = le répertoire résultat où les fichiers CoNLL-U seront écrits, différent de conlluDirectory précédemment indiqué.
      • importedPropertiesPrefix = “ud-import-”
      • defaultFormPropertyName = word
      • defaultLemmaPropertyName = lemma
      • defaultUposPropertyName = ud-pos
      • defaultXposPropertyName = cattex-pos
      • defaultUfeatsPropertyName = ud-feats
      • insertTokensWithoutUdAnno: cocher la case

Vérification du fichier CoNLL-U exporté

Opérations à réaliser avec les fichiers CoNNL-U résultats de l'étape précédente déposés dans le sharedocs Profiterole de chemin Cactus Data > Projets > Profiterole > corpus > alignement_bfm-srcmf-ud

  • aucassin-ud-with-ponct-non-phrase-lemma.conllu
  • aucassin-ud-with-ponct-non-phrase.conllu (sans les lemmes pour faciliter la comparaison)
  • dans les fichiers CoNLL-U exportés dans le répertoire résultat, vérifier que :
    • tous les tokens de ponctuations sont présents
      • et insérés dans les bonnes phrases selon l'Algorithme de rattachement des ponctuations aux phrases UD existantes et nouvelles (voir la section ci-dessus)
    • les phrases averbales et lacunaires (non-phrases) sont bien présentes
      • tous les tokens des non-phrases sont présents
      • ces tokens sont bien répartis dans les bonnes non-phrases
    • la taille du corpus est bien augmentée du total des nouveaux tokens (ponctuations + non-phrases)
    • la totalité des colonnes produites et en particulier :
      • ID : les numéros de tous les tokens (colonne 1 / ID) sont bien calculés, y compris pour les ponctuations et les non phrases
      • HEAD : pour les tokens ayant la colonne 7 (HEAD) renseignée, les liens pointent vers les bons numéros de mots
      • FEATS
        • LG pour la ponctuation insérée, la valeur est “|_|” au lieu de “_”
    • tous les gap des phrases lacunaires sont bien codés dans des lignes commentaires ”# gap“ et correspondent bien aux gaps du corpus PROFITEROLE
    • les “newdoc” et “sent_id” ont été conservés
    • les “newdoc” et “sent_id” des nouvelles phrases sont corrects
    • la propriété “SpaceAfter=No” est affectée aux tokens qui ne sont pas suivi par un espace dans la phrase
      • la restitution des “SpaceAfter=No” (contenu de la colonne MISC) importés est correcte (non vérifiable pour aucassin)
      • les nouveaux tokens ont un “SpaceAfter=No” correct (l'interférence entre les SpaceAfter=No importés et générés n'a pas été vérifiée)
  • le validate.py UD passe
    • LG Ce serait surprenant parce que par construction les ajouts de ponctuation et de non-phrases donnent des arbres incohérents (plusieurs racines), mais ce n'est pas un problème, ce n'est pas l'objectif à cette étape
public/chantier_injection_ponctuations.txt · Dernière modification: 2020/11/01 22:10 par loic.grobol@gmail.com