Closed amir-zeldes closed 4 years ago
ANNIS 3 is also removing pointing relations where the source or target node is not part of the subgraph. The difference to ANNIS 4 seems to be, that there are SSpanningRelation instances that are part of the "ref" layer in GUM that are not available in ANNIS 4 yet.
Thanks for looking into this, but I'm not sure I understand - why would the source (or destination) spans from the ref layer not be available? The entity annotations connected by these edges are showing up fine and are searchable, and the edges are too. Only the behavior of the visualizer triggering seems to be different.
The visualizer is not triggered by the pointing relations, but by the coverage edges. The coverage edges for the "entity" nodes belong to the layer (or "edge_namespace") "ref" as well. E.g. in the line
1169 c ref NULL
in the components.annis of the GUM corpus you can see such a named coverage component. When iterating over all edges of the subgraph, the coverage edges from the entity span to the tokens are included and their edge_namespace/layer "ref" is added to the general lists of edge layers for this subgraph. The visualizer triggering does not differ between the edge types (coverage, dominance, pointing) but just that there is an edge of any type.
ANNIS 3 also did not include edges where one of the referenced nodes is not in the subgraph, as it was also reported in korpling/ANNIS#83. This is consistent with the behavior of ANNIS 4. The difference is, that the relANNIS import of ANNIS 4 does not use the edge_namespace/layer when reconstructing the rank-table entries that are omitted for performance reasons, but just uses a the empty string as component/edge_namespace/layer name.
In conclusion this is an inconsistent behavior of the graphANNIS relANNIS importer for these reconstructed coverage edges. I therefore would transfer the issue to the graphANNIS repository and fix the bug there.
I see... So the 'edge' instruction was triggering on a coverage edge, not a PR... I never would have guessed that, since I always thought of the c edges as more of an artifact of the RDBMS scheme, but of course they are SRelations, so that makes sense. If the fixed behavior solves the concrete issue of the visualizer not appearing then I guess this is all fine. Thanks!
In ANNIS 3.x, specifying 'edge' as the triggering condition in resolver_vis_map renders the visualizer even if only one end point of the edge is in the search result. In 4.0.0-beta.2, it seems the visualizer is only rendered if both source and target of the edge are in context. This is problematic for visualizations like coref, in which both end points of the edge are often far.
To see the difference in behavior, compare results for
entity
in GUM for ANNIS 3 (show coref for all hits) vs. 4 (only if antecedent happens to be in context). The resolver entry is: