というアプローチを取ることにした。というのは、「それぞれの用途に特化した複数のシステム上にコンテンツを生成し、それらのコンテンツをライトウェイトに後付で結びつけて運用するアプローチ」の一環。

元々tDiaryに移行したときからそうしようと思っていたんだけど、用途ごとに特化したblogツールを自作しようと思っていたらいつまで経っても完成しないんで、そっちもありもの（Movable Type）にして稼働開始。

基本的に、tDiary上にジャンルにこだわらないさまざまな思いつきを時系列で書いていき（フローテキスト）、そこから何かコンテンツとしてまとまったものが浮かび上がったら、それらをとりまとめてblogツールの方に移動する（ストックテキスト）といった運用イメージ。

というのは、本来コンテンツとしての有用度が高いのは、ストックテキスト的な部分なんだけど、はじめからストックテキストとしてコンテンツを作るのは難しい。なかなか完成しないと出力ができず、出力がないと反応もないので、何もかもが沈滞する方向に向かってしまう。かといって、気軽にフローテキストとして出力していくと、コンテンツの完成度が高まらないし、また有用なコンテンツも時間とともに流されがちだ。

WikiLikeとかで試していた、フローテキストもストックテキストもどちらも同じツール（枠組み）できちんと扱えるようにしようという試みは、あきらめた。コンテキストによって見せ方（ユーザーインターフェース）を変えればそれなりにいけるかと思っていろいろ試してみたけど、どうにも（保持するデータ形式もユーザーインターフェースの作りも）中途半端になりがちだ（というか納得のいくレベルの完成度と汎用性を両立できなかった）。

ちなみにフローテキストの集積所としてはtDiary以外にも影舞（プロジェクト管理）があるし、ストックテキストの集積所も基本はMovable Typeにするつもりだけど、場合によってはWikiや静的HTMLを利用することもあるだろう。あとsubversionも使うつもりだけど、どうやって統合するか考え中です（学級委員会風）。

で、コンテンツの移動管理はリンクやrewriteやredirectを駆使して手動で行いつつ、全体をライトウェイトに結びつける手段の一つとして、Estraierのestmerge.cgiを使った全文検索を用意し、複数システム（サーバー）にまたがったコンテンツを串刺しで検索できるようにしておく。

estmerge.cgiは複数システムにまたがった関連文書検索もできるから、各コンテンツに「関連記事」リンクとかを用意しておけば（まだ作ってない）、ある程度自動的に複数システムにまたがったコンテンツを連動させることができるだろう。

あと「MM/本のメモ」のような、ライトウェイトな外部データベースでURL情報を管理し、RSS出力を介して利用しておくことで、あるコンテンツのURLが移動した場合にそちらのURLさえ更新すれば、自動的に各所の（RSSを利用して生成した）URLも最新の情報に追随することになる。

現状はまだ作りかけだけど、今後の方針としてはそういう方向でサイト全体を再構成していく予定。