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

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

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

[-1]

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

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

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

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

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

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

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

[-1]

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

[-1]
…но виртуальность ложки не вызывает сомнений. Ибо иная реальность виртуальна самой себе до такой степени, что ее можно пощупать руками — реальность все же остается реальностью, сколько бы непрерывной и мнимой она не была. Реальность снов — тем более.

«Хотите поговорить об этом? — А как же!»

Но ложка — вещь сугубо нелинейная и не такая простая, как может thinked. Я бы сказал, что ложка — это фрейдовский символ Матрицы… но виртуальный символ «отсутствующего ничего» не хочет вписываться в наше куриное восприятие true reality, хотя и формирует вокруг себя пространство Мебиуса. И когда нам, восторженным идиотам, кажется, что ложка гнется — на самом деле ложка просто делает трансферт в себя.
Ну да — сложно ожидать чего-то более иллюзорного, чем пространство Мебиуса, реализованное в образе ложки — когда комплексная матрица ложки демонстрирует финт с перетеканием реальной части ложки в мнимую. И обратно.

 — Нео, что случилось?
 — Матрица упала. И придавила агента Смита…

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

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