RE: [edict-jmdict] Future System (Was: Moving forward .....)

["Stuart McGraw" <smcg4191@********>]

Jim Breen wrote:
> OK, here goes an attempt at a rough outline.

Specific questions interleaved below. .

First, thanks for writing this.  It mostly matches my 
understanding but clarifies some details that were a 
little vague before.  The auditing stuff will require more
database support.

But I don't see anything about development process here.
This description describes the external behavior of the 
entire system. Also, I posted previously about requesting 
a top-to-bottom, ready-to-go, complete (or nearly complete) 
application.  It seems like that is what is being requested 
here (due to lack of any development process discussion.)
It also seems to imply an app-centric design rather than
a data-centric one (nothing wrong with that of course...)

A few days back I posted an offer to put the stuff I have 
developed so far on your development machine to allow 
you and other to play with it (since the barriers to installing 
locally are pretty high) but I never got a response.  So I 
had hoped you would address the development process 
in this message.

>[...]
> 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. 

How deep is this undo stack?  Just the most recent change?
All changes?

>[...]
> 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.

Email?  IM?

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

A bulk loader (aka bulk importer)?
Presumably you will have whatever was used to load the 
jmdict.xml file into the database initially which can also 
be used (or easily modified) to load additional jmdict-xml 
formatted data.  Is this enough, or do you also want 
something that will import edict-style entries?  (Last time 
I looked I thought there were many, many slightly varying 
edict formats.)

Or, alternatively, by bulk updates do you mean changing 
existing entries en masse?  For example splitting an existing 
PoS into two, and updating all the entries tagged with the 
old PoS to the appropriate new one?  Such a bulk updater 
comes with the database, it is called SQL.  :-)
If there are updates that happen frequently enough that SQL 
is cumbersome, them one would need to know more details 
first.

>[...]