私なりのPiggydbへの考察と感謝

まずは、改めて、このような素晴らしいアイデアプロセッサを作成、改良し続けて下さっていることに、
また、
などの過去ログにおいて、様々なヒントを下さっていることに、
Piggydb作者様、EBtの作者様、先輩ユーザーの方々に、深く感謝したいと思います。
本当にありがとうございます。
それでは、この上位フラグメントをセントラルイメージとして、
下位フラグメントにて、#386
ごめんなさい。タグが意図されずに継承されてしまっていたので、いくつか不適切なタグを削除しました。これは以前にも問題になったのですが、こういった場だとタグ継承（あるいはタグ自体）がうまく機能しないんですよね。
ということに関連して、私なりに、Piggydbにおける
などのことについて述べさせて頂きたいと思います。
素人の身勝手な考察ですが、何かの参考になれば幸いです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"リンクのトラックバック"と"ネットワーク"についての考察

フラグメントに情報を記入する際、参考にしたフラグメントにリンクを張りますよね。
その際のリンクは一方通行のリンクとなるわけですが、ネットワークとしてPiggydbを使う場合、
やはり、（手間の問題を度外視すれば）毎回つながりを付け足すのが正しい方向性なのでしょうか？
(機能として、リンクの"トラックバック機能"を追加すれば解決するのでしょうが
現在備わっている機能をいかに活かしていくかを考えるのもユーザーの楽しみの一つだと思いますから
・・・ただ、もし今後お時間があるようでしたら検討の片隅に加えて頂けますとありがたいです。どうぞよろしく御願いします)
例えば、EBtでの双方向リンクというのは非常に使いやすい機能だと思いました。
ですが、 #265 「構造」と「機能」からPiggydbのモデルを分析する
Piggydbでは、EBtにおいては暗黙に意識しているような「意味」も表現手段に加えていると解釈できると思います。つながりに方向があるのは、視点を意識しているためです。例えば、A → B と B → A は異なります。Aの視点から見たBとの関係とBの視点から見たAとの関係は異なるからです。つまり、これは「意味」を単位にしているということです。タグも同様です。タグというのは、情報の「意味」を表すために純化して設計された仕組みです。
というつながりの方向性という考え方も興味深いです。
それとも、リンクを張った時点で何らかの共通点があるのだから、"""タグ"""で括れば良いのでしょうか？
もちろん、ケースバイケースだとは思いますが、作者様や他のユーザーの方々からアドバイスを頂ければ幸いです。
どうぞよろしく御願い致します。

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

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

作者からの回答

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

—

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

— → ...

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

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

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

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

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

タグの継承について

#399
  1. ドラマの表題でフラグメントを作る。（第一セントラルイメージ）
  2. 子タグ（親タグは”ドラマ”）として、”ドラマ名”という固有名詞でのインデックスタグを作成して、各フラグメントに貼り付けます。
  3. ドラマの表題の下位フラグメントとして、あらすじというフラグメント（メインブランチ）を作成。
  4. １シーン＝1フラグメントと小分けして時系列のつながりをもってつなげていく。
  5. 上記の行程を繰り返し、複数のドラマの情報を入力します。
上記の作業中、4.の過程であらすじを書いたフラグメントに、その場でエッセンスとしてのタグを付けていくことが多々あります。
その際、次につながっているフラグメントは時系列でつながっているので、必然的に関係のないフラグメントが継承されることになります。
もちろん、ドラマ名という固有名詞のインデックスとしてのタグも継承されるので、
利便性という意味では、ケースバイケースなのですが、
やはり、Pigydbのコンセプトの整理、という意味では、タグの継承機能は削除した方が良いと一ユーザーとしては思います。

— → ...

今思い出したのですが、'#'で始まるタグは継承されないのでした。コンテンツの内容ではなくて、データベース上の役割を表すようなタグは、'#'で始めるようにすれば多少は使い分けができるのではと思います。ということで、その手のタグは早速リネームしておきました。