Skip to content

OpenissuesTop

anonymous edited this page Oct 9, 2011 · 8 revisions

Open Issues in DELPH-IN Technology

There are many issues in processing with DELPH-IN technology that require serious research to make progress. Some topics have been discussed multiple times by developers. This page is intended to contain pointers to such topics. Some topics may be of interest to students as potential subjects for research. Each topic has an associated contact person (`mentor') who will be responsible for helping people who may be interested in carrying out the research, at least with respect to its DELPH-IN related aspects. DELPH-IN members supervising students should check this page regularly as a source of potential student projects/direct students to this page.

The role of the mentor

The role of the mentor is not to serve as a thesis supervisor (or quasi-supervisor), but rather to provide a point of contact into DELPH-IN concerns and on-going DELPH-IN activities. Mentors (potentially in collaboration with co-mentors) will create and maintain a page on the DELPH-IN wiki for each topic they take charge of. That page should briefly state the nature of the problem and particularly how it relates to DELPH-IN concerns. Open Issues pages should include pointers to relevant DELPH-IN research and perhaps one or two pointers into the general literature, but are not expected to include extensive bibliographies. Finally, the page should include contact information for the mentor, who should be willing to discuss the issue with a potential researcher. Mentors should `subscribe' to the pages they are in charge of to monitor them for updates.

Open Issues

Grammar Matrix Extensions

Open Issues in Need of Mentors

[The following list was developed during the FeforOpenIssues discussion. Additional topics can be listed here but should also be announced/discussed on [email protected].]

  • Information structure

    • Representation of topic (and focus) in MT experiments
  • Word sense disambiguation

  • CLIM-free DELPH-IN: multiplatform; graphics package we like that works across platforms. Need page outlining current obstacles, and known best practices for future work (e.g., abstracting menus in some way that will be interpretable by multiple GUIs) List of demands on the software -- 30GB memory processes but also laptops.

  • TDL extension: "strict" types (i.e., the ability to require resolution to leaf types)

  • List operations

  • Discontinuous parsing (see LkbLpconstraints for a possible approach)

  • Means of turning of subsets of large grammars to facilitate their initial exploration by new developers

Clone this wiki locally