Nodes, Edges und SecEdges in Konstituentenstruktur (tree) sind leer oder werden nicht angezeigt

[Annotation-123]

Obwohl sie abfragbar sind, werden die Label von Knote und Kanten nicht angezeigt und sekundäre Kanten werden nicht abgebildet.

Bei einer Suche nach den sekundären Kanten (z.B.) weden Start- und Endpunkt farblich markiert. Bei einer Suche nach einem bestimmten Knotentyp (z.B. np) wird die entsprechende Umrandung eingefärbt - die Beschriftung fehlt aber.

Das Ganze war sowohl bei Bäumen, die mit Synpathy erstellt wurden, als auch bei solchen, die mit Atomic erstellt wurden, der Fall.

Außerdem habe ich versucht, PointingR über den arch_dependency-viewer anzeigen zu lassen, hier war auch Abfragbarkeit gegeben und es wurden auch der Start- und Endpunkt farblich markiert. Es fehlte aber der entsprechende Pfeil.

Muss vielleicht noch etwas installiert werden?

Der Fall bei:
annis 3.0.1 und 3.1.6
firefox und chrome

[FlorianZipser]

Es könnte sein, dass die Tabelle resolver_vis_map bzw. die Datei resolver_vis_map.tab angepasst werden müssen. Um Kantenlabels für Konstituentenbäume anzuzeigen hgeht ANNIS per default von einem Annotationsnamen "func" aus. Heißen die Labels anders, müsste dies eingestellt werden bspw. mit:
KORPUS_NAME NULL syntax node tree syntax (tree) 0 edge_key:label

[Annotation-123]

Das Umstellen auf cat und func hat das Problem für die Knoten und Kanten gelöst. Gibt es auch einen Begriff für die sekundären Kanten?

[thomaskrause]

Die Annotationen auf den sekundären Kanten müssen den gleichen Namen haben wie die der primären Kanten. Werden die sekundären Kanten denn eingezeichnet und es fehlen nur die Annotationslabel oder fehlen die sekundären Kanten ganz?

[Annotation-123]

Die sekundären Kanten fehlen ganz. Abfragbar sind Start, Ende und Label und Start und Ende (z.B. Knoten und Token) werden eingefärbt, aber die gesamte sekundäre Kante fehlt. Das ist übrigens auch bei den arch_dependeny-Pfeilen der Fall.

[thomaskrause]

Für die sekundären Kanten gibt es auch ein Mapping in der resolver_vis_map. Der Standardwert ist "secedge" und muss dem Kantentyp entsprechen (diesen kann man z.B. durch den "Info"-Link in der Korpusauflistung neben dem Korpusnamen und dann über "Edge Types" finden. Die Einstellung um den Namen für den Kantentyp zu ändern ist "secedge_type", also z.B.

KORPUS_NAME NULL syntax node tree syntax (tree) 0 edge_key:label;secedge_type:mysecedge

Der arch_dependency Visualizer sollte eigentlich ohne Einschränkung alle "Pointing-Relation" Kanten anzeigen können (also die, die in in AQL über den Operator "->" abfragbar sind). Dominance-Kanten kann arch_dependency leider nicht anzeigen.

[Annotation-123]

Ich habe jetzt der Einfachheit halber die sekundären Kanten "secedge" genannt. Unter den Beispielabfragen befindet sich u.a. diese "node & node & #1 ->Attribute[secedge="G1"] #2", bei der die sekundären Kanten mit dem benannten Problem (Kante selbst fehlt) angezeigt werden. Ich versuche jetzt nocheinmal Ihre Variante, aber wenn ich es richtig verstehe, wäre das in diesem Fall ja dann unnötig, weil die sekundären Kanten ja schon secedge heißen.

[Annotation-123]

Habe gerade noch einmal die resolver_vis_map.tab-Datei verändert. Das funktioniert für die Kanten und Knoten, hat aber auf die Darstellung der sekundären Kanten keinen Effekt.

[Annotation-123]

Gibt es dazu mittlerweile eine Lösung? Habe jetzt auch nochmal den direkten RelANNIS-Export aus ATOMIC genutzt. DIe sekundären Kanten sind da, werden aber nicht angezeigt.

[thomaskrause]

Ich glaube wir brauchen zum debuggen ein Beispielkorpus (ein Satz z.B.) bei dem das Problem auftritt. Dann könnte ich näher in die Daten reinschauen und rausfinden warum der Visualizer die sekundären Kanten herausfiltert.

[thomaskrause]

Ok, anhand der Testdaten konnte ich das Problem nachvollziehen. Die sekundären Kanten waren als Pointing Relation modelliert, müssen aber auch Dominanz-Kanten sein um in der Visualisierung angezeigt zu werden. Um den Dominanzkanten den Typ "secedge" zuzuweisen muss man in Atomic die Pseudo-Annotation "t:secedge" an die Kante hinzufügen.

Danach kann man mit

node & node & #1 >secedge #2

danach suchen (also ">secedge" anstatt "->secedge") und die die Tiger-Visualisierung zur Anzeige nutzen

[amir-zeldes]

OK, wenn ich das richtig verstehe, beantwortet das die Frage (tree ist für Dom-Kanten gedacht, d.h. PRs werden dan grundsätzlich nicht dargestellt.). Falls da noch Fragen sind, wie man das im Korpus modellieren könnte, sagt bitte Bescheid.