The reader may take away five important lessons from the project:  1) planning is crucial, 2) experience counts, 3) choose wisely, 4) be flexible, and 5) keep a sense of humor. 

3.1  Planning is crucial

Digitization requires a material long-term financial investment, and pulls on often limited organizational resources.  Common sense dictates that results be planned well, and measured to make the return on the initial investment imminently clear.  Tools like a project schedule, a prospective budget, a mid-project review, and a plan for a file naming convention served to ease the project's execution.The reader should have a roadmap to where he or she is going. The timeline used in the project, shown in part in Exhibit 3.1, helped the author to frame the project by letting benchmarks lead the way.  Instead of wondering through the project what remained to be done, the author needed only refer to the Project Schedule. That is of particular value later in the project when the tsunami of fine details and unresolved issues press to take over the project.  A project schedule is a valuable way to stay on track.

 Exhibit 3.1:  Excerpt from Project schedule  (in U.S. dollars)

Planning a notional budget upfront forced the author to reflect upon actual inputs to the project. How much would be needed for office supplies, long-distance calls, or extra equipment?  Have a small amount of contingency funds been imbedded into the budget to cover inevitable surprise expenses, like the subscription to FastSum Integrity authentication software?  A working budget forces one to ponder the various pieces which go into the effort.

A plan to evaluate day-to-day journaling of activities mid-point through the project helped enormously in planning the second part of the project.  By keeping a log to which one could refer mid-point, the author was able to pinpoint logistical problems immediately, and prepare for their resolution in the second part of the project.

Inadequate planning on the author's part in arriving at a file naming convention meant repeating tasks four or five times, which would have been avoided with better preparation, and saved lots of time.  Files were renamed 6 times before an adequate name construction could be used, shown in the example, below, Exhibit 3.2.  First, the files were named for consistency, by family surname, to provide some order to the chaos. Then, it became clear that some unique object identifier was necessary to reduce confusion regarding similar documents.  Thus, a taxonomy was born to assign numbers to each file.  The unique identifier consisted of an assigned surname number, a generation number, a unique individual number, a document type, then the numbered order of the document type.

In the example in Exhibit 3.2, the Civil War Pension record JPEG file, was assigned the number 23 because the first individual bearing that surname in the pedigree chart was numbered 23 (Rosa May Wilhelm); that Phillip P Wilhelm was the sixth generation back, his unique individual number on the pedigree chart was 46, the document type was a military record assigned the number 7, and it was the first of its kind.

 Exhibit 3.2:  Iterations of one file name for a Civil War Pension record

But then the filename became too long.  File naming outlined in the project's initial research proposal dictated that the ISO 9660, Level 2 convention for naming files would be followed, as mentioned before in section 1.2, which allows file names of up to 31 characters.  In file naming, only lower case characters a-z, numerical digits, and special characters period, underscore, and hyphen would be used.   Spaces or any other special characters would not be used.  Thus, the file name was shortened in its third iteration.

For its fourth iteration, a new name was needed because the new low resolution surrogates of the digital master files needed a name, which would actually be uploaded to Greenstone.  The suffix 'lo' was appended to the file name, still within the 31 character limit.  Then, after creating, building, and previewing the Greenstone collection, the author learned that the term "page" in the filename, confused Greenstone, and aborted compiling of the library.  Thus, in its fifth iteration, the term 'page' was removed from the file name.

Finally, the author learned that Greenstone reads a file name up until the first period to extract the name of the file, and then stops reading the name.  Typically, one would call a file filename dot JPEG, or filename dot BITMAP, and so forth.  But Greenstone stopped reading the filename after the first dot, which in our example was 23.  Thus, the file name was recorded in Greenstone as 23 along with all other files prefixed '23,' excluding the rest of the file name, creating confusion for the user with multiple files titled "23."  Therefore, in its sixth and final iteration, periods were removed from file names to allow Greenstone to properly index the entire name of the file. 

Through each iteration of renaming files, all associated metadata needed to be reloaded, as well.  It wasn't just a matter of renaming one file. The new digital library designer would do best by testing a small sample of about 5 files, and running them through the whole process, including compiling the library, before naming all files.  Technical anomalies as with the term 'page' or the 'dot' were unavoidable.  But beware of rushing into a project without giving serious thought to planning the file names.

Time invested in planning upfront nets tremendous savings later in the project.

3.2 Experience counts

With that thought in mind, lesson 2 teaches us that experience counts, or rather that inexperience can result in painful revisions and delays. 
Problems encountered in the project were, perhaps, typical of a first effort in creating an online digital library collection.  Problems arising from inexperience in digital project planning, as mentioned, and problems of a technical nature were common in the effort.

Inexperience in prepping the documents and retaining their provenance added time.  With little training, creating a taxonomy for the first time added time.  Understanding new and complicated standards, like the TEI-P-5 Guidelines, added time.  Poor equipment selection added time in requiring that some documents be outsourced.  Inexperience with Library of Congress Subject Headings meant long and laborious dissection of appropriate headings for collection objects which added time.

Several technical problems resulted from inexperience. Resolution of scanned images was of mediocre quality due to the age of the scanner and poor technique, and troubleshooting the Greenstone Library Interface in constructing a basic digital library with Greenstone was an ongoing battle that a more experienced builder would not have had to endure.

The free, open access, Greenstone Digital Libray software is a welcome solution to many collections, which would otherwise not be mounted to the World-Wide Web were it not for Greenstone.  The power of posting to the world an item plus its full bibliographic record for later data harvesting, is the stuff of which librarians dream.  But the amount of difficulties surmounted, and the limited support documentation made the selection one to reflect upon.  Greenstone proved a very cramped space in which to build a repository for a beginner.  Its assets are great for universality of metadata but at a high cost.  Dated and unreadable user manuals meant repeated combing through computer-ease written in awkward English. 

Grand designs of "reading rooms" or side-by-side ASCII text translations for each object in an An American Tale, FAQ's, a Contact Us page, Chronological Lifeline, and User Guide all fell flat with hard to understand capabilities served up in Greenstone. If the author were to embark on the same project again, the author would have invested more time in learning more about the potential of other content management systems like DSpace, WebPress, Drupal, Mambo, PostNuke, or Plone.  They may not explicitly be identified as "digital library" software, or automatically support library standards like MARC, Dublin Core, or the Open Archives Initiative Protocol for Metadata Harvesting, but their features and documentation may be better suited for the non-programmer, at a first-strike effort in creating a digital library.

3.4 Be flexible

Revisions during the course of the project meant a better end-product. Original scanning techniques were changed mid-project to improve clarity.  Tighter chronological groups of records meant more refined presentation.  Outsourcing oversized documents meant inclusion of critical objects. Therefore, flexibility resulted in a more polished digital library.

Above all else, the reader should remember to try to maintain a sense of humor.  The task of mounting a digital library to the World-Wide Web is no small feat.  The ability to stand back and laugh at one's foibles or mishaps will only aid to keep the project on track, as well as its creator.