Что же делать с кейвордами?

Будет очень интересно почитать планирующуюся культовую смирновскую книжку «Как перестать классифицировать записи и начать писать», потому, что без книжки этого понять невозможно. Вот пишет, например, Вадим про нити. Ну как не высказать своё мнение на этот счёт? Обязательно надо высказать. Высказываю.

1. Нити и кейворды — это одно и то же;
2. Не нужно плодить лишние сущности без надобности.

Вот есть у тебя цепочка заметок по поводу одной задачи, типа «поставлена задача» — «возможные пути решения» — «решена вот так», ну и что мешает создать кейворд «задача»? Просто сделай кейворд, зачем его называть словом «нить»? Тут есть два варианта: или Вадим не дописал о каких-то потайных функциях нитей, или он просто не понял, что это то же самое, что и кейворды. Разумеется, я склоняюсь к первому. Точнее, даже, надеюсь на первое; а также на то, что он напишет что-нибудь на эту тему.

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

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

По этому поводу у меня уже давно есть, например, мысль ввести синтаксис prevkey и nextkey для вставки ссылок на предыдущую и следующую заметки, содержащие хотя бы один из кейвордов данной. Возможность отображать «новые снизу» реализовать вообще не трудно. Можно даже просто сделать, чтобы по /keywords/path/to/key выдавались новые сверху, а по /threads/path/to/key — снизу.

В конце концов, ничего не мешает сделать в таблице Keywords столбец IsThread, чтобы формально отделить кейворды от нитей. Но я лично в этом не вижу смысла.

Что ещё? А, вот что. Кейворды, в отличие от нитей, не теряют актуальности. То есть, задачу ты поставил и решил, а про идиотов, например, можно писать всегда — тема неисчерпаема. Благодаря Юлии Шабунио в e2 можно сортировать кейворды по дате последнего использования. В этом случае, неактуальные нити постепенно будут сдвигаться вниз.

В e2 Release 1.02 предположительно будет очень крутая штука, которая позволит ориентироваться в бесконечных кейвордах и нитях, а также отличать те кейворды, которые по сути кейворды от тех, которые по сути — нити. Причём, без IsThread.

Теперь немного о том, какая же всё-таки структура кейвордов является самой правильной? Линейная, древовидная или в стиле R2?

Проблема линейной структуры том, что кейворды (сюрприз!) никак не связаны друг с другом. Получается, что «программирование» и «PHP» настолько же самостоятельные темы, насколько «снукер» и «toki pona». Но это не так, программирование и PHP — близкие темы. И это хочется как-то обозначить в структуре, потому, что нужно как-то связать соответствующие заметки друг с другом. Программирование — это более общая тема, чем PHP, Delphi и mySQL. Исходя из этой посылки возникают древовидные кейворды.

Однако, у древовидных кейвордов тоже полно проблем: в половине случаев непонятно, какая тема является общей для двух других. Мой случай, например: я не знаю, «комментатор Саша» должен быть субкейвордом «снукера» или «идиотов»? По идее, и того и другого. В результате этих рассуждений возникают кейворды в стиле R2 (aka «паутинообразные»)

Но и тут не всё гладко. Новая проблема состоит в том, что нам обязательно нужно определиться с тем, какой из двух связываемых кейвордов является более общим. А это не всегда легко/возможно. То, что «fight club» по отношению к «кино» кейворд дочерний — сомнений не вызывает; но вот я, например, не знаю, как бы я связал «Лебедева» и «дизайн». Однако, связать бы их хотел.

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

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

Разумеется, кейворды «PHP 5» и «программирование» связаны сильнее, чем «PHP5» и «web-строительство». Поэтому, по кейворду «PHP 5» хотелось бы видеть:

Cм. также: PHP, программирование, web-строительство

То есть, именно в таком порядке, а не, скажем, по алфавиту. Для этого можно ввести необязательный параметр «сила связи» и дать возможность задавать его при связывании.

Вот такие мысли.