Getting Names Right

This page summarises the techniques for adding and editing Names to achieve consistency. It includes some detailed guidance omitted from the overview pages. It is best first to understand the basic concepts using the cross-references at the foot of the page.

This page is about getting the information right in the first place; there is a page covering correcting mistakes in Names.

Why bother?

There is some work involved in getting Names entered correctly. The main reason for taking the trouble is that you can only search for Names with any accuracy if each person has one label only to identify him or her. The tips set out here will help to ensure that those entering information use the same label each time.

NB As with other aspects of Openlaw, this only matters if it matters to you. If you are simply rushing a Disclosure List out, you should not need to pay any more attention to the detail of Names than you would for a WP list. Even in this situation, however, you should find that accurate pick-lists make for faster, as well as better, lists

Review as you go

Accurate Names entry is easy to review as you are entering data. Since every incorrect entry (a mis-spelling, a slight variation on a name to make two names etc) can quickly be propagated from the pick-lists, it pays to keep on top of the Names at the early stages of adding entries. The main tools for review are the Additional Reports on Names and the function to Find and Replace Names. Both are covered in more detail below and in their respective sections in this Manual.

Getting Names in

Either enter them through Names Menus as Individuals and/or Organisations and then as Stored Names or just type them in the required format and then parse them.

The Required Format for direct entry into Item Cards

You can, of course, type anything you like into the Senders and Recipients fields. These formats are only "required" if you want the parsing rules to recognise the components of Names and put them into the right place. That in turn is only "required" if you want the benefit of pick-lists for consistent naming. The most common ways of setting out Names is shown below:

Components	Example
First Name Last Name	Tony Blair
First Name + Last Name of Organisation	Tony Blair of HM Government
First Name Last Name [Job] of Organisation	Tony Blair [Prime Minister] of HM Government
Title First Name Last Name [Job] of Organisation	(The Rt Hon) Tony Blair [Prime Minister] of HM Government
[Job Description]	[Prime Minister]
[Job Description] of Organisation	[Prime Minister] of HM Government
First Name Second Name Third Name Last Name	A C L Blair
Alias	Blair (or anything users will use to find him)

Any of these variants should parse as intended, that is, put the right components into the right place in the lookup tables.

Pitfalls - Entry via the Names Menus

There should be little scope for getting this wrong. Each component is added manually. Required elements such as square brackets round Job Descriptions are supplied for you. Exact matches are prevented (so you cannot make two identical entries for the same name). Stored Names are built from pick-lists. Names can be reviewed and edited before being used and there are constraints on deleting or editing Names which are in use. You can, of course, spell a Name incorrectly, enter near-matches, and allocate the wrong Job or Organisation to an Individual.

Pitfalls - entry by typing names into Item Cards

There is more scope here not just for error but for misleading the parsing process. The more obvious rules include:

Job Descriptions

If an entry includes or comprises a Job Description, such as [Managing Director] the words must be enclosed in square brackets.

Titles and Surname Prefixes

You can ensure that these are correctly treated by adding new ones to the right Parsing Look-Up (see Helping the Parse Routine). If your Case involves people with specialist titles (say ranks in the armed forces) or country-specific Prefixes (such as Spanish aristocratic titles) you can add them to the appropriate LookUp and they will be treated correctly on parsing.

Organisations

Improve the accuracy of parsing Organisations by a) adding to the Parsing Lookup of common Organisation names (see Helping the Parse Routine) and b) by adding manually an Organisation which might be otherwise treated as an Individual.

Example of helping Parsing to distinguish between an Individual and an Organisation

The Recipient of a letter is called Newcastle Chocolate Shop. If it were John Brown of Newcastle Chocolate Shop, then Parsing would readily identify that everything to the right of of was an Organisation. Without 'John Brown of' , however, Parsing will assume that Newcastle Chocolate Shop is an Individual with the surname 'Shop', and the Look-Up name will appear as Shop, Newcastle Chocolate.

Defeat this by one of two methods:

a) add Newcastle Chocolate Shop as an Organisation via the Names menu. If it is already there, then parsing will know that this is an Organisation and treat it accordingly

b) go to Data / Names / Parsing Lookups / Organisation Words and add 'Shop' as a new entry. Parsing will then know that any Name including the word 'Shop' is an Organisation.

Dummy Runs at Parsing

Most common parsing errors can be fixed in advance by the methods described above. It is too late to use them pre-emptively, however, if you do not see the errors until after parsing. Take a copy of the Case and run parsing on it. Examine the Names Reports carefully. If you spot errors which might have been headed off (e.g. by adding an Organisation in advance) you can then do it in the master Case.