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

Question

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

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

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

Answer 1

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

Answer 2

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

Возможность создать такую ​​сеть: создать пары тегов и позволить людям оценивать воспринимаемое расстояние (используя меру, например, 1-10, что-то вроде [синонимы, похожи, ..., антонимы], ...) при поиске ищите все теги на определенном расстоянии.

Должна ли мера быть равной дистанции, если она идет в противоположном направлении ([a, b] close -> [b, a,] close)? Или близость подразумевает [a, b] закрытие и [b, c] закрытие -> [a, b] закрытие?

Может быть, первое слово по умолчанию вызовет другое семантическое поле? Если вы начинаете с «социального работника», «аналитик» находится рядом. Если вы начинаете с «программист», «аналитик» также рядом. Но, начиная с любой из этих точек, вы, вероятно, не посчитаете другую как близкую («социальный работник» никоим образом не близок к «программисту»).

Таким образом, вы будете оценивать и оценивать только пары в обоих направлениях (в случайном порядке).

[TagRelations]
tagId integer
closeTagId integer
proximity integer

Пример выбора похожих тегов:

select closeTagId from TagRelations where tagId = :tagID and proximity < 3

Answer 3

Механизм, который я реализовал, заключался в том, чтобы использовать не сами данные теги, а косвенную таблицу поиска (не строго термины СУБД), которая связывает тег со многими подразумеваемыми тегами (очевидно, тег связан с самим собой, чтобы это работало) .

В проекте Python таблица поиска представляет собой словарь, снабженный ключами для тегов, со значениями наборов тегов (где теги - это простые строки).

В проекте базы данных (безразлично, какой это был механизм СУБД) были следующие таблицы:

[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, тогда как остальные рассчитываются алгоритмически (не важно, как именно.) Подумайте, на примере базы данных приколов, которую я привел; запись ['blond', 'derisive', 0.5] будет соответствовать ['pondian', 'derisive', 0.5] и поэтому будет предлагать все насмешливые шутки дано другому.