Differences

This shows you the differences between two versions of the page.

--- treex:coordinations [2015/03/14 19:49]
popel
+++ treex:coordinations [2015/10/17 21:53] (current)
popel
@@ Line 78: / Line 78: @@
 === Motivace pro zvolené řešení společných rozvití ===
-Společné rozvití je většinou těžké odlišit od privátního (cf. "Jan a Marie, kteří"). Typicky jsme si jedním rodičem jisti a ten druhý (či třetí) je nejistý (jako v životě:-), mohli bychom jim tedy říkat mother a father, až na to, že pokud je možných otců víc (koordinovaných), tak v lingvistice se nestává, že by jen jeden byl rodičem a ostaní ne).
+Společné rozvití je většinou těžké odlišit od privátního (cf. "Jan a Marie, kteří"). Typicky jsme si jedním rodičem jisti a ten druhý (či třetí) je nejistý (jako v životě:-), mohli bychom jim tedy říkat mother a father, až na to, že pokud je možných otců víc (koordinovaných), tak v lingvistice se nestává, že by jen jeden byl rodičem a ostatní ne).
 Často nás rozdíl mezi společným a privátním rozvitím nezajímá a pražský styl nám to komplikuje, že takto jemná distinkce se odráží v celé topologii stromu. V tomto návrhu je snadné tu distinkci ignorovat.
@@ Line 95: / Line 95: @@
   * V UD jsou předložky a spojky "dole", takže není třeba metod, které by hledaly efektivní děti/rodiče a ještě navíc přeskakovaly předložky (parametr dive=>AuxCP zmizí).
-  * Lze zařídit, aby treexové API "předstíralo" nějakou jinou reprezentaci (třeba Prague/Stanford/Moscow family style), než jaká je ta skutečná treexová interní. Problém ale nastává, když pak chce někdo měnit strukturu, tedy přidávat či převěšovat uzly. Myslím, že pak musí přesně vědět, jaká je ta interní struktura, protože zde se jakékoli předstírání může dost vymstít. Ono by to předstírání asi bylo matoucí i při prohlížení v TrEdu (či XML treexových souborů) a při debugování. Proto bych se radši takovémuto předstírání vyhnul.
+  * Lze zařídit, aby treexové API "předstíralo" nějakou jinou reprezentaci (třeba Prague/Stanford/Moscow family style), než jaká je ta skutečná treexová interní. Problém ale nastává, když pak chce někdo měnit strukturu, tedy přidávat či převěšovat uzly. Myslím, že pak musí přesně vědět, jaká je ta interní struktura, protože zde se jakékoli předstírání může dost vymstít. Ono by to předstírání asi bylo matoucí i při prohlížení v TrEdu (tedy kdyby API předstíralo a TrEd ne, opačně viz [[treex:coordinations#vizualizace-v-tredu]]) či XML treexových souborů a při debugování. Proto bych se radši takovémuto předstírání vyhnul.
+  * Samozřejmě Read::CoNLLU bude umět načítat stanfordské koordinace a Write::CoNLLU je bude zapisovat. Budeme mít taky bloky, které budou převádět mezi naší treexovou (právě popsanou v tomto návrhu) reprezentací koordinací a různými jinými styly (Read/Write ::CoNLLU může tento transformační blok interně využívat).
   * Některé reprezentace koordinací mohou být výhodnější pro některé typy parserů. Bylo by jistě zajímavé to prozkoumat (jak plánujeme už několik let, a mezitím o tom vyšlo několik článků, ale žádný to ještě neprozkoumal tak důkladně, jak bych si představoval). Myslím si ale, že je chyba přizpůsobovat treexovou reprezentaci tomu, co umí současné parsery. Měli bychom se už konečně odpoutat od představy, že když je v treebanku nějaký jev reprezentován nějakým stylem, že to tak musíme dělat i při trénování parseru.
@@ Line 111: / Line 113: @@
 Možná by šlo využít perlovských anotací proměnných (viz ''perldoc attributes''), ale to moc lidí neumí používat. Jednodušší asi bude metoda ''$nodeA-''''>align_type_to($nodeB)'', respektive ''$nodeA-''''>deprel_to($nodeB)''
 (''deprel_to'' by fungovalo pro sekundární rodiče i pro toho primárního, pro ostatní uzly by to vrátilo undef).
+==== Vizualizace v TrEdu ====
+Pokud se TrEd nepoužívá k editaci, ale jen k prohlížení, dovedu si představit i nějaké "předstírání" jiné struktury, než jaká je ta skutečná interní, a víc zobrazovacích módů. Jednalo by se jen o vizualizaci definovanou v stylesheetu. Přesto bych jako výchozí zobrazovací mód vybral takový, který nic nepředstírá, aby to uživatele nemátlo.
+Primární mód by zobrazoval všechny koordinované uzly jako sourozence (v jedné rovině). U vnořených koordinací by tedy toto zobrazení vedlo k o něco širším (plošším, tedy ne tak hlubokým) stromům než v současnosti (což na širokoúhlých monitorech může být spíš vítané). Uzly s ''is_conjunct'' by byly nějak zvýrazněné. Pokud to TrEd umí, tak bych koordinované uzly dal do společného rámečku, tedy nějak takto
+<html>
+<pre>
+       ------------------ love-----------
+      /     /        /           \       \
+  ---/-----/--------/--        ---\-------\---------
+  | John Mary and Bob |        | bed and breakfast |
+  ---------------------        ---------------------
+</pre>
+<span style="border:1px solid blue;padding:5px;"><span style="border:1px solid black">Simon and Garfunkel</span> or Dylan</span>
+</html>
+Alternativní zobrazovací mód by byl podobný tomu současnému, až na to že (stejně jako v primárním módu):
+  * Společné rozvití by viselo na prvním (primárním) rodiči a ostatní by byly jako secondary dependencies značeny čárkovanou hranou. (V současném zobrazení visí společné rozvití na spojce a je tedy na stejné rovině jako jeho rodiče, což mi odjakživa přišlo velmi matoucí. Toho se teď zbavíme.)
+  * Koordinační spojka by byla na stejné úrovni jako conjuncts. Takže conjuncts i koordinační spojka (čárka) by visely na umělém (přidaném) uzlu.
+<html>
+<pre>
+               love
+             /     \
+       #Coord       #Coord
+      /  / | \         /| \
+     /  /  |  \       / |  \
+ John Mary and Bob  bed and breakfast
+           #Coord
+          /    |  \
+     #Coord    or  Dylan
+    /   | \
+ Simon and Garfunkel
+</pre>
+</html>

[ Back to the navigation ] [ Back to the content ]

Institute of Formal and Applied Linguistics Wiki

Differences