EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
EBt 歴もまだそんなに長くない私がいうのが適当かどうか分かりませんが…。
私の例で言えば、
- もともとのつながりよりも、後で（Piggydb でいえばタグ的に）つけたつながりの方に意識のフォーカスが移ることが多々ある。
- 元々はノード（空メモ、Piggydb でいえばタグ的）だったものにメモコンテンツを加筆する場合があり、Piggydb でいえばフラグメント化することがある。
という状況ですので、こっちが「概念的包含関係」でそっちが「構造的包含関係」、というような意識をすることは EBt を使う限りに置いては全くありません。
要は私のいい加減な使い方に、EBt の自由度が高いことがずばりマッチングしているという感じですね。
—
なるほど、おそらく普通に情報管理をする場合は、ほとんどの場合、構造的な関係なだけで十分で、後は必要に応じて、ユーザーの側で適当に関係の意味を読み替えればいいということなんでしょうね。
これは個人的な研究テーマなのでここで深入りするのは避けますが、「概念的包含関係」と「構造的包含関係」の二つの直行する軸は、人間の認知上、本質的な区別ではないかと考えていて、フラグメント、タグもそういった経緯で発想したものではないかと、まあ事後的に考えたりしているわけです。これはもうちょっと文献などを当たって掘り下げて行こうと思っているのですが。もうこれはPiggydbとは離れた話だと思って下さい (^_^;
しかし、これを読んだ人が混乱しないか、いささか心配です。これは大前提ですけど、こういった抽象的なコンセプトは全く気にせずに、今提供している機能だけに着目して、適当に自由に使って頂くのが一番だと思っています。
元々はノード（空メモ、Piggydb でいえばタグ的）だったものにメモコンテンツを加筆する場合があり、Piggydb でいえばフラグメント化することがある。
実はこれがとても重要ですね。Piggydbも将来的には、こういった滑らかな運用が出来るようにしたいです。
「構造」と「機能」からPiggydbのモデルを分析する
ここ数日、タグについてのとても有意義な議論（#240より）が展開されていて、いろいろと刺激になっています。Piggydbの機能の背後にあるコンセプトやそこから派生するいろいろな考え方などは、研究サイトで検討しようと思っていたことで、こちらに載せるつもりはなかったのですが、せっかく機会を頂いたので、ちょっとログ的に書いておきたいと思います。
（注意）以下には無根拠な妄想が多分に含まれるので、あんまり真剣に読まないように。
以前に私のブログを読んだことがある方ならご存じの方もおられるかもしれませんが、私は、物事について考えるときに、「構造」と「機能」という概念が極めて強力なツールとして機能すると感じています。「構造」と「機能」は人間の認知の根幹を成すもので、人間が何かを認識する際、同じものを見ていても、構造的に捉えるか、機能的に捉えるか、基本はこの二つだけで説明できてしまいます。何故なら、これらの認知は人間の知覚器官に由来する云々、、、（略）
Piggydbはテキストや画像のような静的なデータの集まりを扱うツールなので、これについて分析する際は、「機能」は「意味」と言い換えた方がいいでしょう。
さて、まずこの道具立てを用意したところで、件の議論で比較の対象となっているEBtとPiggydbの違いについて考えてみます。EBtについては認識違いがあるかもしれないことは予めご了承下さい（間違いがあれば訂正します）。
- EBt for Windows
「構造」と「意味」の枠組みで考えると、EBtで表現しているのはほぼ「構造」だけです。その構造がどのような「意味」を持つかはすべてユーザーの解釈に委ねられています。例えば、リンクはただつながっている以上の意味はなくて、つながりの意味は何なのか、例えば、従属関係なのか、あるいは修飾の関係なのか、といったようなことは表現されておらず、ユーザーの解釈次第です。以上のような特徴がEBtの柔軟性の高さの理由ではないかと思います。
と、これを書いた後にEBtの仕様を改めて見てみると、リンクにラベルが付けられるようになっているんですね。しかも、ラベルは方向別に付けられるようになっているようです。これは進化の方向としては凄く正しい気がします。というのも、リンクが具体化する過程でタグ的な概念が生じてくるからです。ますます興味深いEBt、、、
Piggydbでは、EBtにおいては暗黙に意識しているような「意味」も表現手段に加えていると解釈できると思います。つながりに方向があるのは、視点を意識しているためです。例えば、A → B と B → A は異なります。Aの視点から見たBとの関係とBの視点から見たAとの関係は異なるからです。つまり、これは「意味」を単位にしているということです。タグも同様です。タグというのは、情報の「意味」を表すために純化して設計された仕組みです。
以上のように、わかりやすさ、柔軟性の高さはEBtの方が優れているわけですが、では、Piggydbには+αの表現力を追加しているとして、それが何の役に立つのかという部分が問題になります。と実はこれが今後の研究課題だったりします。一つ言えるのは、Piggydbはメモやアイデアツールとしてはややオーバースペックなのではないかということです。このことが原因で、件の議論にあるように、タグとつながりに関する混乱が起きてしまうのだと思います。
こうやって考えると、Piggydbはかなりモデリングツールに近いような感じです。ああやはりと言うか、そうなる理由は個人的にはよく分かります。基本的に自分の思考パターンがそうなっているからでしょう。モデリングツールとしての力を十分に発揮できるようにするためには、また別の戦略が必要になるんでしょうね、、、
ひとつここで注意しておきたいのは、以上の議論はあくまでモデルについてだけの話で、アプリケーションの機能自体は別のパラメータとして議論する必要があるということです。だから本当は、上記のように単純な比較はできないのが実際のところです。