Piggydbを使いこなす

ここではPiggydbの仕組みをより有効に活用するためにはどうすれば良いかということについて考えます。現状では確立しているノウハウと呼べるものはまだありません。以下に挙げられている指針はあくまでも提案レベルのもので、ユーザーさんからのツッコミによって議論が展開しているものもあります。よいアイデアがあれば是非こちらまで(#2)。

固有名詞をタグに使う

Chaos Piggydbで取り上げた「超」整理法という本に、「分類の単位として固有名詞を用いるべき」だという指摘があるのですが、これはPiggydbを利用する際にも有効な手法だと思います。
同じようなテーマを共有するフラグメント登録していると、それらのフラグメントに対して、くり返し同じ組み合わせのタグを付けていたりする事がよくあると思います。こういった場合は、それらのタグを統合するような固有名詞があれば、そちらをタグにしておいた方が後々の変更に強くなります。
通常はタグとして抽象名詞や形容詞などを利用する場合が多いと思います。このようなタグはその時の主観的な判断によって選択されるので(例えば重要性に関することやジャンルなど)、知識が成長すると共に認識が改まり、変更が必要になる可能性が高くなります。しかし、固有名詞ではそういった心配をする必要がありません(固有名詞の呼称が変わったとしてもタグのリネームは容易です)。
Piggydbではタグに対してもタグ付けできるので、固有名詞を分類のクッションとして利用することができます。例えば、複数のフラグメントに固有名詞でないタグを付けていて、それらの分類に対する認識が変わった場合、該当するフラグメント全てに対して修正を施さなければならなくなります。しかし、フラグメントに固有名詞タグを付けている場合、その固有名詞タグに対する分類を修正するだけで済みます。
ちょっと分かりづらいと思うので、具体的な例で説明してみます。
Chaos Piggydbでは書籍の内容を引用したデータベースを作っていますが、これらのフラグメントには基本的に書籍の名前のタグが付いています。そして具体的な内容についての分類はこの書籍名タグに対して行っています。実は個人的に作っているプライベートのPiggydbでは、当初直接フラグメントに内容を表すタグを付けるようにしていました。しかし同じ書籍から引用される内容は当然のことながら、同じようなテーマに沿ったものが多く、同じ組み合わせのタグがくり返し現れます。もし、この組み合わせに一つタグを追加したくなった場合、該当する全てのフラグメントを見ながら、タグを追加していく必要があります。Piggydbではフラグメント一括処理が比較的簡単にできるので、数が少なければそれほど大変な作業ではないと思うのですが、書籍名をタグにしていれば、そのタグに対してタグを追加するだけで済みます。

→ ...

この記事を読んで私も「超」整理法、買って読みました。16年前の本で、PCを中心に書かれている第二章は流石に古さを感じさせますが、それ以外の部分は非常に示唆に富む内容で大いに刺激を受けました(この本読んだ後、まず会社の机・キャビネットに溜まっていた資料と名刺をどっさり捨てました)。ただ、固有名詞を分類の単位として用いるということについての直接の言及先は梅棹忠夫著の「知的生産の技術」だったんですね。ちょっと早とちり。

→ ...

フラグメント登録数も多くなり最近感じたことは、タグを介してのフラグメント同士の結びつきは、 疎密度でいいのではないだろうかということです。 タグの機能は、少しでも関連のあるフラグメントを引き出せる糸。 ある主題を前提にフラグメントを関連付けるのは、新たな作業と思っています。 私の場合、ファイリングツールとしての使い方が主なため、必要なときに関連資料も含めて 引き出せることが主眼で使っております。 フラグメントに一つ一つ意味を持たせていると、フラグメント登録自体がやっかいなことになり いつまでたっても肝心のフラグメントが蓄積されず中途半端な状態になってしまう、というのが 私なりの印象です。 Piggydbの意図するところとずれているかもしれません。勝手な使い方をしております。

キーワードとタグを混同しない

タグを付けるときに、何も考えずに、タイトルや本文中にあるキーワードを利用するというのはあまり有効ではありません。これらのキーワードはタグにせずとも全文検索の対象となりますし、キーワードが必ずしもそのフラグメントの(本質的な)内容を表現しているとは限りません。
まずタグは思ったほど必要にならないと考えた方が良いかもしれません。まずはつながりのネットワークだけを作っていき、ネットワークあるいはツリーが複数出来上がってきた頃に、それらに共通する概念を発見したらそれをタグにします。このような「発見」に基づくタグは比較的有益です。

→ ...

タグが削除されて更新されていたのですね。了解しました。
#237と関連して少し感じていることを書かせていただきます。
つながりとタグの2つの機能が別々に与えられていることについては、最初は戸惑いましたが、広い意味での関連性を2つの視点で与えられるので、より強い関連性がつながりで、そうでない緩やかな枠組みがタグでというように使い分けできて重宝しています。
全文検索でもピックアップ可能ですが、検索しなくともそこにキーワードとしてタグが見えているというのは個人的にはとても安心できる材料となっています。そういう意味でいうと、タグを多用するかどうかは多少のノイズは許容しても目で見える範囲に置きたいか、そうでないかというポリシーの違いのように感じます。
個人のPiggydbならタグを余計につけても、このタグは機能していないなと思えば後で削除すればどんどん消すなり別のタグを付け直すなりできるので気楽ですが、やはりマルチユーザだと一定のルールというかポリシーに沿ったタグ付けが必要なのはよく理解できました。

タグとつながりの使い分け

後でいくらでも整理できるので、とにかく最初はどんどんタグ付けしていく、というのは実は私も当初考えていまして、ブログにもそのように書いた記憶があります。ですので、整理することによってタグがうまく機能している限りは全く問題ないと思います。
しかし、私の場合はそれでタグ管理が破綻してしまったという経験がありまして、それ以降は慎重にタグ付けするようになったという経緯があります。
「必ずタグを付ける」理由として、「その情報が取り出せるという安心感」を得るためだということですが、情報へのアクセスを保つためには、タグだけではなくて、つながりを作ってネットワークを維持する方法もあります。例えば、EBtはそのように活用されていますよね?
「理解の助け」となるタグと「情報が取り出せるという安心感」を与えるタグ、というのは微妙に両立しない領域があると感じていまして、それがタグとつながりの使い分けに繋がるのではないかと漠然と考えています。後者はできるだけつながりで実現した方が良いという考え方ですね。私が「キーワード」という言葉で表現したかったのは、その辺のニュアンスだろうと事後的に考えたりしています。
ただし、「情報が取り出せるという安心感」を与えるタグが有効な例があって、それが固有名詞です(#182)。これは対象となる情報の意味を表すわけではないですけど、インデックスとしてはとてもうまく機能します。
こうやって書くと、タグとつながりの使い分けってかなり敷居の高いものだという印象を与えかねませんよね。この敷居を越えるだけの価値があるとは思っているのですが、、、
この問題はもっと時間をかけないと分からない部分も多いかもしれません。データの量とか、種類、目的、利用環境など、いろいろな要因があります。例えば、Piggydb.jpの場合は文脈を知らない閲覧者についてもある程度考慮する必要が出てきます。

直交するコンセプトを明示できるのがタグのいいところ? → ...

「必ずタグを付ける」理由として、「その情報が取り出せるという安心感」を得るためだということですが、情報へのアクセスを保つためには、タグだけではなくて、つながりを作ってネットワークを維持する方法もあります。例えば、EBtはそのように活用されていますよね?
Piggydb でも EBt でも、つながりが最も重要と思います。
ただ、例えば A→B→C→D→E→F というようなつながりがあり、A・C・E のグループと B・D・F というグループについて、先のつながりとは直交したコンセプトがあれば、A→C, A→E, C→E というようなつながりを個別に作っていくよりは、A・C・E について X、B・D・F について Y というようなタグを立てた方が作業が簡便で、かつ、それぞれのグループの意味付けをタグ名称で明確に意識できるところがいいと思います。グルーピングし直しのコストが低いところも魅力です。もちろん、例えば A→E に強い関連性があれば、それはつながりをつければいいのですが。
EBt ではタグに相当する機能はないので、上記の例であれば、まず A⇔B⇔C⇔D⇔E⇔F という関係(EBt は双方向つながりなので)で 5 つのメモを作って、X、Y というノード(タイトルだけの空メモ)を別に作り、X には A・C・E それぞれと、Y には B・D・F それぞれとのつながりを作ります。
Piggydb でも、主にドキュメントビューでの利用を想定して、タイトルだけのフラグメントを作り、それに対して複数のフラグメントを並べていく場合がありますよね。あれと同じでしょうか。ドキュメントビューで使わないならわざわざそうしなくてもタグをつけた方がスマートなような気がします。

つながりとタグの使い分け例: 「Table Tennis Videos」

Piggydbのデモサイト「Table Tennis Videos」は、つながりとタグの使い分けが比較的うまくいっている例として挙げられるのはないかと思います。
このデモサイトは、卓球のYouTube動画を集めたデータベースとなっていて、一つのフラグメントが一つの試合、あるいは一つの動画に対応しています。
このサイトでつながりをどのように活用しているかと言うと、一つの大会に関係する動画をまとめるのに利用しています。例えば、以下のフラグメントは去年横浜で開催された世界選手権大会に対応するものですが、そこからつながるフラグメントとして、大会全体を総括する動画や、男子シングルス、女子シングルスをまとめるフラグメントがあります。
このようにつながりによって階層化された構造を追っていくと、大会全体の構造を効率良く把握することができて、目的の動画を見つけやすくなります。
それではタグはどのように利用されているか。上のリンクからフラグメントを見れば大体分かりますが、ひとつの試合に貼り付けられているタグとして、開催年、選手名、大会の種類、開催地などがあります。これらはおそらくタグの利用方法としては納得しやすいのではないかと思います。これらのタグはつながりでまとめられた「大会」という単位を越えて適用されるものです。
比較的分かりやすい例なので、このデモサイトにおけるつながりとタグの使い分けについてはなんとなくイメージを掴んで頂けたのではないかと思います。
しかし、Piggydbにおいてさらにハードルが高いのは階層タグの使い方です。デモサイトのタグツリーを見るとどうなっているでしょうか。
ツリーのルートにはいろいろなタグがありますが、主なものとして、「協会(association)」、「国(country)」、「大会(event)」、「場所(place)」、「選手(player)」、「スタイル(style)」、「年(year)」という抽象的な概念を表すタグがあります。これらのタグは直接フラグメントには貼り付けられておらず、他のタグを修飾するのに利用されています。
このサイトで最も重要だと思われるタグは選手の名前を表すタグですが、このタグはツリーのどの部分にあるでしょうか。すぐに分かると思いますが、「選手」タグの下を見てみると、「男子(men)」、「女子(women)」というタグがあり、それぞれの下に男子、女子選手を表すタグを見つけることができます。
しかしこれだけではありません。「協会」タグの下を見てみると、各国の卓球協会を表すタグがずらずらとあり、その下を見ると、それらの協会に所属する選手名の一覧が現れます。これらのタグは先ほど「選手」タグから辿って発見したタグと同じものです。
経路は他にもあります。「スタイル」というタグから辿って、「ラケットのグリップ(grip)」を経由し、「ペンホルダー(penhold)」タグの下を見てみると、また選手の名前があります。
もうお分かりだと思いますが、階層タグでは上のように、一つのタグを複数のタグ(カテゴリー)で分類することができ、より抽象的なカテゴリーからより具体的なカテゴリーまで、いくつもの経路を辿って目的のカテゴリーに辿り着くことができます。さらにこのカテゴリーは推移的(より下のカテゴリーはより上位のカテゴリー全てに所属する)に適用されるので、例えば、「男子」タグをクリックすれば、男子選手の関係する全ての動画をリストアップすることができます。つまり、タグ階層のどの部分からでも自由にカテゴリーの広さを選択して、フラグメントを検索できるということです。
そして重要なのは、フラグメントに適用すべきタグは最も具体的なタグだけでOKだということです。ある選手のタグを試合フラグメントに貼り付ければ、そのフラグメントはその選手の所属国やスタイル、性別によっても同時に分類されることになります。
以上がデモサイトを例にしたつながりとタグの使い分け、階層タグの使い方の例です。この例では、どのようなタグが必要になるか、つながりをどのように利用すればよいか、サイトを構築する前からなんとなくイメージは出来ていました。それは私自身が卓球に詳しいということもありますし、大体誰でもイメージできる常識的な知識の構造だったということもあります。知識の構築プロセスとしては、どちらかと言えば、トップダウンだったわけです。
しかし、トップダウンで作った知識は構造がかっちりとしすぎて、なんとなく面白くありません。卓球動画サイトのように実用向けだとこれでいいとは思うのですが、もっと無秩序から秩序を構成する形に持って行きたいところです。マインドマップについて書いた記事(#261)で、Piggydbは「どちらかと言えば、ボトムアップ式の方法にフォーカスしていきたい」と書きましたが、これもデモで実演できたらいいなと考えています。おそらく近々立ち上げる「Piggydb研究サイト」は、そのような形で構築していくのではないかと思います。

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

これは非常に便利ですね、さっそく#centralimageにリネームさせて頂きました。
タグのリネーム機能、便利です! それと親子タグへの移動も手軽ですし、タグ周りの充実ぶりはピカイチですね!)
この機能があるのであれば、タグの継承周りは、現状維持でも良さそうですね。
特に、固有名詞のインデックスタグなどは、継承してもらえると非常に楽にフラグメントを作れますから。

マルチユーザーでのタグ管理

自分が作成したフラグメントの一覧は、右上に表示されているユーザー名をクリックすれば見れますよ。guestのものについては「magician」というタグを使って一覧するしかないですが。
他の訪問者の方が混乱しないよう、magicianというタグをpersonタグの下に、その他、magicianさんが独自に利用されているタグをmagicianタグの下に、という形で設定しておきました。何か新しいタグを試すときは、同様にmagicianタグの下に作ってから試すようにしてみて下さい。トップレベルから隠れるので、混乱の元になるのを避けられると思います。

タグの整理、どうもありがとうございます。
実は私自身、ずっと気になっていまして
magicianの親タグにUserタグをつけた方がよいだろうか、
でも、あまり勝手に親子タグまで増やすのはどうだろうかと、悩んでいたのです。
#centralimageタグも、できれば最初から実際にフラグメントタグ付けすれば分かりやすかったのでしょうが、
勝手にタグを増やすことに抵抗感がありまして。
管理人様の方で整理して頂き、スッキリしました。どうもありがとうございます。
今後、どうしても必要だと感じたタグはmagicianの下で試させて頂きたいと思います。
今後ともどうぞよろしく御願いします。

タクソノミーの呪縛から逃れる

私の説明はいささか抽象的な感じだったので、このような具体的な例に展開して頂けるのは有難いです。
「インデックスタグ」、「エッセンスタグ」という表現は面白いですね。この話をもうちょっと展開するとすれば、タグを付けるときに、より大勢の人が理解できるような分類体系を採用するか、データベースの文脈に沿った体系を採用するか、ということになるんじゃないかと思います。
いわゆる「フォークソノミー」は、大量の情報を共有しながら分類するので、前者の分類体系になるわけですが、Piggydbでは多くの場合、個人でデータベースを管理することになるので、他人に分かりやすい「インデックスタグ」にこだわる必要はありません。ただ、従来のタギングに慣れていると意識せずに「インデックスタグ」を作ってしまうのではないかと思います。なので「エッセンスタグ」に移行するためには、意識的に使い方を変えていく必要があります。
個人的には、「インデックスタグ」を追求すると、タクソノミー(taxonomy)の分野に足を踏み入れてしまうので、これは結構不毛なことではないかと考えたりしています。タクソノミーと言えば、海外のユーザーさんにNASAの開発したタクソノミーを紹介してもらったことがあります。
Piggydbから提案したいのは、こういった万能の分類体系にこだわらず、「エッセンスタグ」で自分の問題にフォーカスした方がよい、ということです。
「エッセンスタグ」で重要なことを一つあげるとすれば、それはタグ名が必ずしも名詞である必要はなくて、まだ学習が足らずに「もやもや」の状態のときは、一つの「命題」がタグになり得るということです。その命題について情報を集めていく過程で、適切なキーワードを発見したり、あるいは発明したりできるかもしれないし、派生的なコンセプトを発見できるかもしれない。そのときに、いかに借り物のコンセプトを持ち込まないようにするか、というのがポイントで、これはできるだけ沢山の情報を集めてつながりを作る、ということにかかってくるのではないかと思います。

手書きのイメージをタグにできるPiggydbは凄いアイデアツールですね

私の説明はいささか抽象的な感じだったので、このような具体的な例に展開して頂けるのは有難いです。
日頃本当にお世話になっているPiggydbとその作者様へ、少しでも恩返しが出来たようで嬉しい限りです。
「インデックスタグ」、「エッセンスタグ」という表現は面白いですね。この話をもうちょっと展開するとすれば、タグを付けるときに、より大勢の人が理解できるような分類体系を採用するか、データベースの文脈に沿った体系を採用するか、ということになるんじゃないかと思います。
両者の使い分けについては、作者様のご指摘の通りだと私も思います。また、「インデックスタグ」、「エッセンスタグ」という考え方は、#394「 "タグ"は"エッセンス"を括ったもの」ぐらいから形になってきたのですが、それから約一ヶ月、試行錯誤と実践を経て、大分、考え方が整理されてきました。
タクソノミーの呪縛から逃れつつ、「インデックスタグ」を活用するためのコツは、一般的な固有名詞のみで親子タグを構成していく事かなと思います。もしくは、全文検索を信じて、「インデックスタグ」は基本的に使わないという割り切った考え方も有りだと思います。
Piggydbから提案したいのは、こういった万能の分類体系にこだわらず、「エッセンスタグ」で自分の問題にフォーカスした方がよい、ということです。
私もその意見に賛成です。「インデックスタグ」は丁寧に構築された場合でも、情報の検索性の向上にしかつながりません。しかし、「エッセンスタグ」を上手く積み重ねることが出来れば、素晴らしいアイデアの創造や、真の意味での情報の理解、知識の獲得につながっていくと思います。また、情報の検索性という意味でも、いわゆるQ&A系サイト(人力検索はてなやOKWave等)に近い(キーワード検索と質問文の中間ぐらいかな)有機的な情報の探し方が可能になっていくと思われます。
「エッセンスタグ」で重要なことを一つあげるとすれば、それはタグ名が必ずしも名詞である必要はなくて、まだ学習が足らずに「もやもや」の状態のときは、一つの「命題」がタグになり得るということです。
なるほど、「命題」ですか! これは的確な表現ですね。ちなみに、「命題」の状態の時は、その「タグ名」が上手く浮かばない状態のことが多いと思われます。その代わりに「もやもや」としたイメージがいくつかある。そういうときこそ「タグフラグメント」の出番ですね!
適切な名詞が浮かばない状態でもタグを作ることができる「タグフラグメント」はやっぱり素晴らしい発明ですね!
その命題について情報を集めていく過程で、適切なキーワードを発見したり、あるいは発明したりできるかもしれないし、派生的なコンセプトを発見できるかもしれない。そのときに、いかに借り物のコンセプトを持ち込まないようにするか、というのがポイントで、これはできるだけ沢山の情報を集めてつながりを作る、ということにかかってくるのではないかと思います。
借り物のコンセプトを持ち込まないようにする」、これは確かに重要なポイントですね。その為には、タグフラグメントの名前に、「これはいったいどんな意味?」といった質問文や、シンプルに「命題A」など、「不必要な先入観を持たない仮タグ」を活用していくのも一つのコツではないかと思います。
そして、とにかく直感的にフラグメント貯めていって、既存のタグ分類を飛び越えた自由な「つながり」をたくさん作っていく。たくさんの情報が集まれば、そこから共通点を見いだしたりしてくことで、適切なキーワードが閃いたり、新たな概念を理解することができるようになるでしょう。
「エッセンスタグ」と「タグフラグメント」はまさに相性抜群! このコンビが生み出す創造力を活用していくのは本当に楽しい限りです。作者様、Piggydbをどんどん楽しく進化させて下さって、本当にありがとうございます!!

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

なんとか正式版の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の図にある「共通のフラグメントとつながりでつなげる」をイメージすると良いのかなと、漠然と思っています。つまり共通のフラグメントがゆるやかなグルーピングのタグのような役割をするわけです。情報の入力はタグに比べて少し煩雑になりますが、後々にタグフラグメントなどと混ざって混乱することが無くなる方が有益ではないかなと。

オフラインブログから知的生産ツールまで、変幻自在のPiggydbを逆引きしてみた

Piggydbを使って早一ヶ月が過ぎ、だいぶ自分なりのPiggydbの使い方が見えてきました。そして、気付いたこと、いや驚かされたことは、Piggydbの多彩な可能性の数々です。そこで、Piggydbを様々な方に興味を持って頂けるように、Piggydbの機能から何が出来るのかではなくて、他のサービス、ツールをPiggydbで再現することはできないかを検証してみました。特に一般的にはオンライン専用のサービスを完全オフラインのツールとして利用したいと思っている方の助けとなれるように考えてみました。逆に言えば、目的に合わせてどうPiggydbを活用していくかという事を逆引きでまとめてみる、ということになります。
ユーザ層にあわせ,ポータルの使い方を案内するフラグメントを作る。
書籍風の見出しフラグメントを追加。
初期ユーザ向けに,ステップバイステップのPDFマニュアルと画面及び用語解説ページ。
これらをドキュメントビューから作成したPDF及び配布向けページ。
ただ、現状の方向性としては、手取り足取りのドキュメント作成、ケニーさんが仰る、いわゆるPDFのような普通のドキュメントの作成についてのプライオリティはそれほど高くありません。
というのも、色々な人にPiggydbについて説明してきて、「Piggydbとは~のようなものである」という説明をしてもあんまり意味がないと気が付いてきたからです。
Piggydbはかなり汎用的なソフトウェアですので、その操作方法やコンセプトを説明しても、「で?」という反応になりがちです。
なんと言いますか、Piggydbは従来のソフトウェアの代替を意図して作られたものではないので、余計に「仕組み」だけを説明しても意味がないんですね。
今回の一連のフラグメント群が、作者様の意図とは少々ずれているのは、承知の上です。それでもPiggydbユーザーの増加を願って、逆引きさせて頂きます。どうぞお許し下さい。

「親子タグが使えるオフラインブログソフト」としてのPiggydb

  • タグは日本語でも自動補完されるので入力も簡単です。
    • #162 2. インプットボックスにはタグ名の補完機能が備わっている
  • タグクラウドビュー、タグツリービュー、タグフラットビュー。お好みで使い分けられる3つのタグビューが用意されています。
    • #536 Piggydb 5.0-dev5 リリース - 「タグパレットにクラウド・ビュー」
  • テキストと一緒に画像も自由に張れます。画像のサイズは最適化されて表示され、原寸大を別ウィンドウで開くことも可能です。
  • YouTubeのビデオプレイヤーを埋め込むことも可能です。
    • #377 知識創造ソフトウェア: Frieve Editor, iroha Note
  • テーブルを使うことで画像やテキストを自在に配置することができます。
    • #49 テキスト整形のヘルプ
    • #64 埋め込みは何重にも入れ子にすることができます
  • ブログ内検索も可能。全文検索機能は軽快で高性能です。
    • #38 全文検索
  • 最新の記事からチェック、古い記事から順番に読む。作成日時、更新日時をそれぞれ、昇順、降順で並び替え可能です。
  • カレンダー機能も搭載。日ごと、月ごとの記事を手軽に一覧表示することが可能です。
    • #59 カレンダー
    • #298 Piggydb 4.14 リリース - 「フラグメント・リストビューにソート機能を追加」
  • スタンドアロン・パッケージなら、誰でも簡単にインストールして、気軽に使い始めることができます。
    • #246 スタンドアロン・パッケージ
  • 他の人に中身が見られないように、パスワードで保護することも可能です。
    • #18 ログイン画面
  • 逆に、他の人でも閲覧は可能で、編集は不可能というモードも。ユーザー登録でコメントを残すことも可能です。
  • 1クリックでAll-in-Oneバックアップ。アーカイブファイルを解凍して、埋め込んだファイルとXMLファイルを、自分の目で確認できます。
    • #48 エクスポート/データベース復元(リストア)
  • Firefox Add-onの「Stylish」を使うことで、カラーカスタマイズも自由自在。お好みのテーマカラーでPiggydbをご使用頂けます。
    • #369 見た目のカスタマイズについて
    • #546 ブラック&オレンジがテーマのPiggydb用Stylish
  • Firefox Add-onとの連携で、入力中のテキスト保護や自動保存も可能。お好みのテキストエディタで本文を入力することだってOKです。
    • #443 テキストエリアの自動バックアップ

「完全オフラインの個人用Wiki」としてのPiggydb

  • まずは、以下の2つのページを参考にして下さい。その上で足りない情報をこの記事で補足説明していきます。
    • #556 「親子タグが使えるオフラインブログソフト」としてのPiggydb
    • #170 Piggydbと類似ソフトウェアの比較
  • 更にタグのページに本文とそれで分類されている記事の両方を表示できます。
  • 外部リンクはもちろん、Piggydb内の記事を関連付けてリンクすることが出来ます。
  • 関連する記事を複数のタグで絞り込んでいくこともできます。
  • 登録した情報をまとめて見る場合に便利な文章を作成できます。また、この文章は印刷にも適しています。
    • #32 出来上がった知識を眺める「ドキュメント・ビュー」
    • #121 ドキュメント・ビューのサンプル

Piggydbは「疑似マインドマップ」から「知的生産ツール」へ

  • まず前提として、Piggydbはテキストベースのソフトですから、マインドマップをビジュアル表示出来るわけではありません。
    • ですので、本家のマインドマップを作成したり、読んだりした経験のある方でないと、Piggydbを「疑似マインドマップ」として使うことは難しいと思います。
  1. セントラルイメージを新しいフラグメントとして作成します。もちろん、画像をセントラルイメージとして使うことも可能です。
    1. #8 情報を登録してみる
    2. #46 フラグメント登録
    3. #50 ファイルフラグメント登録
    4. #51 画像フラグメントの表示
  2. つながりのあるフラグメントを作り、タイトルにメインブランチの単語を記入します。
    1. #71 つながりのあるフラグメントをつくる
    2. #129 「つながり」をつくる方法
  3. 本文に文章を書くことでBuzan's iMindMapでいう「ノート」機能を再現することが出来ます。
  4. 後は、セントラルイメージやメインブランチからつながりのあるフラグメントを作る行程を繰り返せばOKです。
  5. 自由にフラグメントをツリー状に構成することが可能です。また、フラグメントの並び替えも簡単です。
    1. #66 フラグメント・ツリービュー
以上です。脳内でマインドマップをイメージすることが出来る人にとっては充分に有効な使い方だと思います。
とはいえ、やはり本家マインドマップの使い勝手には及ばないというのが正直なところです。ですが、この使い方をあえて紹介したことには理由があります。それは、「疑似マインドマップ」としてPiggydbを運用することで、「知的生産ツール」というPiggydb本来の目的を果たすための鍵となる機能「つながり」を分かりやすくイメージすることができるようになると感じたからです。
Piggydbは、いろいろな情報を入力しつつ、それらを「つながり」や「タグ」によって柔軟に整理することができる、情報管理システムです。Piggydbという名前から想像できるように、ある程度形式が定まったデータベースとして利用される方が圧倒的に多いようです。
しかし、このデータベース的用途とは異なる、Piggydbの真の目的があります。それは、あらゆる角度でつながりを作ることによって、発想を刺激し、新しいアイデアの発見を促す、より創造的なツールになることです。
Piggydbを自由自在に操って、画期的なアイデアを閃かせたり、既存の情報から新しい概念を発見したりする。そういうことに興味を持ってワクワクする方がいらっしゃいましたら、ぜひ一度Piggydbをお試し下さい。その際に、もし始め方の検討が付かないようであれば、「疑似マインドマップ」の作成からスタートしてみることをオススメします。

「ドラマの台本」や「ノベルゲームのシナリオ」をPiggydbで作成する → ...

  1. 新しいフラグメントを作成し、タイトルに「シナリオの名前」、本文に「あらすじやテーマ、出演者など」を書く。
  2. そこからつながりのあるフラグメントを作成(子フラグメント)し、「柱」(どこで、いつ)を作成します。
    1. タイトルに、シーン番号と「どこで、いつ」の描写を盛り込んで、本文は空白にしておきます。
  3. そこから、「柱」フラグメントからつながりのあるフラグメント(子フラグメント、シナリオの名前フラグメントから見て孫フラグメント)を並列で並べていきます。
    1. ト書(誰が、なにをしている)、セリフ(何を話している)を順番に並べていくのです。
    2. ここで、ト書きはタイトルを「ト書」、本文に「誰が、なにをしている」の描写を書いていきます。
    3. セリフはタイトルに「役名」を書き、本文に「セリフの本文」を書いていきます。
  4. これをシーンごと(柱)ごとに繰り返していきます。
以下に具体例を紹介します。

フラグメント [サンプルシナリオ] 本文:[あらすじ]
...子フラグメント タイトル:[1 さかのうろん・店内(夜)] 本文:[空白]
......孫フラグメント タイトル:[ト書] 本文:[薄暗い店内に、一人だけ残っている建造。]
......孫フラグメント タイトル:[ト書] 本文:[赤手拭を置いたテーブルで、ぼーっと酒を飲んでいる。]
...子フラグメント タイトル:[2 橋] 本文:[空白]
......孫フラグメント タイトル:[ト書] 本文:[渡っていくスクールバス。]
...子フラグメント タイトル:[3 百道・ウォーターフロント] 本文:[空白]
......孫フラグメント タイトル:[ト書] 本文:[幾何学的なデザインの超近代的な住居群。]
......孫フラグメント タイトル:[ト書] 本文:[マンションを見上げている晶江、ケイコ、建造。]
......孫フラグメント タイトル:[ト書] 本文:[興味なく橋を向いている一件。]
......孫フラグメント タイトル:[ケイコ] 本文:「ここ? いいじゃない」
......孫フラグメント タイトル:[建造] 本文:「冗談やなかぞ。こげんピカピカしたとこに住めッか。ここは山の通らん! 第一、こげなとこでうどん屋のできるとか」
......孫フラグメント タイトル:[ケイコ] 本文:「カズちゃん、どないする?」
......孫フラグメント タイトル:[一件] 本文:「……(ソッポ向いている)」
......孫フラグメント タイトル:[ケイコ] 本文:「なァ、どないする?」
ラジオドラマ脚本の書き方/日本放送作家協会九州支部より、サンプルシナリオを引用させて頂きました。
 ----
この手法の一番便利な点は、ズバリ、各シーンやセリフの並び替えが楽だということです。また、要らないと思ったシーンも、後で必要だと思えば、すぐにゴミ箱から戻す事が出来ます。
また、親フラグメントの本文に画像を表示させることもできるので、ノベルゲームのシナリオ作りにも役立つでしょう。その場合は、画像ごとにシーン番号を付け、画像フラグメントを親フラグメント、地の文、台詞を子フラグメントとする二層構造にすると、画像を見ながらセリフを書いたり、並び替えたりすることが出来るので、便利だと思われます。

フラグメント [1 さかのうろん・店内(夜)] 本文:[酒場の画像]
...子フラグメント タイトル:[地の文] 本文:[薄暗い店内で、建造が、一人だけ残っている。]
...子フラグメント タイトル:[地の文] 本文:[赤手拭を置いたテーブルで、ぼーっと酒を飲んでいる。]
フラグメント タイトル:[2 橋] 本文:[画像、夜の橋とスクールバスの画像]
...子フラグメント タイトル:[地の文] 本文:[夜の橋をスクールバスが渡っていく。]
フラグメント タイトル:[3 百道・ウォーターフロント] 本文:[マンションの画像]
...子フラグメント タイトル:[ケイコ] 本文:「ここ? いいじゃない」  
...子フラグメント タイトル:[建造] 本文:「冗談やなかぞ。こげんピカピカしたとこに住めッか。ここは山の通らん! 第一、こげなとこでうどん屋のできるとか」
...子フラグメント タイトル:[ケイコ] 本文:「カズちゃん、どないする?」
...子フラグメント タイトル:[一件] 本文:「……(ソッポ向いている)」
...子フラグメント タイトル:[ケイコ] 本文:「なァ、どないする?」
※上記のサンプルをノベルゲーム風に少しアレンジさせてもらいました。

この場合、画像のついた親フラグメント群に共通の親フラグメントを作成すると、シーンごとの順番を並べ替えることも簡単に出来るようになります。
また、各フラグメントごとに、タグを付けることが出来るので、役者の名前でタグを作ってまとめたり、名言にタグを付けて一覧にしたり、そういういろいろな「遊び」ができるのも、Piggydbの魅力の一つです。
最後になりますが、何故、Piggydbがこのような便利な使い方が出来るのかと言いますと、Piggydbでは「フラグメント」という小さい単位が基準になっているからです。
Piggydbの「フラグメント」にはこの記事のような長文(Pomera DM20の1ファイルあたりの文字数の上限、全角約28,000文字をコピーしても問題なく動作しました)からセリフ一行の短文まで、幅広く使いこなすことができる柔軟な単位です。
つながりやタグ付けのことを考えたらできるだけ、「フラグメント」は短い文章で区切っていった方が良いと私も思います。その一方で分かりやすいフォーマットや目次のない短すぎる区切りの「フラグメント」は、他の人が読むときに読みにくいものになります。自分専用のPiggydbは短く区切り、ネット上のPiggydbは長めにまとめる、そういう使い分けが「フラグメント」を使いこなす上でのコツなのかもしれません。

ツリー型で文章全体を一望できる「アウトラインプロセッサ」Piggydb


以下に、Piggydbをアウトラインプロセッサとして使用する際のTipsを紹介していきます。
  • フラグメントは更新順、作成順などの他に「タイトル順」にも並び替えることが出来ます。(昇順、降順も選べます)
    • タグで括っている場合は、D&Dでの並び替えは行えませんので、手動で数字を変化させて並び替えます。
    • #61 フラグメント・リストビュー
  • スライダーを操作することで、シーンNoのみの一覧から、タイトル一覧、文章全体の一望まで、文章の表示をコントロールできます。
    • #61 フラグメント・リストビュー
    • #286 Piggydb 4.13 リリース - 「新フラグメント・リストビューはスライダーでズームイン・ズームアウト」
    • #299 スライダーでズームイン・ズームアウト
  • ▼トグルボタンを利用すれば、任意のフラグメントのみを表示し、編集することも自由自在です。
    • 編集中でもブラウザのスクロールバーを上下させれば、前後の文章を確認しながら編集することができます。
    • #276 Piggydb 4.11 リリース - 「フラグメント・ツリービューでのコンテンツ表示トグル」
  • サイドバーのブックマークとフィルタを▼トグルボタンから折りたたむ。
    • タグパレットをサイドバー上部に表示させることができます。
    • #323 Piggydb 4.17 リリース - 「サイドバーにタグフィルタを追加」
  • Firefox Add-onと組み合わせれば、自分のお気に入りのテキストエディタを使うことができます。
    • #443 テキストエリアの自動バックアップ
  • できあがった文章を眺めたい場合や、印刷したい場合は、ドキュメント・ビューの利用が便利です。
    • #32 出来上がった知識を眺める「ドキュメント・ビュー」
    • #56 4. ドキュメントとして表示
    • #121 ドキュメント・ビューのサンプル
  • 画面右にツリーを表示させない、一体型のアウトラインプロセッサとして使うなら、普通のテキストフラグメントを使用してもOKです。
    • その場合は、タグではなく「つながり」で作ると、D&Dでフラグメントを並び替える事ができるようになります。
    • #559 「ドラマの台本」や「ノベルゲームのシナリオ」をPiggydbで作成する
  • タグを付けて、各シーンの状況を分かりやすく表示させることもできます。
    • [一人称],[二人称],[三人称],[主人公の視点],[副主人公の視点]
    • [コメディシーン],[シリアスシーン]
    • [A_伏線],[A_回収]
  • 各シーンごとの関連性や、各シーンの元ネタや閃いたアイデアのフラグメントへ「つながり」を作成する。
    • 伏線のシーンとその回収シーンを「つながり」で結ぶ。
    • 花火のシーンと、花火の写真やYouTubeのビデオプレイヤーの埋め込まれたフラグメント間に「つながり」を作る。

アウトラインプロセッサには、たくさんの種類があり、各利用者ごとにこだわりが強い種類のソフトウェア分野だと思います。Piggydbが専門のアウトラインプロセッサと相手の土台で勝負して勝てるかどうかは分かりません。それでも、各シーンごとにタグ付けをする事ができるということは、利用者の発想次第で専門のアウトラインプロセッサを超える可能性を秘めているということ、私はそう信じています。
また、画像やYouTube動画、PDFや各種メディアファイルなど、ファイル種類を選ばない資料と共に、情報をPiggydbに一元化できるというのは、素晴らしい強みだと思います。
創作活動に燃える方々、ぜひ一度Piggydbを使いこなして、素晴らしい作品を生み出してみませんか?

Evernoteをゆる~く快適に使い続けるためのたった一つのルール

たくさんのユーザーが様々に使いこなしいているEvernoteからPiggydb活用方法のヒントを盗むために、両者を併用して数日。両者の特徴を活かした使い分けのコツが見えてきました。

※この考え方は、PoICを参考にしています。PoICはEBtとも親和性の高いメソッドなので、Piggydbとの相性も良いと思います。

閑話休題。私がPiggydbを知った当初はPiggydbにデータを一元化しようと本気で考えていましたが、最近、バックアップのためのエクスポート作業に分単位で時間がかかるようになってきたので、少し考えを改めました。「保存して忘れる」レベルのニュースサイトやライフハック記事のクリップは、全てEvernoteに任せることにしました。(私はEvernoteのプレミアムユーザーです)。そして、Piggydbには「発見」を目的に、「記録」を残すことにしました。「参照」は厳選した情報のみをEvernoteを経由して持ってくることにしました。こうすることで、情報のインプットの手軽さと、Piggydbのスリム化を両立させることができるようになりました。
具体的な手法は以下の通りです。

Evernoteをゆる~く快適に使い続けるためのたった一つのルール。
まずは、Webクリップの為の準備を整えます。現在のEvernoteはFirefox Add-onからWebクリップするとCSSを無視して保存されてしまうので、下記の記事を参考にして1クリックでPDF保存できる環境を整えます。
時折、PDFで保存してもデザインが崩れて、一見、本文が読めなくなるように見えるケースもありますが、対処方法はあります。Adobe Acrobat Professional があれば、ツール→高度な編集→Touch UP オブジェクトツールで、邪魔なWebパーツを簡単にどかすことが出来ます。(フリーで対応しているソフトも探しましたが、すみません、ちょっと見つかりませんでした) しかし、とにもかくにも、PDFを保存する段階では何も気にすることはない! ということが素晴らしいポイントです。もし、後々に崩れたデザインで保存してしまったPDFがあることに気付いた場合でも、その時点で体験版をDLするなり、対応ソフトをもっている知人に頼んだり、と事後対応でスムーズに解決できます。
また、PDFに保存することで、簡単にPiggydbにデータをコピーすることができます。以前利用していたmhtよりも互換性が高く将来的な不安が少ないのもPDFで保存する際の利点です。
次に、ノートを準備します。
上記の記事を参考に、私は以下のようにアレンジしています。
ここまで準備できたら、自由にネットサーフィンをして、どんどんPDFを貯めていきます。気になったページは気軽に保存します。「保存して忘れる」ことで、常に脳をリラックスさせるのです。
そして、毎週1回、Inboxを空にします。「保存して忘れる」私の使い方では、ほとんどのPDFが「Inbox」から直接各「Archive」へ移動することになります。ここで、タグの登場です。
Evernoteにおける私のタグ構成は以下の通りです。
※「トップダウン式インデックスタグ」と「ボトムアップ式エッセンスタグ」は、サンプル用に抜粋しています。
「Inbox」から「Archive」へ記事を移動させるタイミングでタグ付けしていくワケですが、ざっとタイトルを流し読みして、「★★_もう一度見たい」以上の記事がなければ、何もタグ付けをせずに、範囲選択してジャンルだけ分けて、さっさと「Archive」へ収納してしまいます。
「★★_もう一度見たい」以上の記事だけ、タグ付けをしていきます。その際、「★★_もう一度見たい」以上のレベルの記事は、「トップダウン式インデックスタグ」から一番具体的な固有名詞を一つだけタグ付けすればOKです。「レーティングタグ」と合わせて、タグは最低限2つ付いていれば充分です。もちろん、すぐに思い浮かぶようならば、「ボトムアップ式エッセンスタグ」もつけていきますが、気負う必要はまったくありません。「ボトムアップ式エッセンスタグ」は思いついたときにつけるのが本来の使い方ですから。
※なぜ、Evernoteでも一番具体的な固有名詞を一つだけタグ付けでOKなのか。(Piggydbでは後述のように明確な理由があります)それは、固有名詞ならば簡単に脳内で補完できるからです。「東京Vユース」は「東京V」の「育成年代」であることは、階層タグで定義しなくても自然に理解できます。検索時もEvernoteの機能を活かし、工夫をすれば、一番具体的な固有名詞を一つだけタグ付けでも充分に目的の記事を見つけられるはずです。
「★_保存して忘れる」タグは実際には使用しません。利便性を考えて、他の「レーティングタグ」が付いていない記事が、「★_保存して忘れる」記事ということにしています。そして、更に簡単に使うために、上記の通り、「★_保存して忘れる」には一切タグ付けをしません。Evernoteの検索は優秀なので、それに頼ることにします。
そして、ここがポイントなのですが、一度検索した記事には、必ず「★★_もう一度見たい」タグと、「トップダウン式インデックスタグ」から一番具体的な固有名詞を一つだけタグ付けするようにします。検索したということはそれだけで自分にとって重要な記事であるという証拠ですから、一手間かけるだけの価値はあるはずです。
逆に言えば、WebクリップしてPDF化した時点ですぐにタグ付けしたくなるような記事以外は、検索時にタグ付けするだけで充分なのではないかと思います。つまり、表題への解答は以下の通りです。
ちなみに、Webクリップした時点ですぐにタグ付けした記事をボトムアップ式エッセンスタグの具体例の説明を兼ねて、下記に2つほど紹介させて頂きます。

以上が、Evernoteをゆる~く快適に使い続けるためのたった一つのルールです。この方法はPiggydbにも簡単に応用することができます。ノートをタグに置き換えるだけです。PDFを1クリックで保存することだけはできないので、それは手動で行うことになりますが。でも、Piggydbには以下のようなEvernoteにはない素晴らしい長所があります。
具体的には、
  1. フィルタ→新規フィルタ
  2. 以下のタグを全て含む→追加
    1. 「★_保存して忘れる」
    2. 「★★_もう一度見たい」
    3. 「★★★_殿堂入り」
    4. 「ライフハック」
    5. 「サッカー」
    6. 「ゴルフ」
    7. 「PDF」 (Piggydb専用のタグです)
  3. 名前:PDF用テンプレート → 保存
という手順で作成したら、
  1. フィルタ→PDF用テンプレート
  2. この状態で、「新しいフラグメントを作る」
  3. 既に上記のタグが入力された状態で、入力画面が表示されるので、不必要なタグを削除
  4. ファイル→PDFを選択(→タイトルを入力、省略可能)→登録
で、簡単に、タグ付けされた状態でPDFのファイルフラグメントを作成することが可能です。また、もちろんこの方法は普通のテキストフラグメントでも使うことが出来ます。付けたいタグが増えてきたときに特にオススメです。Evernoteのように1クリックで保存できない代わりに、PDFを登録する時点で簡単且つ丁寧にタグ付けを行えるのがPiggydbの魅力の一つですね。
「トップダウン式インデックスタグ
→ 「Football」
→→ 「J2」
→→→ 「東京V」
→→→→ 「東京Vユース」
「トップダウン式インデックスタグ
→ 「Football」
→→ 「育成年代」
→→→ 「東京Vユース」
「トップダウン式インデックスタグ
→ 「Football」
→→ 「監督」
→→→ 「岡田監督」
「トップダウン式インデックスタグ
→ 「Football」
→→ 「JFA」
→→→ 「JFA理事」
→→→ 「環境問題担当」
「ボトムアップ式エッセンスタグ
→ 「理想の上司」
→→ 「怒られるからリスク」
→→→ 「頑張ることに酔って、そこで自己満足するな!」
 と事前に一度だけ構成することで、後は、
一番具体的な固有名詞を一つだけタグ付けするだけで、検索時の視点に立ったタグを活用することが出来るようになります。
以上の2つの他にも、「#545 創造的なツールには魅力的なUI、ビジュアルも必要ではないか」や「#542 PiggydbがEvernoteより優れている3大ポイント」でも紹介させて頂いたPiggydbならではの魅力はたくさんあります。

以上、長々と紹介させて頂きましたが、最後まで読んで頂きまして、本当にありがとうございます。Evernoteの階層タグと全文検索で情報を整理することに興味はあるけれど、クラウドサービスはまだ不安、という方、とにかく情報を整理するのが大好きだという方、ぜひ一度Piggydbを試してみてはいかがでしょう。きっと、その素晴らしさに驚くことを保証しますよ!
P.S.
以上のような過程により、今後はPiggydbとEvernoteを使い分けていくことにしました。でも、両者を併用するとやっぱり、Piggydbの良さを再確認するんですよね。とくにつながりが作りたくなります。(Evernote for Mac では、ノート間リンクという機能が追加されたようです。Evernoteの一歩先を行くPiggydb、格好いいです!)やっぱり、私にとってはPiggydbは最高のアイデアツールです!!

→ ...

いやあ、すごいですね。圧倒されました。Piggydbがmagicianさんの情熱に見合うツールなのかいささか心配になってきましたよ。
PoICは初めて知りました。KJ法の進化形みたいなものですかね。これは折を見て調べてみたいと思います。情報有難うございます。
バックアップのためのエクスポート作業に分単位で時間がかかるようになってきたので
データ量が増えてくると、ブラウザ経由でバックアップファイルをダウンロードするのはつらくなってきますよね。その段階では、データベースファイルを直接バックアップした方が良いと思います(スケジューリングができるアプリを使えば、自動バックアップも可能です)。もちろん、エクスポートされたものと違ってテキストファイルではありませんが。
WebClippingについては、海外ユーザーの間でも話題に上りました。情報のソースの大部分がWebからだと想定すれば、ノートアプリとしては必須の機能だと言えるのかも知れません。Web上のコンテンツをそのまま(レイアウトなども含めて)クリッピングする機能を想定するならば、もうそれだけで独立した一つのアプリにした方が良いのではないか、というのが私が考えてることですね。magicianさんが書かれているように、Piggydbとしては、そういったアプリと連携した方が得策なのかなと。
あるいは、Piggydbでは情報の内容(意味)にフォーカスして構造化していくので、情報の基本はテキストでよい、という考えもあります。どこから持ってきた情報にしろ、見た目の部分は取っ払って、Piggydbにはテキストとして登録しておく。このプロセスを簡便化するために、個人的にはtumblrのbookmarkletを気に入っているので、これと同じ仕組みを導入できればなあと思っています。
私自身は、主に書籍を情報源としているので、WebClippingにそれほど必要性を感じてない、ということもあります。仮にWebを情報源とした場合、皆さんはどんな情報をクリッピングしたり、保存したりしているんですかね?ニュース系の情報が多いかのかな?

情報収集の初期段階での、双方向つながり作成について

camiさん、
いやあ、これは大変参考になります。どうも有難うございます。
実は、Piggydbが他の情報管理ツールと一線を画する部分があるとすれば、それは「情報の重み付け」にあると思っているのですね。最初はバラバラでフラットだった情報の集まりが、利用者の学習や価値観によって重み付けされ、ある種の知識の輪郭が姿を現すと。その終着点がタグフラグメントになると思っているわけですが。
その原則から考えると、全ての情報がフラットで、全ての情報が相互に関係しているような状況が(「みにくいあひるの子定理」)、全く重み付けされていない初期状態だと考えられるので、camiさんの例のように「とりあえずは双方向繋がりで繋げておいて、あとから片方向にするパターンになりやすい」となるのは、とても理に適っているなと思いました。
Piggydbの場合、元々、片方向のつながりを前提としていたために、双方向をオプショナルに扱っているということもあるのですが、つながりを作る操作上の問題もあるなと思いました。例えば、現状、つながりを作る方法は2パターンありますが、ドラッグ&ドロップの場合でも、「つながりのあるフラグメントをつくる」フォームを使う場合でも、起点となるフラグメントを指定することになるので、片方向がデフォルトになるのは自然なのかなとも思えるのです。
つまり、camiさんの「情報収集の初期段階では、フラグメント同士の関係がはっきりしていません」のようなケースでは、つながりを作るのに、別のもっと適切な操作法が必要なのかもしれません。例えば、なんとなく関係しているなというフラグメントの集合を選択して、一括で双方向つながりを作成するとか。この場合、つながりを作る過程で主従を意識する必要がないので、より自然な操作になるのかなと思ったのですが、いかがでしょうか?

→ ...

camiです。
みにくいあひるの子定理、まさにこれですね。
自由度を増す意味でも「一括して双方向つながりを作成」に賛成です。

しかし、繋がりが便利になると、
  • 密接な繋がり
  • もしかしたら関係あるかも?程度の繋がり
この二つを見分ける手段が欲しくなりますね。
タグフラグメントを使えば、強い繋がりを表現できます。
ですが、タグフラグメントは「連想」というより「内包」というイメージが強いです。
また、タグフラグメントは時系列を表すのも難しいです。
そういった「連続性」を表すなら、やはり繋がりを使いたくなります。
方向別に、繋がりに対してパラメータを設定できれば便利かもしれません。
…が、それだとPiggydbのコンセプトを壊してしまわないか不安になります。
前に言った「漠然としたアイディア」というのはこの部分です。
Piggydbの長所を崩さず、片方向繋がりを主軸に置きつつも、繋がりに幅を持たせる方法はないか模索していたわけです。

強い関係と弱い関係

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の図にある「共通のフラグメントとつながりでつなげる」をイメージすると良いのかなと、漠然と思っています。つまり共通のフラグメントがゆるやかなグルーピングのタグのような役割をするわけです。情報の入力はタグに比べて少し煩雑になりますが、後々にタグフラグメントなどと混ざって混乱することが無くなる方が有益ではないかなと。

既存の分類は手軽に済ませ、独自の発想を育てていく

P.S.
 Piggydbを使い始めてから、いろいろとつながりやタグの使い方について考えるようになりました。最近では、以下のような感じで使い分けるようになりました。
 基本的な方針は、Piggydbに限らず、タグ付けなどの情報の整理は細かくしだすとキリがないので、メリハリを付けていきたい、ということです。そこで、既存の分類の部分は手軽に済ませて、自分独自のカテゴリー、グループ分けが思いついた部分のみ、ピックアップしていこうという感じです。
 Piggydbは使っているとどんどん自分の思考が整理されていく気持ちよさがあるツールだと思います。その気持ちよさを少しでも伝えられたらと思い、私なりのPiggydbの使い方を紹介させて頂きました。何かの参考になれば幸いです。素晴らしいツールの開発、本当にどうもありがとうございました。

→ ...

嬉しいコメントをありがとうございます。使い方のノウハウもすごく参考になります。
  • 既存の分類や構造については深追いしない(「分類・整理」にこだわらない)
  • 自分の閃きにフォーカスしてそれを中心に知識を組み立てていく(ボトムアップ)
  • タグフラグメントを使いこなす
これはまさにPiggydb的な使い方だと思います。
eurekaタグは面白いですね。このような情報の重み付けはとても重要だと感じました。

eurekaからintelligenceへ

 我流のノウハウですが、参考になったようで嬉しいです。又、短く要点を掴んで頂いたまとめを読んで、更に私自身も理解が深まりました。どうもありがとうございます。
 eurekaタグは私もお気に入りです。アルキメデスがお風呂場でアルキメデスの原理を発見したときの叫び声が語源のeureka。この話を友人にしたところ、アハ体験という言葉を教えてもらいました。どうやら似た感じの語らしいですが、私はeurekaの方が語感が好きで気に入っています。
 4種類のタグですが、主にquesion→information→eureka→intelligenceの順番で知識を育てていくイメージです。もちろん、ボトムアップのPiggydbなので、順番に拘る必要はなく、参考程度の話ですが。
 ここでポイントになるのが、eurekaからintelligenceへの知識の育て方です。
  1. 会心の閃きが記されたフラグメントに"eureka"という固有タグを付ける。この段階では、閃いたことの具体的な内容ではなく、単純な日記のように閃きが起きた出来事そのものをささっとメモしていくケースも多い。このフラグメントのタイトルは空欄、もしくは仮題にしておく。
  2. そのフラグメントに"つながる"形でそのひらめきを他者に伝えられるまで思考を整理し、具現化していく。(その際、"eureka"タグは継承しない)
  3. その閃きがキーワードに象徴できるぐらいまとまったり、他者に説明できるように文章化、図解化できたら、"eureka"タグを付けた元のフラグメントのタイトルをそのキーワードで名付け、本文に解説を追記する。最後にいよいよフラグメントを"タグフラグメント化"して完了。
 まず、この説明を補足しますと、実際に固有のタグとして使用しているのは、"quesiton","eureka"タグのみで"information","intelligence"という名前の固有タグは使っていません。(親子タグの最上位タグとして使っても良いのですが、とりあえず現状では省いています)実際には利便性の面からinfomationに属するタグも使用していますが、"question","eureka",そして残りのタグは全てintelligenceに属するタグ、という状況が私の理想のpiggydbです。
 また、最初に"eureka"タグをつけた時点でそのフラグメントを仮キーワードで"タグフラグメント化"し、そのタグを継承していって、最後にキーワードを改名するやり方も有りだとは思います。ただ、私の場合、キーワードにまとめ、intelligenceタグを生み出したという達成感に知的喜びを感じているので、この手法を取っています。
 それに、そうしてボトムアップで生まれたintelligenceタグを、今後普通のタグとして運用していく際に、出来るだけタグはスリム化されていることが望ましいと思うので、こういった手法を取っています。もしその過程のフラグメントが参照したければ、"タグフラグメント"から"つながり"をたどっていけば済むわけですから。
 そして、このやり方だと、intelligenceタグは全て"eureka"タグの子タグとなりますが、それは思想的に自然なことだと思います。もちろん、そういえるのは、タグパレットに、ツリー以外のクラウドやフラットといった表示形式があってこそ何ですけれどもね。(タグフラグメントに、親子タグ、タグパレットのクラウドやフラット、素晴らしい機能の相互補完、ツールとして美しいですね)
 そうして生まれたintelligenceタグを複数選択して、新たな親タグを作成していく。これぞまさにボトムアップで育てる自分独自の知識の花。

タグフラグメントはボトムアップの意識と共に

 補足です。
 上記のやり方だと、"eureka"タグを見て、純粋に過去の閃きの瞬間を振り返りたいときに、フィルター機能を駆使する必要があり不便です。ですので、私は実際には、"eureka"タグを付けたフラグメントに直に”つなげる”形で新規"タグフラグメント"を作成しています。
 あえて、上記のやり方を説明したのは、新たにpiggydbに触れる方に、"タグフラグメント"は単に説明が記載できるタグでは無いと言うことを紹介したかったからです。タグ名→フラグメント本文に説明というトップダウンではない。まずはフラグメント本文の内容ありき。そしてそれがタグに昇華するボトムアップ。それがタグフラグメントの本質だと感じているからです。
 例えば、ある日の日記を書いたフラグメント。そのフラグメントに書かれた出来事は、私にとって大事な教訓となったので、その教訓名をタイトルにして、"タグフラグメント"化しよう。そして、スケジュール帳としてても使われているpiggydb。あの日は大事な面接だから、この教訓を忘れないようにしようと言うときに、その面接予定日のフラグメントにその教訓タグを張り付ける。とかね。
 まあ、それは原則論で、私だって実際には利便性との兼ね合いでいろいろと邪道な使い方もしているのですが、そういうボトムアップの意識を常にもって使うのがpiggydbと上手に付き合っていくコツの1つだと思います。

→ ...

このような話をいろいろと聞いてみたいなあと常々思っておりまして、作者冥利に尽きますね。どうもありがとうございます。
eurekaタグのようなメタな役割を持ったタグには、先頭に'#'を付けると便利かもしれません。これはPiggydbの慣例で、他の知識の内容を表すタグと区別できますし、'#'から始まるタグは、サブ(子)フラグメントを作るときに継承されません(通常、サブフラグメントを作るときには、デフォルトでエディタのタグ欄に親フラグメントタグが補完されます)。
「アハ体験」を僕なりの言葉で言うと、「既存のカテゴリを横断するような共通性の発見」という感じになるでしょうか。
この場合の「既存のカテゴリ」は、社会で共有されているものというより、個人個人の頭の中にあるものを指します。ですので、社会的には取るに足らない発見でも、その人の既存のカテゴリを横断しているのであれば、その人にとっては重要な発見となりえます。これが人間の学習プロセスの基本ではないかと僕は考えています。
ということは、個人のカテゴリが社会一般のカテゴリと近いときに、何らかの発見をすれば、それは社会的にも画期的な発見なるわけです。

タグフラグメントはボトムアップの意識と共に

 補足です。
 上記のやり方だと、"eureka"タグを見て、純粋に過去の閃きの瞬間を振り返りたいときに、フィルター機能を駆使する必要があり不便です。ですので、私は実際には、"eureka"タグを付けたフラグメントに直に”つなげる”形で新規"タグフラグメント"を作成しています。
 あえて、上記のやり方を説明したのは、新たにpiggydbに触れる方に、"タグフラグメント"は単に説明が記載できるタグでは無いと言うことを紹介したかったからです。タグ名→フラグメント本文に説明というトップダウンではない。まずはフラグメント本文の内容ありき。そしてそれがタグに昇華するボトムアップ。それがタグフラグメントの本質だと感じているからです。
 例えば、ある日の日記を書いたフラグメント。そのフラグメントに書かれた出来事は、私にとって大事な教訓となったので、その教訓名をタイトルにして、"タグフラグメント"化しよう。そして、スケジュール帳としてても使われているpiggydb。あの日は大事な面接だから、この教訓を忘れないようにしようと言うときに、その面接予定日のフラグメントにその教訓タグを張り付ける。とかね。
 まあ、それは原則論で、私だって実際には利便性との兼ね合いでいろいろと邪道な使い方もしているのですが、そういうボトムアップの意識を常にもって使うのがpiggydbと上手に付き合っていくコツの1つだと思います。