Проблемы, подстерегающие любого создателя рубрикаторов

Введение


Работая в издательстве журнала, я много раз становился свидетелем попыток создания хорошего рубрикатора. Большинство попыток сводились или к делению одной большой рубрики на несколько мелких, или, наоборот, к объединению нескольких мелких рубрик в одну крупную. Все попытки создать идеальный рубрикатор превращались в нахождение компромисса между сложным и очень сложным рубрикатором.
Так же хотелось бы отметить, что все виденные мной рубрикаторы были организованны в виде классического дерева с глубиной вложенности 2-3 уровня. И не было замечено попыток организовать рубрикатор иным образом (Речь идет только о печатных рубрикаторах).
В итоге у меня накопился список вопросов, которые приходится решать любому составителю рубрикатора.

Сколько нужно рубрик?


Дробление большого раздела на несколько маленьких всегда кажется очень простым и логичным способом создания рубрикатора.

image

Однако, дробление — это всегда компромисс. С одной стороны — простой и понятный раздел, в котором очень много информации, с другой, много маленьких разделов. Разница лишь в том, где именно заблудится человек — в элементах одного огромного раздела, или в огромном числе мелких разделов (Например, на сайте www.ashmanov.com/tech/semantic продвигается универсальный рубрикатор на 2500 рубрик!).

Неравномерная вложенность


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

image

На примере видно, что на одном уровне рубрикатора существуют как разделы, которые могут быть конечными «10. Камины. Печи» так и разделы, которые обязательно потребуют дальнейшего уточнения.

Прочее


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

Как назвать обобщающую «рубрику-развилку»?


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

Использование узкоспециальных терминов

Иногда попытки найти это самое общее наименование приводят к использованию узкоспециальных терминов. Попытайтесь угадать, где на предыдущем рисунке находится раздел сантехника? Не нашли? А его там и нет. Зато есть обобщенный раздел: «Оборудование для инженерных систем». Конечно же, специалисты догадаются что, наверное, это примерно и есть сантехника, но все ли, кто будут читать названия создаваемого рубрикатора, являются специалистами?

Как правильно описать двойственный смысл некоторых разделов?


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

Еще один пример:

image

Вроде бы все нормально, но почему ремонт и сервис легковых автомобилей находится в разделе автосервис и услуги, а не в разделе легковые автомобили?

Все просто. Если создать в разделе «легковые автомобили» раздел сервис, то точно такой же раздел придется создать и для грузовых автомобилей. А почему бы и нет? А вот почему: раздел «легковые автомобили» не является конечным разделом. А это значит, что все перечисленные подразделы придется создавать и для каждого из подразделов. А это приведет к тому, что разделов станет очень много. А для обычного печатного издания это неприемлемо не только по причине большого объема печатного рубрикатора, но и по причине сложности выбора раздела для публикации.

Представьте, что вы хотите сдать в прокат отечественный автомобиль для использования его в качестве такси. И вот у вас перед глазами разделы «отечественный», «аренда» (причем неизвестно чего), «прокат», и «услуги такси». Глаза разбегаются, ну не подавать же объявление во все разделы. В итоге вы разворачиваетесь и уходите подавать объявление в другой журнал, где разделов всего два — «куплю» и «продам»…

Двойственность по принципу применимости. «Клей паркетный или паркетный клей?»


Кроме неопределенности со стороны «товаров-услуг» также существует неопределенность со стороны самих товаров и их назначения. Например: клей паркетный – это однозначно раздел «клей» и точно также однозначно раздел «паркет». Но однозначно – это один раздел, а не два! Вот и получается неразрешимое противоречие.

Делать ли подсказки к рубрике в виде списка ключевых слов?



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

image

Хороший вариант. Обратите внимание, у раздела №1 ключевых слов нет. Подразумевается, что раздел описывают включенные в него рубрики. Посмотрите на название и ключевые слова к рубрике 1.2. Тут тоже явно видны сложности с выбором названия и формулированием ключевых слов, описывающих рубрику.

А почему нельзя добавить описание к основным разделам? А кто сказал, что нельзя? Конечно можно. Но если учитывать, что раздел – это сумма всех подразделов то это описание будет просто огромным.
Различать ли конечные и узловые разделы?

Еще одна иллюстрация из того же рубрикатора:

image

Если мы говорим, что некий документ имеет отношение к определенной конечной рубрике, то мы вкладываем в это утверждение вполне определенный смысл. Но когда мы относим документ не к конечной, а к узловой рубрике, то логический смысл такого отнесения несколько размывается. В данном случае мы можем, как подразумевать, что документ имеет некий очень обобщенный смысл и не подлежит дальнейшей детализации, так и то, что документ может быть отнесен ко всем (или почти ко всем) подразделам.

Таким образом, можно сформулировать несколько правил отнесения к рубрике верхнего уровня:
1. Документ относится к узловой рубрике в случае, если он не может быть четко отнесен ни к одной из подрубрик.
2. Документ относится к узловой рубрике, если он может быть отнесен ко всем или к большинству дочерних рубрик.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 18
  • +7
    Вся трудность в том, что у каждого свое представление о том как должен быть категоризирован ассортимент. Я например схожу тихо с ума, когда приходится с подругой зайти в женский магазин. Там как я понимаю логика «Что к чему идёт», а мужчины привыкли к четким отделам: тут рубашки, тут штаны, тут обувь. Но женщинам понятно, значит все не зря.

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

    Другой вариант, где в прямом эфире, через аякс отфильтровываются результаты. Например изначально в магазине 100 000 наименований, после нажатия «Баня» их становится 3000, после «Отделка» — 200, после «Вагонка» — 30, что уже удобоваримо.

    Ну и поиск конечно должен быть хороший.
    • +6
      Отличный пример про расперделение в магазине по теме: «что к чему идёт» vs «рубашки, штаны»
    • 0
      Почему объявление должно быть только в одном разделе?
      • +1
        Объявление только в одном разделе — потому, что изначально речь идет о печатных рубрикаторах. Про особенности трансформации печатных рубрикаторов в интернет-рубрикаторы будет следующая статья.
        • 0
          В печатном издании можно точно так же повторять один и тот же товар в разных разделах, если это необходимо. Если конечно не экономить на бумаге и удобстве пользователей.
      • 0
        Я так и не нашел почему данный топик в блоге Data Mining… нет никакого намека на автоматизированную семантическую систему извлечения знаний/данных из существующей базы.
        • +2
          Одна из проблем тут состоит имхо в том как именно будет просматриваться рубрикатор, если он может быть любым в глубину. Просто если мы ходим по уровню за раз, то нам без разницы что категории второго уровня дублируются, главное что это удобно. А вот если нам где то надо вывести все дерево, то надо будет вычленять основные узлы, и от них плясать.
          Рубрикатор описанный в статье это фолксономия. А описанная в комментариях система все большей фильтрации выборки используя теги это ближе к таксономии. Причем походу без какой то иерархии.

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

          Вот еще парочка статей на тему тегов и категорий.

          Тэги 2.0: сontribute or not! · Spectator.ru

          Фолксономия и/или таксономия

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

          • 0
            >> Все попытки создать идеальный рубрикатор превращались в нахождение компромисса между сложным и очень сложным рубрикатором.

            Согласен. У нас на сайте уже 84000 рубрик с максимальной глубиной 5 уровней =)
            • 0
              Кстати, как храните дерево в базе? Adjacency List, Nested Sets?
            • 0
              А что за сайт?
              • 0
                Нуу, ссылка у меня в хабрацентре
                • 0
                  Честно говоря, не вижу там ссылки.
                  • 0
                    странно, а я вижу =)
                    Сайт: www.pulscen.ru
                    • 0
                      Может быть, дело в настройках приватности? Ладно, не будем больше оффтопить :) За ссылку спасибо.
            • +2
              Как по мне то лучше всего тегирование, и на базе этих тегов создавать рубрикаторы и каталоги по релевантности.
              • 0
                Полностью согласен. Тэги — это очень удобно в обработке. Единственная проблемма в том, что люди любят древовидные каталоги и рубрикаторы а переход от тэгов к дереву не всегда однозначен.
              • 0
                При построении рубрикаторов очень сильно помогает карточная сортировка () — всегда полезно забраться в головы пользователям и использовать их ожидания для данной задачи. Если категорий слишком много для такого исследования, то весь объем карточек можно разделить на части или же сортировать только категории верхнего уровня.

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

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

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