Editor's note: Today's will be part 1 of a special two-day Building a Voter File extravaganza! Quite frankly, this topic is just too awesome to be tackled in one entry, so check back tomorrow for the thrilling conclusion.

Nate Silver had an interesting conjecture recently, in a post about how exactly Norm Coleman got his list of "improperly rejected ballots" in the never-ending Minnesota Senate race:

What I suspect Coleman did to come up with his list of 650 is something like this:

- Create a database of all ballots that were rejected for a non-matching signature ... maybe there were 1500 of these or something statewide.

- Run some algorithm to determine the likelihood of each of these 1500 ballots being a vote for Coleman as based on things like the precinct the ballot was cast in, any information Coleman has about the voter in his voter file, and perhaps even the voter's name (you can tell more than you'd think about someone based on their first and last name).

- All ballots determined by this algorithm to have a >50% likelihood of being Coleman votes were included on his list ... there turned out to be about 650 of these.

There's more beneath the fold:

It's the most...wonderful...time...of the year.  That is, the time when the data for the 2008 elections finally comes in.  There's more...

In my last entry, I discussed matching lists when they did not share a common, persistent and unique identifier.  Basic conclusion: challenging! In this week's entry, I'll share a common technique for making the job a little easier--one which has a number of uses beyond list-matching.  Read more...

In my efforts to duplicate the straightforward plots of David Foster Wallace, I'm going to circle back yet again to one of my earlier posts.  There's more below the fold...

Just a quick note--some technical issues with what I had been planning to do with Building a Voter File left me without a piece this week.  I'll be back at my regularly scheduled time (having worked ahead).  In the meantime, please stick around; I've got a non-series post in the can.  My apologies.

As of the end of our last post, we've obtained and loaded into SQL a recent voter file from Adams County.  This week we're going to examine using the file in a very basic way.

In the last part of the Voter File tutorial, we loaded the Adams County, Ohio file into SQL.  It should now be ready to use.  But first, we need to go through some basic quality control on the file, which I'll show you how to do below the jump.

Consumer data is one of the most frustrating areas of voter file design, especially if you're interested in transparency or an open-source methodology.  Large parts of the voter file process use publically available data, and can be duplicated by any group with relatively low levels of equipment and technical skill (for example, witness my tutorial effort, which I absolutely promise to get back to after the election).  There's no such ability for data appends.  After the jump I'll explain why.

As promised earlier, I'm focusing on the way voter files are used during the runup to an election.  Last week we covered early voting; this week, it's time to focus on new registrants.  Follow me to the magical land of beneath the fold...

As the election approaches, I thought I'd write a little more about the uses of the voter file in this particularly busy time.  It's a very different operation than it is in the earlier stages, when you're setting up your file.  By the time October rolls around, moving as much information into and out of the voter file as possible becomes paramount.  There are a couple of ways that files get used late in the game that don't show up earlier; today, appropos of last night's discussion, we're going to focus on early voting.