Как решить семантические проблемы с веб-сайтами на основе тегов

Question

Веб-сайты, основанные на тегах, часто страдают от деликатности языка, такого как синонимы, омонимы и т. Д. Для программистов, которые ищут информацию, например, о переполнении стека, конкретные примеры:

• Subversion или SVN (или svn, с чувствительными к регистру тегами)
• .NET или Mono
• [Добавлю больше]

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

Сайт, подобный del.icio.us, значительно расширяет свою базу тегов, что, вероятно, затрудняет использование или поиск. Поиск записей, связанных с SVN, вероятно, приведет к выводу большинства записей с тегами subversion и svn, но я могу вспомнить три проблемы:

1. Поиск не завершен, поскольку многие записи могут не иметь оба тега (которые являются «синонимами»).
2. Поиск менее полезен, поскольку вопросы и ответы часто приводят к большему количеству вопросов! Особенно для новичков по заданной теме.
3. Пометка вопроса (примечание: или ответ отдельно, звучит полезно) становится философской: «Пометил ли я правильный путь?»

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

Это подход, который звучит хорошо / выполнимо / привлекательно / полезно? Как это эффективно реализовать?

Answer 1

Распознавание синонимов и семантических связей - это то, что люди хороши в ; решение для организации таксономии открытого типа, как то, что представляет SO, вероятно, было бы неплохо, если бы найти способ оставить соответствие людям.

Один общий подход: кто-то (или какая-то команда) ежедневно просматривает новые теги. Новые синонимы добавляются в группы синонимов. Поиск совпадений по группам синонимов (или, более нюанс, поиск совпадений буквенных или совпадений групп синонимов в соответствии с предпочтениями пользователя).

Для этого требуется поддержка групп синонимов на стороне сервера (работа для команды разработчиков). Требуется тег Wrangler или десять (работают для принципалов или для доверенных пользователей). Для не требуется постоянное масштабирование, хотя & mdash; скорость, с которой общий пул тегов будет расти (вероятно, после первоначального удара открытой бета-версии Here Comes Everybody), по всей вероятности уменьшится со временем, как это делает любой рост органического лексикона.

Синонимия кажется мне самой важной темой. Иерархическое картографирование является амбициозной и более сложной проблемой; это может стоить или не стоить, но, учитывая относительную сложность определения иерархии, вероятно, лучше было бы оставить ее как Фазу 2 для Фазы 1 любого потенциального синонима проекта.

Answer 2

Частично проблема, с которой вы сталкиваетесь, заключается в том, что английский язык изобилует синонимами - различаются ли следующие: управление сборкой, subversion, cvs, управление исходным кодом?

Может быть, а может и нет. Наличие системы, подобной [сейчас] используемой в SO, которая вызывает тег, который вы, вероятно, имели в виду, чрезвычайно полезна. Но это не мешает людям проходить процесс маркировки.

Может быть, вы могли бы отказаться принимать "новые" теги без взаимодействия с пользователем? Прежде чем вы позволите 'sbversion' войти, принудительно проверьте орфографию?

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

Answer 3

Как система узнает, какие теги семантически связаны? Сохранит ли она постоянно растущую карту тегов? Я не вижу, как это работает. Что если кто-то наберет sbversion вместо этого? Как это будет связано?

Я думаю, что запрос пользователя при отправке тегов может сработать. Например, «Вы ввели следующие теги: sbversion, pascal и bindings. Вы имели в виду« Subversion »,« Pascal »и« Bindings »?

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

Фактически, сказав все это, система может использовать результаты ввода пользователя в качестве основы для автоматического сопоставления тегов. Из предыдущего примера кто-то создает тег «sbversion», а при появлении запроса меняет его на «Subversion» - система может узнать об этом и сделать это автоматически в следующий раз.

Answer 4

Я полностью согласен. Масса тегов, которые есть на данный момент. Я не участвую в других сайтах с тегами. Однако было бы очень полезно иметь иерархию тегов вместо ruby ​​ rails ruby-on-rails rubyonrails etc ...

Answer 5

Способ установки программного обеспечения на blogspot.com заключается в том, что на коробке, где вы пишете название тегов, есть ajax-autocomplete-thingie. При этом все ваши предыдущие сообщения будут искать теги, начинающиеся с одинаковых букв. По крайней мере, так вы ловите разные оболочки и написания (но не синонимы).

Answer 6

Проблема состоит в том, чтобы заставить поисковую систему использовать тот факт, что 'subversion' и 'svn' очень похожи до такой степени, что они означают одну и ту же вещь.

Возможно, было бы привлекательным вычислить простое сходство между тегами на основе частоты: 'subversion' и 'svn' появляются очень часто вместе, поэтому запрос 'svn' возвращает вопросы, связанные с SVN, но также и редкие вопросы, помеченные только подрывная деятельность '(и наоборот). Однако 'java' и 'c #' также часто встречаются вместе, но по очень разным причинам (они не являются синонимами). Таким образом, сходство по частоте отсутствует.

Ответом на эту проблему может быть сочетание механизмов, предложенных в этой теме вопросов и ответов:

• Фильтрация опечаток путем предложения тегов, когда пользователь вводит их.
• Ведение пользовательской карты синонимов. Эта карта может быть не такой большой, если она предназначена только для синонимов.
• Разрешение поиска по нескольким тегам, так что пользователь может поместить 'subversion svn' или 'subversion && svn' (ну, от программистов до программистов) в поле поиска и получить оба. Это было бы весьма практично, поскольку многие пользователи могут на самом деле попробовать такой подход, когда они не знают, какой термин является наиболее значимым.

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

@ Стив: Поддерживать постоянно растущую карту тегов определенно не практично. Так как SO накапливает постоянно растущую сумку меток, как мы можем затенить эту сумку, чтобы сделать поиск меток Q / A еще более полезным и удобным способом?

@ Espo: предложения тегов 'Ajax-powered' на основе существующих тегов, очевидно, доступны в SO при создании вопроса. Это, кстати, очень полезно для выбора тегов и подходящего орфографии (избегая проблемы «подрывной деятельности» против «sbversion» от Стива).

Answer 7

Теги - это, по сути, наше признание того, что алгоритмы поиска не соответствуют действительности. Если мы сможем заставить компьютер быть достаточно умным, чтобы определить, что вещи, помеченные как «Subversion», имеют содержание, аналогичное вещам, помеченным как «svn», предположительно, мы можем проанализировать содержимое, так почему бы не пропустить все теги и сопоставить поисковый запрос непосредственно с содержание (т. е. автоматическая пометка, которая в основном отображает ключевые слова в результаты)?!