Welcome to the FreeBMD District Aliasers' home page. This page should provide all the information necessary for you to understand the process that we are following to ensure consistency of approach to district aliasing.
Overview of district aliasing process
District aliasing is a regular activity that starts at the end of a database build and must end before the start of the next database build. Reports are produced from the database that provide information about the spellings used for the districts. From these reports as many of the spellings as possible are aliased against the 'standard list' and at the same time spelling mistakes in them are identified.
The regular steps that are / will be taken are:-
the co-ordinator downloads ToBeAliased.txt (which replaced unk.txt) and divides it into the A_unmatched.txt types of files and also 'before_A', 'after_Z' and 'square' prior to allocation
the co-ordinator allocates the 'normal aliasing' work among the aliasing team members based on files to be aliased (the ...unmatched.txt files) and the letter files to be edited (the district map files such as A.txt)
the co-ordinator extracts the latest district map data files from CVS
the co-ordinator prepares a zip file for each person who is allocated a portion of the district map to edit and emails it as an attachment to the team members who will
identify aliasable spellings
collect the unaliasable spellings, the 'dregs', in a file
add the aliases using dmEdit for the aliases to be made to the districts files allocated to the aliaser
for the aliases to other districts, collect them in a file and periodically email them to the aliaser who has been allocated the letter for them to add to the appropriate district file
return the edited data files and the 'dregs' of the spellings that cannot be aliased to co-ordinator in a zipped attachment to an email
the co-ordinator is responsible for deciding
which of the spelling 'dregs' should be put to one side as (illegible) based on no more than 1 letter being present (with St for Saint counting as a single letter)
which of the spelling dregs look promising for 'page ranging' based aliasing
and which would be unaliasable even if they could be read since they cannot be distinguished between 2 or more districts
and which are candidates to be looked up by the 'district alias lookup' team.
the (deputy) co-ordinator uses the Submissions query portion of the
http://www.freebmd.org.uk/cgi/aliasing-tools.pl page to find the entries that correspond to the spellings that have been selected for page ranging.
the (deputy) co-ordinator identifies those entries where there is insufficient volume or page information to make page ranging feasible and reclassifies the affected spellings as requiring a lookup
the (deputy) co-ordinator sends the entries for page ranging to the team member(s) responsible for page ranging in the current round of aliasing
the page-ranger identifies the aliases that can be made based on page ranging and mails them to the 'normal aliasing' team and returns the remaining dregs to the co-ordinator who includes them with those selected earlier to be looked up
the (deputy) co-ordinator allocates the lookups to be done among the lookup team
allocates the scan lookups among the scan lookup team by transfering the Submissions information into an Excel spreadsheet
the lookup team look up the entries, complete the spreadsheet and return them to the co-ordinator
the co-ordinator decides if any of the aliases proposed would be unsafe, using similar thinking as used for identifying the 'dregs' earlier, and emails the aliases to the members of the 'normal aliasing' team
to manage these 'dregs' entries, various lists have been created in the files illegible.txt, lookups.txt, notLookedUp.txt, unaliasable.txt and wait.txt and the co-ordinator decides the best way to alias these 'dregs' to one of these 'pseudo-districts'
once all the aliases are distributed and included in the letter files by the 'normal aliasing' team, they return their files to both the co-ordinatorand deputy co-ordinator
the (deputy) co-ordinator uses dmEdit to check for duplicates, removes them as necessary, and then checks-in the data files to the CVS system
The other ideas from when this page was first written have been removed from the 'normal aliasing' part of the process as described above and deferred until later when they will be addressed by the District Alias Test team.
The purpose of this team is to find problems with the aliases and to try to identify how to fix them.
In many cases this will involve sending emails to the 'normal aliasing' team for them to either add new aliases, change existing aliases (e.g. by adding either a volume or date dependency) or to remove aliases.
At present there is no clearly defined process for the District Alias Test stage, but the ideas have been kept here so that they are not forgotten
use the normal search page to find entries for dates when a district was not in use
review existing aliases
fix bad aliases
ensure consistency of when ! has been used
remove unnecessary aliases
Those activities not highlighted in any way are those that are performed for each build. Those shown in red are desirable activities to be included at some point in the future.
District Aliasers' Process Page