karuiwu
commented
11 years ago -
Using the first approach, we can have a single "revision operator" for improving accuracies of intransitive and transitive verbs that can be generalized to any word that both can and can't take a certain child.
As an example, let's use the sentence, "As he reports the town runs home".
The verb "reports", exists as both a transitive and intransitive verb. It may make sense to take an object and it may not, depending on the remaining words in the sentence. ZPar made the mistake of attaching a right child to "reports" in a similar sentence, which created other errors (ROOT attaching to "home", "runs" not taking "home" as an object). [Jason says: in an email, I cautioned to not make the revision operators be dependent on the parts of speech or anything linguistic, although the features that help us choose among revision operators could be.]
The revision operator I'm thinking of would allow any reachable right arc from an intransitive/transitive verb to be removed (and never allowed to be added again); and when I say reachable, I mean an arc that when removed, splits the item on the stack into two. As it is, I wouldn't call it a revision operator, but it may inspire or be combined into other ones. I mentioned before that this operator may be more generalized, so a phrase such as "old man" in "The old man the boat" could also be split by this revision operator, given that "old" could be a standalone word.
- Using the second approach, we can add an additional item to the stack and queue, which is a "predictive item". Essentially, whenever a word is shifted onto the stack, "predictive items" will also be shifted onto the stack, which corresponds to potential children of those words. Any time an arc is created, it must match a predictive item (and perhaps there's some leeway). Using this, we can constrain the arcs being created (i.e. so ROOT cannot take certain types of words). Moreover, this additional item would support the creation of additional revision operators, which have easy access to more information about each of the words/what potential beams could be extended without maintaining multiple beams (the predictive item would hold that information). I may have to explain this more if it sounds promising. As an afterthought, this feels a lot like CFG constraints.
There are many possible sets and constructs of revision operators for arc-eager dependency parsing. Our goal at the end of two weeks is to have designed the most optimal set of revision operators given the July deadline.
One approach to brainstorming is to think about the constraints introduced by arc-eager parsing, namely that SHIFTing prevents future left children and REDUCing prevents future right children being attached to the top of the buffer and stack respectively. The revision operators would be centered around loosening these constraints -- the question is to what extent and how much general accuracy will be increased? (1st approach)
Another approach is by visualizing the in-between parses beyond that of words and arcs on a stack and a queue. For example, what if the items on the stack were individual trees? Would this enable other types of operators to be created while maintaining the validity of existing operators? (2nd approach)