強い関係と弱い関係

camiさんの想定されているものとは少し異なるかもしれませんが、強い関係（つながり）と弱い関係（タギング）という二層化されたグルーピングを提供するのがタグフラグメントなんですね。

たとえば、あるタグフラグメントを起点として考えた場合、まずそのフラグメントに「もしかしたら関係あるかも？程度の繋がり」のあるフラグメントをタギングで関連付けておきます（タグフラグメントをタグとして貼り付ける）。これが情報収集の段階です。これはゆるい関係なので、いわゆるつながりのようにきちんとした構造（例えば順序）を持たせるわけではなく、単にグルーピングされている状態です。その後、当該タグフラグメントにとって重要だと思えるフラグメントをタギングからつながりに移行させて構造を作っていきます（この移行作業を簡単にできるようにしていく予定です）。これが、Piggydbで提案しようとしている知識構築（情報の重み付け）の核心部分です。タグフラグメントのページを見ると、上部につながり、下部にタギングと、二層のグループがあることが分かるかと思います。

つまり、ゆるい関係はタグによるグルーピングで表現した方が良いかも、ということなのですが。なんとなく関係しているなというフラグメントの集合を選択して、一括でタグ付けする機能は既にありますので。

camiさんの想定とはちょっと違うかなという気もしないではないですが、、、あるいは、ちょっとした具体例があると、もう少し検討しやすくなるかもしれません。

camiです。 ...
まずはとことんツナガリだけで構造化してみよう
ゆるやかなタグと重み付けされたタグフラグメントの差異と区別

—

camiです。

なるほど！

私の中では、強い相関がタグフラグメントで、弱い相関が繋がり、という扱いでした。
本来のコンセプトでは逆なんですね。

タグフラグメントのシステムは後発ですし、使い方が確立しているわけでもなく、フラグメントをタグフラグメントに「昇格する」という感覚がありました。
どれにも密接に関係している中心となる要素、というイメージが強かったんでしょう。

タギングで弱くグループ分けしておいて、そこから繋がりを見いだすというのは、はっきりしていてわかりやすいですね。
弱くグループ分けするときは、目次になるフラグメントを作ってそこにぶらさげる、という使い方をしていました。
最終的にはその形になるのかもしれませんが、タグフラグメントで仲介させるのは良さそうです。

私の現行のやり方には特にこだわりがあるわけではないですし（使い方が固定されないことがPiggydbの利点）、少しそちらで試してみたいと思います。

—

camiさん、どうもです。

強い相関がタグフラグメントで、弱い相関が繋がり

普通のフラグメントがつながり（隣接関係）しか持てないのに対して、タグフラグメントはタグでもあり、フラグメントでもあるわけですので、つながり（隣接関係）とタギング（包摂関係）という二種類の関係を同時に持てることが大事です。二重になっていることが、ある意味混乱の元になったりしているのですが、この二重性をどう使うかが面白いところかなと思います。

フラグメントをタグフラグメントに「昇格する」

Piggydb的には、普通のフラグメントをタグフラグメントに昇格させる、という展開の方がむしろ自然かもしれませんね。先ほどの話は、初めから研究したいテーマが決まっているような場合ですが、行き先がはっきりと決まっていない場合は、集めたフラグメントの中から、さらに掘り下げたいフラグメント（大体はタイトルが名詞だったりします）をタグフラグメントに変換して、より広い情報を関連付けられるようにします。

使い方が固定されないことがPiggydbの利点

これが最も重要な原則ですね！

このようなPiggydb的知識構築法なるものを、いずれは腰をすえて書こうと思っていたのですが、これは結構いい機会かもしれませんね、、、

まずはとことんツナガリだけで構造化してみよう

結びの言葉に代えて。

Piggydbを図解風にボトムアップ思考で使いたいなら、まずはとことんまでツナガリだけを使ってフラグメントを構造化することに挑戦してみよう。
その中で、これだけは特別な関係だ、これは俺だけの閃きだ、これは私だけの新鮮な発見だ、というフラグメントの構造を見つけたら、そこだけ特別にタグフラグメントを使って、『ID810番』をしてみよう。
1. このとき、既存のツナガリを削除する必要はない。ダブって良い。それが二重構造。だからこそ、『ID810番』。

これにて、#800から始まった一連の簡易説明を終わりたいと思います。皆様、お付き合い頂きまして、本当にどうもありがとうございました。

あくまでも、まだ今の段階では、私の脳内シミュレーションを行っただけの思いつきに過ぎません。いろいろと粗やケアレス発想などあるかも知れませんが、試してみる価値のあるアイデアだと自分では思っています。

早足で簡易な説明となりましたが、私の意図がmarubinottoさんやPIggydbユーザーの皆様に僅かでも伝わり何らかのヒントとなれば幸いです。

改めましてmarubinottoさん、素敵な知的生産ツールであるPiggydbを開発し続けて下さり本当にどうもありがとうございます。

P.S.

Piggydbユーザーの皆様に知の実りがありますように。

実験的に"つながり"をツナガリとカタカナ表記してみました。どうも、つながりだけは平仮名なので、他の単語と比べて、浮くんですよね。だから""と強調するのが癖になってしまっています。ただ、つながりが平仮名で表現されていること、他の単語と少し違うこと、それ自体にもなんとなく意味を感じたりする瞬間もあるんですよね。

イメージを共有出来ていれば、情報の断片でも理解を得られるかもしれない

実は今、私の頭の中に知的生産の技術に関する１つのアイデアがあります。しかし、その手法を紹介するためだけにサンプル例を探して実践する時間の余裕が、残念ながら今の私にはありません。

最後の図解化から文章化ですが、ここにはまずこの作業自体をそもそもやろうとしないという決定的な問題があります。KJ法を単なる情報の整理法だと考えている人に特にこの間違いをする方が多いのではないかと思います。

なぜ、KJ法は失敗するのか？: DESIGN IT! w/LOVE

又、上記で書かれているようにKJ法や発想法のゴールは文章化だそうなので、piggydb.jpで文章で説明できるレベルにまで、自分のプライベートなPiggydbで実践を重ねたら、その時に紹介させて頂きたいと思います。

ただし、そのアイデアはmarubinottoさんが抱いている今現在抱いているイメージに類似しているかもしれない、という気がしています。元々、marubinottoさんが最近仰っていること、そして過去に仰った内容にとても刺激を受けているので、類似することは決しておかしくないのですが。ここで伝えたいことは、イメージが類似している、していない、オリジナルの画期的な発想か否か、ということではありません。

もし、marubinottoさんのイメージと私のイメージが類似していれば、すなわち、私がmarubinottoさんのコメントの意図の少なくとも一部を理解していることになると思います。逆に言えば、もし両者が類似していれば、私のアイデアの断片だけを紹介しても、marubinottoさんには理解して頂けるかもしれない、ということです。

その可能性を信じて、この後のフラグメントからそのアイデアの簡易な説明をpiggydb.jpで行わせて頂きたいと思います。その説明は、Piggydbを実際に使わないと実現できないものになるからです。また、普段はウェブ上と言うことで自粛している、Piggydbらしいフラグメントの使い方をさせて頂きたいと思います。

一連の説明が終わりましたら、終了宣言をさせて頂きますので、少しだけ私に説明の場をお貸し下さい。どうぞよろしく御願い頂きます。

つながりの構築に掛ける手間、タグとの二重構造、はムダではない。

おはようございます。magicianです。昨日の投稿から一日が経ち、自分の中でいろいろと整理が出来てきたので、少しmarubinottoさんのコメントや、Piggydb.jpからの引用を中心に、昨夜の一連の流れを補足したいと思います。というのも、昨日の一連の投稿は、要するに私の中でmarubinottoさんの過去の発言意図がようやく"生の理解"されはじめてきたことだと感じているからです。今、過去のmarubinottoさんの発言を読み返すと、新鮮な驚きがたくさんあります。まずは、Piggydbが考える二段構えの知識構築より。

Piggydbが考える二段構えの知識構築

最近、Piggydbをバリバリ使っているのだけど、これは本当にいいものだなあと、恥ずかしいぐらいに自己満足なんだけど、思ってしまう今日この頃。

ちょっとした調べものなら、タグなど使わずに、つながりだけを使ってゆるく情報を構成していくだけでも、かなり便利に使える。

まずは調べたいテーマを表すフラグメントを作ってから、その下に入手した情報をぶら下げていく。大切なのは、テーマの下にいきなりカテゴリや区分けを表すフラグメントを作らないこと（始めから構成を固定してしまう人がかなり多い）。最初はとにかく手に入れた情報をそのままぶら下げていく。そして、ある程度フラグメントの量が増えてきて見通しが悪くなって来たなと感じたら、どうやって整理するかを考える。このようにして、自己発生的にツリーを構成していくのが基本になる。

単に情報をツリー上に構成していくだけだったら、あらゆるツールでできる、それこそテキストエディタでも可能なんだけど、Piggydbの本領はその先にある。例えば、重要だけどツリーの深いところにあるフラグメントに対して、上の階層のフラグメントから直接つながりを作ったり（これは本当によくやる）、既にできあがった階層の中を横断するようなグループ分けを新たに作ったり。サブフラグメントの順序を気軽に並び替えられるのも便利で、いろいろ考えながら、並び替えたり、整理したりするのはなかなか楽しい。

ここまでの、情報を収集して整理するプロセスだけでも結構使えるのだけど、その先に従来とは違う「タグ」の世界がある。集めた情報から何かを立ち上げていくプロセスである。これについては、いずれきちんとした説明を書かないといけないんだろうと思う。

情報を沢山集めて、その中からある結論（コンセプト）を立ち上げる、そういった知識構築を行う場合は、つながりだけでは不十分で、コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分けが必要になってくる。中卒の自分が言うと説得力がゼロなんだけど、学術論文とかはそのように書かれるものだと自分は理解している（書いたことないけどね）。

こういった知識構築術というのは、学者だけではなくて、ジャーナリストや批評家、さらには小説家のような創作に関わる人たちでも、意識的、あるいは無意識的に行っているはずである。

このいわゆる二段階の情報構成という観点からは、まだまだ機能の改善が必要なのだけど、V5.0で行ったタグフラグメントの導入がいかに重要だったかというのは、このような理由によるわけだ。

ただ少なくともPiggydb.net周辺の議論では全く理解されている雰囲気がないので、より機能を洗練させていかなくてはならないし、説明も必要だと思う今日この頃な訳である。

この記事の内容が今ではすんなり理解できます。今、思えばこの記事も何度も読んだのに、なぜ今のように理解できなかったが不思議ですが、それはおそらく「つながりとタグが重なることへの違和感」が合ったんでしょうね。一見、非効率的なやり方なのですよね、この記事のやり方は。基本的に、情報の入力を効率的に、マニュアル的に行うならば、最初の記事入力の段階でタグで整理していった方が、効率的なのですよ。

また、Piggydbを使っていく内に、どうしてもぶち当たる壁の１つに、「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか？」というものがありますが、その考え方がそもそも違っていたんですよね、多分。今の私なりの答えは、「基本的には、つながりで作り、その上で必要ならばタグでID810番していく。両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」です。

なので、「Piggydbにおける情報入力の効率性」の優先度を大幅に引き下げた最近の私だからこそ、この記事をすんなり理解できるようになったのだと思います。やはり、良いものにはそれなりの手間を掛けるべきなのでしょう。（逆に、情報入力の効率性を突き詰めたら、Evernoteで良いと言うことになるので、この非効率性こそがPiggydbの差別化ポイントであり、隠された利点、なのではないでしょうか。もちろん、Piggydbが情報入力のインターフェイスを改善し、更に進化するのは大歓迎です。とくに、つながりの周辺は、marubinottoさんも進化させるおつもりのようなので、今から楽しみです。とにかく今回の論点は、学問に王道なし、ということでしょう。

そもそも根本的に、図解的、ボトムアップ的、Piggydb的、なタグの運用の仕方をするのであれば、凡人の頭では"この記事ならこのタグ"というというゴールに、最初の記事入力の段階でたどり着けるはずがないのです。つまり、記事入力の段階でタグを当てはめるという作業は、どうしても、検索のためのタグ付け、自分の把握している既存のカテゴリー分類をトップダウン的に当てはめるタグ付けになりがちである、と私は考えます。

最近のPiggydbが、キーワードによる検索能力を高める更新を行っているのも、逆説的にこの考えを裏付けているように感じます。marubinottoさんは、Piggydbにおいて「情報の入力時における検索時の視点の必要性、を出来る限り低くしよう」となさっているのではないでしょうか？

ゆるやかなタグと重み付けされたタグフラグメントの差異と区別

camiさんの想定されているものとは少し異なるかもしれませんが、強い関係（つながり）と弱い関係（タギング）という二層化されたグルーピングを提供するのがタグフラグメントなんですね。

たとえば、あるタグフラグメントを起点として考えた場合、まずそのフラグメントに「もしかしたら関係あるかも？程度の繋がり」のあるフラグメントをタギングで関連付けておきます（タグフラグメントをタグとして貼り付ける）。これが情報収集の段階です。これはゆるい関係なので、いわゆるつながりのようにきちんとした構造（例えば順序）を持たせるわけではなく、単にグルーピングされている状態です。その後、当該タグフラグメントにとって重要だと思えるフラグメントをタギングからつながりに移行させて構造を作っていきます（この移行作業を簡単にできるようにしていく予定です）。これが、Piggydbで提案しようとしている知識構築（情報の重み付け）の核心部分です。タグフラグメントのページを見ると、上部につながり、下部にタギングと、二層のグループがあることが分かるかと思います。

つまり、ゆるい関係はタグによるグルーピングで表現した方が良いかも、ということなのですが。なんとなく関係しているなというフラグメントの集合を選択して、一括でタグ付けする機能は既にありますので。

#627 強い関係と弱い関係

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。

結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。

タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。

今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。

そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

#544 タグを中心にした知識の構築

ゆるいタグ→つながりによる構造化→タグフラグメントによる情報の重み付け
利用者自身が学習によってよりよい分類方法を発見する事と過去のタグの修正の困難さ

上記の２つのバランスを取るためには、つながりとタグの図解 Piggydb風 | davinci noteの図にある「共通のフラグメントとつながりでつなげる」をイメージすると良いのかなと、漠然と思っています。つまり共通のフラグメントがゆるやかなグルーピングのタグのような役割をするわけです。情報の入力はタグに比べて少し煩雑になりますが、後々にタグフラグメントなどと混ざって混乱することが無くなる方が有益ではないかなと。

ID810番

ゆるやかなタグと重み付けされたタグフラグメントの差異と区別

camiさんの想定されているものとは少し異なるかもしれませんが、強い関係（つながり）と弱い関係（タギング）という二層化されたグルーピングを提供するのがタグフラグメントなんですね。

たとえば、あるタグフラグメントを起点として考えた場合、まずそのフラグメントに「もしかしたら関係あるかも？程度の繋がり」のあるフラグメントをタギングで関連付けておきます（タグフラグメントをタグとして貼り付ける）。これが情報収集の段階です。これはゆるい関係なので、いわゆるつながりのようにきちんとした構造（例えば順序）を持たせるわけではなく、単にグルーピングされている状態です。その後、当該タグフラグメントにとって重要だと思えるフラグメントをタギングからつながりに移行させて構造を作っていきます（この移行作業を簡単にできるようにしていく予定です）。これが、Piggydbで提案しようとしている知識構築（情報の重み付け）の核心部分です。タグフラグメントのページを見ると、上部につながり、下部にタギングと、二層のグループがあることが分かるかと思います。

つまり、ゆるい関係はタグによるグルーピングで表現した方が良いかも、ということなのですが。なんとなく関係しているなというフラグメントの集合を選択して、一括でタグ付けする機能は既にありますので。

#627 強い関係と弱い関係

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。

結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。

タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。

今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。

そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

#544 タグを中心にした知識の構築

ゆるいタグ→つながりによる構造化→タグフラグメントによる情報の重み付け
利用者自身が学習によってよりよい分類方法を発見する事と過去のタグの修正の困難さ

強い関係と弱い関係

タグを中心にした知識の構築

なんとか正式版のV5.0をリリースするところまで持ってこれました。この5.0で導入したタグフラグメント（#454）について、混乱している方も多いと思いますので、ここで改めてその意図について説明してみたいと思います。

Piggydbは、いろいろな情報を入力しつつ、それらを「つながり」や「タグ」によって柔軟に整理することができる、情報管理システムです。Piggydbという名前から想像できるように、ある程度形式が定まったデータベースとして利用される方が圧倒的に多いようです。

しかし、このデータベース的用途とは異なる、Piggydbの真の目的があります。それは、あらゆる角度でつながりを作ることによって、発想を刺激し、新しいアイデアの発見を促す、より創造的なツールになることです。

整理法などの本を読むと分かりますが、情報を探しやすくするために情報を分類・整理することは、あまり費用対効果が高い作業ではありません。情報の量と種類が多くなればなるほど、管理が難しくなります。探すことにフォーカスするのであれば、高度な検索機能があれば事足ります。とりあえず何でも保存しておいて、あとから検索すればいいわけです。実際にそのようなツールは沢山あって、それらの機能は信じられないほど高度になっています。

Piggydbでは、もうちょっと情報を形作る部分にフォーカスしようと考えました。そこで、つながりやらタグやらを持ち込んだのですが、、、当初はあんまり深く考えていなかった部分もあり、いろいろと思い通りに行かない部分が出てきました。その一つがタグです。

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。

結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。

タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。

今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。

そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

と、長々とタグフラグメント導入の経緯を書いてきましたが、この考え方が必ずしも多くの人に受け入れられているわけではなく、実際には反対意見も多くて、いろいろと議論も行われました。私自身もこの方法を取り入れてから日が浅いので、必ずうまく行くという保証は出来ませんが、良い感触は得ています。なにより、Piggydbの真のゴールである「創造的なツール」を目指すためには、失敗を恐れずにいろいろと試行錯誤していくしかありません。

つながりを作りやすくする３つの更新

#742 Piggydb 6.11 リリース - 「インクリメンタル・キーワード検索」では、現在選択しているフラグメントを表示したまま、検索することが出来るので、つながりやタグ、特につながりを作るのが、今までよりもとても手軽に行えるようになっていますね。

この時に#668 Piggydb 6.8 リリース - 「スマートレイアウトの改良」を活用するとより便利ですね。画面を縦に３分割（されないときは、ブラウザの文字サイズを縮小すると３分割されます）すると、更につながりを付けやすくなります。

#784 Piggydb 6.12 リリース - 「IDによるピンポイント検索」では、ウェブブラウザのタブ機能で多くのページを開いているときに、違うタブで開いているフラグメント同士でつながりやタグ、特につながりを作りたいときに、非常に便利です。

この３つの更新は、フラグメントのつながりによる構造化、を基本にPiggydbを使っていくときの大きな助けになりますね！　改めて素晴らしい機能の追加、本当にどうもありがとうございます。