«То, что мы видим сейчас — это электронный документобардак, а не документооборот»

Почему меня несколько не устраивает GDS? Есть несколько причин:

• GDS — это слишком универсальная штука: сама найдет файлы, проиндексирует их и сама выдаст результаты поиска. При этом GDS расчитан на «обычного» пользователя, а не на извращенного
  
• GDS постоянно висит в памяти и постоянно что-то индексирует
  
• GDS не индексирует MyBase
  
• Он не может искать по тем документам, которых никогда не было на моем компьютере
  
• У меня несколько другой подход к работе с информацией, нежели подразумевается в GDS
  
• и еще кое-что
  

Но, возможно, я пойду другим путем — недавно появилась интересная идея, «перпендикулярная» GDS. Но это уже в следующем году

Каким я хочу видеть GDS?

• двухкомпонентным: одна часть (spider) индексирует, а другая (независимая от первой) — ищет по полученному индексу (веб-интерфейс предпочтителен).
  
• гибкая настройка индексатора: где, что и как индексировать (а не «весь диск скопом», как сейчас в GDS). Желателен текстовой конфиг и запуск индексатора по Cron
  
• при наличии активного web-сервера GDS не поднимает собственный сервис, а использует cgi-win
  
• импорт/экспорт индексов. Это позволит проиндексировать документы на сервере или удаленном компьютере, а заниматься поиском — на своем рабочем компьютере. Т.е. возможность поиска по тем документам, которых нет на нашем компьютере (и не будет)
  
• накопительная часть индекса, лавинно-инкрементальное индексирование. Это дает возможность сделать экспорт из специфического формата (например, MyBase) в текстовый формат, отиндексировать его, после чего спокойно этот экспорт удалить — индекс останется, а «лишний хлам» на диске нам не нужен
  
• (если что-то еще вспомню, допишу)
  

Если вы утром как-то неправильно проснулись — попробуйте кофе с красным перцем

С тех пор, как у меня появился КПК я стал хотеть, чтобы в ЖЖ добавили wiki-разметку. [ >>> ]

update: еще, как вариант — выпросить парсер у Bolk’а (он его для Регистра писал)

GDS, как известно, мне не нравится. Т.е. вещь забавная и полезная… но меня не устраивает.
Так вот, капризы сбываются! Не успел я сформулировать wish-лист, как оказалось, что такая штука уже есть.
Что хорошо: Русский текст индексирует и ищет. Должны индексироваться doc, xls, mp3 и pdf — но не проверял.
Что удобно — для индексатора можно сделать N профилей, равно как и искать потом по любому доступному индексу. Даже импорт индексов есть — можно проиндексировать документы (на CD, на другом компе) и искать в них, не храня на своем компьютере.

Однако! Требует ActivePerl. У меня, правда, стоит Indigo в составе Sambar Server — и при установке SWISH-E поставился в несколько странном виде и без поискового интерфейса. Только командная строка.
(Ничего, попробуем доработать напильником)

Bonus track: Круче гугла своими руками
Что можно сделать с помощью поисковика: решаемые Гугл-Десктопом задачи
Get SWISH-E

Админ интерфейса, как такового, не будет, за одним исключением — страница добавления новой записи [ >>> ]
В e2 нет такого понятия, как «админский интерфейс» [ >>> ]

Что касается InTerra, то добавление новой записи можно организовать прямо в основной ленте…
Но все равно интересно — а почему отсутствие админки — это величайшее достижение блогостроения?

На самом деле, если честно, то даже переход с линейных на древовидные большого прироста хоть чего-нибудь не дал. Новые паутинообразные кейворды вызывают у меня ещё больший скептицизм… [ >>> ]

А я до сих пор думаю, что keywords (особенно, в экзотических вариантах) мало полезны. Равно как и традиционные системы классификации. И большого смысла для блогописателя в них нет.
Остается жуткий, но правильный путь — придумать систему классификации самому. Для себя.
(Я все больше склоняюсь к ассоцитивно-DM-линкованной системе)

Связывать друг с другом записи — это очень хорошо, но тут другая проблема. В блоге это вряд ли будет работать, потому, что блог хочется писать, а не связи в нём настраивать. Кейворды, они тем и полезны, что позволяют мало напрягаться. А представим, что нам вместо кейвордов нужно вручную перечислять все заметки, которые мы считаем близкими по теме к данной. Ну и что, кто бы этим пользовался? [ >>> ]

• threads: не сложнее keywords, хотя возможности пока ограничены
  
• Хвост и грива: как упорядочивать записи
  
• bonus track
  

«Не хватает важного кусочка — и потерян смысл всей вообще истории, а тот, у кого кусочек на руках, не знает, что ему с ним делать.»
(Маятник Фуко)

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

Большинство СК (систем классификации) занимается тем, что раскладывают записи на кучки (по принципу «чем меньше куча — тем быстрее в ней можно откопать нужное»).
Примерно так:

Как вариант, возможен симбиоз нескольких СК. Какая-то из них для данной выборки окажется более эффективной.

Но обычные СК не группируют контекст и не учитывают динамику (т.е. не видят цепочек типа «поставлена задача»-"возможные пути решения" — «решена вот так»). Требуется система линковки (связывания по контексту/динамике) записей.
Иначе говоря, вместо того чтобы накладывать на систему КС дополнительные уровни, для раскладывания контента по полочкам лучше использовать «альтернативные методы» — вопрос даже не в том, чтобы аккуратно разложить записи по полочкам и кучкам, а в том, чтобы ориентироваться в контенте как рыба в воде — т.е. не только быстро найти нужную запись, но и связанные с ней контекстным вектором. Чудес не бывает, но чем больше возьмет на себя СК, тем лучше для нас.

На этом лирическое вступление можно считать законченным, и пора переходить к более практичным вещам.

Для связывания записей можно использовать:
- намеки (hints) и  ручная настройка привязки
- сотовая классификация
- ассоциативная классификация

Линковку записей проще всего делать нитями. Пользователю достаточно внести имя нити (новую или из списка), в которую попадет эта запись:

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

[-1]

Уважая бритву Оккама, надо сразу сказать, что СК должны взаимно дополнять друг друга, а не дублировать. Это не обязательно, но желательно. Надо быть реалистами и верить в три зеленых свистка.

Так вот, о нитях (threads)и связывании записей можно сказать, что КС и нити не зависимы друг от друга (разнесены по плоскостям в идеальном случае), хотя и пересекаются. Это, кстати, удобно — записи одной нити могут иметь разные КС и, соответственно, разные спектры группировки на кучки.
Технологически поддержка threads разбивается на два этапа:
а) вставка записи в нить; производится аналогично КС (но плоскость имен не пересекается)
б) визуализация нити; вот тут можно извращаться различными методами: графически, на флеше с zoom, линками next/prev или методами «etc». На свой вкус.
Только не надо пытаться смешать в один клубок КС и thread — сами же и запутатесь.