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

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

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

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

強い関係と弱い関係

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

→ ...

camiです。
なるほど!
私の中では、強い相関がタグフラグメントで、弱い相関が繋がり、という扱いでした。
本来のコンセプトでは逆なんですね。
タグフラグメントシステムは後発ですし、使い方が確立しているわけでもなく、フラグメントタグフラグメントに「昇格する」という感覚がありました。
どれにも密接に関係している中心となる要素、というイメージが強かったんでしょう。
タギングで弱くグループ分けしておいて、そこから繋がりを見いだすというのは、はっきりしていてわかりやすいですね。
弱くグループ分けするときは、目次になるフラグメントを作ってそこにぶらさげる、という使い方をしていました。
最終的にはその形になるのかもしれませんが、タグフラグメントで仲介させるのは良さそうです。
私の現行のやり方には特にこだわりがあるわけではないですし(使い方が固定されないことがPiggydbの利点)、少しそちらで試してみたいと思います。

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

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

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

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

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

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

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

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

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

なんとか正式版のV5.0をリリースするところまで持ってこれました。この5.0で導入したタグフラグメント#454)について、混乱している方も多いと思いますので、ここで改めてその意図について説明してみたいと思います。
Piggydbは、いろいろな情報を入力しつつ、それらを「つながり」や「タグ」によって柔軟に整理することができる、情報管理システムです。Piggydbという名前から想像できるように、ある程度形式が定まったデータベースとして利用される方が圧倒的に多いようです。
しかし、このデータベース的用途とは異なる、Piggydbの真の目的があります。それは、あらゆる角度でつながりを作ることによって、発想を刺激し、新しいアイデアの発見を促す、より創造的なツールになることです。
整理法などの本を読むと分かりますが、情報を探しやすくするために情報を分類・整理することは、あまり費用対効果が高い作業ではありません。情報の量と種類が多くなればなるほど、管理が難しくなります。探すことにフォーカスするのであれば、高度な検索機能があれば事足ります。とりあえず何でも保存しておいて、あとから検索すればいいわけです。実際にそのようなツールは沢山あって、それらの機能は信じられないほど高度になっています。
Piggydbでは、もうちょっと情報を形作る部分にフォーカスしようと考えました。そこで、つながりやらタグやらを持ち込んだのですが、、、当初はあんまり深く考えていなかった部分もあり、いろいろと思い通りに行かない部分が出てきました。その一つがタグです。
タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。
結果的に、軽はずみにタグを使うのは良くないな、と考えるようになったわけですが、その一方で、情報を蓄積・整理していく過程で、重要になっていく情報を浮き立たせる手段として、タグが使えるのではないか、という考えがありました。
タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。
今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。
そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。
と、長々とタグフラグメント導入の経緯を書いてきましたが、この考え方が必ずしも多くの人に受け入れられているわけではなく、実際には反対意見も多くて、いろいろと議論も行われました。私自身もこの方法を取り入れてから日が浅いので、必ずうまく行くという保証は出来ませんが、良い感触は得ています。なにより、Piggydbの真のゴールである「創造的なツール」を目指すためには、失敗を恐れずにいろいろと試行錯誤していくしかありません。

創造的なツールには魅力的なUI、ビジュアルも必要ではないか → ...

とても興味深い説明ですね。じっくり考えた上で、個々のポイントにコメントさせて頂きたいと思いますが、まずは一点。私はタグフラグメント、大歓迎です!! ボトムアップ式の情報整理にはまさにうってつけの手段だと思います。
では、以下このフラグメントの本題「創造的なツールには魅力的なUI、ビジュアルも必要ではないか」に関して述べさせて頂きます。インプットした情報をアウトプットする段階でのお話です。
しかし、このデータベース的用途とは異なる、Piggydbの真の目的があります。それは、あらゆる角度でつながりを作ることによって、発想を刺激し、新しいアイデアの発見を促す、より創造的なツールになることです。
この素晴らしい目的を実現するためには、ツールの機能面だけではなく、ツールのビジュアル面にも拘ることが必要なのではないかなと思います。

情報を後から見返したいと思えるようなUIだろうか?
まず最初に、僕はWindowsとiPhoneとiPadのクライアントしか使ったことがありません。もしかしたら、Macでは違うかもしれません。ただ、WindowsとiPhoneとiPadのクライアントのUIは、正直あまり好きにはなれません。あまり素敵ではないからです。
色々な情報をEvernoteに蓄積していく。そして数ヵ月後か数年後、それを見返したいと思うときがくるでしょう。ただ、果たしてこのEvernoteで情報を見返して満足感が得られるのか?機能は貧弱でもより魅力的なUIを持つアプリケーションの方が、読み返すモチベーションも読み返した後の満足感も上ではないだろうか?そう感じたことはありませんか?
ただ、見返すものが、文字通りただの情報だたっとしたら、そこにデザインという観点は的外れでしょう。ただ、大学ノートではなく会えて高価なモレスキンなどのノートを手に取るような人であれば、一度は感じたことがあるのではないでしょうか。
Awesome NoteのUIデザインは本当に素敵です。 もう素敵すぎて、アプリを起動する度にウットリしてしまいます。惜しむらくべきはアイコンでしょうか…。
そして、使い勝手も決して悪くないんですよね。ノートの表示方法も多彩だし、ソートも結構強力です。クイックメモ機能やToDo管理も便利です。ノートブック毎にカラーやアイコンを変えて、ノートブック一覧も見やすくできます。検索の速さも優秀です。

以上、ryodesignblogより引用させて頂きました。
同じ文字としての情報が表示されていても、美しいビジュアルのツールの方がより、創造力を掻き立てられるのではないでしょうか?
ちなみに現状のPiggydbは
  • タグクラウドビューのワクワク感!
    • 大きく育ったタグには、たくさんインプットしたなぁという満足感も感じられますね!!
  • スライドバー操作で、様々に変化するフラグメントリストビューの爽快感!
    • 画像フラグメントのサムネイルが表示されるようになると更に楽しくなりますね!!(要望です、ご検討よろしく御願いします)
  • 軽快な検索スピードと、的確な検索結果を併せ持つ、優秀な全文検索!
    • 一回の表示量を制限しているので、大量の検索結果がある場合でも、極端に遅くなったり重くなったりしないのが職人技って感じです!!
  • フィルタ操作を意識させないシームレスな「関連するタグ」機能!
    • +ボタン、-ボタンでポチっポチっと操作していく感じも、分かりやすく面白いです!!
  • フラグメントツリービューからのつながりをたどるネットサーフィンの楽しさ!
    • 双方向つながりだと更にネットワークが広がり、まさに脳内シミュレータと化します!!
とたくさんの情報を後から見返したいと思えるUIが満載なので、作者様には今後もこの視点を忘れずに持ち続けてもらいたいなと思います。
また、ビジュアルという面では、PiggydbはFirefoxで操作できるツールであるというメリットを生かして、もっとユーザーが積極的にStylishを活用できる環境を整えた方が良いと思います。
まずは、微力ながら私が実際に使っているStylishの記述を紹介させて頂きたいと思います。#546 ブラック&オレンジがテーマのPiggydb用Stylish をご参照下さい。これは、#369 見た目のカスタマイズについて で紹介されたいた記述を参考に個人的なマイナーチェンジを加えた物です。(Thank you for Modifying the Look and Feel of Piggydb!)
ポイントは3点(+注意点が1点)。
  • html body div.ac_results ul li.ac_over{ color: #ff6600 ! important;} の発見。
    • タグの入力補完機能が働いている時に選択しているタグを区別するための色の指定の記述を発見。
  • 小さなアルファベットが読みやすくなるように"Verdana"フォントを指定。
  • visited linkの色を変更しない。
    • ニュースサイトなどと違い、自分で入力した記事なので必要が無い。無意味に色に差がでると逆に混乱する。
    • todo的な利用をする方、読み返し具合を把握したい方などは、個別に配色を設定する方が良いでしょう。
  • @-moz-document url-prefix("http://localhost:8080/warファイル名/document-view.htm" の記述に注意。
    • スタンドアロン・パッケージ以外のユーザーの方は、微調整が必要です。
そして、もちろんカラーリングはお好みで変更して下さい。個人的には、この黒とオレンジの配色がとてもモチベーションを刺激してくれる大のお気に入りとなっていますので、ぜひ一度お試し頂けると嬉しいですが。
私なりにいろいろ工夫してみましたが、もし今後作者様の視点から、Stylishの記述へのアドバイスなどがあると、また一段とPiggydbの楽しさの幅が広がるのではないかと思います。もし、お時間がありましたらご検討願えますと嬉しいです。

つながりの意味とランダムビュー

ネットワーク構造というのは頭の中にだけにある抽象的な構造で、これを抽象的なまま視覚情報、つまり図示するのは結構難しい。例えば、もっとも単純だと思われる2ノードのネットワークを図示することを考える。
ノードをどのように配置するかで、ネットワークの「意味」が変わってしまう。横の配置では対等に見えていた二つのノードが、縦の配置では上下関係があるかのよう見えてしまう。
とありましたが、この感覚は実感することができます。#377 知識創造ソフトウェア: Frieve Editor, iroha Note のような空間的な表現をするソフトでさえ、そういう関係性から抜け出すのは容易では無いと思います。脳内のネットワークをリアルにイメージさせるには、3Dかつ自由な視点方向が求められるのではないでしょうか。
ですが、現実にPiggydbに3Dビューを搭載するのは、非常に困難だと思われますので、Frieve Editorのようにランダムな表示を取り入れてはいかがでしょうか?
つながりのあるフラグメントのみをランダムに表示させるのは、かえって難しいような気がするので、まず「ランダムビュー」というページをPiggydbの上部ツールバーに、「ホーム」 「フィルタ」 「ランダム」 「システム」 「ログアウト」 という風に設置します。
そして、「ランダムビュー」に入ると、全てのフラグメントからピックアップされたフラグメントがランダムに表示されています。そこから、フィルタ機能を組み合わせて、関連するタグのついたフラグメントのみをランダムで表示するようにするのです。
ランダムビューは発想を刺激し、新しいアイデアの発見を促すために使われる古典的な手法の一つですが、試す価値のある手段だと思います。どうかご検討の程、よろしく御願いします。

Piggydbを操作すること、それ自体が今以上に楽しくなりますように

整理法などの本を読むと分かりますが、情報を探しやすくするために情報を分類・整理することは、あまり費用対効果が高い作業ではありません。情報の量と種類が多くなればなるほど、管理が難しくなります。探すことにフォーカスするのであれば、高度な検索機能があれば事足ります。とりあえず何でも保存しておいて、あとから検索すればいいわけです。実際にそのようなツールは沢山あって、それらの機能は信じられないほど高度になっています。
情報を探しやすくするために情報を分類・整理すること費用対効果を高くする事ができれば、それは素晴らしいことですよね。情報を整理するツールを操作すること、それ自体が楽しければ、自然と費用対効果も高くなると思います。
続けるためには「快」が不可欠
以上、ごくありきたりの話に得心がいきましたら、ユビキタス・キャプチャーを続けるための個人的な快感要素を探し出してください。不快要素も見つけ出してください。快の要素を強め、意識し、不快要素を撲滅するようにしていけば、続けられます。
これはユビキタス・キャプチャーに限った話ではないのです。私は最近、かろうじてブログが連日続けられるようになりましたが、続けられるようになった要因は「1Password」と「Text Expander」と「MarsEdit」にあるのです。
ぜんぶLifehacking.jpの堀さんに教わったものですが、「ブログを続ける」というときに障害となったのは、Password入力が面倒くさかったことと、同じ文章をくりかえし入力するのが面倒くさかったことと、タグを覚えるのが面倒くさかったことなのです。それを面倒くさがりながらも何度も続けていたため、それらを取り払ってくれるツールを使うのが快感なのです。だから続くようになったのです。

※ユビキタス・キャプチャーとは? 
一言で言えば「書いて、忘れる」事で、常に脳をリラックスさせる手法です。もっと細かいルールもあるようですが、私は単純に「ちょっとしたことでもこまめにメモすることで、メモしてあるのだから忘れても大丈夫、という安心感を得ることで脳をリラックスさせる」手法と捉えて使っています。
今回の記事とは直接関係は無いのですが、個人的にPiggydbをユビキタス・キャプチャーの重要なツールとして使用しているので、併せて紹介させて頂きました。
デイリータスクが全てきちんと片付けば「快」だし、自分の予定、タスクが全て書き出されていてそこに書かれていることにだけフォーカスすればいい状況も「快」、考えていることやアイデアが頭の中にだけあって「忘れるかも・・・」と思っている事はひどく「不快」。

現在のPiggydbは操作すること、それ自体が楽しくなるツールになりつつある、と、個人的には感じています。この楽しさに関しては、過去に散々語らせて頂いたので、ここでの重複は避けたいと思いますが、あえて一点だけ上げるなら、タグフラグメントの存在は非常に大きいです。
過去のフラグメントを読み直して、タグ漏れが無いか、タグのルールはズレていないか、などをチェックする作業は受動的な作業であまり楽しいものとは言えません。ですが、タグフラグメントという機能とボトムアップの意識を持って読み返せば、それがたちまちアクティブな能動的な作業となります。過去の自分が無意識に積み重ねてきたフラグメントの数々から、成長した自分の目を使って「宝物の情報」を探す、一大アドベンチャーになるのです。
また、更にPiggydbが、操作すること自体が楽しくなるツールに成長するためにいくつか要望を出させて頂きます。
  • タグページからD&Dでタグ付けが出来るようになる。
  • 画像をD&Dすることで、新規の画像フラグメントが作成される。
  • フラグメントにリッチテキストやカラー表示が使えるようになる。
    • カラータグの採用(#369 見た目のカスタマイズについて)
    • テキストの一部にclassを設定できるようにすればStylish経由でスタイルを設定できる(#380)
  • つながりのあるフラグメントを空間的に自由に配置できるように
    • (#473 作者からの回答 など)
以上のようなラインナップになりますが、作者様のモチベーションに合わせて、ごゆっくりご検討して頂ければ幸いです。
そして、インプットする各情報のごとのモチベーションに併せて、タグの細かさを分けるのも、大事なポイントだと思います。自分の趣味に関するタグは細かく、仕事に関するタグはおおざっぱに。これもタグ分けを長続きさせる小さなコツではないかと思います。

ユーザの成長は表裏一体

タグは、いわゆるフォルダ的なカテゴリー分類よりも柔軟な分類手段です。私も当初は疑いなくタグが有用なものだと思ってPiggydbに導入しました。ところが、やはりというか「分類」というのは鬼門でした。データベースが大きくなるにつれて、分類の体系を維持するのが難しくなることに気づきました。何故なら、利用者自身が学習によってよりよい分類方法を発見するからです。そうなった場合、過去のタギングをさかのぼって修正するのは容易ではありません。
確かに、Piggydbを真剣に使っていればいるほど、その問題にはぶつかりますね。実際、私も似たような経験をしていますので、その際の、私なりの対処方法をご紹介します。
※前提として、以下のタグは全て、インデックス(内容を指し示すもの。索引。見出し。また、指標となるもの)としてのタグ ではなく、エッセンス(物事の本質)を括ったカテゴリーとしてのタグの利用法についてのアイデアです。
  • #394 "タグ"は"エッセンス"を括ったもの
  • #262 (タグの修飾は「概念的包含関係」を表し、つながりは「構造的包含関係」を表しています)
もちろんインデックスとしてのタグに応用できるアイデアも含まれていますが、基本的にはエッセンスとしてのタグについて考えています。

「表記揺れタグの採用」
タグの表記揺れはタグを利用するサービス全ての共通命題ですが、親子タグを実現しているPiggydbはこの問題をスマートに回避することが可能です。
  1. 正式名称の親タグの下に、簡略したタグ名を子タグとして登録します。
  2. そうすると、子タグは親タグに含まれますから、正式名称の親タグ、簡略名の子タグ、そのどちらからでも目的のフラグメントが検出されるようになります。

タグの頭に記号を付ける」
タグツリービュー以外の視点、タグクラウドビューやタグフラットビューでの探しやすさを視点に持つことで、一つのタグに複数の役割を持たせることが出来るようになります。その視点から、生まれるアイデアの一つが、「タグの頭に記号を付ける」ことです。
この手法は様々にネット上に紹介されているので、ここでは一つだけ紹介させて頂きます。
例えば、本連載を筆者はプロジェクトと位置づけていますから、本連載に役立ちそうな資料となるメモはすべて.「シゴトハッカーズ」というタグを付けています。
そして、プロジェクトが終わったら、タグをリネームします。例えば本連載が残念なことに終わってしまったら、■「シゴトハッカーズ」というタグに切り替えるのです。
すると、タグは名称で並び替わるので、それまでは上位の方に並んでいた「シゴトハッカーズ」のタグが一番下に落ちます。
上記の用ようにタグをリネームする事で、タグの分類はそのまま維持しながら、タグの鮮度を明らかにする事ができます。

「古いタギングから新しいタギングにタグを継承する」
これは複数の親を持つ親子タグという柔軟なタグ機能を持つPiggydbならではの手法です。基本的な考え方は極シンプルです。
  1. タグが旧タグを細分化するものであれば、旧タグの子タグとして新タグを作る。
  2. フラグメントカートを使い、旧タグの中から適切なフラグメントのみを新タグ登録する。
    1. このとき、複数の親タグからフラグメントをセレクトする事が可能。
  3. タグは削除せずにリネームする。(タグの記号を更新する)
  1. タグが旧タグよりも大きなカテゴリーであれば、単純に旧タグの親タグとして新タグを作成すれば、OK
  2. 当然、複数の旧タグを子タグとする事が可能。
  3. この場合も、旧タグは削除せずにリネームする。(タグの記号を更新する)
もちろん、旧タグとは関係のないまっさらなタグ構造で新タグを作成してもまったく問題ありません。ただ、上記のようにしておくことで、今後も旧タグでの検索能力をあるていど維持し続けることができることがこの方法のメリットです。上記の場合なら、旧タグをそのまま活用できます。後者の場合でも、タグツリービューから混乱無く新タグへと辿り着くことが出来ます。
問題は、こういった小手先の対応が間に合わない場合があることですよね。画期的なタギングの方法を思いついてしまったりすることで。私ならそういった場合は、以下のように対応すると思います。
  1. タグ全てを削除せずにリネームする。(タグの記号を更新する)
  2. 全ての旧タグの親タグとして、「引退済み」というルートタグを設定
    1. 他の旧タグタグツリービューのルートタグから表示されないようにする。
  3. 次に、出来る限り旧タグの設定を活かしつつ、全てのフラグメントに新タグを設定していく。
  • 古いフラグメントには新旧二重のタグが設定され、新しいタグは新タグのみが設定されるようになりますが、それは気にしないことにします。
  • タグのリネームと「引退済み」ルートタグにより、3つのタグビュー全てにおいて、新旧タグの区別がハッキリ表示されるので、大きな混乱は無いと思います。
  • 何より、タグの移行作業は大仕事になり、必ず移行期という期間が発生しますが、この方法なら移行期でも余り混乱せずにPiggydbの使用を継続することが可能になります。
……どちらにせよ、大騒動になるのは避けられそうにありませんが。
やはり、基本的な方針として、最初からトップダウンで杓子定規にタグ付けせず、使用しながら必要だと感じたタグを柔軟にボトムアップでつけていけば、自分の感覚に合ったタグ付けが出来るのではないかと思います。ただ、その自分の感覚自体が成長してしまうのが、一番の問題なんですね……。(その成長は、実は一番の喜びでもあるのですが)
この問題は、一朝一夕で解決出来る問題ではなさそうなので、また良いアイデアが浮かびましたら、ご報告させて頂きたいと思います。

タグフラグメント化と既存のつながり

  1. 既存のフラグメントタグフラグメント化する。
  2. そのタグがつけられる候補になるのは、タグフラグメントとつながりのあるフラグメント群であることが多い。
  3. そのフラグメントからタグフラグメントへのつながりを今後も残していくかどうか。
  4. また、新しくタグ付けされたフラグメントタグフラグメントへつながりを作成する必要があるのか。
このあたりがタグフラグメントとつながりの使い分けに関して混乱するところだと思いますが、私の意見は下記の通りです。
  • 既存のつながりはそのまま維持する。
    • つながりは芋づる式の記憶の連鎖を保存する役割も担っているから、タグフラグメント化しても重要な役割を果たし続ける。
  • 新しいタグは基本的にタグフラグメントへのつながりを作成する必要はない。
    • タグフラグメント化するということは、新しい概念が自分の中に誕生したと言うこと。
    • 新しい概念に沿って、タグ付けすることと、発想の連鎖によってつながりを作成することは意図が違う。
    • 新しい概念に沿ってタグ付けしたフラグメント発想の連鎖を感じたのであれば、臨機応変に重複して対応させればよい。

トップダウン式のインデックスタグと、ボトムアップ式のエッセンスタグの使い分け → ...

タグを使わずに、フラグメントとつながりだけで情報を構成していると、情報収集の中心となっているフラグメントがあることに気づきます。それらのタイトルは、自分がフォーカスしている問題だったり、重要なコンセプトを表していたりします。こういったフラグメントを後からタグに変換して、もっと広範囲の情報を収集したり、表示したりできるようにすれば良いのではないかと考えるに至りました。
今までのタギングというのは、コンテンツの中から適当にキーワードをピックアップしたり、自分が知っているカテゴリーの中から選択する、というのが一般的だったのではないかと思います。タグを付ける際、後々どのようなキーワードでその情報を特定できれば便利だろうかと考えるわけですが、Piggydbの利用方法が探索的になればなるほど、その予想は外れる、あるいは利用者自身の成長によってタグツリーが陳腐化してしまう可能性が高くなります。
そこで、タグの役割を少し変えてみて、データベースの中から自然発生的に現れるタグ、あるいは利用者のフォーカスを表すためのタグという形にシフトさせたらどうなるだろう、というのが今回導入されたタグフラグメントで実験しようとしていることです。
つまり、トップダウン式のインデックスタグと、ボトムアップ式のエッセンスタグの使い分け、この2つの考え方を整理してみたということですよね。

「トップダウン式のインデックスタグ
複数の親を持つ親子タグを設定できるPiggydbでは、固有名詞を分類するインデックス式タグの作成が楽しいです。
#270 つながりとタグの使い分け例: 「Table Tennis Videos」
そして重要なのは、フラグメントに適用すべきタグは最も具体的なタグだけでOKだということです。ある選手のタグを試合フラグメントに貼り付ければ、そのフラグメントはその選手の所属国やスタイル、性別によっても同時に分類されることになります。
player
→ women
→→ FUKUHARA Ai
style
→ grip
→→ shakehand
→→→ FUKUHARA Ai
country
→ Japan
→→ JPN
→→→ FUKUHARA Ai
association
→ JPN
→→ FUKUHARA Ai
とFUKUHARA Ai選手は4つのルートタグ(player,style,country,association)をご先祖様に持っている訳です。直接の親タグには、(women,shakehand,JPN)の3つの親タグを持っています。又、JPNも国連加盟国としての分類、競技団体としての分類、2つの親を持っていることになります。
(サッカーの英国などは、国連加盟国としては一つの国家ですが、競技団体としては、英国四協会と呼ばれる4つの協会がFIFAに独立して登録されています。従って、FIFAワールドカップには4つの協会がそれぞれ別のチームとして予選に出場します。逆に、一つの国連加盟国から一チームしか出場できないオリンピックでは、現在ロンドン五輪に向けて、サッカーのチーム構成をどうするかが、国家的関心事となっています)
つまり、一度FUKUHARA Aiという固有名詞をタグ登録してしまえば、あとは各フラグメントにFUKUHARA Aiというタグをつけるだけで、上記の分類が全て一度に行われるわけです。他のタグツールのように、全てのフラグメントに個別でJPN,shakehand,womenといったタグを付ける必要がないのです! これは非常に操作が楽になります!!
一度作成したら、あとはタグそのものを分類すればOK! 一々個別のフラグメントタグを修正する必要はないのです。例えば、年齢でもタグ付けをしたいと思ったら、birth1988というタグを、FUKUHARA Aiというタグの親タグに設定するだけでFUKUHARA Aiのタグがついた全てのフラグメントが、birth1988でも検索されるようになります!
この機能は、竜頭蛇尾型のモチベーション人間、いやいや、後で楽をするために最初の苦労は惜しまないタイプの人間にピッタリです。やる気のある最初に几帳面にタグを構成しておけば、実際に使う段階では、固有名詞を一つ選択するだけで整理された複数のタグが作成されるのです。これが他のタグソフトであれば、最初に几帳面にタグを構成してしまったら、実際に使用する段階でも、几帳面にタグを付けていかなければ、タグ構造が破綻してしまいます。
以上が、「トップダウン式のインデックスタグ」の概要になります。

「ボトムアップ式のエッセンスタグ
「トップダウン式のインデックスタグ」が、フラグメントよりも先にタグの構成を考えるのとは逆に、「ボトムアップ式のエッセンスタグ」は、まずとにかくフラグメントを作成して、貯めていきます。
  1. このフラグメントはどのようなタグで分類すべきなのか、などは気にせずに、とにかくフラグメントを貯めていく。
  2. ある程度、フラグメントがたまった段階で、フラグメント群を見なしてみて、中心になっているフラグメントを探す。
  3. そのフラグメントタグフラグメント化して、関連するフラグメントタグづけていく。
作業手順はこれだけですが、これだけでは、実際にイメージすることは難しいと思いますので、これから、いっしょにどんなタグタグフラグメントが「ボトムアップ式のエッセンスタグ」となるのか、考えていきたいと思います。
  • 人によって判断基準が異なる分類、主観的な分類。
    • 上記の固有名詞を中心にした「トップダウン式のインデックスタグ」は誰が見ても同じ分類ができる客観的な分類ですよね。
    • 逆に、個々で判断が分かれる分類である、ということが「ボトムアップ式のエッセンスタグ」の一つの目安となるはずです。
これを言い換えた説明が、以下の作者様のコメントになるのだと思います。
#155 何のために「分類」するのか?
ではPiggydbにおける「分類」とは何なのか? それは一言で言えば、「ユーザー自身が学習するため」の分類です。本来分類という作業は機械的にできるものではありません。先程書いたように知的負荷の高い作業です。検索のためのタグ付けであれば、単純にキーワード検索でもいいということになってしまうかもしれませんが、本当の分類(classification)は、そのキーワードが情報に含まれるかどうかとは無関係です。よって、Piggydbではユーザー自身が考えてタグ付けすることが重要です。
以下に、私の考える「ボトムアップ式のエッセンスタグ」の具体的な例を順不同でどんどん紹介してみます。
  • 「こんなに暗い設定なのに何故か笑える、こんなドラマ、阿部サダヲじゃなきゃムリ!」
    • 凄く面白かったドラマに関する感想を書いたブログ記事があったとします。
    • そして、何作か違うタイトルなのに同じような感想のブログ記事を書いたことに気付きます。
    • その時に、一番分かりやすい(とか一番最初に書いた等)ブログ記事のタイトルをタグフラグメント化します。
    • そして、似た感想を持ったブログ記事を、作成したタグフラグメントタグ付けしていきます。
    • (※ブログ記事=フラグメント
    • 単純に阿部サダヲが出演したドラマに関するフラグメント全てにタグを付ける訳ではないです。
    • あなたが自身が実際に見て、そう感じたドラマについて語ったフラグメントにのみこのタグを付けます。
    • 逆に、例え阿部サダヲが出演していないドラマでも、同じような雰囲気を感じれば、このタグを付けます。
    • そうなった場合、タグの名前をリネームすることもあります。
    • リネームを繰り返し、自分のもやもやっとした感想が一つの言葉として整理され時こそ、記念すべき新たな概念の誕生の瞬間です。
  • 喜怒哀楽タグ、感情タグ
    • どんな気分になりたい時に読み返したいのか、を意識してタグを付けていきます。
    • 落ち込んでいるから笑いたいなぁ、という時のために「笑」。今日は泣きたい気分だ、というときに「哀」。
    • もちろん、自分のグチをつらねた「怒」タグなど、フラグメント記入時の感情をタグにしてもOKです。
以下にライフハックに関する「ボトムアップ式のエッセンスタグ」を列挙してみます。
  • 「楽しくなくちゃ続かない」
  • 「シンプルイズベスト」
  • 「コストパフォーマンスは重要。高い商品は気軽に消費出来ないから逆効果」
  • 「オレの好み」
  • 「いつか試してみたい」
上記の例が、利用者のフォーカスを表すためのタグということになると思います。利用者の考えから分類したタグですね。
そして、情報収集の中心となっているフラグメントというのが、例えば
というネット記事を(mhtファイルで)保存したフラグメントです。このネット記事を読んでから、ユビキタス・キャプチャーという考えを知り、その後しばらく、このフラグメントからつながりをつくる形でどんどんとユビキタス・キャプチャーに関するフラグメントを作成していきました。そして、2~3日後、これは一つのタグで分類するべき考え方だぞ、と感じたので、全ての起点となったネット記事を保存したフラグメントをそのままタグフラグメントとして使用することにしました。
では、ここで何故、固有名詞として、「ユビキタス・キャプチャー」というタグを作らなかったかについて説明します。
  • ユビキタス・キャプチャーの他にもライフログやMoleskineなど、別の固有名詞が含まれているから。
  • 正式なユビキタス・キャプチャーの方法論ではなく、自己流にアレンジされているから。
ということで、
  1. まず、 「全てを手帳に記録する」、ユビキタス・キャプチャーの実践 | Lifehacking.jp]というフラグメントタグフラグメント
  2. タイトルが長すぎるので、「全てを手帳に記録する」、ユビキタス・キャプチャーの実践」にリネーム
  3. インデックスタグとしてに「ユビキタス・キャプチャー」、「ライフログ」、「Moleskine」という固有名詞タグを作成。
    1. 3つの固有名詞タグのそれぞれの子タグとして、「全てを手帳に記録する」、ユビキタス・キャプチャーの実践」を登録
    2. ここを親タグor子タグとして登録する、そもそも登録しない、はケースバイケースです。
  4. 自分の中で考え方が消化できてきたので、タグの名前を「書いて忘れる」にリネームする。
  5. 以後、「書いて忘れる」為のコツ、などに関するフラグメント全てに、このタグを付けていく。
以上、「ボトムアップ式のエッセンスタグ」についての概要と具体例でした。

いささか、長文になってしまいました。ここまで読んで頂きまして、どうもありがとうございます。いずれまたPiggydbを使い込んで頭が整理されてきたら、もっと短く要点を絞った説明ができるようになると思います。その時には、適切で説明しやすい具体例も見つかっていることだと思います。今の段階では、この助長な説明文でどうぞお許し下さい。この説明が、あなたの素敵なPiggydbライフの手助けになれば幸いです。

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

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

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

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

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

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

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

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

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

#742 Piggydb 6.11 リリース - 「インクリメンタル・キーワード検索」 では、現在選択しているフラグメントを表示したまま、検索することが出来るので、つながりやタグ、特につながりを作るのが、今までよりもとても手軽に行えるようになっていますね。
この時に#668 Piggydb 6.8 リリース - 「スマートレイアウトの改良」 を活用するとより便利ですね。画面を縦に3分割(されないときは、ブラウザの文字サイズを縮小すると3分割されます)すると、更につながりを付けやすくなります。
#784 Piggydb 6.12 リリース - 「IDによるピンポイント検索」 では、ウェブブラウザのタブ機能で多くのページを開いているときに、違うタブで開いているフラグメント同士でつながりやタグ、特につながりを作りたいときに、非常に便利です。
この3つの更新は、フラグメントのつながりによる構造化、を基本にPiggydbを使っていくときの大きな助けになりますね! 改めて素晴らしい機能の追加、本当にどうもありがとうございます。