Changes between Initial Version and Version 1 of Road Map


Ignore:
Timestamp:
10/22/10 17:04:56 (11 years ago)
Author:
beki01
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Road Map

    v1 v1  
     1= PET road map, resulting from discussion at the Paris meeting of DELPH-IN = 
     2 
     3First of all, the list of all completed items: 
     4  * converge main & cm into one new main branch 
     5  * [http://pet.opendfki.de/wiki/ProgrammingStyleGuide code style recommendations fixed] 
     6  * poll for functionality, esp. in input part, has been done 
     7  * no need for a ticketing system other than trac 
     8 
     9This is a list of possible topics to discuss in this session. 
     10Please add topics freely that you feel are missing. 
     11 
     12  * after that: ''refactoring the code'' 
     13    * have a sub-group working out a list of deprecated things 
     14    * get rid of ECL as much as possible 
     15      * remove input modes that rely on ECL, complete MRS treatment as far as necessary 
     16    * remove as much of the load on "item" as possible 
     17    * encourage developers to remove obsolete code and merge similar functionality where possible 
     18    * refactoring into new code style, once it is fixed 
     19    * documentation of (especially new) modules, 
     20      * add scripts to illustrate use 
     21      * necessary resources (data to train / models, training scripts, etc) 
     22    * copyright notice updates ? 
     23  * GUI: which one, desired functionality? 
     24  * XML-RPC / API enhancments 
     25  * put the road map and TODO into the PET trac 
     26  * implement Lohuizen unifier to enable multi thread operations 
     27  * release plans / procedures (LOGON?) 
     28  * include C++ REPP implementation (RebeccaDridan has working code  
     29    --- not 100% LISP compatible yet --- differences not necessarily bugs) 
     30 
     31== Wishlist == 
     32 
     33 * generation 
     34   * MRS equivalence test 
     35   * MRS rewriting (for trigger rules), also used in idiom checking 
     36 * unique output separation for standard-io server mode (requested many times in the past) 
     37 
     38= PET API proposal, worked out at the Fefor meeting of DELPH-IN = 
     39 
     40The idea is to replace the cheap executable (with 'pipe' over stderr...) by a library. The library in turn then could be wrapped in an executable (if someone really still need this), or better in a XML-RPC or other socket server. The library could also be called directly from Java (via JNI) or scripting languages like Python. 
     41 
     42The main motivation is to have a more flexible configuration. Currently, the cheap binary has to be restarted (including time-consuming grammar loading) each time the number of readings to return is to be changed, for example. Using the new API, this option could be modified for each parse individually.  
     43 
     44Moreover, the different configuration sources (command line, pseudo TDL config file, partly true TDL definitions in the grammar) should be unified. 
     45 
     46Generally, no new features will be added, just the implicit interface will be made explicit and streamlined. For example, it will not be possible to exchange the grammar during runtime, as this would require fundamental changes in the code (and is not considered necessary). 
     47 
     48== Elements of the API == 
     49 * basic configuration like which grammar image to load, cheap command line options that cannot be modified at runtime 
     50 * cheap command line options that can be modified at runtime 
     51 * MRS globals (shared with LKB, readable also from file via pseudo TDL parser; cf. JerezTop discussion) 
     52 * parse from preprocessor (SMAF) input, raw text input obsolete? 
     53 * retrieve result chart in different formats 
     54  * MRS 
     55  * MRS-XML 
     56  * RMRS 
     57  * tree 
     58  * HTML (?) 
     59  * typed FS (FS-XML?), with feature path to sub-FS 
     60  * fragments 
     61 * access to type hierarchy 
     62  * sub/supertype 
     63  * type subsumption 
     64  * type name and code 
     65  * FS prototype (FS-XML?), but no feature structure unification 
     66  
     67== Feature requests == 
     68 * configurable start symbol for parsing (FrancisBond) 
     69 * change lexicon during runtime (not possible for the built-in lexicon, but probably for lexDB)  
     70 * change model during runtime