title: Fuzzy record matching with multiple columns of information
body: <p>I have a question that is somewhat high level, so I'll try to be as specific as possible.</p>
  
  <p>I'm doing a lot of research that involves combining disparate data sets with header information that refers to the same entity, usually a company or a financial security.  This record linking usually involves header information in which the name is the only common <em>primary</em> identifier, but where some secondary information is often available (such as city and state, dates of operation, relative size, etc).  These matches are usually one-to-many, but may be one-to-one or even many-to-many.  I have usually done this matching by hand or with very basic text comparison of cleaned substrings.  I have occasionally used a simple matching algorithm like a Levenshtein distance measure, but I never got much out of it, in part because I didn't have a good formal way of applying it.</p>
  
  <p>My guess is that this is a fairly common question and that there must be some formalized processes that have been developed to do this type of thing.  I've read a few academic papers on the subject that deal with theoretical appropriateness of given approaches, but I haven't found any good source that walks through a recipe or at least a practical framework.</p>
  
  <p>My question is the following:</p>
  
  <ul>
  <li><p>Does anyone know of a good source for implementing multi-dimensional fuzzy record matching, like a book or a website or a published article or working paper? </p></li>
  <li><p>I'd prefer something that had practical examples and a well defined approach.</p></li>
  <li><p>The approach could be iterative, with human checks for improvement at intermediate stages. </p></li>
  <li><p>(<em>edit</em>) The linked data is used for statistical analysis. As such, a little bit of noise is OK, but there is a strong preference for fewer "incorrect matches" over fewer "incorrect non-matches". </p></li>
  <li><p>If they were in Python that would be fantastic, but not necessary.</p></li>
  </ul>
  
  <p>One last thing, if it matters, is that I don't care much about computational efficiency.  I'm not implementing this dynamically and I'm usually dealing with a few thousand records.</p>