Hello, Ratnapharki's (1999) is a shift-reduced parser. Others like Stanford NLP are now releasing shift-reduced parsers. There are differences between them, though. For example, Zhang and Clark (2009)'s parser (cited by Stanford's new parser) is similar except that they use a global discriminative model applying Collins (2002) perceptron, whereas Ratnaparkhi’s parser has separate probabilities of actions chained together in a conditional model (based on ME).
Perhaps that route, among others, would be an interesting one to have a new parser in opennlp. Cheers, Rodrigo On Sun, Jun 22, 2014 at 9:44 PM, Richard Eckart de Castilho <[email protected]> wrote: > Some time ago I asked the mstparser developers if they would consider > contributing the parser to OpenNLP. They said that mstparser isn't > up-to-date anymore since better parsers are now available, but in > principle didn't reject the idea. > > If OpenNLP was interested in adopting the mstparser, that might > be something to follow up on. > > The mstparser is only a dependency parser, not a constituency parser > as the one currently included with OpenNLP. > > Cheers, > > -- Richard > > On 20.06.2014, at 09:33, Jörn Kottmann <[email protected]> wrote: > >> On 06/19/2014 06:00 PM, Miller, Timothy wrote: >>> There is a paper at this year's ACL conference on a statistical parser >>> with some interesting properties [1]. I tracked down the software [2] >>> and it is apache-licensed (unlike most other high quality parsers such >>> as the Berkeley and Stanford parsers). It is written in Scala so in >>> theory it should be compatible. Most importantly it is about as accurate >>> as those state of the art parsers on English (about 33% error reduction >>> from the Ratnaparkhi parser that opennlp currently uses), and may be >>> superior for cross-language performance. >>> >>> I am going to play with it with some of our clinical data to get a feel >>> for speed/accuracy on clinical text. Just curious if there is any >>> interest in a wrapper for this parser in opennlp? >> >> I don't think a wrapper is interesting for us. If people want to use this >> parser it is probably >> better if they integrate it directly or use a component framework like UIMA >> or GATE. >> >> Anyway, getting a new parser as a contribution would be interesting. >> >> Jörn >
