Future System (Was: Moving forward .....)

[Jim Breen <Jim.Breen@**********************>]

[Jim Breen ([edict-jmdict] Moving forward (Was: bad entries in submissions)) writes:]
>> [Jim Rose (Re: [edict-jmdict] bad entries in submissions) writes:]
>> >> ............  So stating the objectives formally in writing, and then  
>> >> picking somebody to have first crack at meeting them is my suggestion.
>> 
>> I think I've roughly mapped that out in the past, but in the next couple
>> of days I'll try and spec what I think is needed and we can discuss it.

OK, here goes an attempt at a rough outline.

==================================================================
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
=======================================================================

I'm running out of puff, and I need to go and weed my veges. Let's
see how that goes for starters.

Cheers

Jim

-- 
Jim Breen                                http://www.csse.monash.edu.au/~jwb/
Clayton School of Information Technology,               Tel: +61 3 9905 9554
Monash University, VIC 3800, Australia                  Fax: +61 3 9905 5146
(Monash Provider No. 00008C)                ジム・ブリーン@モナシュ大学