タグフラグメントにはいくつの要素が詰まっているのだろうか?

タグフラグメントをいくつかの要素に分けてみる。特に、私なりのやり方、Piggydbをボトムアップ中心で図解風に使っていく場合、という視点で分けてみる。

以下は、Piggydbをボトムアップ中心で図解風に使っていく場合のイメージ作りには役に立ちますが、タグフラグメントの『ID810番』を重視する場合にはあまりオススメしないやり方です。(フラグメントの『構造』は"つながり"で作るべきだと考える場合)

つながりとタグの図解Piggydb風

※あくまでもイメージ です。

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

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

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

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

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

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

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

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

ID810番

重み付け → ...

重み付け

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

おはようございます。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において「情報の入力時における検索時の視点の必要性、を出来る限り低くしよう」となさっているのではないでしょうか?

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

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

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

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

タグフラグメントにはいくつの要素が詰まっているのだろうか? → ...

タグフラグメントをいくつかの要素に分けてみる。特に、私なりのやり方、Piggydbをボトムアップ中心で図解風に使っていく場合、という視点で分けてみる。
  • "つながり"で構造づけることができる。
    • 名前を付けることなく、図解のように"線でつなげたり"することができる。
  • タグフラグメントで『ID810番』する事が出来る。
  • 本文を表現できる
    • 名前を与えられる(=本文に対応した一行見出しを作ることが出来る)

以下は、Piggydbをボトムアップ中心で図解風に使っていく場合のイメージ作りには役に立ちますが、タグフラグメントの『ID810番』を重視する場合にはあまりオススメしないやり方です。(フラグメントの『構造』は"つながり"で作るべきだと考える場合)

『ID#810』をする=◯◯◯◯をする、イメージを#810フラグメントとその周辺から考えて下さい。 → ...

以後は、『ID#801』,『ID#810』,『ID#816』等という風に入力、表記していきたいと思います。これが一番シンプルで楽だと感じたので。(自動でリンクが張られるので)。
極端な話、単に#801だけでも話は話は通じると思うんですよ。例えば、
どちらも、-"つながり"で『構造』を作り、"タグフラグメント"で◯◯◯◯をする。という◯◯◯◯の間の言葉を#810フラグメントとそれにつながるフラグメント、それを規定するタグなどからイメージして下さい、よろしく御願いします、という事なので。ただ、他の単語との最低限の差別化のための飾りは必要かなと考え、『ID#801』とすることにしました。
IDをQID(Question ID)にしようかなとも一瞬思いましたが、そもそもQuesutionとは限りませんし、この仕組みの名称自体、『ID#801』で思案中な訳なので。
時間もないので特に遡って表記を修正したりはしませんが、今後はそうしていきたいと思いますので、どうぞよろしく御願い致します。