Citizens for Community Action, Inc.

29th Ward

Absentee Voter Analysis

For the April 13, 1999 Election

Between Floyd Thomas and Isaac Carothers

Prepared by:

Richard Barnett

Wayne A. Strnad

---

Introduction

The data analysis contained within this report is for the election of April 13, 1999 between Floyd Thomas and Isaac Carothers. The report consists of several printed volumes of information that include:

The original raw data received from the Chicago Board of Elections migrated into a database and sorted by precinct and then voter name
Volume 1	Precincts 1 through 28	Pages 1 through 177
Volume 2	Precincts 29 through 56	Pages 178 through 363
Detailed report on Questionable Items for each absentee voter
Volume 3	Precincts 1 through 28	Pages 1 through 186
Volume 4	Precincts 29 through 56	Pages 187 through 333
Index for Volumes 3-4
Questionable Description Entries for each absentee voter
Volume 5	Questionable 1 through 10	Pages 1 through 181
Volume 6	Questionable 11 through 13	Pages 182 through 345
Volume 7	Questionable 14 through 16	Pages 346 through 553
Volume 8	Questionable 17 through 25	Pages 554 through 751
Volume 9	Questionable 26 through 43	Pages 752 through 908
Index for Volumes 5-9
Voters that Filled out Applications but had no Ballots
Volume 10	61 pages
Voters that Filled out Ballots but had no Applications
Volume 11	21 pages
Voters that Filled out Applications and Ballots
Volume 12	51 pages
A street by street listing showing all absentee voters location
Volume 13	94 pages

Although great care was taken in the compilation of this information it is slightly incomplete. For example, the data from precinct 35 was not available. Thus, the number of questionable items will no doubt increase as will the numbers generated for the other reports. Despite this fact, we feel there is more than adequate information presented to call for a full scale investigation of this election, be it local, state and/or federal.

If it is the case that the state and federal people claim it's a local mater then let us remind them that this city also has state and national candidates running for election.

The information that follows might seem somewhat abstract to some but it really has a basis in simple concepts. It is provided for thoroughness so that one can understand what was going on with the absentee vote in the 29th Ward during that election both from a database perspective and practical point of view.

---

Technical Background

The data that came from the Chicago Board of Elections was not in any database format but rather as a text file. After analyzing the data, we created a structure (a table) that would allow us to migrate all the information into our table. The name for this table is 29th Ward Voters. We were told that the data consisted of all the people that voted in the runoff election between Thomas and Carothers. Figure #1 illustrates this structure. The 363 pages composing Volumes 1 and 2 of the reports is the actual list of voters that were migrated into this structure. For convenience in looking up information we sorted the information by precinct and then alphabetized the voter names.

Each line item you see in Figure #1 is called a field. There are 15 fields. Every person who appears in this table has 15 pieces of information associated with them. A single person's data (all 15 items thought of as a single entity) is called a record. This table contains 15,751 records. All the records, thought of as a single entity, is usually referred to as a recordset.

Nearly all of the field names are self-explanatory. For example, NAME, ADDRESS and ZIPCODE are typical items. For our purposes the last six fields were not important and could have been eliminated but for integrity sake, we eliminated nothing.

There are two fields that might require a bit of explanation and they are ID and IDNUM. The ID field is an automatic counter that we use to count the number of records in the table. IDNUM, which we'll talk about later, is actually the voter's registration number.

Another table was created that corresponded to the information that appeared on an absentee voter's form. See figure #2 for the fields. How does one relate one table to another? The relationship is called a link. Without getting into the type of link created, suffice it to say that in this case the link we needed to create between the two tables was via the IDNUM. This link assured us that for every entry in the Absentee Voter table there would be an entry in the original recordset.

The last sentence above is a "best" scenario type case. Ideally, every application that was filed should have a corresponding ballot and the IDNUM should have existed. This was not the case for this election. In fact, there were 258 ballots that had no applications. Also, there were 669 applications filed but no ballots received. Out of 1746 records only 819 or approximately 53% had an application and corresponding ballot and of those nearly 98% had questionable information. The detailed records showing these questionable items can be found in the 333 pages report labeled Volumes 3 and 4.

A diagram that may help in understanding what is going on with this follows. Usually this type of diagram is referred to as a Venn diagram.

In the ideal case every person found in the absentee voters list (circle labeled B) should also appear in the recordset A. In this case, the list of absentee voters should be a subset of the larger set A. We say B is contained in A.

A

B

Actual data indicates that only some of the absentee voters were in the larger (15751) recordset. In the diagram, the overlaping of the two circles indicates that only some of the absentee voters were in the recordset. This region is called the intersection of the two sets.

By way of a simple example, suppose recordset A consisted of voters whose registration numbers were 1, 2, 3, 4 and 5. Recordset B consisted of voters whose registration numbers were 4, 6 and 8. Then the voters registration number that would be common to both recordsets is 4. Our diagram would now look like this:

Now in actual fact, recordset A had 15,751 voters. Noteworthy are those voters that were not part of this recordset and not in the intersection of the two.

Because of the discrepancy in not finding voters in the larger recordset, we had to come up with a structure that would allow us to incorporate the original data records that had an IDNUM for every absentee voter along with those that did not appear in the larger recordset. Also, since we wanted to track information on the application, we needed a structure to fill the bill.

This structure (table) we refer to on the reports is called the Absentee Voter 99 - Combined List.

As it implies, the combined list consists of everybody that either appeared in the large recordset and filed an application and/or ballot (the intersection of A and B) or not (B - the intersection of A and B). In the example, the combined list would be a recordset consisting of 4, 6 and 8.

The specific fields for this recordset can be found in Figure #3.

As you can easily see, much of the structure is consistent with the naming of fields that appears in other tables.

There are some fields though that need a minor explanation and they are:

OFFICEDATE: On the Absentee Voter Application in the upper left hand corner you see For Office Use Only. The OFFICEDATE is the "Date" on that form.

AV_CODE: Similar to the OFFICEDATE, this is something that is filled out by the Board of Elections.

REASON: There are 10 boxes on the form that the applicant has a choice to pick from as a REASON to vote absentee. In the reports that are available you will see reasons 0-10. The number 0 indicates that no reason was given. Numbers 1 through 10 indicate a choice on the form with 1 being the first entry in the leftmost column and continuing down the column to 5. The second column starts with number 6 and continues through 10.

STUDENTCITY, STUDENTCOUNTY AND STUDENTSTATE:

If a person checked REASON = 2 then they should have completed these three pieces of information.

JUDGEPRECINCT AND JUDGEWARD: For REASON = 4 the voter had to fill in the precinct and ward they were serving as a judge.

TEMPPHYINCAP: If a voter was temporarily physically incapacitated they needed to fill in why. This field contains their response.

PERMPHYINCAP: Voters who are permanently physically incapacitated need to fill in this item. This field contains that response.

AUTHORITYAGENCY: For people that are performing official election duties. This field contains that data.

BALMAILNAME, BALMAILADDRESS, BALMAILCITY, BALMAILSTATE, BALMAILZIP: This is the information for the Board of Elections on where to mail the ballot to.

APPLICATIONFILED AND BALLOTFILED: Each of these fields is a yes/no response. A yes response is indicated by a checkmark on the reports.

---

Due to the volume of information that had to be looked at and put online, we proceeded in several phases.

Phase I - Data Conversion

Converting the raw data into a database format.

We were given the original raw data from the Chicago Board of Elections for the Thomas-Carothers runoff election that occurred in April, 1999. This data was then migrated into a database structure as illustrated in Figure #1. The field structure that we employed was isomorphic to the structure used by the Chicago Board of Elections. Thus, if any errors existed they would be from the data received from the Chicago Board of Elections.

In any reference to this migrated data, we say information is either "In DB" or "Not in DB" and mean the information is contained in the original database or not in the database, respectively.

Phase 2 - Identify Absentee Applications and Ballots in the database

Photocopies of all the information were provided. It was an arduous task going sheet by sheet just to identify those entries that should have appeared in the database. Fact is, most people did not appear in the database. Thus, we had to create a file of exceptions. The exceptions file contained all the people that were not in the original database.

If everything were perfect, every absentee application would have a corresponding ballot and every IDNUM that appeared on the application (it's labeled Key on the form) would have a corresponding entry in the database.

Phase 3 - Build Table of Exceptions

Similar to the combined list table this table consists of all the people that either filed an application or ballot but had an IDNUM different from the DB. On an application the IDNUM is called a KEY and it is located in the upper left hand corner under "For Office Use Only."

Phase 4 - Build Combined List

By this stage the original photocopies have been viewed twice. This marks the third viewing. Here we go voter by voter and build the combined list. At the end of this process we have a complete set of records of all the people that voted absentee for this election.

Phase 5 - Identify Questionable Data

Unique to every voter is an ID. In the database this ID is labeled IDNUM. In the real world this is the voters registration number that more often than not, is not a number at all, but rather a number with letters - a string in computer lingo.

So that no two voters have the same registration number it is a requirement of this field to be unique. However, as was discovered while working with the data, there are a multitude of unique voter registration numbers that refer to the same person i.e. their number is different but the rest of the data is the same. This points to questionable "integrity" of the data that, in the business world, would generally not be accepted for a multitude of reasons. And, since this data is the source of actual voters, it might suggest that some people voted more than once.

Contained within the data were a multitude of errors relating to voter registration numbers. To keep with the conformity and restraint of the IDNUM, we created the NOKEYxxxx entry, where xxxx uniquely identifies the entry. The first NOKEY entry is labeled NOKEY0001. The second, NOKEY0002, the third NOKEY0003, and so forth. This scheme allowed for entries up to NOKEY9999. This secured data integrity and provided a "way out" of the dilemma of entering data that had no voter registration number associated with an application or ballot.

Similar to the construct of the db file with a unique IDNUM is the file of questionable items. This file consists of two fields -- one a number, which we called QID (short for Questionable ID) and the other, Qdescription (short for Questionable Description).

There are 42 questionable items and they are listed below.

Questionable Description File

Description	QID	Description	QID
Application for someone else	1	No Signature	43
Application Incomplete	38	Not in DB	16
Area Code	2	Not in Ward	17
Ballot filled out by someone else	37	Note Date Received by BOE	35
Ballot from another election	34	Note Date Signed	31
Ballot Incomplete	3	Other	23
Board Date Received	24	Printed Versions Differ	18
Different Address	4	Printing Similar to Other Application	42
Incorrect Ballot	5	Questionable Ballot Form	39
Initials on Application	7	Questionable Code	30
Initials on Ballot	8	Questionable Reason	25
Misspelled Name on Ballot	9	Questionable Signature	29
Name Misspelled on Application	41	Seems OK	26
Name Scratched Out	40	Signature Different	19
No Application	28	Signature Printed	27
No Ballot	10	Street Misspelled	33
No Code	11	Two Reasons	20
No Date Received by BOE	12	Two Signatures on Ballot	32
No Date Signed	13	Use of Middle Initial Inconsistent	21
No Key	14	Use of Middle Name Inconsistent	36
No Reason Given	15	Used Social Security for Disabled Voter's ID	22

Note: This information was sorted and then placed in this document. The reason the numbers (QID) are not in numeric order is that as we were entering and verifying data we discovered we needed more questionable items. Thus, they were added on a need to create basis.

The detailed information regarding a line by line description for every absentee voter can be found in the 908 page report labeled Volumes 5 through 9.

Phase 6 - Generate Queries and Reports

The final stage of this project dealt with queries and reports.

For related information click on one of the following links:
Analysis of Data Received,
Conclusions and Tables,
Recommendations,
View the Data/Reports.