Here, in no particular order, are some responses to the current discussions:
1. Divvying up the translation
Several folks have volunteered for a whole letter. I'd rather go by subjects
because I think it would be easier to get up the relevant vocabulary and
background for a single area (about which one already knows a certain amount)
than to have to make sense of, say, Airplane, Apple, Apple Computer, Anatomy,
and John Quincy Adams. Not everyone may need this simplification, of course!
Sure, a managing committee and several standing satellite committees sounds like
a sensible organization. I'll join the technical committee, if volunteers are
being solicited; that's where I can do the most good (I've been a programmer
far, far longer than I've been a Hellenist).
3. Software ownership
I agree that it's appropriate that the underlying code be publicly available. I
am not thrilled about the GNU copyleft, but recognize that this is a standard in
(some segments of) the software community. My objection is philosophical and
ethical: I do not feel that it is wrong for the company I work for to sell its
software products, nor that it is wrong that I be paid for producing them.
Another possibility might be, as David Meadows proposed, to form a corporate
entity of some sort that would hold copyright to the software, perhaps in some
sort of partnership with UK as appropriate. This copyright holder could then
make the code available in much the same way as the Suda text will be
available: in a book, on an FTP server, whatever. Bottom line: yes, openness
and availability are right, and I've said all I have to say about ways and
4. Implementation details
Obviously, as Max Christoff probably knows as well as I do, it doesn't matter
what language one uses. That choice should be made based on availability of a
compiler for all target platforms and convenience in the language of what one is
trying to do. Given completely free choice, I'd pick PL/1 for what is largely a
text-processing application. (Those who really care why I think so can email me
off-list.) I'm much more concerned with the database storage and retrieval than
with the display, because I expect that's a larger part of the job. One
decision that might be made up front is whether to convert from storage form
(possibly SGML) to display form (PDF or HTML or whatever) on the fly, or to
"compile" the various entries ahead of time. This will depend on how things are
to be displayed. If I'm browsing the Suda for amusement (and, yes, people will
do this), I'll be selecting whole entries to be displayed. If I'm searching for
keywords, will the search results present the whole of each relevant entry, or
just a one-line "teaser"?
Which leads to
I think it's time to start thinking about how we want SOL to work. We already
know that we want to display the text of the Suda, in English, on the Web. We
want an attractive display, consistent with the viewer's equipment and
preferences. We want to provide more information than just the raw text, and we
want the reader to be able to tell what's Suda and what's added.
I think we also want search capabilities. Perhaps some access to the Greek text
would be useful. The issue of alphabetical order has already come up: maybe we
want to be able to list entries sorted by the Greek alphabet, by the
transcriptions in the Roman alphabet, or by the English rendering of the
lemmata. Bill Hutton's prototype page also allows a notation of how far along
an entry is in the review process, and who worked on it.
So I think several informal, working design documents might be useful at this
a. SOL from the reader's point of view (what does www.suda-online.org look like
on your screen and what can you do with it?)
b. SOL from the editor's and translator's point of view (how do we get texts
into our database, and what information do we want to have along with the raw
c. SOL from the systems point of view (what are we storing and how big is it?
what tools will we need? do they exist in adequate form?)
I'm still thinking about "user requirements" stuff, not detailed
implementation-level design. As we're designing our human organization, we can
also be working on the organization of our raison d'e^tre. I'll undertake to
make a start on (b), if folks think this makes sense, secure in the knowledge
that I'll get all sorts of useful refinements from all of you.