作者からの回答

magicianさん、沢山の書き込み有難うございます。一通り目を通してみましたが、一度だけでは消化しきれませんね(笑)。とりあえず、気になった部分にお返事していきます。
#396 ネットワークとしてPiggydbを使う場合、やはり、(手間の問題を度外視すれば)毎回つながりを付け足すのが正しい方向性なのでしょうか? ... リンクを張った時点で何らかの共通点があるのだから、"""タグ"""で括れば良いのでしょうか?
これは全くユーザーさんの自由で「このやり方が自分にとって役に立つ」というのが基本になると思います。もちろんPiggydbとしての方向性というものはありますが、使い方に「こうあるべき」というのがあると、とても息苦しい感じになってしまうので、本当に思うままにいろいろと試して頂ければと思っています。
#396 つながりの方向性
やはり方向がないほうがよいことも多いなあと最近では思っています。おそらくV5.xでなんらかの修正を行うことになるでしょう。
#393 "タグの継承機能"の削除提案
あった方がいいケースとそうではないケースと結構明確に分かれるのですよね。余裕があれば、選択できるようにするなんらかのインタフェースを導入したいところなのですが、、、ちょっと検討してみましょう。
#399 エッセンスを括ったカテゴリーとしてのタグ
「ドラマの魅力を研究する」例はとても面白いですね。「エッセンスを括ったカテゴリーとしてのタグ」は、今後のPiggydbで重要になってくる部分です。magicianさんにご紹介頂いたボトムアップのプロセスが少しでも効果的に行えるように改良できればいいなと思います。
#400 つながりとタグは表裏一体: 私なりの結論としては、つながりとタグについては 細かい使い分けはしないというか、役割が重複しても気にしないということです。
全くその通りだと思います。少なくとも今のPiggydbでは、どっちでもいいんじゃないかというケースが多々あります。これは結構難しい問題で、ソフトウェアとしてうまく表現できればいいなあと思っていろいろと考えています。
#395 キーワード=タグ
これは今となっては単なる言葉の問題だったなと思いますが(タグはもちろんキーワードになるべき)、要はタギングを機械的に行わないほうが良いのではないかということです。一番懸念していたのは、フラグメントの数が増えていくときに、ずっと一貫して同じようにタギングしていけるのかという部分です。これはタグというか分類というものの根本的な問題です。
#395 私の夢はエッセンスとしてのタグで百科事典を作ること
いいですね~ (^_^
#397 つながっているフラグメントの一覧表示についての要望
「深い階層の"つながり"」というのは、一つのフラグメントから沢山のつながり(子フラグメント)がある状態を指しているのでしょうか?それとも、つながりもタグと同様、下位フラグメント(子だけじゃなく孫以下も)を全て一覧表示したいということでしょうか?

早速のお返事、どうもありがとうございます。
自分なりに数日間整理はしてみましたが、Piggydbに関しての自分なりの思いの9割がたを一気に述べさせて頂きましたので、
作者様のお時間がある時にゆっくりと順番にレスを頂ければ、幸いです。
そして、これらの意見が、少しでも作者様の開発とモチベーションのお役に立てば、これ以上喜ばしいことはありません。
P.S.
残りの1割は下記へのレスです。
今日までのスレが落ち着いてきたあたりで、もう少し具体的に説明指せて頂ければなと考えています。 #367
特にジャンルをサッカーのポジションに当てはめる手法は面白いですね。トップレベルの分類を13種類に限定するというのも興味深いです。確かに、頭の中で常に記憶しておくには数の限定が重要になりますよね。「マジックナンバー7」というのもありますし。色分けが重要だというのも頷けます。

#397 つながっているフラグメントの一覧表示についての要望
「深い階層の"つながり"」というのは、一つのフラグメントから沢山のつながり(子フラグメント)がある状態を指しているのでしょうか?それとも、つながりもタグと同様、下位フラグメント(子だけじゃなく孫以下も)を全て一覧表示したいということでしょうか?
後者です。(つまり、親、祖父、曾祖父、と初代のご先祖様までたどれるようにして欲しいです)
前者は、現状でも親フラグメントを開いて、ドキュメントビューか、#66 フラグメント・ツリービューで一覧できますから。
具体的に言いますと、
つながりのあるフラグメントの一覧表示機能。
現状、自分より下位のフラグメントは、すべてそのフラグメントから
ドキュメントビューやフラグメント・ツリービューで開ける仕様になっていますよね
それを自分より上位のフラグメントに関しても同じように扱えるようにしたいのです。
もしくは、そのフラグメントのつながりの最上位フラグメント(複数ある場合も)へのリンク機能
例えば、私の今回の一連のフラグメントは更新順に読んでいくとなかなか読み取りにくい構造になっていたと思います。
ですが、#388 私なりのPiggydbへの考察と感謝を開いて、
この上位フラグメントをセントラルイメージとして、下位フラグメントにて~以下略~
という言葉から、
ドキュメントビューもしくは、フラグメント・ツリービューで一覧して頂ければ、
分かりやすく読んで頂けるような構造を意識させて頂きました。
でも、更新順に読んでいったら、#388の存在には気づけないですよね。
ですので、全てのフラグメントに、その最上位のフラグメントへのリンクが張ってあれば、
そのフラグメントからドキュメントビューや、フラグメント・ツリービューで一覧することが出来ますよね。
例えば、「#400 ”つながり”と”タグ”は表裏一体」から一発で 、#388 私なりのPigydbへの考察と感謝へのリンクが欲しいのです
(現状、一つ上位のフラグメントはリンクが表示されていますよね
それをどんどん上にたどっていくと以上のリンクにたどり着きますよね、下記のように。)
#400#399#389#388
→→→→→→#394#388
その際、現状のドキュメントビュー、フラグメントツリービューがそうであるように、
重複したフラグメントが表示されるのは、問題ないです。
というより、逆に省かれてしまうと構造が分からなくなるので困ります。
また、そのような仕組みであれば、例えば、#394の上位フラグメント(セントラルイメージフラグメント)が
#388とは違う、他のセントラルイメージフラグメントであっても、問題なくたどり着け、一覧することが出来ますよね。
システム的な負担が重いのかもしれませんが、どうぞご検討の程、よろしく御願いします。

実は、たった今、問題を説明しやすくするために、 #388 私なりのPiggydbへの考察と感謝から
  • #387 解説ありがとうございます。...
  • #360 Piggydb素晴らしいオフラインタグ情報整理ソフトです
という二つの上位フラグメントへのつながりを外させて頂きました。
つまるところ、最大限にワガママを言わせて頂ければ、
例えば、#388フラグメント#centralimageという特殊タグを設定しておけば、
上位フラグメントに遡る際に、 そこで一旦遡るのを中止してそのセントラルイメージフラグメントから、
ドキュメントビューや、フラグメント・ツリービューで下位フラグメントを一覧できるようにできたら最高です。
もし、#centralimage機能が備われば、
#388というセントラルイメージフラグメントに2つの上位フラグメントへのつながりがついているままでも、
#400を読むときに一番読みやすいスタート地点(つまり、一番近い#centralimageフラグメント#388
へ遡ることが出来るようになりますから。

→ ...

つまるところ、そもそも私は、掲示板などを更新順に逆さから読んでいくのが苦手なんですよ。
かならず、全てのレスを表示させて、頭から順番に読んでいくタイプなのです。
(活字を読むこと自体は早いほうなので、大量に読み流すのは気にならないのですが)
実際の所、少数であれば、すべての下位フラグメントに、セントラルイメージフラグメントへのつながりをつければ、解決できる問題ではあります。
マルチカラムビューとフラグメントの複数選択、D&Dによるつながり作成で、意外と簡単につながりは作成できますし。
また、すべてのセントラルイメージフラグメントに、専用タグをつけたり、ブックマークや、ホームタグをつける手もあります。
工夫次第で解決できる問題ではあるんです。現状のPiggydbの機能でも。
ただ、それでもあえて要望という形で提案させて頂いているのは、
現状の、自分より下位のフラグメントは簡単に一覧表示できるのに、自分より上位のフラグメントは一覧表示できない、
という構造は、トップダウン、ツリー型の構造に近いものだと感じているからです。
もちろん、作者様は私に指摘される以前からお気づきでしょうし、技術的な問題、システムへの負荷などの問題が大きいのでしょう。
それを承知で、失礼かとは思いましたが、それでもPiggydbが少しでもボトムアップ型のアイデアプロセッサに近づけばと思い、
あえて、ご指摘させて頂きました。どうぞお許し下さい。
#261 マインドマップについて
ツリー構造での発想法は、まずセントラルイメージという根となるテーマを決めることが前提で、そこから連想を広げていくという方法です。発想の方法としてはトップダウン式です。Piggydbでは、既存の情報から連想をしながら情報を入力していくことも可能ですが、最初は関係を意識せずランダムな情報を入力することもできます。そして情報と情報の間の関係は後から定義することができます。つまりトップダウン、ボトムアップ、どちらでも可能であると言えます。ただし、Piggydbとしてはどちらかと言えば、ボトムアップ式の方法にフォーカスしていきたいと考えています。まだまだ機能としては完全に表現しきれていないのが現状ですが。
P.S. 8月3日の深夜25時15分ごろ、Piggydb、サーバー落ちしましたか?
私の使い方がハード過ぎたのでしょうか?
それともサーバーメンテナンスのたぐいでしょうか?
後者だと良いのですが・・・
とりあえず、25分頃には復旧して今これを投稿していますが・・・

作者からの回答 → ...

現状、自分より下位のフラグメントは、すべてそのフラグメントから ドキュメントビューやフラグメント・ツリービューで開ける仕様になっていますよね それを自分より上位のフラグメントに関しても同じように扱えるようにしたいのです。
それは、つながりに方向なんていらないのでは、という話に近いです。そして実際にV5.xではそういった形になるのではないかと考えてます。
ただし、つながりが方向を持っている限り、ユーザーインタフェース上では、その方向に沿って情報を追う、ということを前提にすべきだろうなとは考えています。なので、親の方向にも全く同じインタフェースで遡っていけるようにする、ということにはならなくて、やるとしても別の形になるんじゃないでしょうか。上位への移動と下位への移動を同一視しないということですね。そうしないと、方向の意味はほとんどなくなります。
上位への移動について、どのぐらいの優先度をもって考えるかと言えば、そうですねぇ、、、それほど優先度は高くないかなあというのが今の感覚です。情報へのエントリポイント(セントラルイメージ)については、ブックマークタグを付けておくなどすれば、とりあえずは入り口を見失うことは避けられると思います(既にmagicianさんもそのように書かれてますが)。

"つながり"の双方向化には賛成です

#396 つながりの方向性
やはり方向がないほうがよいことも多いなあと最近では思っています。おそらくV5.xでなんらかの修正を行うことになるでしょう。
これを読んだとき、一瞬だけ反対しそうになりましたが、よくよく考えてみると、大きな問題はありませんね。
マインドマップのような構造も、時系列での構造も3つ以上のフラグメントつなげればその方向を示すことは出来ます。
逆に、双方向のつながりになれば、今以上に自由に気軽につながりを作ることが出来そうです。
リンクのトラックバック機能に関しても、つながりが双方向になれば、ほとんど問題なく代用することが出来ると思いますし。
(実際、リンクのトラックバック機能をつながりで代用するのに気乗りしなかった理由は、
どちらが上位フラグメントなのか微妙に迷うからというのが大きな理由でした。
だからといって共通の上位フラグメントを作ってまで、並列の関係を作るのもめんどくさかったですし)
それに、並列のフラグメントをリンクでたどっていけるのも、結構気持ちよさそうですし。
私としては、つながりの双方向化には賛成です。
実際に修正するには手間がかかるのでしょうが、頑張って下さい。
V5.xの発表、とても楽しみに待っています。