Пространственное отображение ключевых слов / тегов - PullRequest
2 голосов
/ 29 января 2009

Я пытаюсь понять формулировку или идею построения пространственных карт связанных / общих ключевых слов или тегов. Используя SO в качестве примера; если вы перейдете на https://stackoverflow.com/tags и введете «python», вы получите все теги, в которых есть это слово, но нет тегов, которые могут быть тесно связаны (WSGI, Google App Engine, полет и т. д.). *

В соответствии с моим вопросом, как вы могли бы построить пространственную карту, к которой можно было бы обратиться, чтобы найти тесно связанные теги / ключевые слова из поиска, упорядоченные по их весу? Но тогда как сохранить вес тега foo для потенциально большего количества тегов и при этом поддерживать работоспособность системы?

Я уже смотрел этот технический доклад Google Дэвида Вайнбергера, который является отличным техническим докладом, который заставил меня задуматься. http://video.google.com/videoplay?docid=2159021324062223592&ei=qseASZvgI6e4qAP91a2PDg&q=google+tech+talk

Ответы [ 4 ]

1 голос
/ 02 февраля 2009

Проверьте концепции кластеризации из "Программирование Коллективного Разума" О'Рейли .

0 голосов
/ 29 января 2009

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

То есть "c ++" и "stl" часто встречаются вместе, а "stl" редко (?) Появляется без "c ++", поэтому они связаны (хотя бы в одном направлении). «c ++» и «алгоритм» также часто встречаются вместе, но они появляются все чаще, поэтому они не связаны между собой.

0 голосов
/ 29 января 2009

Размышляя о том, как можно структурировать данные, я мог подумать о системе из четырех таблиц. одна таблица будет исходными данными (например, с SO должна быть какая-то таблица вопросов), которая присоединяется к таблице тегов, а затем к таблице весов тегов, которая присоединяется к таблице тегов.

#pseudo code
     source table {
     id: int
     source_data: text   
     }

     source_tag table {
        source_id: int
        tag_id: int
     }

     tag table{
      id: int
      tag: String(30)
     }

    tag_weight table {
        base_tag_id: int
        weight: float( 0-10 or 100 ) or int ( count of mutual occurrence )
        source_tag_id: int      
    }

Я понятия не имею, насколько эффективна эта структура, но я полагаю, что над ней нужно работать. В противном случае, чтобы это работало, при новых поступлениях в исходные данные может сработать триггер после обновления или рабочий процесс в фоновом режиме перебалансирует веса в заданное время.

0 голосов
/ 29 января 2009

Вам нужен хороший поисковик. ;)

Сделай сам: реализуй один из алгоритмов подобия. Например: Расстояние Левенштейна или Коэффициент Кости .

Или используйте что-нибудь готовое к использованию, например Lucene .

...