El dv 01 de 04 de 2011 a les 10:53 +0200, en/na Kevin Brubeck Unhammer va escriure: > Mitchell Jeffrey <[email protected]> writes: > > > [...]
[...] > > > Additionally, some items in > > the grammar will be rule-based while others may (perhaps in future) be > > probabilistic. > > I would leave out that sentence. The bigram tagger does statistical > disambiguation, I don't see how anything probabilistic within the CG > module could be more than a hack. Agree, no need for statistics here. > > Consideration will need to be given to how the parser design affects > > end-user usage for users as well as grammar writers, and should > > include facilities for testing, debugging and optimisation of > > constraint grammar definitions. > > > > ## Deliverables & Schedule > > The primary focus of this project will be to design, implement (in > > C++), integrate and document a language-independent CG parser, and > > also to specify the XML grammar standard it will accept. Most of the > > time will be spent on detail item (5), with the expectation that much > > of the other functionality will already be available elsewhere within > > Apertium. > > > > 4 week community Bonding: Reading around the subject area and > > acquiring specific skills such as C++, parser design, language > > processing and computational linguistics If you don't already know C++ then this is not the time to learn it. The best thing would be to code a prototype in Python -- paying attention not to use any language specific features. Then later you or someone else can port it to C++. You need to think about which existing finite-state library you want to use to build the automata. It would be good to give some theoretical details on how you are planning to represent the sentence, and the rules. > > 12 week coding period: pursuant primarily to detail item (5) > > 1 week sprint: final polish, debugging and documentation effort > > I'd like to see a more detailed plan, especially wrt. which features > should be implemented and prioritised. Some of the CG functions > implemented by e.g. vislcg3[1] are a lot more important than others, so > think about the feature set and test cases for that. E.g. LIST, > SELECT/REMOVE, star (*), BARRIER, Careful (C) are important. Things like > spanning window boundaries, setting marks or making dependency trees > should be deferred until much later. Unification is possible to avoid by > just writing more rules. Exactly. Fran ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
