複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ

例えば、ドラマの魅力を研究していく目的でアイデアプロセッサとしてPiggydbを使用したいとします。
  1. ドラマの表題でフラグメントを作る。(第一セントラルイメージ)
  2. タグ(親タグは”ドラマ”)として、”ドラマ名”という固有名詞でのインデックスタグを作成して、各フラグメントに貼り付けます。
  3. ドラマの表題の下位フラグメントとして、あらすじというフラグメント(メインブランチ)を作成。
  4. 1シーン=1フラグメントと小分けして時系列のつながりをもってつなげていく。
  5. 上記の行程を繰り返し、複数のドラマの情報を入力します。
ここまでで、まず準備完了です。
そして、各シーン事に、このシーンでは視聴者に何を訴えたいのかということを
”視聴者があこがれる勇敢な心”というような具体的にタグとして括っていきます。
エッセンスを括ったカテゴリーとしてのタグ
次に今度は、”視聴者が憧れる勇敢な心”というタグのついたフラグメント一覧を並列に並べます。
”視聴者が憧れる勇敢な心”という共通の上位フラグメントを作成し、そこからタコの脚のようにつなげていくのです。
つまり、この段階では、(並列関係の)つながりタグが重複しているんです。
では、なぜタグ付けするだけでよいのに、あえて親フラグメントをつくって横のつながりを作るのか
それは、タグによるグループ分けよりも、横のつながりの方が、マインドマップをイメージしやすいからです。
この場合、親フラグメントがセントラルイメージ(第2セントラルイメージ)の役割になります。
こうやって複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ
を作成していけるのが、Piggydbの奥深さだと私は捉えています。

”つながり”と”タグ”は表裏一体

つながりタグの使い分けですが、現状、私は
といった風にとらえています。
ですが、#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ で例を示したように、
私なりの結論としては、つながりタグについては
細かい使い分けはしないというか、役割が重複しても気にしないということです。
重要なのは、フラグメント同士の関連性をきちんとイメージ出来るかと言うことです。
  1. まずは、マインドマップのようにつながりが伸びていき(ツリー状だけではなく、ボトムアップ、ネットワークのイメージを忘れない)
  2. そして、共通点をタグで括って(ここで新しいマインドマップ、チャイルドマインドマップを作るイメージ)、
  3. そのタグをセントラルイメージにして、またつながりが伸びていく。
こういうイメージを持てるかどうかが大切なのではないでしょうか。
  1. つながりで成長
  2. タグでぽんとワープして集まり
  3. また集まってつながりでウネウネと伸びていく。
もちろん、数あるPiggydbの活用の可能性のほんの一部分でしかないのでしょうが、
私はずっとこんな使い方ができるツールを探していたのです。ありがとう、Piggydb!!

タグの継承について


  1. ドラマの表題でフラグメントを作る。(第一セントラルイメージ)
  2. タグ(親タグは”ドラマ”)として、”ドラマ名”という固有名詞でのインデックスタグを作成して、各フラグメントに貼り付けます。
  3. ドラマの表題の下位フラグメントとして、あらすじというフラグメント(メインブランチ)を作成。
  4. 1シーン=1フラグメントと小分けして時系列のつながりをもってつなげていく。
  5. 上記の行程を繰り返し、複数のドラマの情報を入力します。

上記の作業中、4.の過程であらすじを書いたフラグメントに、その場でエッセンスとしてのタグを付けていくことが多々あります。
その際、次につながっているフラグメントは時系列でつながっているので、必然的に関係のないフラグメントが継承されることになります。
もちろん、ドラマ名という固有名詞のインデックスとしてのタグも継承されるので、
利便性という意味では、ケースバイケースなのですが、
やはり、Pigydbのコンセプトの整理、という意味では、タグの継承機能は削除した方が良いと一ユーザーとしては思います。

"タグ"は"エッセンス"を括ったもの

タグは大きく分けて2種類に分けられると思います。
・一般的なジャンル。(例、ドラマ、アニメ、報道、etc)
・時系列による区分。(2011年8月作成、2011年9月作成、etc)
・固有名詞による区分→#182 固有名詞をタグに使う,#258 タグとつながりの使い分け 等を参考にしました。
※(カテゴリーとは。
1.哲学で、アリストテレス以来の用語。
物事を分類する際、もはやそれ以上に分けることのできない、もっとも根本的、一般的な基本概念
属性、量、状態、関係等。最高の類概念。範疇
2.一般に、同じ性質のものが属すべき範囲、部門。範疇
ここでは、1.をイメージしつつも余り頑なになりすぎないように2.を基本概念とする)
#155 何のために「分類」するのか? での
ではPiggydbにおける「分類」とは何なのか? それは一言で言えば、「ユーザー自身が学習するため」の分類です。本来分類という作業は機械的にできるものではありません。先程書いたように知的負荷の高い作業です。検索のためのタグ付けであれば、単純にキーワード検索でもいいということになってしまうかもしれませんが、本当の分類(classification)は、そのキーワードが情報に含まれるかどうかとは無関係です。よって、Piggydbではユーザー自身が考えてタグ付けすることが重要です。
を私なりに捉えた概念が、エッセンスを括ったカテゴリーとしてのタグということになるのだと思います。

夢は"エッセンス"を集めて百科事典をつくること

何が問題になるのかと改めて考えてみると、やはりタグの数が増えていくに従って全体を把握できなくなり、結果的にタグでの検索を利用しなくなる、結局のところ全文検索だけを使うという状態になることでしょうね。こうならないためにはやはりタグで何を表現したいのか、何のためにタグ付けするのかを意識する必要があるのではないかと思っていて、それが「キーワードとタグを混同しない」というルールにつながったりしています。
に関してですが、私は、完全に、キーワード=タグという認識ですね。
(前提として、シングルユーザーでの使用を想定しています。)
つまり、キーワード=タグにすることによって、
2. キーワードを失念することなくいつでもこのタグで情報が取り出せるという安心感が感じられる
ということを大事にしたいのです。
タグの数が増えていくに従って全体を把握できなくなり、結果的にタグでの検索を利用しなくなる
とのことですが、Piggydbは階層型のタグが使えるので、上手く活用すれば問題ないと思います。
私が考えるに、むしろ的確な全文検索ができるキーワードが思いつくのであれば、
それはきちんと情報が頭の中に整理されていることの証だと思うので、
その場合は心配しなくて良いのではないでしょうか?
むしろ問題なのは、全文検索の為のキーワードも思いつかない場合だと思います。
またこれは個人的な考えですが、
私の夢はエッセンスとしてのタグで百科事典を作ることなので、タグは多ければ多いほど良いという考えです。
ですので、 #256 全文検索を多用しない理由には、ほぼ全面的に同意です。

複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ → ...

例えば、ドラマの魅力を研究していく目的でアイデアプロセッサとしてPiggydbを使用したいとします。
  1. ドラマの表題でフラグメントを作る。(第一セントラルイメージ)
  2. タグ(親タグは”ドラマ”)として、”ドラマ名”という固有名詞でのインデックスタグを作成して、各フラグメントに貼り付けます。
  3. ドラマの表題の下位フラグメントとして、あらすじというフラグメント(メインブランチ)を作成。
  4. 1シーン=1フラグメントと小分けして時系列のつながりをもってつなげていく。
  5. 上記の行程を繰り返し、複数のドラマの情報を入力します。
ここまでで、まず準備完了です。
そして、各シーン事に、このシーンでは視聴者に何を訴えたいのかということを
”視聴者があこがれる勇敢な心”というような具体的にタグとして括っていきます。
エッセンスを括ったカテゴリーとしてのタグ
次に今度は、”視聴者が憧れる勇敢な心”というタグのついたフラグメント一覧を並列に並べます。
”視聴者が憧れる勇敢な心”という共通の上位フラグメントを作成し、そこからタコの脚のようにつなげていくのです。
つまり、この段階では、(並列関係の)つながりタグが重複しているんです。
では、なぜタグ付けするだけでよいのに、あえて親フラグメントをつくって横のつながりを作るのか
それは、タグによるグループ分けよりも、横のつながりの方が、マインドマップをイメージしやすいからです。
この場合、親フラグメントがセントラルイメージ(第2セントラルイメージ)の役割になります。
こうやって複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ
を作成していけるのが、Piggydbの奥深さだと私は捉えています。

"つながり"は”ブランチ”

つながりマインドマップにおけるブランチに近い概念だと思います。
発想の連鎖、記憶のつながり、時系列的なつながり、そういったものを表現するのが、つながりだと。
ただし、マインドマップではビジュアル的な制約から情報量に制限がありますが、
Piggydbでは(少なくとも情報の入力時には)、情報量に制限はありません。
特に、ブランチと違い、つながりは下位概念方向のみならず、
上位概念、並列概念方向にも伸ばすことが容易です。

Piggydbはボトムアップ型のマインドマップとしても活用可能 → ...

#266 EBt作者さんのブログより「EBtの基本概念」 にて
その他、「リンクの方向に縛られて、思考が阻害される」というのは、なるほどと思いました。確かにPiggydbにおいては、つながりを作るときに「この方向で良いかな?」と一瞬考えてしまうことがあります。これはネットワークのノードが、テキストのように内容が曖昧なものになると、特に問題になるような気がします。文章としての上下関係は迷いませんが、比較的対等な横つながりの関係では煩わしい問題になりそうです。これは改善のきっかけとなりそうな良いヒントを頂きました。
フラグメントを並列概念方向に並べたいとき、私は上位フラグメント(親フラグメント)を作成し、
そこからタコの脚のように、横にフラグメントを並べていきます。
その時、上位フラグメントは、セントラルイメージの役割をするわけですが
マインドマップではセントラルイメージを作成してから、ブランチを伸ばすわけですが、
Piggydbでは、まずフラグメントを並べてから、それらを束ねるセントラルイメージの正体を考えることが出来るわけです。
これが、つまりボトムアップという思考法なのではないでしょうか。
実際のところ、私はPiggydbを使う際に、頭の中で、マインドマップをイメージしていることが多いです。
ただし、その際に気を付けているのが、
  • 上記のようなボトムアップの思考を忘れないこと。
  • 特に、一つのフラグメントが複数のセントラルイメージを持つことを恐れず、むしろ積極的に歓迎すること。
の2点です。
つまり、私はPiggydbをボトムアップ型のマインドマップのようなアイデアプロセッサとしても活用しているということです。

"タグの継承機能"の削除提案 → ...

そして、本題ですが、
発想の連鎖をイメージしたつながりの場合では多くの場合、タグの継承を行っても問題ないと思います。
(私の場合、このケースでも問題が起こることがありますが)
ただし、時系列に沿っていたり、記憶のつながりをイメージしてつながりを作っている場合、
タグの継承を行うと混乱をきたす場合があると思います。
ですので、Piggydbのコンセプトを整理するという意味に置いては、
  • タグの継承機能は削除された方が良い
と提案させて頂きたいと思います。
ただし、(特に個人使用の場合においては)ちょっと「BackSpace」キーを押せば良いだけなので、
実用レベルに置いては、急ぎの改善は必要ないと感じています。

複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ → ...

例えば、ドラマの魅力を研究していく目的でアイデアプロセッサとしてPiggydbを使用したいとします。
  1. ドラマの表題でフラグメントを作る。(第一セントラルイメージ)
  2. タグ(親タグは”ドラマ”)として、”ドラマ名”という固有名詞でのインデックスタグを作成して、各フラグメントに貼り付けます。
  3. ドラマの表題の下位フラグメントとして、あらすじというフラグメント(メインブランチ)を作成。
  4. 1シーン=1フラグメントと小分けして時系列のつながりをもってつなげていく。
  5. 上記の行程を繰り返し、複数のドラマの情報を入力します。
ここまでで、まず準備完了です。
そして、各シーン事に、このシーンでは視聴者に何を訴えたいのかということを
”視聴者があこがれる勇敢な心”というような具体的にタグとして括っていきます。
エッセンスを括ったカテゴリーとしてのタグ
次に今度は、”視聴者が憧れる勇敢な心”というタグのついたフラグメント一覧を並列に並べます。
”視聴者が憧れる勇敢な心”という共通の上位フラグメントを作成し、そこからタコの脚のようにつなげていくのです。
つまり、この段階では、(並列関係の)つながりタグが重複しているんです。
では、なぜタグ付けするだけでよいのに、あえて親フラグメントをつくって横のつながりを作るのか
それは、タグによるグループ分けよりも、横のつながりの方が、マインドマップをイメージしやすいからです。
この場合、親フラグメントがセントラルイメージ(第2セントラルイメージ)の役割になります。
こうやって複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ
を作成していけるのが、Piggydbの奥深さだと私は捉えています。

双方向をイメージしたセントラルイメージとその疑似再現

が好材料だったので、例にしてみましたが、ネットワークという視点で考えると、
で、その際に、もしもつながりが双方向であったら
何ら違和感が無く複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ
となると思います。
ですが、現状Piggydbでも単につながりをループさせるだけで
(つまり、上位フラグメントと下位フラグメントに同一のフラグメントを指定させるだけで)
フラグメント・ツリービューで一覧表示させることが出来ます。
また、構造的にも少し脳内補完すれば、充分ネットワークをイメージできると思います。

双方向"つながり"ネットワークの具体例 → ...

双方向つながりネットワークの具体例
  1. 並列のフラグメント群がタイトル表示
  2. +ボタンを押す度に、そのフラグメントと並列のフラグメント群のタイトルが表示される
  3. そして▼ボタンでタイトルが表示されているフラグメントの本文が一気に開閉される
下記に具体的な例を紹介させて頂きます。
1.並列のフラグメント群がタイトル表示
#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップを表示する。

#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ タグ表示
本文表示
 →つながりのあるフラグメントをつくる
 #400 ”つながり”と”タグ”は表裏一体  ▼ タグ表示
 #401 タグの継承について  ▼ タグ表示    
 +#394 "タグ"は"エッセンス"を括ったもの  ▼ タグ表示
 +#389 "つながり"は”ブランチ  ▼ タグ表示  
 #435 双方向をイメージしたセントラルイメージとその疑似再現  ▼ タグ表示  

2ー1.+ボタンを押す度に、そのフラグメントと並列のフラグメント群のタイトルが表示される
#389 "つながり"は”ブランチ” の+ボタンを押す。

#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ タグ表示
本文表示
 →つながりのあるフラグメントをつくる
 #400 ”つながり”と”タグ”は表裏一体  ▼ タグ表示
 #401 タグの継承について  ▼ タグ表示    
 +#394 "タグ"は"エッセンス"を括ったもの  ▼ タグ表示
 +#389 "つながり"は”ブランチ  ▼ タグ表示  
   +#390 Piggydbはボトムアップ型のマインドマップとしても活用可能  ▼ タグ表示  
      +#393 "タグの継承機能"の削除提案 ▼ タグ表示  
     ※#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ ▼ タグ表示  
 #435 双方向をイメージしたセントラルイメージとその疑似再現  ▼ タグ表示  

※ここで双方向なので、また、#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ が表示されるが、
ここはユーザーが無視するか、EBtのような感覚で捉えるか、プログラム的に表示させないようにするか、 などなど
検討の余地があると思います。
2ー2.+ボタンを押す度に、そのフラグメントと並列のフラグメント群のタイトルが表示される
#390 Piggydbはボトムアップ型のマインドマップとしても活用可能 の+ボタンを押す。

#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ タグ表示
本文表示
 →つながりのあるフラグメントをつくる
 #400 ”つながり”と”タグ”は表裏一体  ▼ タグ表示
 #401 タグの継承について  ▼ タグ表示    
 +#394 "タグ"は"エッセンス"を括ったもの  ▼ タグ表示
 +#389 "つながり"は”ブランチ  ▼ タグ表示  
   +#390 Piggydbはボトムアップ型のマインドマップとしても活用可能  ▼ タグ表示  
      +#391 上位フラグメント   ▼ タグ表示   
      #398 マインドマップのビジュアル的制約 
     ※+#389 "つながり"は”ブランチ  ▼ タグ表示      
      +#393 "タグの継承機能"の削除提案 ▼ タグ表示  
     ※#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ ▼ タグ表示  
 #435 双方向をイメージしたセントラルイメージとその疑似再現  ▼ タグ表示  

3.そして▼ボタンでタイトルが表示されているフラグメントの本文が一気に開閉される もしくは、タイトル横の▼で個別に本文を表示させていく。
というイメージです。
並列という言葉は適切ではないかもしれませんね。
上手い単語が思いつきませんが、つまり、直接つながっているフラグメント同士と言い換えればいいでしょうか。
双方向ネットワークでは、方向性よりも距離感の方がより重要なビューポイントになるかもしれないですね。

シンプルなボトムアップ式タグフラグメント案

こんばんわ。
481エラー報告
タグフラグメントの良い使い方が思いついたが、言葉で説明するのは難しそうだ。新しくサンプルデータベースを作って、それをアップロードして作者様に実際に見てもらおう。
で触れたタグフラグメントの活用アイデアについて、実際に使ってみて、だいぶ固まってきたので、ひとまず概要を紹介します。
基本的な考え方は#399 複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップを発展させたものになります。

エラー報告 → ...

……大変、申し上げにくいのですが、Piggydbがエラーを起こしました。
原因は、#trashタグタグフラグメント化しようとしたことだと思われます。
元々、
  1. タグフラグメントの良い使い方が思いついたが、言葉で説明するのは難しそうだ。
  2. 新しくサンプルデータベースを作って、それをアップロードして作者様に実際に見てもらおう。
という流れだったので、私本来のPiggydb自体はまったく被害有りません。
又、現在、新しいdbを作成し、そこにバックアップを復帰させたところ、
バックアップのタイミングと、#443 テキストエリアの自動バックアップのおかげで、
なんとか8割方は復旧できそうなので、大きな問題はありません。
やはり、バックアップの意識は大事ですね!
もしよろしければ、エラーした状態のデータフォルダとプログラムフォルダを無圧縮zipしてありますので、
今後のエラー解消のお役に立つようでしたら、アップロードする準備がありますので、お声をかけて下さい。

複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ → ...

例えば、ドラマの魅力を研究していく目的でアイデアプロセッサとしてPiggydbを使用したいとします。
  1. ドラマの表題でフラグメントを作る。(第一セントラルイメージ)
  2. タグ(親タグは”ドラマ”)として、”ドラマ名”という固有名詞でのインデックスタグを作成して、各フラグメントに貼り付けます。
  3. ドラマの表題の下位フラグメントとして、あらすじというフラグメント(メインブランチ)を作成。
  4. 1シーン=1フラグメントと小分けして時系列のつながりをもってつなげていく。
  5. 上記の行程を繰り返し、複数のドラマの情報を入力します。
ここまでで、まず準備完了です。
そして、各シーン事に、このシーンでは視聴者に何を訴えたいのかということを
”視聴者があこがれる勇敢な心”というような具体的にタグとして括っていきます。
エッセンスを括ったカテゴリーとしてのタグ
次に今度は、”視聴者が憧れる勇敢な心”というタグのついたフラグメント一覧を並列に並べます。
”視聴者が憧れる勇敢な心”という共通の上位フラグメントを作成し、そこからタコの脚のようにつなげていくのです。
つまり、この段階では、(並列関係の)つながりタグが重複しているんです。
では、なぜタグ付けするだけでよいのに、あえて親フラグメントをつくって横のつながりを作るのか
それは、タグによるグループ分けよりも、横のつながりの方が、マインドマップをイメージしやすいからです。
この場合、親フラグメントがセントラルイメージ(第2セントラルイメージ)の役割になります。
こうやって複数のセントラルイメージを持つボトムアップ、ネットワーク型のマインドマップ
を作成していけるのが、Piggydbの奥深さだと私は捉えています。

ボトムアップ式タグフラグメントの作り方 → ...

  1. 自然と、共通の内容を持つフラグメント群がたまる。
  2. その中で中心となっているフラグメントを発見し、タグフラグメント化する。→BCIF
  3. そのタグの親タグを設定する。(新規ならば、タグフラグメントを作成するのを忘れないように)
    1. ただし、元々タグ付けされていたら、その子タグとして設定される。その場合は、違和感がないかだけ、一応チェックする。
  4. 1のフラグメント群をショッピングカートでまとめて選択し、タグ付けする。
  5. BCIF(タグフラグメント)を#homeのボトムアップセントラルイメージフラグメントインデックス(BCIF_Index)につながりを作る。(片方向!)
    1. 空更新して、BCIFを上に上げておくと、つながりを作るのが楽。
  6. 既存のつながりはそのままでOK
    1. 内と外のつながりを整理したくなるが、記憶の連想を守るため、そのままにしておく。その方が楽だし、混乱もないし。
  7. 新しいフラグメントには、レスを付けていけば、自然とつながり(双方向化する)とタグが継承されていく。
  8. 他のフラグメントを追加する場合は、双方向つながりとタグ、両方を追加する手間を惜しまない

CIF=セントラルイメージフラグメントの略語
同じくBCIFはボトムアップセントラルイメージフラグメント

タグフラグメントのつながりに関する思案 → ...

  • 元々の双方向つながりは、いじらずにそのまま維持。
  • タフフラグメントで括っているとき、つながりが無く孤立しているタグも別にそのままでイイ。
    • 重要なCIFだった場合は、双方向で適切なつながりを付ければいい。
    • つまり、基本的には、できるだけシンプルに手間をかけないことを優先。その上で、手間をかけるに値するつながりなら、臨機応変に付ければ良い。
  • タグフラグメント同士のつながりも双方向で。
  • 例外は、BCIF_Indexフラグメントとのつながりのみ。ここは利便性優先で、片方向つながりでOK。
ドキュメントビューのことは、深く気にせず、とにかく、混乱無くスムーズに手軽に使っていけることを最優先。

CIF=セントラルイメージフラグメントの略語
同じくBCIFはボトムアップセントラルイメージフラグメント

既存の中心フラグメントをタグフラグメント化する際の問題点 → ...

既存の中心フラグメントタグフラグメント化する際の問題点を整理してみよう。
※#b-up-CI=Bottom UP Central Image
※元々タグフラグメント自体がタグなので、タグ一覧で探せるのだが、
私にとってCIFは重要なタグであり、フラグメントなので、特別扱いする。
この問題は、#homeにBCIF_Indexを作り、そこにつながりをつければ、解決できる。
こうすれば、とりあえず、もっとスッキリとシンプルにタグフラグメントを活用できるはず。

CIF=セントラルイメージフラグメントの略語
同じくBCIFはボトムアップセントラルイメージフラグメント

タグフラグメントの親子タグ構造について → ...

BCIFは本来分類されるべき、親タグの下に構造的に整理する。
piggydb(親タグ)→このsampledbそのものの扱いについて(BCIF)
その際、またボトムアップ式だとかで整理したくなるが、それは我慢する。それは余分。蛇足。
すっきりとしたタグ名が並ぶ中、文章でのタイトルがタグ名になっている違和感にもじきに慣れるはず。
むしろその違和感が、ボトムアップとトップダウンタグの良い目安になるかもしれない。
(私の場合、トップダウンのタグにも、タイトル風の名前を付けることが多いから、あまり当てにはならないけれど)

CIF=セントラルイメージフラグメントの略語
同じくBCIFはボトムアップセントラルイメージフラグメント

ポイントは、タグフラグメント同士のつながり → ...

  1. メモをフラグメント登録する時点では、深く考えずにドンドン登録していき、まずはフラグメントを気軽に貯めていくことが重要。
  2. しばらくして、たまったフラグメントに共通項が見え始めたら、ボトムアップ方式で整理する。
  3. そして、ボトムアップ方式から生まれたタグフラグメント同士につながりが生まれていけば、理想的。
3.の段階が一番重要なポイントなのですが、このあたりは、感覚的なものが大きいので、
現在、鋭意作成中のsampledbが一段落しましたら、一度アップロードしますので、一度軽く見て頂ければなと思います。

タフフラグメントは素晴らしいボトムアップ型の情報整理ツール → ...

以上のように、タグフラグメントに関して、考察し、実際に試行していますが、
とにかくタグフラグメントは素晴らしいボトムアップ型の情報整理ツールですね!
多少のクセは有りますが、慣れてきますと、すさまじく使い勝手が良いです! 本当に素晴らしい機能をどうもありがとうございます。
marubinotto logの方で
薄々感づいてはいたけど、前バージョンでの変更の影響が想像以上に大きい事が分かって頭を抱えてしまう。無い頭を絞ってうんうん考えた挙げ句、前バージョンの成果を半分ほど削除してやり直す事にした。ここをいい加減な形にしておくと、後で大変な事になりそうだということはなんとなく分かるので。
というのが、どういった内容なのか私には検討もつきませんが、作者様、どうか頑張って下さい!
更に改良されたPiggydbの登場を楽しみに待っています!

→ ...

う~ん。今の仕様でつながりを双方向に作ると、端的にわけが分からなくなりますね。どうやって情報を追いかけていいか混乱してます (^_^;