Могут ли теги победить рубрики? Иерархии тегов

    Какую роль играют разделы, категории, хабы, и прочая фасетная классификация и т.п. в нашей интернет жизни. Так ли все очевидно с ними?
    Все эти понятия пришли к нам из бумажного прошлого, тогда жесткая систематизация была единственным способом навигации в книгах и документах. По началу в интернет средах рубрикация была чуть ли не единственным способом навигации. Каталоги цвели и множились, Yahoo яркий пример превращения каталога в мега успешный проект с капитализацией в 32 млрд $.

    теги побеждают рубрики. босх

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

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

    Почему Теги не стали великим откровением и могильщиком рубрик?


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

    2. Аналогично, контент расположенный в рубрике, скорее всего находится там по праву, а вот теги которыми он снабжен, это просто субъективное мнение того кто ставил метки.

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

    4. В интернет магазинах и других системах, где классификация рулит — рубрикация это основа навигации.

    Итого, за исключением пункта с магазинами, все остальные преимущества рубрикации сводятся к предсказуемости качества находимого по рубрике контента.

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

    С другой стороны интуитивно ясно, что теги это тоже рубрикация, но просто в более общем и демократичном виде.Собственно из-за этой демократичности теги и проигрывают рубрикации. Излишняя свобода приводит к неопределенности.

    Например, если мы используем тег как навигатор, но навигатор в контексте какого то сообщения, то это одно:
    Я читаю очередную новость про мобильник и вижу там тег «покрытие». При переходе по этому тегу, на самом деле я должен переходить по связке «мобильная связь» + «покрытие».
    Если же текст был про разведение особоудойных коров, то тег «покрытие» имел бы другой смысл «коровы»+ «покрытие».
    Если я встретился с тегом без контекста, например, просто увидел их в облаке тегов сайта, то как отличить «покрытие А» от «покрытия Б»?

    трахать или звонить

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

    Что делать?


    С точки зрения развития технологий тегирования это означает вот что:

    Использование тегов для поиска

    1. В сомнительных случаях лучше использовать не один тег, а совокупность тегов для получения выборки сообщений.
    2. Эта совокупность может быть составлена из Основного тега (того который заказан в качестве критерия выбора постов) и дополнительных, то есть, тех ярлыков в которых пользователь «часто пасется».
    3. Дополнительные теги, естественно, должны часто встречаться с Основным, то есть быть «связанными» — сильно коррелирующими.

    Установка тегов

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

    Иерархии

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

    Иерархии тегов таят огромный потенциал. Это, иерархии естественные, то есть те которые как тропинки протаптываются пользователями, а не прокладываются проектировщиками.

    Можно сказать преамбула окончена. Далее следуют вполне конкретные рецепты от нашего математика Сергея Львова. Очень надеюсь, что ему дадут на Хабре голос (popolznev).

    Первые шаги к иерархии тегов


    Автор: Сергей Львов

    1. Чего хотим


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

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

    Поскольку ярлыки отвечают за «тематичность» сообщений, наведение порядка в куче ярлыков означает учреждение некой мерки, которая позволила бы сказать, насколько любые два ярлыка тематически близки друг к другу. Эта мерка может
    быть устроена как метрика (= расстояние) в математическом смысле слова (то есть для любых двух различных ярлыков расстояние между ними должно быть положительным числом, не зависящим от порядка перечисления ярлыков; расстояние от
    ярлыка до самого себя равно нулю). Но нам показалось удобнее сделать мерку наподобие коэффициента корреляции (минимальное значение, для совсем не связанных ярлыков, равно 0, максимальное — 1). К тому же этот коэффициент не обязан быть симметричным: один ярлык ко второму может быть привязан сильнее, чем второй к первому.

    2. Элементы и обозначения


    Через M обозначается множество всех сообщений, хранящихся в нашей болтотеке: M = {m1,..., mN }. Понятно, что множество M со временем меняется, число сообщений растет, но динамика нас не интересует: мы рассматриваем систему в произвольный фиксированный момент. S — это множество всех тегов-ярлыков, имеющихся на данный момент в системе: S = {s1,..., sNN }. Между множествами M и S определено соответствие (отношение), которое по аналогии с геометрией (многие читатели скажут: с теорией графов! — но придумали-то это геометры) можно назвать инцидентностью: сообщение m и ярлык s инцидентны, если сообщение m помечено ярлыком s.

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

    Если s1,..., sr — ярлыки, которыми помечено сообщение m (можно определить теговое множество сообщения m: S(m) = {s1,..., sr}), то определены величины e[s1](m),..., e[sr](m), которые называются (теговыми) значимостями сообщения m. Как именно они вычисляются, сейчас для нас не очень важно, но вычисляться
    они должны так, что чем значимее сообщение, тем выше его значимость. Грубо-приблизительно говоря, значимость сообщения — это количество «плюсиков», выставленных сообщению читателями. Особенность нашей системы: плюсик ставится не просто сообщению, а прикрепляется к ярлыку (ярлыкам).

    Учитываются генетические связи между самими сообщениями: у каждого сообщения могут быть «потомки» и «предки» («предшественники»). Если сообщение m2 написано в ответ на сообщение m1, то сообщение m1 будем называть непосредственным предком или предшественником для m2, а m2 — непосредственным потомком. Если сообщение m2 написано в ответ на сообщение, являющееся непосредственным потомком сообщения m1, то m2 будем называть прямым потомком (или просто потомком) сообщения m1. Если сообщение m2 написано в ответ на сообщение, являющееся потомком сообщения m1, то m2 будем также называть (прямым) потомком сообщения m1. Аналогично определяются прямые предки (предшественники).

    3. Подход № 0: статистика появлений


    Система, которую мы строим, ничего не понимает. Для нее ярлык — это просто набор символов (проблему омонимии вынесем за скобки — будем считать, что каким-то образом она решена). Поэтому оценить тематическую близость ярлыков система может только основываясь на частоте их совместных появлений: естественно считать, что если пара ярлыков часто встречается вместе, то они тематически близки. Обозначим через µ[s] количество сообщений, помеченных тегом s, через µ[u] количество сообщений, помеченных тегом u, а через µ[su] количество сообщений, помеченных тегами s и u одновременно.

    Первая попытка определить коэффициент тематической связи ярлыков s и u:

    ρ0(s, u) = µ[su]/(µ[s] + µ[u]µ[su]). (1)

    Величина, которая стоит в знаменателе — это количество сообщений, снабженных хотя бы одним из ярлыков s, u.
    Чем плоха формула (1)? Прежде всего, бегать по всем сообщениям — это может оказаться очень долго. Неплохо бы иметь хорошую выборку сообщений, чтобы уменьшить объем работы. Тем более что возможна вот какая ситуация. Понятно,
    что сообщения-потомки часто будут наследовать ярлыки своих родителей. И если в системе заведется длинная ветка диалога (на форумах или в том же жж такое случается сплошь и рядом), не интересная уже никому, кроме ее участников, то она может перекосить статистику.

    Выход возможен такой. Назовем сообщение узловым, если оно имеет более одного непосредственного потомка. Далее, пусть µj[s], µj[u], µj[su] — количества узловых сообщений, помеченных, соответственно, ярлыком s, ярлыком u, ярлыками s и u одновременно. Теперь поправим формулу (1), учитывая не все вообще сообщения, а
    только узловые:

    ρ0j(s, u) = µj[su] / (µj[s] + µj[u]µj[su]). (2)

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

    Введем коэффициент зависимости ярлыка s от ярлыка u:

    ρ1j(s, u) = µj[su]/µj[s]. (3)

    Смысл этой формулы простой: чем чаще ярлык s встречается отдельно от ярлыка u, тем меньше зависимость ярлыка s от ярлыка u.

    Заметим, что все три формулы дают единицу, если подставить один и тот же ярлык на место двух аргументов: то есть ρ0(s, s) = ρ0j(s, s) = ρ1j(s, s) = 1. Это естественное условие нормировки.

    Пойдем дальше. Во всех формулах, которые мы пока предъявили, ключевым элементом служит частота одновременных появлений двух ярлыков. Однако иногда смысловая близость двух ярлыков может быть причиной как раз их одновременного
    непоявления. Например: то, что один человек назовет помидорами, другой поименует томатами — но у одного юзера будет все время встречаться только ярлык «томаты», а у другого — только «помидоры». Если исключить априорное приписывание «томатам» и «помидорам» статуса синонимов (такие приемы мы пока исключаем из рассмотрения), то можно надеяться уловить близость ярлыков, которые часто одновременно появляются вместе с каким-либо третьим ярлыком. Например, если ярлык «гомология» часто ходит вместе с ярлыком «топология», и ярлык «гомотопия» часто ходит вместе с ярлыком «топология», то, даже ничего не зная о гомологиях и гомотопиях, можно предположить, что эти вещи имеют что-то общее, тематически близки. Формульно это можно выразить так (мы по-прежнему учитываем только узловые сообщения):

    ρ2j(s, u) = max(v∈S)((µj[sv]j[s])(µj[uv]j[u])). (4)

    Здесь мы опять, однако, вернулись к симметрии: по построению, ρ2j(s, u) = ρ2j(u, s). Смысл этой симметрии в том, что мы теперь ищем третий ярлык, к которому были бы близки два сравниваемых ярлыка. Заметим, что всегда ρ2j(s, u) ≥ ρ1j(u, s) (потому что при u = v и при s = v один из сомножителей в скобке правой части формулы (4) равен 1, а в торой совпадает с ρ1j(u, s), то есть значение ρ1j(u, s) заведомо достигается, а максимум может оказаться и побольше).

    Можно попробовать еще обогатить формулу:

    ρ3j(s, u) = max(max(v∈S)((µj[sv]j[s])(µj[uv]j[u])), max(v∈S)((µj[sv]j[s])(µj[uv]j[v]))). (5)

    4. Возможность других подходов


    Все формулы, приведенные в предыдущем пункте, реализуют попытки угадать тематическую близость на основе статистики. Что еще можно сделать? Можно попробовать задействовать оснащение нашей избы-обсуждальни: вспомним, что ее главную
    изюминку представляет собой система значимостей. Любую из формул (1)–(5) можно модифицировать следующим способом. Числа µ с разными индексами — это количества сообщений, удовлетворяющих тем или иным условиям (каким именно условиям — за это как раз отвечают индексы, приписанные к µ). Количество сообщений — это сумма единичек: за каждое сообщение, удовлетворяющее нужным условиям, в величину µ добавляется не 1. Если добавлять не 1, а величину, зависящую от значимостей сообщения (поскольку во всех наших формулах участвуют как минимум два ярлыка, и значимостей можно задействовать как минимум две), то мы получим более тонкие формулы. Но будет ли эта тонкость к добру — вопрос сложный. Мы не будем сейчас обсуждать это подробно — отложим на потом.

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

    Комментарии 44

      +3
        0
        Вообще то я об этом
          +1
          этот тег надо было добавить в свою статью :)
            0
            оба надо б
              +1
              fixed
          +10
          Автор подымает один из самых больных вопросов: на сайтах можно найти поиском только по одному тэгу, а так, чтобы найти одновременно хотя бы два тэга (не говоря, чтобы показать по тэгу за минусом какого-то третьего) — уже никак. В результате либо ты лопатишь гору лишней информации, просматривая один тэг, либо сразу уходишь в поисковик.
            +3
            У меня есть алгоритм вывода статей по тегам именно так — задаются три тега, и вначале выводятся все статьи со всеми тремя совпадающими, потом выводятся все статьи с совпавшими любыми двумя тегами, и потом уже выводятся все статьи, в которых один из представленных тегов. Причём делает это за один SQL-запрос.
            Вариант для поиска номеров статей:
            SELECT id, count(*) as weight FROM tag_links 
            WHERE tag IN (1,2,3) GROUP BY id ORDER BY weight DESC

            Вариант для вывода списка статей:
            SELECT articles.id, articles.title FROM tag_links, articles 
            WHERE tag_links.id=articles.id AND tag_links.tag IN (1,2,3) 
            GROUP BY tag_links.id ORDER BY count(*) DESC

            Если интересно, могу написать статью про то, как шёл к этому решению. Ничего выдающегося, в общем-то, но боюсь, здесь в комменте это затеряется…
              0
              tag_links.tag — идентификатор тэга? Кто такие 1, 2 и 3?
                0
                Всего три таблицы — articles, tags и tag_links, реализующая связь многие-ко-многим первых двух таблиц.
                Таблица articles: id, title, body
                Таблица tags: id, name
                Таблица tag_links: id, tag
                  0
                  Вы это сейчас на какой вопрос отвечали?

                  Я правильно догадываюсь, что на первый вопрос — ответ «да»?
                    0
                    м-м-м… да, простите. Верно, tag_links.tag — идентификатор тега, tag_links.id — это идентификатор статьи.
                    1, 2, 3 — айдишники искомых тегов. Их может быть и больше трёх.
                      0
                      Громковато это называть «алгоритм», ИМХО… действительно, ничего выдающегося.
                        0
                        согласен. Зато работает. А в своё время я не нашёл ничего готового, кроме посылания запросов в цикле и последующей обработки и сортировки.
                0
                Нельзя исключить какой-то тег.
                Сложного в реализации поиска по нескольким тегам ничего нет, поэтому и непонятно почему нигде такого нет. А потом и появляются «никто не читает теги».
                  0
                  что значит Нельзя исключить какой-то тег? Уберите из запроса ненужный тег и найдите заново.
                    0
                    Нет, мне нужно «всё вот это», но чтоб «вот этого» ни в каком виде не было.
                      0
                      а, я понял. Верно, эти запросы такую выборку сделать не позволят. Нужно подумать, как это сделать. На крайний случай — отдельным вторым запросом.
                      0
                      глупость написал
                        0
                        так не получится — SELECT вначале отбирает записи, и только потом группирует и сортирует их. А так как в записи только одно поле tag, то NOT IN точно не сработает, потому что после первого условия там записи с полем tag из первого списка.
                          0
                          Я осознал это и удалил комментарий, когда вашего ответа еще не было, извините)
                            0
                            да ладно. Пусть будет мой ответ для других.
                            К тому же, у вас не глупость. Я вот тоже хочу так писать — WHERE tag IN (:includedTags) AND tag NOT IN (:excludedTags). Возможно, получится разработать такую структуру таблицы tag_links, чтобы такой запрос сработал (что вряд ли), или составить запрос по другому, например, через самопересечение этой таблицы.
                            0
                            Самым простым способом будет считать исключаемые теги отдельно (включив их в IN) и если их больше 0 — отбрасывать эти результаты.
                            0
                            SELECT id FROM tag_links WHERE tag IN (1,2,3) 
                            AND id NOT IN (SELECT id FROM tag_links WHERE tag IN (4,5,6))
                            GROUP BY id ORDER BY count(*) DESC
                            
                        0
                        Написал статью про реализацию тегов в SonataAdminBundle, вставил эти запросы в конец статьи. Не стал отдельной статьёй постить.
                          0
                          Ссылку сделать забыли на упомянутую статью. habrahabr.ru/post/233695/
                            0
                            упс… точно! Спасибо за ссылку
                      0
                      Размышления на тему привели к такому решению:
                      1. Когда пользователь добавляет тег к статье, сохранять не только сам тег, но и раздел, в который публиковалась данная статья.
                      2. Если пользователь, читающий определенную статью, кликнет по такому тегу, мы сможем выдать ему только те материалы, которые содержат данный тег + имеет привязку к этому тому же разделу, что и та статья, в которой он по нему кликнул.

                      На счет умного поиска. Очень красивое решение, но пользователь может интересоваться сегодня шоколадками, а завтра колонизацией Марса.
                        0
                        Раздел — это тоже теги, по хорошему.
                        Теги тегам теги!
                        +1
                        Картинки шикарны!
                          +1
                          Тоже как-то раз много думал в сторону тегов и их невообразимой мощности: nashev.livejournal.com/64025.html
                            0
                            А что в итоге с тем стартапом которому Вы свои тексты посвятили? Там bad request какой то.
                              0
                              Переименовались в mem2.com, поразвивались и исчезли…
                            0
                            Вот тут теги шикарны и самодостаточны (осторожно — матюки):
                            ru-chp.livejournal.com/tag/
                              +3
                              Я обычно ставлю много тегов, с тем, чтобы потом можно было просматривать связанные статьи. Добавление 2-3 тегов не даёт практически ничего, нужно ставить десяток тегов.
                              Но это плохо работает, если нет механизма поиска по нескольким тегам. Даже больше, если этого механизма нет, то теги сильно уступают рубрикам. В принципе, в статье об этом и написано…
                                0
                                Выше вы описывали внутренности своего механизма поиска, как и что устроено «под капотом». А можно где-то посмотреть в действии или это не публичный проект?
                                  0
                                  В этом комментарии я больше говорил про личные записи. В частности, в Evernote в заметках я указываю 2-3 тега-рубрики (работа, проект, 2014) и пяток тегов, относящихся конкретно к этой заметке. После этого очень удобно их искать, и проблема тега «покрытие» из статьи исчезает, достаточно указать фильтры проект+игры или развлечение+игры, и найдутся разные заметки.
                                  А сайт, на котором я использовал систему тегов, я вам в личку отправил.
                                  0
                                  Мы о том и пишем, что если побольше тегов, не только у сообщения, а вообще в системе, то можно проанализировать частотные связи между ними, и вообще говоря, взять на себя смелость экстраполировать запрос по «одному тегу», в запрос по «группе тегов особенно связанных с этим». Чем умнее мы метрику расстояния между тегами рассчитаем, тем более правильно будет работать система.
                                  И не нужны будут «вычитания» тегов, или поиск по 2-3. Математика разрулит.
                                    0
                                    Всё равно нужны будут.
                                    Математика может лишь помочь автоматически предлагать более умный выбор, что б такого ищущему предложить дописать в запрос, и что б такого пишущему приписать своей статье. Помочь модератору найти теги-синонимы, теги-подкатегории и т.п.
                                  0
                                  Теги, конечно же. читают. Иначе — зачем они тогда нужны? Хотя… искать по ним удобно.
                                    0
                                    По мне так, рубрики — это частный случай тэгов.

                                    Разница только в организации пользовательского итнерфейса и структуры БД, связанная с принимаемыми ограничениями частного случая «рубрики» по сравнению с общим случаем «тэги».
                                      +2
                                      Выскажусь про соотношение тегов и каталогов. С математической точки зрения, теги — это сетевая структура данных, то есть более общий случай категорий, которые лежат в иерархической модели. Поэтому, чтобы теги как минимум не проигрывали, должен быть модерируемый список тегов первого уровня, которые могли бы соответствовать категориям первого уровня, далее идет множество тегов второго уровня, которое соответствует подкатегориям. И в запасе еще остаются простые обычные привычные теги.
                                        +1
                                        Мне кажется, что мы в этой статье предложили как все эти «уровни» отношений тегов вычислять, и тем самым сделать из тегового пространства вместо месива big bang, какие-то ассоциации и системы.

                                        Наверное зря для математической части статьи не нарисовал красивых картинок. Придется повторить.
                                          0
                                          Картинки надо б к формулам, ага.
                                          +3
                                          Думаю немногие сталкиваются с подобными темами и смогут по достоинству оценить всю прелесть это статьи. Но в любом случае, автору огромное спасибо и респект, вы попытались описать то, что ряду проектов хочется получить в виде технического решения, но, как правило, даже сформулировать задачу, которую вы описываете, является весьма сложно.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое