つながりと順序（重み付け）
コメント、こんな感じで書いてよかったでしょうか？
（いつも）コメント有難うございます。完璧です(^_^
ネットワークだよ、という考え方との整合性はちょっと整理が必要かも
鋭いです～。当初ツリーではなくてネットワークなので順序というものはなく、単につながりがあるということを意識してはいたのですが、ご指摘の通り、これは情報の見せ方にも関わってきます。上から下に並べる見せ方では結果的に順序を無視できなかったわけですね。
実はPiggydbのモデルとしては、現状のものが最終段階ではなく、将来的には「つながり」にもっとフォーカスを当てようという計画があります。具体的には「つながり」にも意味づけを出来るようにしたいと考えています。まあオントロジーみたいなものですよね（多分）。
そのように考えると、「順序（重み付け）」というのは「つながり」に付属する意味づけの中の一つのバリエーションだと言えると思います。そしてそれはバリエーションの中でも比較的重要なので先行して導入してしまおうと、そのように考えたわけです。
なので、他にも意味づけが追加できると考えて頂ければ、整合性の面では特に問題ないかなあ、と考えています。もちろん「見せ方」のバリエーションについても同時に検討していくことが重要だと思います。
グラフみたいなものは以前から考えてはいるのですが、これはどちらかと言えば技術的な問題になるので、ある程度時間を割いて調査する必要がありますね（HTML5とか）。
EBtの情報有難うございます。これは面白そうですね。結構歴史の長いソフトのようですね。「似たような概念のソフトがあまりないのでわかりにくいのですが」なんて私と同じ悩みが (^_^; 後で試してみたいと思います。
—
（いつも）コメント有難うございます。
あれ、ばれちゃったか？ というか別の常連さんと間違われている可能性も。
つながりの意味付け、そしてそのバリエーションとしての順序というのは興味深いですね。かといってあまりユーザが指定する部分を増やすと、ユーザが一貫性のある指定をすればいいですが、自分みたいないい加減な輩だと破綻しそうで怖いですf(^^;。
もし自分でプログラム書くならという（決して実現しないいい加減な）立場で考えると、少なくとも現時点では、つながりのあるドキュメント同士で参照した回数によって自然と重み付けができていくようにしておき、ドキュメントビューの順序は別に指定できるようにするような気がします。思考するときは重要性、関連性が強いものを中心に取り上げるが、他人に話をするときは必ずしも重要な順にしない、ということから考えて。
常に十分練らずに思いつきベースで書きますのでお許しを。
—
ブログ拝見してますよ (^_^
「参照した回数によって」という動的な重み付けは、私が構想しているものよりもさらに先にあるものです。とても興味深いです。なんと言いますか、いまPiggydbがフォーカスしているのは、ユーザーが意識的に行う意味付けですよね。コンセプトでは意識的に行うからユーザーが学習出来る、とかなんとかもっともらしいことを言ったりしてますけれど。「動的な重み付け」は、ユーザーの行動の集積が結果的に意味を生成するという無意識な意味付けで、これは、Web2.0の時代では標準的な仕組みになりつつあると思います。いずれはPiggydbにどのように取り入れるか検討したいテーマですが、ま、精進が必要ですね（要は勉強不足です）。
「つながり」に対する意味付けが、不必要な複雑さを増大させることになるのではないか、というのがやはり一番の懸念事項です。これはある程度慎重にならざるを得なくて、ある程度納得できるレベルになるまで熟成させているところです。
ネットワーク型のメモソフト - EBt
ちょっと前にユーザーさんから教えて頂いたEBtというソフトウェアを試してみたのですが（#208）、このソフトウェアのコンセプトはPiggydbにとても似ています。いままでPiggydbに似たものとして、WikiとかEvernoteなどを紹介したり、されたりしてきたのですが、このEBtこそがPiggydbと同じようなソフトウェアとして紹介できる初めてのものではないかと思いました。しかもEBtは結構歴史が長いようなので、Piggydbにとっては先輩にあたるソフトウェアです。
- EBt for Windows
EBtのコンセプトはPiggydbよりも遥かにシンプルです。あるのは情報の単位となる「メモ」とそれらをつなぐ「リンク」だけです。はっきり言って、手軽なネットワーク型メモツールが必要なのであれば、Piggydbよりも、このEBtの方が遥かに軽くて使いやすくてオススメです。元々はZaurusというPDA向けに開発されていたということで、モバイル上のアイデアプロセッサとしても最適なソフトウェアだと思います。
情報の構造がネットワーク型になるのはPiggydbと同じですが、EBtのリンクは双方向のつながりであるところがPiggydbと異なる点です。双方向リンクのメリットとして、リンクを辿って進むのも戻るのも同等の操作になるので、ネットワークの移動操作が一元化できるということがあります。
Piggydbの「つながり」は有方向なので、EBtのリンクと比較すると、＋αの意味付けが行われていることになります。そういった意味でも、EBtの方がずっとプリミティブなモデルを採用していることが分かります。さらに、EBtでは情報の分類もリンクで行うようになっています。つまり、メモがタグの役割も兼ねています。
このプリミティブなモデルに意味付けを追加していけば、Piggydbのモデルと同等のものが出来上がるわけです。そういった意味で根を同じくするソフトウェアだと思います。
とても興味深いと思ったのは、EBtの作者の方も私と同様の悩みを抱えておられるようで、既存の情報管理というものはツリー構造というものに支配され過ぎているので、こういった自由なネットワーク構造が果たしてどれほど受け入れられるのか、という部分を気にされているようでした。
ツリー構造は、例えば書籍などがそうですが、情報の構成に制約を追加することによって、ある種の分かりやすさを実現しています。ツリー構造は一次元の構造なので、誰でも順序に従って情報を追いかけることができます。しかし、実際に書いている内容はもっと複雑な構造を持っていることがほとんどなので、書籍の構造に束縛されすぎると内容を正しく理解できない恐れがあるわけです。個人的な経験から言えば、こういった「束縛」は結構馬鹿にできないところがあると感じています。
と、ここではこれ以上深入りするのは避けますが、こういったEBtとPiggydb、あるいはその他の情報管理とのモデルの差異を考えていくのは結構興味深いものがあります。
こういった話題が出たからという訳ではないのですが、実は近々Piggydbのモデルをネタにした裏Piggydb研究サイトをスタートしたいと目論んでいます（もちろんPiggydbを使って）。発想法などに興味がある人にとっては必読の内容になるかもしれない（？）ので、お楽しみに。
ツリービュー、アウトラインビュー
EBtのツリーで、カレントメモを起点として両手が同じメモにつながっている構造を最初に見たとき、「何じゃこりゃ？」とすごく違和感があったのを覚えています。ところがだんだん使い慣れてくると、理屈は抜きにしてメモを探しやすい。メモをたぐっていって自分の見つけたいものが出てくると、検索した方が早かったんじゃないかと思いながらも、自分の頭を使いながら探している感覚が快適でとてもいいです。
Piggydbのフラグメントだと例えば#224は#209からつながっていることは見えますが、#209が何とつながっているかはそこまで移動しないと分からない（末端のフラグメントを開いているときはアウトラインビューもツリービューも使えない？）ですよね。
EBtでもその事情は劇的には違わないのですが、常にツリービューでメモ間を動けるのと移動のレスポンスが軽快なのとで、全体を俯瞰したり捜し物をするのに重宝しています。
「構造」と「機能」から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はかなりモデリングツールに近いような感じです。ああやはりと言うか、そうなる理由は個人的にはよく分かります。基本的に自分の思考パターンがそうなっているからでしょう。モデリングツールとしての力を十分に発揮できるようにするためには、また別の戦略が必要になるんでしょうね、、、
ひとつここで注意しておきたいのは、以上の議論はあくまでモデルについてだけの話で、アプリケーションの機能自体は別のパラメータとして議論する必要があるということです。だから本当は、上記のように単純な比較はできないのが実際のところです。
フラグメントの順序
最近、「思考の整理学」（外山 滋比古著）を読みました。ざっと読んだ感じ、個人的に、全体的にはあまりピンとこなかったのですが、部分的にはいくつか参考になる記述がありました。順序については「エディターシップ」という節に興味深い記述があります。
ABCDEという5つの問題があるとき、ABCDEではまるでおもしろくないが、EDCBAだったら一変しておもしろくなり、ECDABだったら又違う見え方になる可能性があるので、細切れのメモを書いたカードから着想を得られる、という趣旨の部分です。
雰囲気的にPiggydbの典型的な使われ方に近いんじゃないかと感じました。
「思考の整理学」（外山 滋比古著）
「思考の整理学」を読んで、Piggydbの活用を連想させるのは、#229で書いた順序の他、
- メモする
- 寝させ（何で「寝かせる」と書かないの？）て発酵させる
- 寝させて、セレンディピティ（探しものと違うものからの新しい着想）を得る、インブリーディング（同系繁殖）を避ける
- 脈のあるものをピックアップする
- ピックアップしたものを他のノートに整理してメタ化する
という一連の着想法です。
「思考の整理学」のように全部紙で行えばトイレでメモするのは簡単ですが、整理、メタ化が大変です。Piggydb（でデスクトップPC)だとメモする箇所は固定されますが、発酵させるべきメモをどんどんためていって、そこから情報を整理したり、つながりやタグからの予想もしなかった新しい発見を得られる効果は大きくできる気がします。
フラグメントの順序とエディターシップ
ABCDEという5つの問題があるとき、ABCDEではまるでおもしろくないが、EDCBAだったら一変しておもしろくなり、ECDABだったら又違う見え方になる可能性があるので、細切れのメモを書いたカードから着想を得られる...
子フラグメントがドラッグ＆ドロップで並び替えられるようになったので、よりエディターシップを発揮しやすいツールになっていればいいなと思います。
今後の改良において「エディターシップ」は重要なキーワードの一つになりますね。バラバラの情報をいかに快適にオーガナイズできるか。