JMdict/EDICT/etc. Maintenance System

(This is intended to be a user-oriented "big picture" without technical, database, language, etc. issues adressed.)

BROAD GOAL

The goal is to have the master file for JMdict/EDICT as an online database capable of:

• supporting the editing of existing entries and addition of new entries by users via a WWW interface;

• providing regular, e.g. daily, generation of JMdict, EDICT, EDICT2, etc. files for distribution and use by other applications.

• enabling the amendment/new-entry to managed and controlled by a self-perpetuating group of editors.

THE EDITORS

There would probably need to be three groups of people (with overlapping membership as appropriate) who would collectively be in charge.

1. two or more sysadmins, who would hold the root password, provide overall management of the host server(s) and install software packages, carry out major reorganizations, etc.

2. a number of editors who can examine proposed new entries and amendments and approve them, reject them, modify them. Editors would be appointed by invitation.

3. a small group of senior editors (maybe 2 or 3) who would also be able to appoint new editors, resolve disputes between editors, and in drastic circumstances remove editors.

TYPICAL USER INTERFACE

A user would typically submit an entry or propose a new entry via an HTML form, which in the case of an amendment would be preloaded with the existing entry. For amendments the entry would typically be identified by the entry number, enabling other applications to have "Edit" hyperlinks point to the update system, e.g. http://www.edrdg.org/entedit?db=jmdb&entno=12234560 The entry number is available in the JMdict and EDICT2 files and could be added as an option to the basic EDICT file too. Such "Edit" links would/could be in WWW systems such as WWWJDIC, Jeffrey's Server, Ice Mocha, Denshi Jisho, etc.

The edit screen could optionally allow access to a record of previous changes to the entry, comments by the submitter, editors, et al.

New entries would be handled in the same way, except that the form would not be preloaded.

Having submitted an entry/amendment, a user would be given a transaction number, and through another screen would be able to query the progress and outcome of their submission.

Users would not be required to create accounts, log in, etc.

THE UPDATE PROCESS

Once an entry/amendment is submitted, it would be placed in a work-in-progress area, and at that stage would only be available to the editors. Once an amendment is approved, the new entry would "go live" in the database, and the previous contents of the entry would go into a backup area where it could be viewed and from which, if necessary, the update could be reversed. A short-form summary of the update and submitter/editor comments would go into a viewable audit trail area associated with the entry.

EDITOR INTERFACE

Editors would have a log-in system. Once logged in they could see any submissions awaiting editorial inspection and approval/rejection, and could select or be allocated entries to work on.

Editors would also have access to lists of recently added/amended entries (with links to the full entries), and any other bells and whistles that might get added.

Editors could, of course, submit entries and amendments of their own, but these would need to be seen and approved by another editor.

Some sort of cooperative system would be needed to allow an editor to dispute a decision by another editor, and achieve resolution of such disputes.

BULK UPDATES

Some facility should be provided for the addition of batches of entries prepared offline, or extracted from another source.

Also there should be the facility for the bulk application of modifications. A "sandbox" system for testing such changes would be appropriate.