NAME

Treex::Core::Coordination

VERSION

version 2.20150928

DESCRIPTION

Coordination is an object that collect information about a coordination structure in a dependency tree. It knows all nodes involved in the coordination, i.e. it holds references to the corresponding Node objects.

conjuncts (root nodes of subtrees that represent a conjunct and its dependents)

orphan conjuncts can be distinguished: ExD orphans of deleted real conjuncts

delimiters (conjunctions and punctuation delimiting conjuncts, such as commas)

conjunctions can have their own private dependents (multi-word-conjunctions such as Czech "nejen-ale"; comma-conjunction pair etc.); then, we link to the head node of the conjunction subtree

shared modifiers (root nodes of subtrees that depend on the whole coordination, either linguistically motivated (e.g. shared subject of three verb conjuncts) or a technical rule (e.g. attach quotation marks to the root of the text between them))

private modifiers (direct dependents of any conjunct, or, in exceptional cases, of a delimiter)

All this information is stored independently of the current parent-child relations in the tree, i.e. independently of the scheme currently used to represent a paratactic structure using dependencies and labels. The Coordination object is thus useful to collect and store information about coordination during its transformation between two schemes.

Nevertheless, there are methods that can use the current parent-child links and labels to identify the nodes participating in coordination and to register them within this object. And there are other methods that can relink the current nodes using a particular annotation scheme.

Important:

Logically, participants and modifiers are subtrees. We store references to the current root nodes of the subtrees. If the inner topology of the subtree changes our references will no longer be valid. We may still be pointing into the subtree but we will not hold its local root. In particular, if the participant or modifier is a nested coordination, it is covered by a separate Coordination object, and a method of that object is invoked to reshape the coordination according to a particular annotation scheme, our reference will get broken.

This issue requires special care when manipulating coordinations. We have to be aware of what we are doing outside the Coordination object and that it is rather short-lived.

A possible partial solution would be to setup a function that handles root changes. The node we refer to would get a reference to the handler as a wild attribute. Coordination-aware transformations could call it when they downgrade the node within its own subtree. We would still be vulnerable to other manipulations from the outer world. The handler would get references to the old and the new root of the subtree. Wherever it would find reference to the old root in the coordination, it would redirect it to the new root. It would also have to change the list of its private modifiers (which could be even conjuncts of the nested coordination; as long as they do not participate in our coordination, it is OK).

Another partial solution would be to define an abstract object class that could be either Node or Coordination. Lists of participants and modifiers would refer to objects of this class instead of just Nodes. If a nested coordination was detected, the target object would be a Coordination.

METHODS

AUTHORS

Daniel Zeman <zeman@ufal.mff.cuni.cz>

COPYRIGHT AND LICENSE

Copyright © 2013 by Institute of Formal and Applied Linguistics, Charles University in Prague

This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.