|Parish Register Transcription
By Rod Neep
|Continuing with the topic of transcribing parish registers, we move on
to burial registers.
So what separate items of information (fields) do we need for a transcription for an event such as a burial? Furthermore, what information is available in a burial register? The answer to the second question governs the answer to the first. Unfortunately, different burial registers during different periods of time differ in their format and the amount of information they contain. In early parish registers we encounter a simple written statement such as Francis son of John Neep and Mary his wife was buried 27 June 1779. In later parish registers, we find a pre-printed page with columns of information, including entry number, Name, Abode, When Buried, Age, and a final column By whom the ceremony was performed. In addition, it is not uncommon for the vicar to add other notes.
Essentially, the later registers contain the most information, and so these must be the ones on which our standard is based. Sometimes of course, earlier registers do give more information, and even the later ones have additional information written in the margins on occasion. We need fields (items of information) in the database to cater for all of these, and we need to establish a standard way that the information is entered..
It helps in presenting the information in printed form to have the information in a certain order, so that it reads easily and makes sense, and this also governs the order of the information in the database.
No (The register entry number)
Pre-printed in later style registers, none in early registers. If transcribing an early register, then simply leave this empty. Note, as in the example below, that I use a four digit number, as some pre-printed registers for larger parishes go above 1000.
Format: dd mon yyyy/y e.g. 20 Jan 1834 or 20 Jan 1701/2
Why have this data format? The answer is that although it does not match the American format, it is unambiguous. (There could otherwise be a confusion between 12/1/1848 and 1/12/1848). It also allows us to enter a date before March 26th as the real year before the calendar changed in 1752. (Before 1752, the year number changed on March 26th). Computer databases have a data type as text or date format. Unfortunately date data format is of no use for us as genealogists, because it doesnt like dates such as 23 Jan 1711/2, and some even get muddled up with older years such as 1798 or 1898, whilst being quite happy with 1998. So my recommendation is to stick with the data type as simple text. Sure, it can no longer be sorted by date, but we have a way around that problem later. If no birth date is given, then leave that item (field) blank.
This is an extra item of information which we can add into the database, so that we can sort entries into date order if need be. We cant rely on the vicar entering every baptism in chronological order. Quite often we see examples where one or more burials have been added at a later date. In final prints of course, the sortdata column is omitted.
The format I use for sortdate is yyyy mm dd, e.g. 1824 02 27 for 27th February 1824. (Again entered as a text data type). This gets over our problem of being able to sort entries into actual date order. We simply click on the sortdate column and then use the database command to sort it. It works perfectly.
This is simply the Christian name of the person. Occasionally when entering data, we encounter someone with several names, such as Francis William Jonathan. There is no harm in recording them all in this field, but it can present a problem when the transcript is finally printed. (Yes - I do like good old fashioned paper for archiving information!). If we enter the full name, then it overflows the column in the final print, or some information is missed on the print. So what I do is use an abbreviation such as Francis Wm. J., and then make a note of the other names in the notes column at the right.
This is an additional field , in which we can enter information such as wife of John, son of John & Mary etc. In most earlier burial registers this information is stated, although surprisingly, it may not be noted in later registers when the pre-printed forms are used.
I always use upper case letters for real surnames. This avoids confusion where a surname is used as a Christian name, for example, one of my ancestors was William Watkins NEEP. I never use all upper case, or all lower case, as in the example quoted WILLIAM WATKINS NEEP or William Watkins Neep may be totally misinterpreted as being a double or hyphenated surname!
The age at death. The following examples of abbreviations are used:
Note that this is entered into the database as a simple text field. We cannot use it for calculations, but a numeric field type would not be able to accept the data in the format d or m.
In later registers, and sometimes earlier ones too, the town, or even full address of the family are entered. I use this field to record this information. I am quite happy to use abbreviations such as: St. - Street, Rd. - Road, Cott. - Cottages, etc. as this takes up less space in a final print. Sometimes addresses may be quite long, e.g. 56 Parkinsons Road, Basford, Nottinghamshire especially where the address is not in the same parish as the baptism, and therefore I tend to use an abbreviation such as Basford Notts., and then put the full address in the notes column.
This column is used to record any additional notes, especially margin notes written in the register. Sometimes, a burial register may give an occupation of the deceased, and so this is entered into this field. I also use it to expand details which may have been abbreviated in other columns. As this field may sometimes contain quite a lot of information, I usually set the data type as a memo field rather than a text field. On most databases, the maximum number of characters allowed in a text field is 255, and sometimes we need to exceed this.
An example of a final print of part of a burial register transcription (Minchinhampton, Glos.)
Creating an index
If the data is in a database, then creating an index is very simple. What we need is a query of the data with the fields in the following order:
Surname sorted alphabetically ascending
The result being something like this.
(part of the index of burials for Parkend, Gloucestershire)
Below: an example of the database as entered, from an early burials register without entry numbers:
Below: an example, using the same database structure, of a post 1813 burials register
|The use of commas and quotation marks
It is very tempting to enter data such as: Margin note: Illegitimate, or 13, High Street, Newent.
Commas or quotation marks should never be used in a database! It presents a big problem if the data needs to be exported into a different database software. I prefer to use Microsoft Access as my database software, but not everyone else does, furthermore, others may have different types of computers.
There is a standard for transferring data between different databases, and this standard has existed since computers first began to be used. Every database can import files of this standard. The file type is known as a Comma Separated Variable file. CSV file for short. It is a simple text only computer file. Each field of data is separated by a comma, and enclosed in speech marks. It looks something like this:
No,Birth date,Baptism date,First
name,sex,Father,Mother .... etc.
So if our data contains commas or speech marks, then it is impossible for it to be transferred sensibly to a different database or a database in a different type of computer. Well, not quite impossible, but it entails hours of work editing the CSV file to get rid of all of the extra commas and speech marks. Believe me, it is a pain!
Copyright ©1999 Rod Neep