コンセプトの文脈を支えるタグフラグメントの二層構造

#651で見つけたブログ記事(「KJ法は発想支援ツールとして有効?」)で展開されている考察がなかなか興味深かったので、ここからちょっと展開してみたいと思います。
このブログの筆者であるyama氏は、キーワードを中心にした共同作業でのアイデア創造手法(KJ法の変形)について、
私をして違和感を持たせたというのは、おそらく、提出させられた「キーワード」の裏にあるアイディア、そしてその背景、文脈が全く切り取られたかたちで議論の俎上にあげられたということだったように思う。... しかし、複数の参加者が、突然、「キーワード」あるいは「一行見出し」のみをならべ、相互の関連を考察しようとしても、何も新しい発想など生まれる筈がない。「一行見出し」がそれに代表されているリッチな内容が参加者間で了解されていないからだ。こうした議論が、表面的なもので終わるのは不思議なことではない。
という感想を述べておられますが、これは全くその通りであると私も思いました。
キーワードや見出しの質にもよるとは思いますが、発想のために重要なのはその背後にある膨大な文脈の方であって、キーワードはあくまで結果に過ぎないと思うのです。
面白いと思ったのは、このキーワードを中心としたある種の恣意的な連想ゲームというのは、この記事にある研究会の中だけではなく、現在のメディアを媒介した一般的なコミュニケーションにおいても同様のことが展開されているという点です。
特にインターネット上のコミュニケーションでは、こういった現象がますます加速していって、キーワードから完全に文脈が排除され、受け手の好きなように解釈・再利用されるという感じになっています。
私自身は、これはいわゆる創造的なプロセスとは逆行するものではないかと考えていて、故に共同作業でのアイデア創造についても懐疑的に考えざるを得ないと思ったりしています。
Piggydbではコンセプトタグフラグメントというもので表現しますが、これは試行錯誤の結果発見されたコンセプトにせよ、これから調べたいと考えて、予め設定されるコンセプトであるにせよ、その下に膨大な文脈情報をぶら下げることができるようになっています。
タグフラグメントとは「タグとしても使えるフラグメント」のことですが、このタグフラグメントはつながりとタグという二つの経路を使って他のフラグメントと関連付けることができます。以下のスクリーンショットのように、二層のグループ化されたフラグメントを持つことができるわけです(上部がつながりによるもので、下部がタギングによるもの)。
http://piggydb.files.wordpress.com/2011/08/full-fledged-tag-page.png
コンセプトを下支えする情報が二層化されることによって、コンセプトにとってより本質的な情報はつながりで接続、単に関係がある情報はとりあえずタギングしておく、という感じで、関連情報を振り分けながら、コンセプトの輪郭を作り上げていくことができます。あるいはその過程で、別のコンセプトを発見したりということも起こりやすくなります。
創造的なプロセスを実現するためには、膨大な文脈情報をいかにうまく構成できるかというのがキーポイントで、それをタグフラグメントによる二層構造で表現してみよう、というのがPiggydbのアプローチです。

名前と文脈の表裏一体構造

名前やタイトル、あるいはキャッチフレーズの重要性は理解しています。ただ、それは単一では存在し得ないということですね。すごいキャッチフレーズを生み出せるのは、膨大な文脈を把握しているからこそだと思います。であるが故に、魂がこもる、と。その表裏一体の構造をいかに表現するかというのが(今のところの)Piggydbのテーマです。
プロセスとしては、情報収集から、検討、発見、名付けというのがボトムアップの知識構築なので、名付けが「過程でありゴールの1つ」だというのはまさにその通りだと思います。
また、名前にフォーカスするか文脈にフォーカスするかというのは、状況によって変わってきますよね。
例えば、ある種の狭いコミュニティの中では高文脈(ハイコンテクスト)な状況が生まれますので、名付けの重要性にはなかなか思い至らなくなる。名付けというのは、それまでコミュニティの中で積み上げてきたコンセプトの組み替えになるので、少なからず抵抗も生まれます。
一方、低文脈(ローコンテクスト)な状況、つまり多くの不特定多数の聴衆にアピールするためには、分かりやすい名前やキャッチフレーズが重要になる。例えば、「造反有理」などは20世紀に生まれたスローガンの中でも最大級ものものです。ただ、動員された多くの人はその文脈を理解せずに(あるいは理解しないことを狙ったとも言えますが)、大変な悲劇を引き起こしてしまった。

ハイコンテクストとローコンテクスト

どうも673です。なるほど、仰るとおりですね。私の考えも上手く伝わっているようで何よりです。
ハイコンテクスト、ローコンテクスト、面白い言葉を教えて頂きました。概念としてはなんとなく想像できていましたが、改めてキーワードにしていただけると、そのキーワードの裏側の文脈を"ググって"調べることができるのでありがたいです。
[#654] コンセプトの文脈を支えるタグフラグメントの二層構造 で述べられたいたこと
このブログの筆者であるyama氏は、キーワードを中心にした共同作業でのアイデア創造手法(KJ法の変形)について、
私をして違和感を持たせたというのは、おそらく、提出させられた「キーワード」の裏にあるアイディア、そしてその背景、文脈が全く切り取られたかたちで議論の俎上にあげられたということだったように思う。... しかし、複数の参加者が、突然、「キーワード」あるいは「一行見出し」のみをならべ、相互の関連を考察しようとしても、何も新しい発想など生まれる筈がない。「一行見出し」がそれに代表されているリッチな内容が参加者間で了解されていないからだ。こうした議論が、表面的なもので終わるのは不思議なことではない。
という感想を述べておられますが、これは全くその通りであると私も思いました。キーワードや見出しの質にもよるとは思いますが、発想のために重要なのはその背後にある膨大な文脈の方であって、キーワードはあくまで結果に過ぎないと思うのです。
での問題を解決する1つの手助けになるのが、"キーワード"を個々が納得できるまで"調べる"、"文脈を把握"した後の行うことではないでしょうか。
まあ、KJ法の話はこのぐらいにして、Piggydbでの話に戻しますね。
また、名前にフォーカスするか文脈にフォーカスするかというのは、状況によって変わってきますよね。
Piggydbはどちらの状況にも対応できるツールですようね。特に名付けができていない段階で、文脈にフォーカスして思考できるのは、Piggydbの優れた長所の1つだと感じています。

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

おはようございます。magicianです。昨日の投稿から一日が経ち、自分の中でいろいろと整理が出来てきたので、少しmarubinottoさんのコメントや、Piggydb.jpからの引用を中心に、昨夜の一連の流れを補足したいと思います。というのも、昨日の一連の投稿は、要するに私の中でmarubinottoさんの過去の発言意図がようやく"生の理解"されはじめてきたことだと感じているからです。今、過去のmarubinottoさんの発言を読み返すと、新鮮な驚きがたくさんあります。まずは、Piggydbが考える二段構えの知識構築より。
Piggydbが考える二段構えの知識構築
最近、Piggydbをバリバリ使っているのだけど、これは本当にいいものだなあと、恥ずかしいぐらいに自己満足なんだけど、思ってしまう今日この頃。
ちょっとした調べものなら、タグなど使わずに、つながりだけを使ってゆるく情報を構成していくだけでも、かなり便利に使える。
まずは調べたいテーマを表すフラグメントを作ってから、その下に入手した情報をぶら下げていく。大切なのは、テーマの下にいきなりカテゴリや区分けを表すフラグメントを作らないこと(始めから構成を固定してしまう人がかなり多い)。最初はとにかく手に入れた情報をそのままぶら下げていく。そして、ある程度フラグメントの量が増えてきて見通しが悪くなって来たなと感じたら、どうやって整理するかを考える。このようにして、自己発生的にツリーを構成していくのが基本になる。
単に情報をツリー上に構成していくだけだったら、あらゆるツールでできる、それこそテキストエディタでも可能なんだけど、Piggydbの本領はその先にある。例えば、重要だけどツリーの深いところにあるフラグメントに対して、上の階層のフラグメントから直接つながりを作ったり(これは本当によくやる)、既にできあがった階層の中を横断するようなグループ分けを新たに作ったり。サブフラグメントの順序を気軽に並び替えられるのも便利で、いろいろ考えながら、並び替えたり、整理したりするのはなかなか楽しい。
ここまでの、情報を収集して整理するプロセスだけでも結構使えるのだけど、その先に従来とは違う「タグ」の世界がある。集めた情報から何かを立ち上げていくプロセスである。これについては、いずれきちんとした説明を書かないといけないんだろうと思う。
情報を沢山集めて、その中からある結論(コンセプト)を立ち上げる、そういった知識構築を行う場合は、つながりだけでは不十分で、コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分けが必要になってくる。中卒の自分が言うと説得力がゼロなんだけど、学術論文とかはそのように書かれるものだと自分は理解している(書いたことないけどね)。
こういった知識構築術というのは、学者だけではなくて、ジャーナリストや批評家、さらには小説家のような創作に関わる人たちでも、意識的、あるいは無意識的に行っているはずである。
このいわゆる二段階の情報構成という観点からは、まだまだ機能の改善が必要なのだけど、V5.0で行ったタグフラグメントの導入がいかに重要だったかというのは、このような理由によるわけだ。
ただ少なくともPiggydb.net周辺の議論では全く理解されている雰囲気がないので、より機能を洗練させていかなくてはならないし、説明も必要だと思う今日この頃な訳である。
この記事の内容が今ではすんなり理解できます。今、思えばこの記事も何度も読んだのに、なぜ今のように理解できなかったが不思議ですが、それはおそらく「つながりとタグが重なることへの違和感」が合ったんでしょうね。一見、非効率的なやり方なのですよね、この記事のやり方は。基本的に、情報の入力を効率的に、マニュアル的に行うならば、最初の記事入力の段階でタグで整理していった方が、効率的なのですよ。
また、Piggydbを使っていく内に、どうしてもぶち当たる壁の1つに、「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか?」というものがありますが、その考え方がそもそも違っていたんですよね、多分。今の私なりの答えは、「基本的には、つながりで作り、その上で必要ならばタグID810番していく。両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」です。
なので、「Piggydbにおける情報入力の効率性」の優先度を大幅に引き下げた最近の私だからこそ、この記事をすんなり理解できるようになったのだと思います。やはり、良いものにはそれなりの手間を掛けるべきなのでしょう。(逆に、情報入力の効率性を突き詰めたら、Evernoteで良いと言うことになるので、この非効率性こそがPiggydbの差別化ポイントであり、隠された利点、なのではないでしょうか。もちろん、Piggydbが情報入力のインターフェイスを改善し、更に進化するのは大歓迎です。とくに、つながりの周辺は、marubinottoさんも進化させるおつもりのようなので、今から楽しみです。とにかく今回の論点は、学問に王道なし、ということでしょう。
そもそも根本的に、図解的、ボトムアップ的、Piggydb的、なタグの運用の仕方をするのであれば、凡人の頭では"この記事ならこのタグ"というというゴールに、最初の記事入力の段階でたどり着けるはずがないのです。つまり、記事入力の段階でタグを当てはめるという作業は、どうしても、検索のためのタグ付け、自分の把握している既存のカテゴリー分類をトップダウン的に当てはめるタグ付けになりがちである、と私は考えます。
最近のPiggydbが、キーワードによる検索能力を高める更新を行っているのも、逆説的にこの考えを裏付けているように感じます。marubinottoさんは、Piggydbにおいて「情報の入力時における検索時の視点の必要性、を出来る限り低くしよう」となさっているのではないでしょうか?

コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分け

ここまでの、情報を収集して整理するプロセスだけでも結構使えるのだけど、その先に従来とは違う「タグ」の世界がある。集めた情報から何かを立ち上げていくプロセスである。これについては、いずれきちんとした説明を書かないといけないんだろうと思う。
情報を沢山集めて、その中からある結論(コンセプト)を立ち上げる、そういった知識構築を行う場合は、つながりだけでは不十分で、コンセプトの中核を成す構造と、それらを根拠づけるための材料となる情報との区分けが必要になってくる。中卒の自分が言うと説得力がゼロなんだけど、学術論文とかはそのように書かれるものだと自分は理解している(書いたことないけどね)。
やっと、つながりで構造をつくる、という入り口に辿り着いたところなので、タグフラグメントの運用面についてはまだあまり実感がありません。これから自分のPiggydbをこの方式で実践していく中でしか、つかめないのかもしれませんが、marubinottoさんによる「きちんとした説明」を受けられる日を楽しみにしています。(もしかしたらもう既にあるのかもしれませんね、探してみます)

コンセプトの文脈を支えるタグフラグメントの二層構造 → ...

#651で見つけたブログ記事(「KJ法は発想支援ツールとして有効?」)で展開されている考察がなかなか興味深かったので、ここからちょっと展開してみたいと思います。
このブログの筆者であるyama氏は、キーワードを中心にした共同作業でのアイデア創造手法(KJ法の変形)について、
私をして違和感を持たせたというのは、おそらく、提出させられた「キーワード」の裏にあるアイディア、そしてその背景、文脈が全く切り取られたかたちで議論の俎上にあげられたということだったように思う。... しかし、複数の参加者が、突然、「キーワード」あるいは「一行見出し」のみをならべ、相互の関連を考察しようとしても、何も新しい発想など生まれる筈がない。「一行見出し」がそれに代表されているリッチな内容が参加者間で了解されていないからだ。こうした議論が、表面的なもので終わるのは不思議なことではない。
という感想を述べておられますが、これは全くその通りであると私も思いました。
キーワードや見出しの質にもよるとは思いますが、発想のために重要なのはその背後にある膨大な文脈の方であって、キーワードはあくまで結果に過ぎないと思うのです。
面白いと思ったのは、このキーワードを中心としたある種の恣意的な連想ゲームというのは、この記事にある研究会の中だけではなく、現在のメディアを媒介した一般的なコミュニケーションにおいても同様のことが展開されているという点です。
特にインターネット上のコミュニケーションでは、こういった現象がますます加速していって、キーワードから完全に文脈が排除され、受け手の好きなように解釈・再利用されるという感じになっています。
私自身は、これはいわゆる創造的なプロセスとは逆行するものではないかと考えていて、故に共同作業でのアイデア創造についても懐疑的に考えざるを得ないと思ったりしています。
Piggydbではコンセプトタグフラグメントというもので表現しますが、これは試行錯誤の結果発見されたコンセプトにせよ、これから調べたいと考えて、予め設定されるコンセプトであるにせよ、その下に膨大な文脈情報をぶら下げることができるようになっています。
タグフラグメントとは「タグとしても使えるフラグメント」のことですが、このタグフラグメントはつながりとタグという二つの経路を使って他のフラグメントと関連付けることができます。以下のスクリーンショットのように、二層のグループ化されたフラグメントを持つことができるわけです(上部がつながりによるもので、下部がタギングによるもの)。
http://piggydb.files.wordpress.com/2011/08/full-fledged-tag-page.png
コンセプトを下支えする情報が二層化されることによって、コンセプトにとってより本質的な情報はつながりで接続、単に関係がある情報はとりあえずタギングしておく、という感じで、関連情報を振り分けながら、コンセプトの輪郭を作り上げていくことができます。あるいはその過程で、別のコンセプトを発見したりということも起こりやすくなります。
創造的なプロセスを実現するためには、膨大な文脈情報をいかにうまく構成できるかというのがキーポイントで、それをタグフラグメントによる二層構造で表現してみよう、というのがPiggydbのアプローチです。

包摂の二重性問題

「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか?」
これは今までに何度も書いていますが、かなり重要な問題だと思っています。ヒトの認識・認知的にも根拠があるようなので、近々考えを書いてみようかなと思っています。概念的包摂と構造的包摂の認識問題ですね。
「両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」というのも、この包摂の二重性問題に関わっているので、なかなか的を得ているかもなあと思いました。自分も良く分かっていないことが多いので、開発を続けながら理論的な部分を詰めていきたいところです。

つながりの意味が、分かった時にタグフラグメントが生まれるんだ。 → ...

見た目が悪くなってしまい残念ですが、一番シンプルなモデルで表現してみました。AとBのフラグメントの間にあるつながりの意味を考え、その意味が「対義語だ」分かったとき、その意味と意味が支配する範囲をタグフラグメントで規定する。その時、タグフラグメントは名詞でなく、文章で良いのです。むしろ、文章の方が良いかもしれません。
ここでの注意点は、タグは決して、共通点を括ったときにのみ発生するものではないということです。(以前の私の考えとは変化してきていますので、ご注意下さい)

タグフラグメントが 指し示す中心と周辺 → ...

フラグメント群をつながりで構造化し、つながりの意味が見えたとき、その意味とその意味が支配する範囲をタグフラグメントで規定しよう」という考えの内、タグフラグメントが 指し示す中心と周辺に関するイメージ画像です。

フラグメントを人に見立てて、チームにしてみた。

フラグメントを人に見立てて、チームにしてみた。
  1. とにかくフラグメントを作って、思った通りにどんどんつなげてみよう。
    1. 後から考えると、これヘンだなぁっていうつながりがあっても大丈夫だから、なんとなくつなげたいと思ったら、どんどんつなげてみよう。
  2. そのうちに、いろんなつながりで構造化されたフラグメントたちの中に、特に強調したいフラグメントたちが見つかるかもしれない。その時は彼らのリーダーをタグフラグメントにして、全員に同じユニフォームを着せて1つのチームにしてみよう。
    1. 今までのつながりはそのままにしておいていいよ。それでも、タグフラグメントのチームになって同じユニフォームを着たことで、ほかのつながりとは違うっていうことが分かるようになったよね。
  3. こうして、チームをいっぱい作っていこう! その時、チームが出来ないつながりやフラグメントも出てくるけれど、残念、それは仕方がないことなんだ。でも、いつか彼らのチームが見つかる日が来るかもしれないよ。
    1. だから、チームはきちんと作らないといけないけれど、つながりは思いつきで作っても大丈夫なんだけど、それは何故かな? その理由がちゃんと分かったら、キミは今日から一人前のPiggydb監督だ!

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

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

これにて、#800から始まった一連の簡易説明を終わりたいと思います。皆様、お付き合い頂きまして、本当にどうもありがとうございました。
あくまでも、まだ今の段階では、私の脳内シミュレーションを行っただけの思いつきに過ぎません。いろいろと粗やケアレス発想などあるかも知れませんが、試してみる価値のあるアイデアだと自分では思っています。
早足で簡易な説明となりましたが、私の意図がmarubinottoさんやPIggydbユーザーの皆様に僅かでも伝わり何らかのヒントとなれば幸いです。
改めましてmarubinottoさん、素敵な知的生産ツールであるPiggydbを開発し続けて下さり本当にどうもありがとうございます。
P.S.
Piggydbユーザーの皆様に知の実りがありますように。

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

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

実は今、私の頭の中に知的生産の技術に関する1つのアイデアがあります。しかし、その手法を紹介するためだけにサンプル例を探して実践する時間の余裕が、残念ながら今の私にはありません。
最後の図解化から文章化ですが、ここにはまずこの作業自体をそもそもやろうとしないという決定的な問題があります。KJ法を単なる情報の整理法だと考えている人に特にこの間違いをする方が多いのではないかと思います。
又、上記で書かれているように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を使っていく内に、どうしてもぶち当たる壁の1つに、「つながりでもタグでもどちらでも表現できる情報の構造を"どちらで"表現するか?」というものがありますが、その考え方がそもそも違っていたんですよね、多分。今の私なりの答えは、「基本的には、つながりで作り、その上で必要ならばタグID810番していく。両者が重なるというムダ、非効率さこそが、実はPiggydbの二重構造の本当の価値」です。
なので、「Piggydbにおける情報入力の効率性」の優先度を大幅に引き下げた最近の私だからこそ、この記事をすんなり理解できるようになったのだと思います。やはり、良いものにはそれなりの手間を掛けるべきなのでしょう。(逆に、情報入力の効率性を突き詰めたら、Evernoteで良いと言うことになるので、この非効率性こそがPiggydbの差別化ポイントであり、隠された利点、なのではないでしょうか。もちろん、Piggydbが情報入力のインターフェイスを改善し、更に進化するのは大歓迎です。とくに、つながりの周辺は、marubinottoさんも進化させるおつもりのようなので、今から楽しみです。とにかく今回の論点は、学問に王道なし、ということでしょう。
そもそも根本的に、図解的、ボトムアップ的、Piggydb的、なタグの運用の仕方をするのであれば、凡人の頭では"この記事ならこのタグ"というというゴールに、最初の記事入力の段階でたどり着けるはずがないのです。つまり、記事入力の段階でタグを当てはめるという作業は、どうしても、検索のためのタグ付け、自分の把握している既存のカテゴリー分類をトップダウン的に当てはめるタグ付けになりがちである、と私は考えます。
最近のPiggydbが、キーワードによる検索能力を高める更新を行っているのも、逆説的にこの考えを裏付けているように感じます。marubinottoさんは、Piggydbにおいて「情報の入力時における検索時の視点の必要性、を出来る限り低くしよう」となさっているのではないでしょうか?

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

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

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。
結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。
タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。
今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。
そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。

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