Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've recently done a similar task, although I was matching new data to existing names in a database, rather than looking for duplicates within one set. Name matching is actually a well-studied task, with a number of factors beyond what you'd consider for matching generic strings. </p> <p>First, I'd recommend taking a look at a paper, <em>How to play the “Names Game”: Patent retrieval comparing different heuristics</em> by Raffo and Lhuillery. The published version is <a href="http://www.sciencedirect.com/science/article/pii/S0048733309001528" rel="noreferrer">here</a>, and a PDF is freely available <a href="http://infoscience.epfl.ch/record/161961/files/Lhuillery%20RP2009b.pdf" rel="noreferrer">here</a>. The authors provide a nice summary, comparing a number of different matching strategies. They consider three stages, which they call parsing, matching, and filtering.</p> <p>Parsing consists of applying various cleaning techniques. Some examples:</p> <ul> <li>Standardizing lettercase (e.g., all lowercase)</li> <li>Standardizing punctuation (e.g., commas must be followed by spaces)</li> <li>Standardizing whitespace (e.g., converting all runs of whitespace to single spaces)</li> <li>Standardizing accented and special characters (e.g., converting accented letters to ASCII equivalents)</li> <li>Standardizing legal control terms (e.g., converting "Co." to "Company")</li> </ul> <p>In my case, I folded all letters to lowercase, replaced all punctuation with whitespace, replaced accented characters by unaccented counterparts, removed all other special characters, and removed legal control terms from the beginning and ends of the names following a list. </p> <p>Matching is the comparison of the parsed names. This could be simple string matching, edit distance, Soundex or Metaphone, comparison of the sets of words making up the names, or comparison of sets of letters or <em>n</em>-grams (letter sequences of length <em>n</em>). The <em>n</em>-gram approach is actually quite nice for names, as it ignores word order, helping a lot with things like "department of examples" vs. "examples department". In fact, comparing bigrams (2-grams, character pairs) using something simple like the <a href="http://en.wikipedia.org/wiki/Jaccard_index" rel="noreferrer">Jaccard index</a> is very effective. In contrast to several other suggestions, <strong>Levenshtein distance is one of the poorer approaches when it comes to name matching.</strong> </p> <p>In my case, I did the matching in two steps, first with comparing the parsed names for equality and then using the Jaccard index for the sets of bigrams on the remaining. Rather than actually calculating all the Jaccard index values for all pairs of names, I first put a bound on the maximum possible value for the Jaccard index for two sets of given size, and only computed the Jaccard index if that upper bound was high enough to potentially be useful. Most of the name pairs were still dissimilar enough that they weren't matches, but it dramatically reduced the number of comparisons made. </p> <p>Filtering is the use of auxiliary data to reject false positives from the parsing and matching stages. A simple version would be to see if matching names correspond to businesses in different cities, and thus different businesses. That example could be applied before matching, as a kind of pre-filtering. More complicated or time-consuming checks might be applied afterwards. </p> <p>I didn't do much filtering. I checked the countries for the firms to see if they were the same, and that was it. There weren't really that many possibilities in the data, some time constraints ruled out any extensive search for additional data to augment the filtering, and there was a manual checking planned, anyway. </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload