The Ryerson Index

to death notices and obituaries in Australian newspapers

Introduction

The DeathIndex program facilitates the recording of newspaper death notices for the Ryerson Index. It has functions to aid in

• entering and saving significant details from newspaper notices, and

• formatting and emailing the data to the DPS indexing co-ordinator.

This Windows version of the DeathIndex program was developed by Rob McDonell of ARK ANGLES. It is based on the original DOS program by John Graham of the Sydney DPS (johngrah@ozemail.com.au).

Quick Start Guide

1. Run the program.

2. On the left hand side of the display insert the code for the newspaper you are listing. This will remain as default until you need to change it to another.

3. Insert the issue date either by using the drop down calendar or typing in the date. This will remain as default until you need to change it to another.

4. Click on Insert Record (+) when the display on the right hand side of the screen will set up the appropriate defaults as to date etc and provide a cursor in the name field.

5. Type in the surname and given names in exactly the same format as before, i.e. SURNAME,Given Names

6. Enter the event date by clicking the drop down calendar, followed by the type of event (death is the default; change it if necessary by clicking the drop down menu).

7. Fill in the 'At', 'Late of' and 'Formerly of' fields as appropriate.

8. Fill in the age field. Years is the default; change it if necessary by clicking the dropdown menu.

9. Complete the entry type field. Death is the default; change it if necessary by clicking the drop down menu

10. If the deceased has an alternative name or names, insert this/these in the windows provided. It is no longer necessary to prepare separate entries for alternative names.

11. If there are further entries for this issue, click on Insert Record (+) when a fresh screen will display. Proceed to record each additional entry in the same way.

12. When all the entries for this issue have been completed, click send. A pop-up screen will ask whether you want to send the data in the body of an email message or as an attachment. Click the preferred arrangement, ie send in email body. Note this will become the default until changed so for future use, you only need to hit enter.

13. You will be presented with an addressed, completed email showing all the items you have entered in alphabetical order. If satisfied that they are correct, hit send. If you discover an error even at this stage, close the email by clicking on the X button, click the entry containing the error which will then display, edit it, then again hit send. A fresh amended email message will display.

Notes: Navigation buttons, that are self-explanatory, at the top of the screen enable you to move around the entries and to delete an entry if necessary. The use of the drop down calendar for dates is preferable as this will eliminate typographical errors but the facility to type dates is useful in those few instances when, say in a legal notice, the event date may have been years earlier. Retention of sent emails is unnecessary as the programme stores data for each issue. If there is a need to refer back to it, entering the issue date will immediately display full details of your return, which can then be amended as necessary and re-sent if required.

Installing the Program

The DeathIndex program and documentation is supplied in a single installation program called deathindex_setup.exe. Run this to perform the installation. You can accept the default installation directory, or chose an alternative one. The install program will create the directory, copy all required files, and create shortcuts on the Start Menu.

The program requires a PC running Windows 2000, XP, Vista or 7.

For the Send function to actually create and send an email requires a MAPI-compatible email client such as Outlook or Thunderbird. Hotmail, Gmail, Yahoo mail etc will NOT work.

Running the Program

Running the program displays the main screen, from which all functions are performed.

Across the top of the screen is the button bar. The buttons allow you to navigate through your data, add and delete entries, process the completed file, and set display options.

Below and to the left are spaces to enter the newspaper code and issue date. Each newspaper is allocated a two character code by the DPS indexing co-ordinator. Enter the newspaper code and date of issue to begin entering new information or viewing or editing information already entered.

Note that the newspaper code and issue date, and all the data entered for it, is automatically saved when the program closes, and reloaded when the program is run again. Changing the newspaper code or issue date saves the current records, and then loads the records that apply to the new issue.

Below the newspaper information a list of all the names already entered for the selected issue. Navigate through the list by clicking on one of the names, or by clicking on the [First record], [Prior record], [Next record] and [Last record] buttons at the top of the screen, or by pressing the [Page Up] or [Page Down] keys on the keyboard.

To the right is the detailed information for the current notice, shown in individual fields. Jump between fields by clicking on a specific field, or by pressing the [Tab] or [Shift]+[Tab] keys on the keyboard.

Entering the Data

Each notice in the newspaper is entered as a separate record in the list. Add a record by clicking on the [Insert record] button at the top of the screen, then enter all the fields relevant to that notice. The record can be saved by clicking on the [Post edit] button, or cancelled by clicking on the [Cancel edit] button. Records are saved automatically if you move to another record or insert another new record.

After each record has been entered, click on the [Insert record] button again to add the next record.

The current record can be deleted by clicking on the [Delete record] button. A dialog box will appear to confirm this action before it is performed.

The current record can be changed simply by typing the new data into the appropriate fields.

Using the Date Pickers

Dates can be entered directly into the Issue and Date fields. Type in the numbers required, or press the [up] and [down] arrow keys to cycle through the day, month and year values. Press the [left] and [right] arrow keys to move between the day, month and year parts of the date. Or hold the [Alt] key and press the [right] or [left] arrow keys to increment or decrement the date by one day. Or hold the [Alt] and [Shift] keys and press the [right] or [left] arrow keys to increment or decrement the date by one week.

Note: Whatever part of the date (day, month or year) the cursor is in when you tab out of a date field, the cursor will return to when you tab into it again. Do not assume that you can just start typing in the day when you enter a date field.

Alternatively, hold the [Alt] key and press the [down] arrow key, or click on the down arrow to the right of the date, to show a popup calendar for easy selection of the date. In the popup calendar, click on the year to change the year, click on the month name to change the month, and click on any day to select a specific date. Press the [Page Up] and [Page Down] keys to jump to the previous or next month. Press the [Ctrl]+[Page Up] and [Ctrl]+[Page Down] keys to jump to the previous or next year. Press the arrow keys to jump between days. Press the [Enter] key to accept the selected date.

Sending the Data to the DPS

Once all data for the current issue is entered, click on the [Send] button at the top of the screen. This will create a text file in the format required by the DPS. It will be called 'xxyymmdd.txt' where 'xx' is the newspaper code and 'yymmdd' is the issue date.

A dialog box will ask whether you also want to attempt to email the file to the DPS indexing co-ordinator using your default email client. This may be Mozilla or Outlook or Eudora or any other MAPI-compliant program. The email is stored in the email program's outbox, ready for sending next time you log on to the internet. The address to which the email is to be sent can be changed from the default value prior to sending.

If your email client is not set up correctly, or does not support the MAPI communication protocol, then you can manually email the saved text file to the indexing co-ordinator.

Description of the Fields

Name

The full name of the person at time of death is entered here. The format is "SURNAME, Given Name(s)". The surname is to be entered in upper case, with limited exceptions:

1. Where the surname is prefixed by de, de la, van, or something similar - the prefix is in the same case as in the notice
2. Where the surname begins with Mc or Mac - the "c" or "ac" are in lower case, with the rest of the surname in upper case. The exception to this exception is MACKAY - always in upper case, as this is common usage.

Titles (such as Doctor, Sir, Lady) are not entered.

Nicknames, if present, are entered in round brackets ( ) following the given names. Any nickname in the notice is entered, regardless of whether or not it is a commonly-used abbreviation (such as Bill for William). If there are two (or more) nicknames, they are entered one after the other, each in its own set of round brackets, with a single space between (eg "O'REILLY,William (Bill) (Tiger)". 

Awards (such as OAM, AM, MBE) are not entered.

Religious orders are only included in the case of a Sister. Quite often a Sister will have a male name, and appending "(Sister)" helps to clarify the reason for the name. When included, "Sister" (or its abbreviation) is entered in round brackets ( ) following the given names. Any other religious titles are not entered.

This is a mandatory field.

Event Date

The date and type of the event are entered here. The type of date to be entered is one from the following list, whichever is available from the notice, ranked in decreasing order of importance:

• Date of death
• Date of funeral, requiem mass, memorial service or cremation
• Date of birth (generally only present for babies)
• Date of publication (this ensures we ALWAYS have a date)

The newspaper issue date, event date and event type should be in the following relationship:

• For date of death, the event date should be prior to the issue date, but not more than 10 years prior.
• For date of funeral, requiem mass, memorial service or cremation, the event date should be within one year either side of the issue date.
• For date of birth, the event date should be prior to the issue date, but not more than 120 years prior.
• For date of publication, the event date must equal the issue date.

This is a mandatory field.

Locations

The preferred location details (as shown on the web page) list the place of death, the final town or city of residence, followed by any prior residences, in the format "at Bulli, late of Sydney, formerly of Melbourne, Adelaide and Perth". To get this information, or the best approximation to it, there are three different location fields:

AT:

If there are any locations shown as "at" in the notice, they are entered here, although there are a few exceptions.

"at home" tells us nothing, if the location of home isn't given. Even if given as "at home, somewhere", this is translated better as "late of somewhere", rather than "at somewhere", because the latter doesn't specifically indicate residence at "somewhere".

Similarly, "at his residence, 1 Smith St, Somewhere" is indexed as "late of Somewhere".

"at hospital" is even worse, and should be ignored completely. (however, "at (place) hospital" should be entered.)

"at a nursing home" is treated the same as "at hospital".

LATE OF:

If there are any locations shown as "late of" or "of" in the notice, they are entered here. In theory, there should never be more than one location under "late of", but in practice submitters sometimes get it wrong, and a person can be "late of Sydney and Melbourne".

FORMERLY OF:

If there are any locations shown as "formerly of" in the notice, they are entered here.

For all location fields, where street addresses are given, ignore them.

When a comma is present anywhere in the location field, always follow it with a space. This lets the HTML better format the web page - whereas "Sydney,formerly" is treated by HTML as a single word because there is no space, "Sydney, formerly" is treated as two words, and so can make better use of line wrapping.

Age

The age and age type is entered here, if known. Enter the number of years, months, weeks or days in the first field, and the relevent type in the second field. If the deceased is a very young baby, and the age cannot be accurately determined, select age type "Infant". If the deceased was Stillborn, select that as the age type.

If entered, the Age value should be between 1 and 120 inclusive. It should be blank if Age Type is Infant or Stillborn.

Notice Type

The type of notice in the newspaper is selected here. Choose from:

• Death notice
• Funeral notice
• Obituary
• Legal (probate) notice

The default is "Death notice", which caters for the vast majority of Ryerson entries.

Previous Names

Details of any previous names are entered here. This includes a maiden or previously married name or alias.

When a maiden name is shown, eg "SMITH, Mary (nee JONES)", or previous married names are shown, eg "SMITH, Mary (formerly BROWN, then BLACK)", then the additional names are entered in full. Up to three previous names can be entered. The format is the same as for the Name field. The order of the names is not important.

EXAMPLES:

"SMITH, Mary (nee JONES)" would be entered as follows:

"SMITH, Mary (formerly BROWN, then BLACK)" would be entered as follows:

New Notice Today

Some newspapers show by means of an indicator of some sort that a notice is appearing for the first time. If you are indexing one of these newspapers, and if the co-ordinator has decided to record this information, then you will see a check box field labelled "If new today".

If this field is present, you should put a check mark here if the notice is being published for the first time, or leave it blank if the entry has previously been published.

If you don't see this field, then either the newspaper does not include this information, or the co-ordinator has decided not to record it.

To Be Checked

This check box is used to indicate whether the notice can be read clearly. You should put a check mark here if some of the notice is illegible, otherwise leave it blank.

Special Cases

It is important to remember that we are indexing what is actually present, not what we think should be present. Thus, if we come across a name which looks to be mis-spelled, resist the temptation to correct it - record it EXACTLY as published.

If we come across two or more entries which contain identical information, so that they can be definitely determined to be for the same person, then:

1. if one of the notices contains more detail than the other, index only the notice with the most detail.
2. if one of the notices contains different detail to the other, then index both notices.

It is important that we don't merge details from multiple notices into a single index entry.

A simple rule to follow is to only index a notice if it adds new information.

Merging of Notices

When we come across two (or more) notices on the same day which appear to be for the same person, details from the multiple notices can be merged into a single entry, subject to strict guidelines. This can only be done if the indexer is convinced that two notices relate to the same person.

The operative word is "convinced". There will be cases that fall into the "is it the same person or not" category? The simple solution - if you are in any doubt at all, then index each notice separately. Only if you are completely convinced should the notices be merged.

General guidelines to decide whether or not to merge are:

1. the surnames in each notice must be identical. This is non-negotiable - different surnames mean no merging.
2. any given names in the notices must be the same (allowing for variations like an extra given name, or a nickname).
3. any dates given in the notices must be identical (ie if a death date is given in both, then the dates must be identical). If only one has a death date, then look at other data to decide.
4. names of parents, siblings or children, if given, must be similar. However, we need to allow for variations in given names like William and Bill, Elizabeth and Betty, etc, and we also need to remember that, with multiple marriages, children from one marriage may not be listed in a notice submitted by their step-siblings or step-parent.
5. location details, if given, must be similar (allowing for variations like "at St. Leonards" and "at RNSH", or "at hospital" and "at Westmead Hospital".
6. age, if given, must be the same - or at least very close, if other evidence is compelling.
7. it is permissable to merge details from death and funeral notices. In this case, the notice type is taken from the notice which provides the most information.

Remember, the merging process applies only to notices for the same person on the same day. We do not merge details from notices published on different days - every day is treated as a separate instance for indexing purposes.

Most Common Formatting Errors

1. We do not include titles and decorations. "Dr", "OAM", "Father", "Reverend" etc can all be ignored. The only exception is "Sister" as a religious title, because sometimes the religious name is a male given name, and adding "Sister" clarifies the issue. If present, "Sister" should be included in brackets following the given names. Although the name might be in the format "SMITH, Sister Mary Paul", we index it as "SMITH, Mary Paul (Sister)" so that the entry appears correctly in the SMITHs under "M", not "S".

2. Every comma in any of the location fields, and in any of the "Previous Name" fields, must be followed by a single space. HTML does not recognise a comma as a word separator, and will treat two words separated by a comma but no space as a single word.

3. For the same reason, always leave a space between the given name and the bracket or quote before a nickname, so HTML uses the space as a word separator.

4. The "Previous Name" fields require a FULL NAME - remember they are headed "Previous Name", not "Previous Surname"! We can't just assume that the given names given in the "Name" field apply to "Previous Name" fields - the case may be a full alias, with different surname and given names.

5. Do not leave two spaces anywhere between words - one space is all that is required.

6. When entering a nickname, always enter it in brackets, regardless of how it is shown in the paper. Do not leave a space between the bracket and the start of the nickname, or between the end of the nickname and the final bracket.

7. When in doubt over difficult-to-interpret letters (eg "i" or 'l", "o" or "e", think of what you're typing. "Alstonville" or "Aistonville". "Sheila" or "Shella". The correct interpretation will often be obvious.

8. Do not include street addresses in locations, unless the street name is part of a larger name (eg "The South Street Hostel").

9. When "at" and "late of" are the same town or suburb, do not index "at".

10. Watch your spelling! While some places are spelled incorrectly in the paper (and we therefore index them as published), many others are typos by the indexers. If you do find an incorrect spelling while indexing a day, then please add a note at the beginning of the email and the indexing co-ordinator will add a comment to the record in the database.

11. Obvious family-type "nicknames" (Gran, Nana etc) are not indexed.

12. When deciding whether a name is a nickname or a maiden name, look for the comma between surname and given names. The normal convention is that (in the absence of a categorical statement such as "nee" or "formerly") then a name in brackets or quotes to the left of the comma is a surname, and to the right of the comma is a nickname.

13. We do not index the place where a funeral is to be held. The location fields are solely for details of where the deceased lived.

14. We do index a hospital, nursing home etc appearing in the location fields (unless it is just the non-specific "at hospital", "at a nursing home") because, particularly in the case of a nursing home, this is likely to be the location where the deceased last "lived".

15. When there are multiple entries on the same day for the same person, we index the entry with the most information first. We then only index any of the others if they provide additional information to any of the usual fields (name, date of death, age and location). As our primary objective is to provide death details, having a funeral notice which provides a funeral date but no other extra information is not enough to warrant an entry.

16. We always index EXACTLY what is published, without interpretation. This means not adding the state to placenames when the state isn't shown in the notice. It means not correcting mis-spelled placenames (although you should point out such errors via a comment at the top of the email, so the indexing co-ordinator can add a comment to the record.)

17. When a birthdate is given, but no age, then an age can be calculated. However, if only a birth year is given, then only an approximate age can be calculated. Because the program does not allow the entry of "c65" as an age, the secret is to enter the year portion in the age field, and then insert the "c" immediately before the years in the email before sending it. The age in the email would then look like ";(c65);".

18. Do not add a state to a place name. If the state is listed in the notice, then we index it - but if we only have a place name, then that's all we can index. It is too risky to add a state, because places like Richmond occur in more than one state.

19. If you are indexing consecutive issues of the same paper, do not omit an entry because you remember having indexed it on a previous day. It is important that we index EVERY notice EVERY day, for three reasons:
    1. for some papers (eg SMH), people don't index consecutive days and so don't know what was published yesterday
    2. it is possible that a researcher may not have access to every day's paper, so we need to indicate all the possibilities, not just one of them
    3. it is possible that a subsequent notice contains corrected information