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

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

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

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


tags tagging hierarchical-clustering
person tzot    schedule 23.09.2008    source источник

Ответы (3)


arrow_upward
7
arrow_downward

Это сложный вопрос. Две крайности — это онтология (все иерархично) и фолксономия (теги не имеют иерархии). У меня есть ответ на WikiAnswers со ссылкой на Clay Shirky вы не должны устанавливать иерархию.

person Yuval F    schedule 23.09.2008
comment
Статья Клэя Ширки была очень интересной. Очевидно, фактор близости (в примере с базой данных) был введен для смягчения связанных терминов (в статье пример «гей» и «квир»). - person tzot; 23.09.2008
comment
По какой-то причине я не смог найти ссылку на статью Клэя Ширки на странице WikiAnswers. Вот он: shirky.com/writings/ontology_overrated.html. Мне это тоже понравилось. - person Peter V. Mørch; 04.01.2013

arrow_upward
4
arrow_downward

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

Возможность построить такую ​​сеть: создайте пары тегов и позвольте людям оценить воспринимаемое расстояние (используя меру вроде 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
person Ralph M. Rickenbach    schedule 23.09.2008
comment
Близость односторонняя; если он должен быть двусторонним, то будет вставлена ​​другая запись с другой близостью. - person tzot; 23.09.2008
comment
@malach: В качестве проблемы UX, касающейся использования иерархии, я бы сказал, что (i) программное обеспечение должно использовать подход семантической сети, который вы описали на основе математики, но (ii) пользователи, которые хотят заниматься садоводством в своих личных коллекциях тегов. должно быть разрешено, но не принудительно упорядочивать теги в иерархии, поскольку некоторым пользователям это покажется более удобным, чем простой список. В программных системах, где персонализация тегов невозможна, можно использовать плоский список, если только эксперты в предметной области не примут иное решение. - person rwong; 10.05.2011

arrow_upward
2
arrow_downward

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

В проекте 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], используемым для определения гравитации для каждого связанного тега; отношение тега «самостоятельность» всегда содержит 1,0 в trlValue, в то время как остальные вычисляются алгоритмически (это не важно, как именно). Подумайте о примере базы данных шуток, которую я дал; запись ['блондинка', 'насмешка', 0,5] будет коррелировать с записью ['пондийская', 'насмешка', 0,5] и, следовательно, предложит все насмешливые шутки, учитывая другую.

person tzot    schedule 23.09.2008