Here at Service Objects we come across a lot of names, particularly the names of places. We also work with a lot of personal names, but for now I would like to focus on just place names. Whether the name is for a city, town, village, hamlet, district, region, state, prefecture, mining area, national park, theme park or what have you; chances are that the place may have one or more even alternate spellings and alternate names associated with it.

For a human fluent in English, “North Carolina” and “N. Carolina” will be considered equal, but for a computer they are not. With the use of fuzzy-matching and/or standardization we can work around seemingly trivial issues like this. Now let us suppose that you are working with a set of Japanese data and come across the same name but written in Katakana “ノースカロライナ” or Ukrainian data written in Cyrillic “Північна Кароліна” or even Thai “รัฐนอร์ทแคโรไลนา”. Well, fuzzy-matching and standardization are still our friends; we just have more fuzzy-matching and standardization rules to consider. However, we first need to ensure that we even have the data available to associate a name in a different language.

We’ve been creating a list of place names to help us tackle problems like the ones mentioned above. We currently have a list of over five million unique place names generated from a pool of approximately 11 million names. We are aggregating name data to come up with a more comprehensive list that consists of known alternates, variations in spellings, different languages and the transliterated versions for the different languages.

Here’s a quick look at what we have accomplished, so far:

• Current list of approximately eight million place names and growing
• Transliteration and phonetic mappings for various languages
• Case, accent and kana sensitivity handling
• Queryable using fuzzy-matching algorithms

We have taken some of what we have learned from our DOTS Address Validation – International service and built upon it in order to improve data beyond the realm of just address validation. When working with Phone, Email, IP, Demographic and Geo-coordinate related data we too often find that location names do not match up. Naturally this is to be expected, since different data vendors will have different standardizations and practices when it comes to naming conventions. Utilizing a comprehensive place name library will allow us to quickly perform various actions, such as cross checking multiple data sources against each other with increased flexibility and match rates.

It may not be immediately apparent how useful a place name library like this is and what kind of avenues it can open up, but expect to see new and exciting developments from us in the coming months!

What is a Hack-a-thon? 

The term “hackathon” (or “hackfest,” “codefest, or “hackday”) combines the words hack and marathon. In other words, a caffeine-fueled frenzy of innovation. Though coding is a common hackathon task, these events, which can last from a single day or an all-nighter to more than a week, aren’t just for hacking. Hackathons can be used to solve a critical problem, to learn, to brainstorm new and innovative ideas, or even in support of a cause. Companies like Facebook, Google, Shutterstock, and AT&T are among the many notable companies that use hackathons. Here’s how we use hackathons here at Service Objects.

Every Day Hackathon Mentality

Innovation is important to Service Objects, so much so that we are given tremendous freedom to continually innovate our products. Innovation is part of our jobs to the point that every day is essentially a hack day. However, we also have to juggle our day-to-day tasks and other responsibilities. It dawned on us that starting our own hackathons would allow us focus on innovation in a more focused and more collaborative manner.

Service Objects’ Hackathons

So far, we have held two hackathons and are looking forward to our third one in the next month. Every other month, we set aside two solid days for our hackathons. 

We block off the engineering area of the office using police tape to block off the hallway leading to our area. Though our area is located in a quiet, isolated corner of the building, having a physical blockade reinforces the message that we’ve already shared with the rest of the company: Do not disturb! Everyone knows that we are not to be interrupted unless it’s an emergency. Even then, one point of contact is assigned to handle the case, allowing the rest of the team to continue hacking. 

The police tape also puts us in the right frame of mind. We know that when we enter the hackathon zone, we are entering an area where we are encouraged to step outside of our comfort zones. We have no set rules other than to build something we think will help the company and its customers. For example, our internal applications group might try their hand at interesting new services and functionality while the R&D team could create an internal app that they think would benefit the company in some way.

Though we’ve only held two hackathons to date, we’ve already generated some useful ideas such as:

.   The identification of unincorporated locations of a city

.   A new way to collect business data

.   A new fuzzy matching algorithm for our email validation service

.   A potential way to identify telemarketers from a phone number

The entire team looks forward to our hackathons. While we get to innovate daily, our hackathons allow us to come together — without interruption —  specifically to ask “What if?” and push ourselves outside of our comfort zones. We enter the each hackathon with the knowledge that anything is possible, and we conclude each one with a fresh set of ideas for the betterment of our company.