The Erasmus Project

Resources for developers of Bible software

Submitting Material

We are happy to receive submissions of material to include in the library. First, make sure the material matches the following criteria. If so, contact us.

  1. Material must be in the public domain. This means it must have be specifically placed into the public domain by the copyright holder or it must have had an original copyright no later than 1928 in the United States. WE WILL NOT ACCEPT MATERIAL THAT IS UNDER COPYRIGHT. Note the following exception.
  2. Exception: if you are the copyright owner and wish to include your material here, you must have released it to the public domain or else you must agree that it can be used for any purpose so long as it remains unmodified and the copyright is included with it. We will not include material with more complicated restrictions than this.
  3. Material should match the following formatting rules. We might accept material without these rules (our decision), but it will not appear in the library until we have formatted it, and this can take a long time.
  4. Material must be be primarily in English (some original Greek, Hebrew, or Latin might be accepted).
  5. You must indicate the provenance; that is: where you obtained the material (web site, book/magazine name if you scanned it, etc).
  6. Material must be largely unmodified from the original - other than the following formatting rules below and the Text Markup as defined here.
  7. Material should not be overly sectarian or "fringe."
  8. Material must be Biblically relevant and adhere to established protestant hermenuetical principles.
  9. Material should be provided as HTML, PDF, plain text, Open Office, or Word97 for text; BMP, JPEG, or PNG for images; MIDI, MP3, or WAV for audio. Multiple files can be placed into a ZIP archive.
  10. The Erasmus Project makes the final determination as to what it included in the library.

Formatting:

The formatting of erasmus-project text follows some simple HTML layout, with a few modifications. This is detailed in the Source File Layout, but the purpose is to make the text easy to procedurally transform for use in software. The source file layout document also includes guidelines for when various tags and directive ought to be used.

Rules for formatting

The overall goal is to be as true as reasonable to the original published version of the work in question. It is the policy of the Erasmus project not to modify or adjust the meaning, interpretation, or offensiveness of any of the material - even for subtle adjustments. However, it is understood that electronic display of material is often much different than the printed page and some changes in layout - but not content - are allowed and encouraged. Specific rules follow:

  1. Paragraphing. As much as possible, the original paragraphing is to be left in-tact. Sometimes, this may not be obvious from the sources - in which case, best guesses are made. However, if it seems equally valid to place a given paragraph break in one of two places, opt for the one which reduces the size of the paragraphs, even though that will create additional paragraphs. If a paragraph terminates with a colon, semicolon, comma, or dash, use a <br> tag to include the following text in the same physical paragraph even though it may appear, visually, as multiple paragraphs. Of course, if the terminating punctuation is clearly a print, copy, or scan error, it can be replaced with the proper character.
    Paragraphs are indicated by one or more of the following source conventions. 1) A <p>, </p> tag pair, 2) A blank between paragraphs, and/or 3) Use of a directive line.
  2. Spelling corrections. Obvious mispellings and typos can be corrected, for instance, "preist" instead of "priest". But alternate spellings (e.g. "color" vs "colour") should be left unchanged. No archaic language or spelling may be "corrected". Nor should corrections be made for anything that could indicate a stylistic or intepretive choice - for instance the use of "he" or "He" in reference to God is left as-is. However, all sentences should begin capital letters unless there is a very good reason not to do so.
  3. Unicode. Use of ASCII codes above 127 is not allowed. If necessary, use UTF-8 formatting. Only 7-bit ASCII, UTF-8, and Biblos Greek formatting are allowed.
  4. Punctuation. Generally, this is left alone. However, it is allowable for opening/closing apostrophes and quotes to be converted to 7-bit ASCII equivalents. Likewise, n-dash, m-dash, and double dash (--) can optionally be converted to a normal dash (-), although it is recommended that a space-dash-space be used if this is done.
  5. Consistency. Minor inconsistencies in formatting may (and should) be corrected. For instance if a numbered list is numbered inconsistently, this can be corrected. For instance, "1)", "(2)", "(3.)" in the same list could be consistently normalized to just one of those forms.
  6. Words of Christ. There is some minor disagreements about what Bible text to include as words of Jesus for purposes of highlighting/colorization. No Bible text should include specific coloration for text. For words of Christ, the <woc>, </woc> tag pairs should be used to delimit the text. The software using such text can decide whether or not to use it, and what coloration and mechanism is appropriate.
  7. Print vs. Electronic Changes. Some book formatting is specifically related to the fact that the text is in a printed form. If there is a better layout for electronic display, this should be used. Following are some examples:
  8. Images. Images should always include a title indicator with the #IMAGE directive, and shedding information if appropriate. Images that are nested within text should use the <div style="float:"> mechanism to float text around the left or right of the images. However, this mechanism should not be used for interlinears. Rather, use the <block>, </block> tag pair to delimit blocks in interlinears.
  9. Other considerations.