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

Так вот, этот принцип можно использовать для сквозного учета backlink history. В каждый пост вносится thread id, либо новый, либо «предшественника». После чего мы можем отслеживать развитие темы.
contra: ключевые слова позоляют делать только общую выборку постов по тематике, проследить динамику по ним трудно.

Какие проблемы?
1. Не совсем понятно, что делать, если две нити требуется разъединить или объединить.
2. Управление thread list при большом количестве thread.

[-1]

Полезность keywords в Регистре сильно преувеличена. Иначе говоря, польза от них есть, но значительно меньше, чем хотелось бы.
Будем думать дальше.

Не знаю, как кому, а для меня тема ailev: Гиперкниготексты достаточно актуальна (хотя из прочитанного половину не понял — а чего еще ожидать от хамелеонки?).
Регистр как движок не обеспечивает связанность записей — каждая запись изолирована. Поэтому:
- невозможно проследить иерархию и генезис записей
- невозможно найти запись, если не помнишь keyword или точные слова в этой записи

Будем думать.

А я все о том же…
Не знаю, как кому, а мне нужен хороший и удобный классификатор, чтобы ориентироваться в своих записях. Нужен ли он остальным (и будут ли им пользоваться) — вопрос десятый.
Поскольку ключевые слова (keywords) никакой пользы (как средство классификации) лично мне не приносят, то отправляются в долгий ящик. Фасетная [?] классификация (ФК), теоретически, должна помочь… но внедрение ФК — это жопа. Мало того, объем и разброс тематики записей не способствует ФК.
Но рациональное зерно в ней есть. Мы можем воспользоваться комплексной системой классификации, используя различные методы агрегирования. Поиск — уточнением или дополнением.
Вот от этого и будем дальше танцевать.
[-2] [-1]

Если мы посмотрим на существующую контент-модель Регистра, то увидим, что она достаточно простая. Простая и прямая, как доска ;) Визуально примерно так:

Некая дорожка из плит, и натыканные разноцветные флажки (мне лень было раскрашивать, вы уж сами).
Но такая простая к-модель неэффективна (по крайней мере, для меня). Надо будет переходить на более сложную схему… но об этом позже.

Вот примерно такая контент-модель хочется:

[-1]

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

Хотя некоторые считают ключевые слова чуть ли не панацеей, я в этого джинна не верю.
Да, ключевые слова позволяют разложить одну большую кучу записей на несколько мелких кучек — согласно тематике. Но от этого куча так и остается неупорядоченной.
Упорядочить записи можно. Если предварительно сгенерировать список ключевых слов по принципу УДК (не копировать!). И при этом много ключевых слов останутся незадействованными.
Поэтому обычно ключевые клова вводятся по мере надобности. А с предыдущими записями, которые подходят под это ключевое слово — что делать? Ворошить и перебивать КС в N записей? Так лень же!
Фасетная классификация? ФК начинает хорошо работать на большом объеме равномерно раскиданных данных. 10 000, например. А когда записей пара сотен, издержки на ФК превышают эффективность использования.
Сотовая классификация, тоже в жопе, поскольку у меня нет плотной упаковки записей.
Что же делать? Есть два пути, облегчающих жизнь:
а) использовать ортогональную систему классификаторов (иерархическая/многоуровненвая рубрикация, threads, маркеры важности), позволяющие искать по стыкам (точкам пересечения, converge)
б) использовать параллельную систему — аннотации по контексту (constrict, предельно сжатое содержания записи). Минус: не умею я грамотно сжимать контекст и поддерживать релевантность аннотаций во времени.

Раздумывая о вечном классификации контента всегда натыкаешься на две трудности:
1) Сама по себе КК на пустом месте не возникает — ее нужно прописывать руками в каждую запись. Каждый раз, как только мы вводим/изменяем систему КК. Выходом была бы динамическая КК, но до этого жить и жить
2) КК необходимо составлять до, а не после появления записей. Соотвественно, требуется предугадывать содержание будущих записей и их место в КК (мелкая корректировка под сиюминутные нужды на это не влияет).
Если бы не две этих жопы, жить было бы легче и веселей.

Идея анализа внешних поисковых запросов, хотя и заманчива, но с практической стороны — близка к бесполезной, поскольку:
- непонятно, что именно ищет посетитель
- посетитель может искать вполне конкретную запись, и не согласен на принудительную замену
- непонятно, какую из N записей context chain считать более релевантной перехваченному запросу.

Как вариант, после анализа внешних поисковых запросов можно выводить не конкретную запись, а context chain. Но польза от этого сомнительна, а усилий требует.

И что делать? А ничего. Тем, кто заходит в блог и пытается откомментировать запись годичной давности, уже ничего не поможет. Кроме белых тапок и горизонтального положения…
А для остальных будем строить context chain. Вот urbansheep предлагает строить цепочки вручную и по номерам. Ну а я записываю в todo «поддержка перекрестных threads» (т.е. когда запись входит в несколько нитей)