Использование «нечеткого поиска» при перекрестных ссылках на данные - PullRequest
Новая
       31

Использование «нечеткого поиска» при перекрестных ссылках на данные

0 голосов
/ 10 февраля 2012

Мой отдел занимается сбором и отображением данных из широкого круга внутрифирменных источников для использования в интеллектуальном анализе данных / информационных панелях компаний.

Одна из серьезных проблем, с которыми мы сталкиваемся, заключается в перекрестной ссылке на названия местоположений в различныхведомства.Мы - довольно крупная организация, и отделы с разными интересами делают свои собственные отчеты для любого местоположения.В целом, в названии EXACT много различий, которые есть в названии местоположения в отчетах по этим отделам.Например, место может упоминаться как:

  • Сказочный ресторан
  • Сказочный ресторан
  • Fabulous F & B
  • Когда место проходит некоторую реконструкцию ... Fabulous Cafe '
  • или даже Центр прибыли 12345ABC

Итак, у меня вопрос: какие существуют лучшие практики согласования этих имен в нашей собственной базе данных и коде?Давайте пока предположим, что мой отдел не имеет возможности объединить организацию в рамках единого стандарта иерархии (что было бы оптимальным решением).В настоящее время наша практика состоит в том, чтобы поддерживать постоянно растущие справочные таблицы имен местоположений, которые затем возвращаются в наш собственный стандарт именования.Это позволяет нам поддерживать историческую согласованность с нашими данными.

Возможно ли / целесообразно ли реализовать какой-то «нечеткий поиск» при перекрестных ссылках на местоположения?Например, что-то, что могло бы игнорировать такие слова, как «the», или относиться к «cafe» и «restaurant» одинаково (основываясь на некоторой заранее определенной логике).

Я, конечно, не думаю, что мыкогда-либо сможет алгоритмически учитывать ВСЕ случайные соглашения об именах, с которыми мы сталкиваемся, но достаточно ли этого, чтобы иметь возможность учитывать некоторые / большинство из них?

1 Ответ

1 голос
/ 11 февраля 2012

Ключевое слово: . retagged. Нечеткий поиск часто встречается в и определенно полезен здесь. Но приведенные вами примеры могут быть слишком сложными для автоматической интеграции, вам потребуется вмешательство пользователя и надлежащая .

Я успешно использовал нечеткое сопоставление для повторного импорта музыкальных плейлистов. Даже из интернета. Название и исполнитель обычно предоставляют достаточно данных для достаточно надежного нечеткого соответствия моей музыкальной коллекции (по крайней мере, если у меня есть песня).

Однако нечеткое сопоставление не будет надежным, если у вас будет только одно слово, как в вашем примере с «невероятным рестораном».

Хорошее нечеткое сопоставление будет использовать основы и иметь представление об общих словах и синонимах. Так что «ресторан» и «кафе», вероятно, не будут считаться значимыми. Ключевой момент в том, чтобы иметь достаточно данных. Вероятно, одного слова будет недостаточно для определения местоположения.

...