The following principles were written by Peter Shillingsburg and distributed at the MLA meeting in Toronto, December 1993. They may be used to provide a broader context for the Guidelines for Electronic Scholarly Editions adopted by the MLA's Committee on Scholarly Editions, similar to those which exist for printed scholarly editions.
Please send comments to firstname.lastname@example.org
1. Usability: The Ideal Standard of usability must be that the archive be as easily available as possible to all potential users who have a sufficiently sophisticated computer system to take advantage of electronic scholarly editions. We do not want to make this difficult.
At first I thought that meant that the electronic edition should be packaged and sold or distributed in multiple forms: on floppy disks, tapes, CDs, and laser disks, and with separate forms for Macs, DOS, and UNIX. And in the short haul, I believe that will be the case. It seemed clear that the archive and navigation system as a whole should be designed to take advantage of all the capabilities of desktop computers in their most advanced configuration; but I thought, as well, that the archive must be "available" in some of its basic forms to the least well-equipped user. I suppose that idea results from the democratic principle and the hope that the work of the editor will be available to the greatest number of people. We all know that in the print world, few of us have been able to afford the full-scale scholarly edition of all the works we study. Even our libraries have trouble supplying a whole intellectual community with all the full-scale scholarly editions they should have purchased. So it seemed good to aim for wide distribution of electronic editions.
Reflection suggests that there are serious problems with the idea of distributing electronic editions on disks, CDs, etc.---or at least with the idea of making that the primary mode of distribution---the one determining the standards of data capture and storage.
The first problem with it is the need to create multiple forms for different platforms and different levels of computer power and auxiliary drives. That means duplication of effort for every archive that is created.
The second is that, once distributed, any further improvements to the archive would either be foregone by previous purchasers or new editions would need to be distributed.
A third is that the multiple stand-alone concept requires that each user's computer must be big enough to house sophisticated multi-media software AND the whole archive in order to have maximum utility.
So, at the moment, the First Standard of Electronic Scholarly Editions appears to be: That Electronic Scholarly Editions be Data Bases attached to a Network. There are a number of distinct advantages to this thought.
Of course, archives could be made available whole to users capable of handling them, and spin-offs in the form of disks, CDs, and even printed texts could be produced as publishers or purchasers saw the need or opportunity.
2. Transportability: The largest problem for the concept of electronic editions when approached from the tradition of print editions---each user with a single final copy of the work---is that nothing, at the moment, is platform-independent: if it works on UNIX, it won't work on DOS or Macintosh. The software system and the archival materials for Electronic Scholarly Editions should be PLATFORM-independent.
At the moment Network Access seems to be the most feasible long-term way to achieve platform independence. I say long term because the networks are currently unable to carry "real time" video, but that will change before long. In addition, we should be looking at progress in the handshaking department between IBM and Macintosh which make it possible to use a single machine in either mode. That may be another solution, but it would be available only to persons with the "right" kind of machine, and that is a concept I would nudge us away from.
The question can be seen as an alternative between developing an EDITION that is available in a different form for each platform, or of developing ACCESS to the Edition from many platforms. I favor the latter.
Because HyperCard for Macintosh and ToolBook for DOS and VNS (Virtual Notebook System (Rice U.) or MOSAIC (U. of Illinois) for UNIX and other hypertext and multimedia authoring systems have been developing, as they must, for specific platforms, it has been natural to think of developing an archive with one of these software and hardware configurations in mind. DynaText has recently been touted as a viable alternative, for it has a different version for each of the three main operating system. But it is currently proprietary (expensive) and lacks some of the graphic capabilities of other systems. No system to date incorporates collation capabilities with graphics. But the standard we aim for must in some sense be universal. And it may be that ACCESS to the editions rather than the EDITIONS themselves is what needs to be Platform-Independent.
Once we find or develop the adequate software authoring and navigational software---adequate in the sense that it lets us do all the things that users of scholarly electronic editions want to do---then the Archive version of the software and the User versions of the software can be linked. Users will have software resident at their personal work stations, the network will connect them to the individual archives, and the data-base version of the software will make use of the archive available regardless of the platform (hardware) the user happens to have.
3. The design of the system and the storage specifications for the archived materials must anticipate the desires of the community of textual critics and scholarly edition users:
4. Security and order: A system for protecting the original archive from user alteration must be combined with an orderly system for identifying user-created copies of any parts of the archive. The original materials must maintain integrity, but users must be free to create alternative versions. New versions should be AUTOMATICALLY and PERMANENTLY identified as new versions, NOT ORIGINAL.
5. Integrity: Archival materials must be linked to specific material sources. Provisions should be made to maintain and enhance a source copy of each scholarly edition. It seems ideal that each archive remain in process, but that the maintenance and improvement of each archive be centralized.
6. Expandability: The archive must be expandable: by the archive owner or compiler as new materials and new links seem appropriate; and by users in a parallel commentary field or bulletin board.
7. Hardcopy capability should be available for "on-demand" publishing. (The question of whether a user should pay for the privilege is separate from the question of whether the capability should be there.) This relates to the current debate about the future of hard-copy scholarly editions. The need for printed texts will continue, but an ideal electronic scholarly edition may make the printed scholarly edition obsolete. A printed text would come to be thought of as one possible version of the work more fully represented by the electronic archive.
8. The "Navigation" system should provide a user-friendly set of options and indications of the availability of the links described in section 3. It should enable a user to retrace a session's use of the archive. It must provide a way to "get back" after chasing a particular line of inquiry through several levels of the hypertext. Likewise, it should be designed to keep the user easily aware of "where" the local viewing scene is in relation to the archive as a whole. In a printed book, one always knows how far one is from the beginning or end of the book. In electronic environments the size of the whole and one's place in the whole should also be readily knowable. Further, in a printed book one can leaf forward or backward or skip forward or backward, while in the electronic environment one can move anywhere and it appears that one has moved only one screen away. There are other ways to imagine the feeling of lostness one can get in the electronic environment; this merely points to the problem.
Please send comments to email@example.com