Master Encoding Guide: Length

Record Content: Length

Many records will include the document length, generally on the third line, below the author and recipient line. The convention most records will follow is an Arabic number and "p." for "pages." All text on this line should be coded as <length pages="3">. If there are multiple page numbers listed to signify a letter and an enclosure, the pages are added up and entered as one value.

For example:

<length pages="4">2 p., 2 p.</length>

Master Encoding Guide: Code

Record Content: Code

About half of all records include a code found on the upper right corner of the slip. The codes are used to track individual accession documents, letterbook documents, or diary and miscellany documents. The codes are a combination of letters and numbers. The vendor was asked to encode all of this text with <c> and we later ran an XSL transformation to parse out the distinct pieces of information. This will allow us to track the documents by their accession and letterbook numbers as well as to separately track the institutional codes for accesssioned documents.

There are four types of codes and each one is also associated with slip color: letterbook=white, accesssion=yellow, diary=pink, and miscellany=pink.

Letterbook codes all begin with "Lb" and have up to a five-digit number following it. These slips are white (<record color="3white">). They have an optional @author as well, but this is only rarely applicable:
Example:

<code type="letterbook" number="1234">Lb1234</code>

<code type="letterbook" number="21" author="JQA">JQA/Lb/21 [end]</code>

Accession codes are made up of an insitution code (where the original is housed and from whom we received a copy) and up to a six-digit number (the document tracking number). These slips are almost always yellow (<record color="2yellow">). Occasionally, an accession code is found on a blue slip. This is considered an editor error in the creation of the slip and will be reconciled later. The code should be rendered the same.
Example:

<code type="accession" repository="DNA" number="2589">DNA:2589</code>

<code type="accession" privateowner="MBSmith" number="2589">MBSmith:2589</code>

Miscellany codes are essentially shelf marks for their physical location, constructed with M for Miscellany, initials (usually JA or JQA) for the author, and a number for the volume.
Example:

<code type="miscellany" author="JA" number="78">M/JA/78</code>

Diary codes are also essentially shelf marks for their physical location, constructed with D for Diary, initials (usually JA or JQA) for the author, and a number for the volume.
Example:

<code type="diary" author="JQA" number="12">D/JQA/12</code>

General codes. Some slips, usually blue, have a code associated only with an institution but do not have a number attached because we do not have a physical copy to accession and track.
Example:

<code type="general">NN</code>

Master Encoding Guide: Place

Record Content: Place

If a place is included on the slip, it will follow the date on the top line. Place names should be transcribed as they appear, either abbreviated or spelled out, tagged with <place> element. Place names are controlled through two attributes: location and axis.

Required Attributes

@location.
If a place name appears on the slip, it is usually rendered exactly as it appears in the document, therefore "The Hague" might be written in the French, "La Haye," if it appeared that way on the original manuscript. The value of the @location should have the English spelling of the city only. Any other place information, for examle a street address, will be found in the text of the record. If two city locations are included, both cities will be listed as the value of @location, separated with one white space. When there is a question about the proper English spelling of a city, consult the Getty Thesaurus for Geographic Names.

Example: <place location="The Hague">La haye</place>
<place location="Philadelphia">Philadelphia, 32 South Street</place>
<place location="Braintree Quincy">Braintree and Quincy<place>

Most of the city names have been automatically populated using XSL transformation. Encoders need to just check that the values are English city names only.

Optional Attributes

@axis.
There is an optional attribute to include the axis point for a given location. This information is provided in the Getty Thesaurus. The rules for encoding the longitude and latitude axis points will be determined during encoding level 2.

Still Proofreading... but Encoding Begins!

It has been a busy couple of months since the last post. While continuing with the proofreading, which has taken much longer than originally estimated, we have developed a full schema (also in RelaxNG) for encoding the data and have hired a consultant to develop some nifty XSL transformations to move the data from our short vendor schema to the full schema. Following this post I will begin uploading the master encoding guide that provides a detailed narrative of each element and examples of the mark-up.

Master Encoding Guide: Dates

Record Content: Dates

<date> The date element is the most important piece of information on each slip. The physical card file, as well as the physical archive collection and the microfilm, is arranged chronologically. It is the first access point to the documents. It is also the most complicated, due to the variety of date formats and the rules regarding sorting. The date section of the full schema is derived from the unique dating structure of the control file, as it was originally organized and inventoried. As noted above, all text in the date field is retained as is and the attributes control the data for sorting and searching.

Required Attributes
The <date> requires a choice of one of the following attributes:

@when.
The most comment type of date found in the control file are exact dates with a known day, month, and year. These are controlled in the @when with a date parameter of year-month-day (YYYY-MM-DD). If either the month or day is uncertain, encode the @when with "99", i.e. YYYY-99-99. This will allow for proper sorting—complete dates come before incomplete dates.

Example: <date when="1771-12-21">21 Dec. 1771.</date>
<date when="1776-07-99">July 1776</date>

@when and @ante.
Any date that is known to be written before a certain date using the term "ante." These are also controlled with the standard date parameter year-month-day.
Example: <date when="1790-07-11" ante="ante">ante 11 July 1790</date>

@when and @post.
Any date that is known to be written after a certain date using the term "post."
Example: <date when="1790-07-11" post="post">post 11 July 1790</date>

@when and @to.
Any range of dates with a known beginning and end. These elements must be used as a group.
Example: <date when="1790-07-11" to="1790-08-31">11 July–31 Aug. 1790</date>

Optional Attributes
The following attributes may be added to any of the required attributes above:

@circa.
Any of the above four types of dates (when, when/ante, when/post, and when/to) that are preceded by a "ca." or "circa" should also include the @circa. The value is "yes" and @circa can be combined with any other date attributes.
Example: <date when="1745-10-21" circa="yes">ca. 21 Oct. 1745</date>

@conjectural.
Any date that appears in brackets is a conjectural date. The date may be conjectural for a variety of reasons (illegible, not present on the letter, supplied by context), but the key feature is the use of brackets. The value is "yes" and @conjectural may be combined with any other date attributes.
Example: <date when="1772-12-02" conjectural="yes">2 Dec. [1772]</date>

@noDate.
Any date field that includes the phrase "n.d." should have the @noDate. This may appear alone, but more often accompanies a supplied date in brackets. The @noDate may be combined with any other date attribute.
Example: <date noDate="yes" post="1773-06-16" conjectural="yes" >n.d. [post 16 June 1773?]</date>

@rank.
The rank will be added using a separate XSL transformation. The ranking will be determined based on the number of attributes to allow for proper sorting.

A note on sorting.
The sorting rules for the database will follow the filing rules used in the physical paper file. Not only are the editors already familiar with these rules, they are the most logical method for the variety of dates—certain and uncertain, complete and incomplete—found in the control file. The original directive adequately described the sorting:

The file contains all ribbon copies of all four types of control slips. In cases where several slips represent different versions of the same document, the order of filing is as follows:

Pink (CDF), White (Letterbook), Yellow (Accession), Blue (Printed or Manuscript Lead)

Arrangement of slips in this file follows strict chronological order throughout the entire span of our documents, 1639-1889. Dates which contain all three elements (day, month, and year) precede those which are incomplete. Inclusive dates are filed under the earlier of the dates, but following all other slips for that day. (An exception to this rule is the filing of accounts with inclusive dates, which go under the later of the inclusive dates, but preceding all other slips for that day.) An example may be taken from the end of a theoretical year:
Ante 15 Dec. 1800
15 Dec. 1800
15-19 Dec. 1800
31 Dec. 1800
31 Dec. 1800-21 Jan. 1801
31 Dec. 1800-18 May 1801
Dec. 1800
1800
Ca. 1800
[1800?]
1800-1809
[post 1800]