grew_match issueshttps://gitlab.inria.fr/grew/grew_match/-/issues2020-05-19T12:21:34+02:00https://gitlab.inria.fr/grew/grew_match/-/issues/18Accès au CONLL ou aux traits cachés2020-05-19T12:21:34+02:00Sylvain KahaneAccès au CONLL ou aux traits cachésLorsqu'on travaille sur un treebank (et notamment lorsqu'on aborde un nouveau treebank), on a besoin de savoir quels sont les traits présents dans le CONLL et donc requêtable, en particulier les traits globaux comme la traduction si elle...Lorsqu'on travaille sur un treebank (et notamment lorsqu'on aborde un nouveau treebank), on a besoin de savoir quels sont les traits présents dans le CONLL et donc requêtable, en particulier les traits globaux comme la traduction si elle est présente.
Une solution serait de permettre l'accès au CONLL.
Une autre, peut-être plus élégante, serait l'accès à tous les traits présents dans un exemple et la possibilité de paramétrer la liste des traits à afficher ou non.https://gitlab.inria.fr/grew/grew_match/-/issues/14Métadonnées2021-11-29T15:08:35+01:00Sylvain KahaneMétadonnéesComment gérer les métadonnées en GREW ?
On veut pouvoir attacher des informations au niveau d'un échantillon, d'un locuteur ou d'une phrase.
On peut imaginer que chacun de ces objets (échantillon, locuteur, phrase) est un nœud du graphe,...Comment gérer les métadonnées en GREW ?
On veut pouvoir attacher des informations au niveau d'un échantillon, d'un locuteur ou d'une phrase.
On peut imaginer que chacun de ces objets (échantillon, locuteur, phrase) est un nœud du graphe, lui-même attaché à ses métadonnées propres (par ex. lieu et date d'enregistrement pour un échantillon; age, sexe, langues parlées pour un locuteur; locuteur, échantillon ou traduction pour une phrase).
Pour le projet Naija, ces métadonnées sont disponibles et on aimerait pouvoir les intégrer et les requêter.https://gitlab.inria.fr/grew/grew_match/-/issues/13Position inter-mot2019-11-14T15:15:38+01:00Sylvain KahanePosition inter-motDe la même façon qu’on nomme une arête (`e:X->Y`), on pourrait nommer une position linéaire inter-mot (`p:X<Y`) (qui, après tout, est une arête de la relation de succession).
C’est utile si on a déjà la relation de concomitance. Du coup...De la même façon qu’on nomme une arête (`e:X->Y`), on pourrait nommer une position linéaire inter-mot (`p:X<Y`) (qui, après tout, est une arête de la relation de succession).
C’est utile si on a déjà la relation de concomitance. Du coup, on pourrait étendre la relation aux positions inter-mots : `p<e` et `p<<e` pour calculer le flux inter-mot (`p.e.card`).
C’est aussi satisfaisant intellectuellement ;) puisque ça sature l’ensemble des “objets" qu’on peut raisonnablement considérer dans un graphe ordonné.
A l’oral, les positions inter-mots sont vraiment des objets, qui ont notamment une durée et peuvent être typés (pause, type de coupure prosodique, chgt de locuteur). A l’écrit, ça peut être un blanc, un no space ou un chgt de paragraphe. Donc on peut même imaginer leur donner vraiment une existence dans l’encodage.https://gitlab.inria.fr/grew/grew_match/-/issues/12Domination2019-11-14T11:44:58+01:00Sylvain KahaneDominationDe même qu’on a la relation de succession (`X<Y`) et la relation de précédence (`X<<Y`), il serait utile d’avoir à la fois la relation de dépendance (`X->Y`) et la relation de domination (`X->>Y`). Notamment pour le calcul de la projecti...De même qu’on a la relation de succession (`X<Y`) et la relation de précédence (`X<<Y`), il serait utile d’avoir à la fois la relation de dépendance (`X->Y`) et la relation de domination (`X->>Y`). Notamment pour le calcul de la projection d'un nœud et du span de cette projection.https://gitlab.inria.fr/grew/grew_match/-/issues/11Dependency length et autres traits structuraux2020-01-25T10:15:20+01:00Sylvain KahaneDependency length et autres traits structurauxCa pourrait être intéressant de précalculer certains traits structuraux, comme la longueur pour une arête (avec valeur négative quand le dépendant est à droite), et de pouvoir clusteriser ensuite sur `e.length`.
Dans le même genre, je p...Ca pourrait être intéressant de précalculer certains traits structuraux, comme la longueur pour une arête (avec valeur négative quand le dépendant est à droite), et de pouvoir clusteriser ensuite sur `e.length`.
Dans le même genre, je pense à l'arité (`N.arity`) pour un nœud, çad le nombre d'arètes sortantes.
On pourrait aussi vouloir clustériser sur le nombre d'arêtes d'un certain type :
* `e: N-[re"comp.*"]->X`
* cluster sur `N.e.arity` (pas sur que ce soit la meilleure façon d'encoder la requête)
Sinon, moi, j'ai mon petit dada : le flux. Donc j'aimerais pouvoir aussi clustériser sur le flux en un point de la chaîne : `N.fluxsize` me donnerait le nombre d'arêtes concomitantes avec `N`. Et comme précédemment je pourrais m'intéresser qu'à certains types d'arêtes `e` et clustériser sur `N.e.fluxsize`.
Encore une info qui peut être intéressante : tout arbre de dépendance induit une structure constituants. A chaque noeud `N`, on peut associer sa projection et notamment la taille de sa projection (`N.span`). Ca serait par exemple intéressant d'interroger sur les tailles des sujets.
On peut imaginer d'autres traits comme `N.leftspan` et `N.rightspan` Ou encore `N.depth` pour la hauteur de l'arbre (pas sur que ce soit intéressant.
Tu proposes également de classer par les résultats par longueur de phrase, mais ça serait bien du coup de pouvoir clustériser par `sentence.length` ou `root.span`.https://gitlab.inria.fr/grew/grew_match/-/issues/9Voute, ordre de concomitance et overlap2019-11-14T15:17:02+01:00Sylvain KahaneVoute, ordre de concomitance et overlapUn graphe linéairement ordonné induit des relations de concomitance entre les arêtes et aussi entre un nœud et des arètes.
Chaque arête e:A->B définit un span(e) = ]A,B[.
span(root) = toute la phrase sauf le nœud racine
Ca serait bien d...Un graphe linéairement ordonné induit des relations de concomitance entre les arêtes et aussi entre un nœud et des arètes.
Chaque arête e:A->B définit un span(e) = ]A,B[.
span(root) = toute la phrase sauf le nœud racine
Ca serait bien d'introduire des relations entre arêtes en fonction de leur span :
1) b couvre a : a << b si span(a) in span(b)
2) non projectivité : a overlap b si les spans ne sont pas disjoints et pas inclus l'un dans l'autre
3) e couvre N : N << a si N appartient à span(a)
4) e est la voute de N : N < a si a est la voute (ceiling) de N, cad N << a et si N << b alors a << b.
5) b est la voute de a : idem
Avec ça on pourrait facilement remettre les punct et les discourse.
Le gouverneur d'un PUNCT est le pied de la voute.
Et aussi rechercher les configurations non-projectives plus simplement.