'つながっている"フラグメントの一覧表示についての要望

#262
まさしくその通りです！フラグメントの構造とは直交するコンセプトにタグを利用する、言い換えると、複数の構造（ネットワーク、あるいはツリー）を横断するものですね。横断しているということを示したいがためにタグという要素を別に用意している、と言ってもいいかもしれません。
EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
そのメモ（あるいはフラグメント）を選択すれば、そこからつながる別のメモが見える、という機能に限って言えば、つながりはタグの代用になるわけですが、Piggydbにおいては、その他の機能で以下のような差別化を行っています。
つながりにページングが無いのは、それほど大きな数のつながりが作成されることを意図していないということですし、タグページにページングがあるのは、大量のデータを修飾の対象とすることを意図しているからです。 つながりの順序は以前話題になりましたけども（#208）、順序は空間上の配置を意味しますから、これはつながりが基本的には構造的な関係を表すということです。
ちょっと堅い言葉で言いますと、タグの修飾は「概念的包含関係」を表し、つながりは「構造的包含関係」を表しています。この二つの区別には常に混乱が付きまといます。
タイヤは自動車の下位概念ではない。タイヤは自動車の部品である。自動車事故は自動車の下位概念ではない。自動車事故は自動車に関連する概念ではある。
とのことですが、つまり、作者様としましては、あまり深い階層の"つながり"は想定していないとのことでしょうか？
私は個人的に、マインドマップのようなビジュアル的制約に縛られていない分
思うままに深いつながりを作成できるのが、Piggydbの利点の一つだと感じているのですが。
「概念的包含関係」と「構造的包含関係」を比較すれば、
「概念的包含関係」の方によりページングの必要を感じるのは理解できますが、
やはり、わたしとしては、「構造的包含関係」にもページングが必要だと感じています。
※ページングを関連フラグメントの一覧表示機能と捉えているのですが、それがそもそもの間違いなのでしょうか？
検索してみると、プログラミングの単語が上位にhitするのですが・・・。
既に、カラー出力など、様々な要望を出している立場で心苦しいのですが、もし、難しくないのであれば、
（既に下位フラグメントは一覧表示できる機能がありがたく備わっていますので）
の搭載を検討して頂けますと、大変ありがたいです。
もちろんお時間があるときで結構です。
もし、つながりフラグメント一覧 が実装されますと、
特に、タグ一覧や、全文検索、リンクなどからたどり着いたフラグメントの文脈を容易に把握できるようになりますから。
※もちろん、現状でもひとつひとつ上位フラグメントに遡っていくことは可能なので、贅沢な要求だとは理解しています・・・。
また、個人的にはカラー出力＞＞＞つながりフラグメント一覧
なので、本当にワガママな要望だと自覚しております。本当に申し訳ありません・・・。
それでは、どうかよろしく御願い致します。

—

#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というセントラルイメージフラグメントに２つの上位フラグメントへのつながりがついているままでも、
#400を読むときに一番読みやすいスタート地点（つまり、一番近い#centralimageフラグメント→#388）
へ遡ることが出来るようになりますから。

— → ...

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

作者からの回答 → ...

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