Иерархии тегов и обработка

Это реальная проблема, которая применяется к элементам тегов вообще (и да, это относится и к StackOverflow, и нет, это не вопрос о StackOverflow).

Вся проблема с тегами помогает группировать подобные элементы, какие бы они ни были (шутки, сообщения в блогах, вопросы и т.д.). Однако там (обычно, но не строго) есть иерархия тегов, что означает, что некоторые теги также подразумевают другие теги. Чтобы использовать знакомый пример, тег "С#" также означает ".net"; другой пример, в базе данных шуток, тег "блондинки" подразумевает "насмешливый" тег, аналогично "ирландский" или "безымянный" или "канадский" и т.д. в зависимости от происхождения страны-шутки.

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

Ответ 1

Это сложный вопрос. Две крайности - это онтология (все иерархически) и фолксономия (теги не имеют иерархии). Я ответил на это в WikiAnswers, ссылаясь на статью Клей Ширки "Онтология переоценена", в которой утверждается, что вы не должны устанавливать иерархию.

Ответ 2

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

Возможность построить такую сеть: собрать пары тегов и позволить людям судить о воспринимаемом расстоянии (используя меру вроде 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

Ответ 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] и, следовательно, предложить все насмешливые шутки учитывая другое.