Pull to refresh

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

Data Mining *
Sandbox

Введение


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

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


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

image

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

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


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

image

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

Прочее


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

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


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

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

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

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


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

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

image

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

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

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

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


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

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



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

image

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

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

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

image

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

Таким образом, можно сформулировать несколько правил отнесения к рубрике верхнего уровня:
1. Документ относится к узловой рубрике в случае, если он не может быть четко отнесен ни к одной из подрубрик.
2. Документ относится к узловой рубрике, если он может быть отнесен ко всем или к большинству дочерних рубрик.
Tags: Рубрикаторрубрицирование
Hubs: Data Mining
Total votes 25: ↑23 and ↓2 +21
Comments 18
Comments Comments 18