Installing voter data
|
|
AdvoKit's voterfile installation process is a multi-step affair. To further complicate matters, there are two possible paths you can take to getting voter data installed. In each case, you must first tell AdvoKit how you want to map your voter data fields into AdvoKit's voter data tables, and then run a perl script from a command line environment to actually insert the voter data into your AdvoKit database. The method that was first developed is decidedly inferior to the second, and so we will only describe the second in detail. The basic steps are:
|
||
|
Your voter data needs to be carefully prepared and have been uploaded to the server. Installing voter data is not an easy process when you are doing it for the first time, and if there are problems with the data, you will have to go into MySQL to purge the bad data before re-running the import. Therefore, it is extremely important to have your voter data prepared well to be used in AdvoKit. The right way to go about this is to use an offline (desktop) application such as Microsoft Access to inspect your voter data for problems, if necessary manipulate the way some of your data is represented, and then export to a comma separated value file. What is a comma separated value file?:
(More details on the CSV file specification can be found here.) AdvoKit has built-in support for a number of typical voter data fields. See the following links for information: AdvoKit does not depend upon having data in most fields. It works best however if you provide at least a fully parsed name, address and date of birth for each voter (by "parsed" we mean separated into parts, e.g. first name, last name, middle initial). Most advocacy operations rely upon other fields for voter filtering, such as "political address" (ward, precinct, etc.), and party affiliation.
Some pitfalls we have seen:
|
|||
|
Upload this file (by e.g. using an ftp client) to your server. It should be placed in the "voterfiles" folder, which is typically located in the folder where all your installed advokit system files are stored. As you will see in the next screen, it is possible to skip the step of manually uploading the voterfile to your server. However it only works for relatively small voter files, and is quite slow. We recommend not using this option.
|
|||
|
When you click on the "Upload Voterfile" link (you must be logged in as the campaign leader), you will first be asked where the voterfile is found:
In this example, we had uploaded a file called "vf.csv" to our voterfiles directory and picked its name from the drop-down list. (Again, we recommend against using the direct upload option.) When you click on the "Choose/Upload File" button, AdvoKit will look at the file, read the field names, and then present you with a screen where you can indicate how your voterfile fields will be related to fields and tables in the AdvoKit voter database.
Each field in your voter file is listed in the left-hand column. For each voterfile field, you should choose the field name in the corresponding AdvoKit data table that you want it mapped to. Note that not all voterfile fields need to be mapped. What to do with voterfile data that you need to use, but for which there is no corresponding AdvoKit field? This is what custom fields are for. The first step is to map the fields that you can, as above, to AdvoKit fields. Then click "Proceed >"
At this point, we can now choose among the unmapped fields from the voterfile to put into custom fields, as can be seen here. Be sure to choose a field type as well as give the new field a name. IMPORTANT: We strongly recommend that you check the box at the top of the screen to have a mapping file generated for use with the command line import utility. Whether or not you use this option, you will still need to execute the voterfile import from the command line. Using a generated mapping file with the import utility is many times faster, and much more reliable, compared with having AdvoKit generate the data import script. Assuming you did check the generate mapping file box at the top of the screen, clicking "Proceed >" will cause a mapping file to be generated and placed into your voterfiles folder on the server. It's useful to write down the name of the mapping file since you will have to type it into the command line in the import step.
|
|||
 |
|||
|
To actually import the voter data into your AdvoKit voter database, you will need to be able to execute a Perl script on your server. The script is called "import.pl" and the original can be found in the advokit-installer/utils directory. It probably makes most sense to extract this file on your PC and edit it there before uploading it to the server. You will need to edit import.pl to include information that the script will need to connect to your MySQL database. This is the same information as was provided when you did the first installation step. Starting on line 20 of the import.pl script, you will see:
Edit these values to provide the correct host, database name, database username, password and table prefix. Save the file and upload it to your voterfiles directory on the server. Now log into a command window on the server (consult with your host if you do not know how to do this) and go to your voterfiles directory. The syntax for running the import script (assuming you are in the voterfiles directory) is:
The import.pl script will now execute. Feedback is provided as to how many records have been imported. When complete, it is a good idea to inspect the data using e.g. phpMyAdmin.In particular, check to see if the number of ak_voter records is correct (should be the same as the number of original records in the voterfile). If there have been any problems with the import, you will probably need to delete the records in several tables in the database and re-do the import.
|
|||
Importing County Voting Records Into Advokit - by John Barta, Morro Bay , California
Advokit works with many tables and fields of data within those tables. The Advokit system is highly structured. Unfortunately, local voter files come in all shapes, sizes, and qualities. So, you will first use your own computer to put that information into shape before it can be imported into Advokit. The process involves getting your local data and then your conversion of that data into a "comma separated values" (CSV) file that is usable by Advokit. The county data must be cleaned up and often parsed in order for Advokit to be able to convert and import it without error into the Advokit system data file which is a MySQL file. You upload your "cleaned up" CSV file to the proper location on the web server where it can be acted upon. The actual importation of data from the CSV file to the MySQL file is done on the web server using a perl script called "import.pl" which is part of the Advokit utilities.
The basic steps in the process are as follows:
1. Obtain the voter file from your registrar of voters. In our case the county provided the file on a CD in a "tab delimited" format. You may also wish to get from the county a printout or other copy of the file structure. This will contain valuable information when you start playing with the data on your personal computer. Sometimes the county information is kept in more than one data table. For example the voter information may not be in the same table as the precinct and district information. If you can get the district and precinct information table from the county you should do that to as it will be useful when later figuring out which candidates are running in which precincts within that jurisdiction. In our case the county voter file only contains information about which local precinct the voter is located in. The information about which districts contain that precinct is contained in a separate file. Keep a friendly relationship with your local voter registrar, it may pay dividends down the road.
2. Study the structure of the local voter file. You should try to understand what the information in each (of the about 60) fields represents. In our case I was able to speak to the "computer guy" at the county office and he was quite helpful in my understanding the purposes of each field in the file. Make a written description of the structure of the county file and each field that it contains. Explain what each field is used for. Once you look around at the data within the file, you will have a much better idea of how it is designed to work. You may find that some fields have no data inside at all. You may also find that two similar-sounding fields actually are not 100 percent the same data. This a good time to ask questions of your registrar because you may make a mistake if you rely on one field and later learn that the data is not exactly what you thought it was.
3. Study the fields that are requested in the Advokit mapping utility. You will need to know what Advokit is looking for so you can make the best of your local voter file data before trying to import it into Advokit.
The fields that Advokit will ask you about for its use in the "_voter", "_residence", "_mailaddress", and "_respolis" tables are as follows:
As you study the Advokit field information compare it to what your local voter file is offering. It is highly likely that you will discover that you'll have to make some changes to your local voter file data in order to use it with Advokit. For example, our local data has a single field for birthdate. This will need to be turned into 3 fields of data – birthyear, birthmonth, and birthdayofmonth. Advokit turns these three fields into the simple birthdate field itself. Also, it turns out that Advokit only stores party affiliation as a single letter – the first letter shown in the CSV field for party affiliation. Locally we have two affiliations that begin with the letter "D" Democrats (DEM) and "Declined to State" (DTS). So, we better change the DTS data in the local file to some other letter or we'll have an inaccurate picture of the number of Democrats in our county. Anyway, there will very likely be a number of opportunities to optimize the local data to make things work better for Advokit.
When you feel confident about what you need to do to your local data you should be able to list what massaging you will want to do to the local voter data before sending it off to Advokit.
4. Clean the county file. This is not the massaging that was mentioned above. It is the process of finding out-of-place or troublesome characters in the local data file. For example, local data containing double-quote (") could be extremely troublesome during the CSV process since the double-quote character is used extensively in that process. The advokit documentation has a link to the CSV standard which is useful. What I discovered is that if I cleaned out the double-quotes, single-quote (apostrophe)('), percent (%) character, semicolon(;), etc. I did not have a problem later. The CVS standard allows quite a number of things to remain in the file, but why take a chance on the odd stuff since it is easy to clean and rare or non-existent anyway?
Open the county file on your personal computer. In our case I used Microsoft Word to load the file. Our file was about 50 megabytes at that point in time and so the operations were a little slow at first. Since the tab character was only used as a field delimiter I was able to search through all fields of the entire file to look for "dirty" data – characters that might cause problems later in the process. The one thing that will for sure cause problems is the double-quote character " The other things I searched to eliminate were the tilde~, the backward apostrophe `, the semi colon; and the apostrophe '. The Advokit help files point you to a CSV standard which will show that most of these are okay, but I didn't want to take chances on how they might be handled by MySQL after being imported into Advokit, so I removed them from the file, too. Once I finished cleaning the file in MS Word I saved it for use by my local database program. In my case, I prefer to use good old Dbase for data manipulation. You may want to use some other program – Access or a local copy of MySQL, for example. Just make sure you save it in the correct form so that it can be imported by your data base program. In my case I saved it in Word as a "Text-only" file that was comma-delimited (with double-quotes around the data for each field).
[Note on how you clean your county file – Use your choice of programs to accomplish that goal, but beware that your early choices can create issues later, if you aren't careful. For example, I could import a tab-delimited county file directly into MS Access but Access will make certain assumptions about the type of data that is being imported – fields that always have numbers in them will be assumed to be integers and not text, for example. So, if you are importing into Access, you need to specify that all fields are text fields and not other data types (date and time, integer, floating, etc.) before or during the importation into Access. Access will not export the data later to a workable CSV file if the fields are not defined as text going in.]
5. Massage/Parse the clean local data file. Once you have loaded your local data into your personal database manipulation program you can start optimizing it for use by Advokit. This is where you will make the changes you planned for at the end of Step 3, previously. So, go in – split the birthdates into three fields, makes adjustments to the party affiliation codes, etc. This is the step where you will be able to add some real value to the county data by good parsing or concantation, etc. If you plan to add additional fields of data, this is the time to do it. In my Dbase case I saved my successful command lines in a file. I was able to then turn this file into a Dbase program script. So, the next time I need to massage the county file I'll be able to save much time by just running the Dbase program. If you use Access to do the local data work – be sure that you end up with all of the data in text fields – otherwise you will not end up with a usable CSV file.
[Note on the CSV standard – the standard calls for each field of data to be separated from the next field with a comma. If the data within the field is text data it is supposed to be surrounded by double quotes. If it is integer data there are no double quotes around the data. Here's the rub – The Advokit import utility wants to receive all of the data as text, regardless of its final disposition. So, a usable CSV file will be in the form of "field1data","field2data","field3data","field4data" etc. If you create a (perfectly legal) CSV file that looks like this: "field1data","field2data",field3data,"field4data" you will have problems (note that field3data is not surrounded by quotes because it was presumably an integer value). You need to be careful to export the data from your database program as all text with no integer, numeric, etc data types in it.]
6. Do final preparations for loading the CSV file onto the server. Make sure that the first record in the CSV file contains all of the field names in CSV format, i.e. "fieldname1","fieldname2","fieldname3", etc. Also, make sure that there are no extra carriage returns at the end of the last record – it may cause problems at the end of the import process. Load the CSV file onto the server. In my case I used a freeware FTP program to upload it into the appropriate directory (/voterfiles/). My file was 80 MB and this took about 45 minutes to upload to the server on my cable connection. It would have taken considerably longer on a dialup connection.
7. Download and alter the import.pl file Use your text file editor to include the information which may be unique to your situation- near the top of the file you will add appropriate information to the
my $CFG_DBPORT= 3306
my CFG $DBNAME='yourAdvokitDBDSN'
my $CFG_user='root'
my $CFG_DBPASS='yourMySQL_DBpassword'
my $CFG_DBPREFIX='ak'
lines. (Several of these parameters are unlikely to change. I.e. 'localhost', 3306, 'root' are examples of information that is not likely to change).
When you have completed editing the import.pl file – save it (it's a text file) and upload it to the server.
8. Mapping your data to the Advokit standard MySQL data. Log into Advokit as a Team Leader. This should have been set up previously from an administrative level. When you are logged in as a Team Leader you will see an option on the left menu bar to "Upload Voterfile". Take the link and follow your nose. You will first identify the CSV file that you uploaded to the server. When you click the "proceed" button you will be presented with a mapping utility. On the left side will be a list of all of the fieldnames from your CSV file. (Folks who have more fields will have a longer list.) This is when your knowledge about the Advokit fields will come in very handy. Using the selection lists in each column you can show the connection between specific fields in your CSV datafile and the fields that Advokit has arranged. When you are done you will click your way through (You'll have to confirm a check box along the way). This is also where you can add some custom fields if your CSV file has them in it. When you have completed the mapping process Advokit will have created a text file with the extension ".map" in the /voterfile/ directory where you previously had the CSV file and the import.pl file.
[Note on Mapping file: If you take a look at your map file you will see that all Advokit did was to create a CSV list of several columns – one column for each of the four tables and an extra one for the custom fields if you added them. Here's the first row of that file in my case:
"csv_column","respolis_column","residence_column","mailaddress_column","voter_column","custom_column"
what follows is a whole list of every field in the CSV file followed by the various Advokit fieldname(s) that correspond to that field in the order shown above. Thus, if you were a careful text editor of your mapping file, you could bypass the Mapping utility]
9. Time to Rock and Roll. All of the pieces are now in place to do the import itself. This is best done from the command line of the server by the server administrator due to permissions issues and server security policies which might interfere or make impossible your executing the command. It may be possible to arrange a Cron job to do this, if you have the appropriate permissions on the server. In our case we were on a shared hosting server with many other accounts. So, for simplicity, we emailed the system administrator and asked them to run the perl command from the server's command line. We gave them the exact command syntax to make it easier for them to just cut and paste the command onto their command line. The basic syntax is:
perl import.pl <mappingfilename.map> <csvfilename.csv>
(note the three spaces in this commandline)
In practice, the command can be quite long since it needs to have path information in it. Ours (ignore the wrapping, but not the spaces) was:
/usr/bin/perl /home/httpd/vhosts/ourdomain.org/aboverootdirectory/advokit/voterfiles/import.pl /home/httpd/vhosts/ourdomain.org/aboverootdirectory/voterfiles/SLOcsvTestSnippet060205.csv-2006-02-05-17-54-16.map /home/httpd/vhosts/ourdomain.org/aboverootdirectory/voterfiles/SLOvotersAll060206.csv
That's It! The import.pl script will do its thing and report what is/has happened on the system. This may take some time, so be patient. I am told that really long files can take some time to handle (ones in the hundreds of thousands of voter and up category) If all goes well you will be in business with voter data at that point. Our file had 150,000 records in it and it took about 50 minutes. (There were no complaints about how long it took from the system administrator, so we assume it was a background task. We also asked him to run it in the middle of the night)
10. Examine the results. When you have been notified of the outcome of the import.pl script, log on to the server and open phpMyAdmin where you can look at the data and all of the Advokit tables. You should see the same number of voters in the "_voters" table as your CSV file if this is your first upload. Note that the number of records in the "_residence" "_mailaddress" and "_respolis" tables will be a lesser number. This is because Advokit only stores one record in "_residence" for each house. Thus, because there are often several voters at the same address – that address will only appear once in the "_residence" table. Make sure the data is in the right places. Congratulations!
Voter Tables
Voter Data: ak_mailaddress field descriptions
| Mailing Address Table from Advokit. One record per unique mailing address. Voters are linked to records in this table. Note that editing a mailing address record changes information for *all* voters who are linked to that mailing address. |
||||
| Field | Req'd Yes or No? | Size (in characters) | Explanation – what it is intended to be used for or very clear example of data that would go into the field | Default by Advokit? If empty, will import.pl automatically put a value in this field? If so what is it? |
| number | 11 | Numeric portion of a street address, e.g. ‘1552’. | Non-digit portions split out. E.g. "1A2B" becomes "12" (yes, this sucks) | |
| num_suffix | 10 | e.g. ‘ 1/2 ’, ‘A’, ‘-1’, etc. This is any non-numeric portion of a street address | Import.pl will split non-numeric portions of street addresses from the initial numeric portion, and put them into ‘number' and ‘num_suffix'. However you can map these fields directly to input fields, in which case import.pl will not automatically create ‘num-suffix' | |
| precompass | 10 | N, S, E etc | Prepended portion of street name indicating direction | |
| streetname | 30 | Elm | ||
| streettype | 20 | ST, Blvd, Road, etc | If not mapped from an input field, import.pl will attempt to split it out of the input street name field. Must match a street type in street types list in import script | |
| postcompass | 10 | N,S,E,W, SE, etc | Appended portion of street name indicating direction | |
| aptname | 10 | Building B | If an aptname is provided, it is written to this field. Otherwise if aptnum is provided, it is written here. If neither is provided, parsing of "line1" may populate this field. | |
| aptnum | 8 | 15 | If the aptname or aptnum contains non-digits, they are stripped out and the numeric characters are written to aptnum. If neither is provided, parsing of "line1" may populate this field. | |
| line1 | 40 | Concatenated address, line one | If not mapped from an input field, import.pl will assemble from street address fields. If street address fields are not provided, import.pl will attempt to parse line1 to populate those fields. | |
| line2 | 40 | Optional second address line | ||
| city | 30 | New Orleans | ||
| state_id | 2 | CA, NY (use standard two-letter state abbreviations) | Must match item in state list in import script | |
| zip | 5 | Only first 5 zip numbers here | ||
| zipplus4 | no | 4 | Only last 4 zip+4 numbers here | |
| county_id | 11 | You can put longer here Advokit will change to its own code | There is a bug in import.pl that requires a county_id to be included during import. You can put in whatever you want. | |
Voter Data: ak_residence field descriptions
| Residence Table from Advokit. One record per unique residence address. Voters are linked to records in this table. Note that editing an existing residence record changes residence information for *all* voters who are linked to that address. |
||||
| Field | Req'd Yes or No? | Size (in characters) | Explanation – what it is intended to be used for or very clear example of data that would go into the field | Default by Advokit? If empty, will import.pl automatically put a value in this field? If so what is it? |
| number | yes | 11 | Numeric portion of a street address, e.g. ‘1552’. | Non-digit portions split out. E.g. "1A2B" becomes "12" (yes, this sucks) |
| num_suffix | no | 10 | e.g. ‘ 1/2 ’, ‘A’, ‘-1’, etc. This is any non-numeric portion of a street address | Import.pl will split non-numeric portions of street addresses from the initial numeric portion, and put them into ‘number’ and ‘num_suffix’. However you can map these fields directly to input fields, in which case import.pl will not automatically create ‘num-suffix’ |
| precompass | no | 10 | N, S, E etc | Prepended portion of street name indicating direction |
| streetname | yes | 30 | Elm | |
| streettype | no | 20 | ST, Blvd, Road, etc | If not mapped from an input field, import.pl will attempt to split it out of the input street name field. Must match a street type in street types list in import script |
| postcompass | no | 10 | N,S,E,W, SE, etc | Appended portion of street name indicating direction |
| aptname | no | 10 | Building B | If an aptname is provided, it is written to this field. Otherwise if aptnum is provided, it is written here. If neither is provided, parsing of "line1" may populate this field. |
| aptnum | no | 8 | 15 | If the aptname or aptnum contains non-digits, they are stripped out and the numeric characters are written to aptnum. If neither is provided, parsing of "line1" may populate this field. |
| line1 | no | 40 | Concatenated address, line one | If not mapped from an input field, import.pl will assemble from street address fields. If street address fields are not provided, import.pl will attempt to parse line1 to populate those fields. |
| line2 | no | 40 | Optional second address line | |
| city | yes | 30 | New Orleans | |
| state_id | yes | 2 | CA, NY (use standard two-letter state abbreviations) | Must match item in state list in import script |
| zip | yes | 5 | Only first 5 zip numbers here | |
| zipplus4 | no | 4 | Only last 4 zip+4 numbers here | |
| county_id | yes | 11 | You can put longer here Advokit will change to its own code | There is a bug in import.p that requires a county_id to be included during import. You can put in whatever you want if you do not have county data. |
| latitude | no | FLOAT | ||
| longitude | no | FLOAT | ||
Voter Data: ak_respolis field descriptions
| Respolis Table from Advokit. This table stores “political address” information. Import.pl will create one respolis record per unique “political address”. Voters are linked to records in this table. Note that editing an existing respolis record changes respolis information for *all* voters who are linked to that record. |
||||
| Field | Req'd Yes or No? | Size (in characters) | Explanation – what it is intended to be used for or very clear example of data that would go into the field | Default by Advokit? If empty, will import.pl automatically put a value in this field? If so what is it? |
| ward_number | no | 20 | If you have wards, use it. If not, ignore. If you have supervisorial district data put it here. | |
| precinct_number | no | 20 | If you have precincts, parishes, etc. that are identified numerically, use this field. | Import.pl will create a single record for each precinct number or name |
| precinct_name | no | 50 | If you have precincts, parishes, etc. that are not identified numerically, use this field. | If you have precinct "portions" make sure names reflect them or the portions will be ignored during import, ie. Use "AG001_A" and "AG001_B" instead of just "AG001" |
| us_rep_district | no | 20 | US Congressional district | |
| us_sen_district | no | 20 | Ignore (or use for your own purposes) | |
| st_rep_district | no | 20 | State representative district | |
| st_sen_district | no | 20 | State Senate district | |
| census_tract | no | 20 | Geographic designation from the US Census | |
| census_block | no | 20 | Geographic designation from the US Census | |
Voter Data: ak_voter field descriptions
| Voter table from advokit. One voter record per voter. Note that residence address, mailing address, and “political address” (respolis) are extracted into other tables by import.pl. |
||||
| Field | Req'd Yes or No? | Size (in characters) | Explanation – what it is intended to be used for or very clear example of data that would go into the field | Default by Advokit? If empty, will Advokit automatically put a value in this field? If so what is it? Comments |
| instance_code | no | 11 | This is meant to support multiple campaigns and voter files – it can be ignored. Designates source of data from which this import comes | |
| instance_area | no | 10 | This is meant to support multiple campaigns and voter files – it can be ignored. | |
| salutation | no | 10 | Mr,Mrs,Ms, etc. | |
| nickname | no | 15 | e.g. Bob | copy of firstname |
| firstname | yes | 15 | e.g. “Robert”(for “Robert L. Smith”) | |
| middle_initial | no | 1 | e.g. “L” (for “Robert L. Smith”) | |
| lastname | yes | 35 | “Smith” (for “Robert L. Smith”) | |
| suffix | no | 10 | Jr., Sr. III, etc. | |
| birth_year | yes* | 4 | Year of birth, e.g. 1946 | |
| birth_month | yes* | 2 | 08 (two digits) | |
| birth_dom | yes* | 2 | Day of the month, e.g. if the birth date is May 31st, then this field would have “31” | *date of birth is used to display age – it is not strictly required |
| birthdate | no | Datetime | There is currently a bug in import.pl – the best approach is to provide birth_year, birth_month, and birth_dom. Leave birthdate unmapped.import.pl will then create birthdate correctly. | Import.pl will calculate this from birth_year, birth_month, and birth_dom |
| confidence_level | no | 1 | This is meant to allow you to indicate your confidence that the information in this voter record is accurate. | |
| gender | no | 1 | ‘M’, ‘F’, or ‘U’. | ‘U’ is the default |
| occupation | no | 20 | E.g. stone mason | |
| citizenship | no | 2 | Use ISO 3166-1two-letter country codes (a list can be found here: http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html) | ‘US’ is the default |
| is_registered | no | 1 | Is the person registered to vote? Y or N ? | ‘N’ |
| registeredon | no | Datetime | Date of voter registration. Format as (e.g.) ‘2006-01-31’ | |
| can_vote | no | 1 | Not clearly defined – intended to indicate whether or not the person will be able to vote. ‘Y’, ‘N’, ‘U’ | |
| will_vote | no | 1 | Not clearly defined – intended to indicate whether or not the person plans to vote. ‘Y’, ‘N’, ‘U’ | |
| absentee | no | 1 | . ‘Y’, ‘N’, ‘U’ – is this person an absentee voter? | ‘N’ |
| party_affiliation | no | 1 | Single character identifying political party affiliation. E.g. ‘D’, ‘R’ | Note:Check your local data before importing and convert to single unique character for each party or you'll end up with both "DEM" and "DTS" (declined to state) as "D" |
| ph_home | no | 12 | Home phone number. No required format, but use consistently (e.g. ###-###-####) to enable e.g. filtering by area code (e.g. ph_home like ‘212-%’) Assumed 7 or 10 digits | Adds dashes at 3-digit intervals |
| ph_office | no | 12 | Office phone number Assumed 7 or 10 digits | Adds dashes at 3-digit intervals |
| ph_mobile | no | 12 | Cell phone number Assumed 7 or 10 digits | Adds dashes at 3-digit intervals |
| no | 30 | Primary email address | ||
| alt_email | no | 30 | Alternate email address | |
| imid | no | 20 | Instant messaging identity/screen name | |
| imtype_id | no | 11 | Associated instant messaging service (e.g. ‘AOL’) type, must match record in imtypes table | |
| alt_imid | no | 20 | Second instant messaging identity/screen name | |
| alt_imtype_id | no | 11 | alternate instant messaging service (e.g. ‘MSN’) type, must match record in imtypes table | |
| uploaded | no | 1 | Originally intended to indicate if the voter record was created by voterfile upload, or entered interactively. Y or N | Set internally to indicate whether data was entered through advokit |
| notes | no | TEXT | Whatever you want can go in here. | |