Это реальная проблема, которая применяется к элементам тегов вообще (и да, это относится и к StackOverflow, и нет, это не вопрос о StackOverflow).
Вся проблема с тегами помогает группировать подобные элементы, какие бы они ни были (шутки, сообщения в блогах, вопросы и т.д.). Однако там (обычно, но не строго) есть иерархия тегов, что означает, что некоторые теги также подразумевают другие теги. Чтобы использовать знакомый пример, тег "С#" также означает ".net"; другой пример, в базе данных шуток, тег "блондинки" подразумевает "насмешливый" тег, аналогично "ирландский" или "безымянный" или "канадский" и т.д. в зависимости от происхождения страны-шутки.
Как вы справились с этим, если хотите, в своих проектах? Я дам ответ, описывающий два разных метода, которые я использовал в двух отдельных случаях (фактически, тот же механизм, но реализованный в двух разных средах), но меня также интересуют не только аналогичные механизмы, но и ваше мнение по проблеме иерархии.
Это сложный вопрос. Две крайности - это онтология (все иерархически) и фолксономия (теги не имеют иерархии). Я ответил на это в WikiAnswers, ссылаясь на статью Клей Ширки "Онтология переоценена", в которой утверждается, что вы не должны устанавливать иерархию.
На самом деле я бы сказал, что это не столько иерархическая система, сколько семантическая сеть с чувственными расхождениями между значениями тегов. Что я имею в виду: математика ближе к экспериментальной физике, чем к садоводству.
Возможность построить такую сеть: собрать пары тегов и позволить людям судить о воспринимаемом расстоянии (используя меру вроде 1-10, что означает что-то вроде [синонимы, аналогичные,..., антонимы],...) и при поиске найдите все теги на определенном расстоянии.
Должна ли мера быть равным расстоянием, если она исходит из противоположного направления ([a, b] close → [b, a,] close)? Или близость подразумевает [a, b] close и [b, c] close → [a, b] close?
Может быть, первое слово по умолчанию вызовет другое семантическое поле? Если вы начинаете с "социального работника", "аналитик" близок. Если вы начинаете с "программиста", "аналитик" тоже близок. Но, начиная с любого из этих пунктов, вы, вероятно, не считаете другого близким ( "sozial worker" никоим образом не близок к "программисту" ).
Таким образом, вы должны были бы оценивать и оценивать только пары в обоих направлениях (в случайном порядке).
[TagRelations]
tagId integer
closeTagId integer
proximity integer
Пример для выбора похожих тегов:
select closeTagId from TagRelations where tagId = :tagID and proximity < 3
Механизм, который я реализовал, заключался в том, чтобы не использовать теги, которые были предоставлены самим себе, а непрямую таблицу поиска (а не строго сущность СУБД), которая связывает тег со многими подразумеваемыми тегами (очевидно, тег связан с самим собой, чтобы это работало).
В проекте python таблица поиска представляет собой словарь с ключевыми словами на тегах, с наборами значений тегов (где теги - простые строки).
В проекте базы данных (безразлично, в каком RDBMS-движке это было) были следующие таблицы:
[Tags]
tagID integer primary key
tagName text
[TagRelations]
tagID integer # first part of two-field key
tagID_parent integer # second part of key
trlValue float
где trlValue было значением в пространстве (0, 1), используемым для придания силы тяжести для каждого связанного тега, отношение тегов self-to-self всегда содержит 1.0 в trlValue, тогда как остальные алгоритмически вычисляются (это не важно, как именно). Подумайте, какую базу данных для шуток я дал, а запись ['blonde', 'derisive', 0.5] будет коррелировать с ['pondian', 'derisive', 0.5] и, следовательно, предложить все насмешливые шутки учитывая другое.