Piggydb.jpへようこそ!

Piggydbは新感覚の情報管理ツールです。いろいろな情報を入力して、それらをつなげたり、分類したりしながら、知識やアイデアを構築できます。個人でもグループでもお使い頂けます。
このサイト自体がPiggydbで運営されています。基本的な仕組みはとても単純です。一つの囲み(例えばこの文章が収まっている四角の領域)が「フラグメント(断片)」と呼ばれる情報の単位で、囲みの上と下の部分には他のフラグメントへのつながりが表示されています(矢印がつながりの方向を表しています)。これらのつながりを辿ることがコンテンツ閲覧の基本になります。
コンピューターに詳しい人たちだけではなくて、誰でも簡単に使えるようにと思って作りました。知的生産に関わる多くの人に利用してもらえたら嬉しいです。受験勉強、研究、執筆、プロジェクト管理、などなど、扱う情報が複雑になればなるほどPiggydbは力を発揮します。
早速Piggydbを使ってみたいという方は、「Piggydbを使ってみる」から始めてみて下さい。Piggydbの最新情報について知りたい場合は#Piggydb Blog、よりディープな話は#The Piggydb Wayへ。
コンテンツの探索を始める場合は、このフラグメントからのつながりを辿るか、ページ右側にある「ブックマーク」や「タグパレット」からどうぞ。

Piggydbの仕組み

1. 小さな情報の断片を集めて、
2. それらをタグで分類したり、
3. つなげて大きな文書をつくったりできます。
4. ドキュメントとして表示

情報を構成して「知識」にする → ...

Piggydbの肝は、登録した情報の断片同士をつなげたり、分類したりする情報の意味付けにあります。単に情報を貯めておいて必要なときに後から検索する、という利用を想定しているのであれば、わざわざPiggydbを選択する理由はありません。情報同士をつなげたり分類したりという過程を経ることによって、利用者が何らかの学びを得る、というのがPiggydbの狙いです。
コンセプト自体はメモツールやデータベースというよりも、マインドマップに近いかもしれません。ただマインドマップよりPiggydbの方が複雑です。その代わり、多様な情報を無理なく結びつけることができますし、大量の情報を扱うことができます。

Piggydbデモ

Piggydbを使ってみる → ...

PiggydbはWebブラウザから利用することのできるアプリケーション(Webアプリケーション)です。ただし、オンラインのサービスとしては提供していないので、ご自分の環境にインストールして利用して頂くことになります。PiggydbはApacheライセンスで公開されているオープンソースのソフトウェアで、パッケージをダウンロードしてご自分の環境にインストールする分には無料でご利用頂けます。普段使っているパソコンにインストールして、自分だけの情報管理ツールとして利用することもできますし、サーバーマシンにインストールして複数人で共有することもできます。
ダウンロードする前にどんな感じか試してみたい、という人のためにデモサーバーを用意しています。情報の登録や編集などの操作を試してみたい方はこちらを利用してみて下さい。
  • デモサーバー - http://piggydb.jp/sandbox/
    • guest/guest でログインできます。
    • あくまでデモなのでデータは定期的にクリアされます。

Piggydbデモ - エーゴブタ

Piggydbの新しいデモサイト「エーゴブタ」を立ち上げました。
このサイトはサブタイトルに「英語例文収集プロジェクト」とあるように、色々な文献から英作文に役立ちそうな英文を集めて、Piggydb上で整理・分類しようというプロジェクトです。
と言っても「英作文に役立ちそうな英文」のネタはそれほど長くは続かないように思うので、英作文向けに限らず、知識として面白い文章も収集しておいて、英語ネタに囚われない知識ベースを構築しようというのが、裏テーマです。
一番注目すべき点は、例文の分類(タグ)です。この分類がとても難しい!英文を書くときに、欲しい例文が探せるような分類をしなくてはならないのですが、どのような分類が良いか、試行錯誤しています。例文が増えていけば、この分類も洗練されていくんじゃないかなとは思うのですが、、、

Piggydbデモ - Table Tennis Videos公開中 → ...

以前から構想していたデモサイトの第二弾(第一弾はこのサイト)を立ち上げました。卓球の動画を集めた「Table Tennis Videos」です。
何故卓球なのかと言えば、単純に私の趣味ですが(^_^;
Piggydbはそもそもこのような用途を想定して作られたものではなくて、この「Table Tennis Videos」も当初は「このようなこともできる」ということを見せるためのものとして考えていたのですが、結果的にはPiggydbの機能をフルに使った、かなり高度なデモが出来たと自負しています。
次回からはこのデモサイトを使って、Piggydbの強みやノウハウ、あるいは現状で足りないと思われる部分も含めて検討していきたいと思います。
卓球に興味がない人も、是非このデモサイトを覗いてみて下さい。迷ったときは「ブックマーク」にある大会の一覧、あるいは「タグ」メニューがインデックスの役割になります。
動画は随時更新していく予定ですので、お暇なときに覗いて頂けると嬉しいです。

Piggydbを使ってみる

PiggydbはWebブラウザから利用することのできるアプリケーション(Webアプリケーション)です。ただし、オンラインのサービスとしては提供していないので、ご自分の環境にインストールして利用して頂くことになります。PiggydbはApacheライセンスで公開されているオープンソースのソフトウェアで、パッケージをダウンロードしてご自分の環境にインストールする分には無料でご利用頂けます。普段使っているパソコンにインストールして、自分だけの情報管理ツールとして利用することもできますし、サーバーマシンにインストールして複数人で共有することもできます。
ダウンロードする前にどんな感じか試してみたい、という人のためにデモサーバーを用意しています。情報の登録や編集などの操作を試してみたい方はこちらを利用してみて下さい。

前提条件 → ...

Piggydbを動かすためにはJavaランタイム(Java 6.0 以降)が必要です。Javaがあれば、Windows, Mac OS X, Linuxなど、どのようなOSでも動作します(Mac OS Xには標準でJavaが搭載されています)。
ご利用のマシンにJavaが入っているか分からない場合は、以下のサイトでチェックできます(サイト内の「Java の有無のチェック」をクリック)。
インストールされていない場合は、上記サイトの手順に従ってJavaをインストールします。

スタンドアロン・パッケージ

PiggydbはWebアプリケーションですが、スタンドアロンアプリケーションのような感覚で利用できる「スタンドアロン・パッケージ」を提供しています。パッケージファイルをダウンロードして適当な場所に解凍し、実行ファイルをダブルクリックすればPiggydbサーバーが起動してタスクトレイに常駐します。
全ての環境でテストをしたわけではないので断言はできませんが (Windows XPとMac OS Xで動作確認済み)、JavaランタイムとGUIのシステムトレイがある環境であれば、このパッケージを利用できる思います。
以下に手順を示します。
1) Javaがインストールされていない場合はこちらでダウンロードしてインストールしておきます(スタンドアロン・パッケージを動作させるためには Java 6 (1.6) 以上が必要です)。
2) Piggydbダウンロードからスタンドアロン・パッケージをダウンロードします。
3) Zipファイルを適当な場所に解凍します。
4) piggydb.exeファイルをダブルクリックすると以下のようなスプラッシュスクリーンが表示されてサーバーの起動が始まります。
Windows以外のOSをご利用の場合は、piggydb-standalone.jar をダブルクリックするとサーバーの起動が始まります。起動しない場合は、コマンドラインから「java -jar piggydb-standalone.jar」を実行してみて下さい。
5) サーバーの準備が完了すると自動的にブラウザが起動されてログインページが表示されます(表示されない場合は、ブラウザを起動して http://localhost:8080/ にアクセスして下さい)。
6) Ownerアカウント owner/owner でログインします。
ログイン後は忘れずにパスワードを変更するようにして下さい(メニュー「システム/パスワード変更」から変更できます)。
Piggydbサーバーが起動しているとき、タスクトレイにPiggydbのアイコンが表示されます。
このアイコンを右クリックするとメニューが表示されるようになっています。
サーバーを終了させたい場合は、メニューから「終了」をクリックします。

情報を登録してみる → ...

Piggydbをインストールして、初めてログインすると以下のような画面が表示されます。まだ情報が何も登録されていない状態です。
左上に「新しいフラグメントをつくる」というリンクがあるので、ここから早速、最初の情報を登録してみましょう。

さらに詳しい情報はこちら → ...

さらに詳しい情報やその他の関連情報については、以下を参照して下さい。
また、このサイトやPiggydbに関するニュースは、タグ#Piggydb Blog」にて配信していますので、定期的にチェックしてみて下さい。

Piggydbダウンロード

Piggydbのアップグレード → ...

既存のPiggydbを新しいバージョンにアップグレードするのはとても簡単です。以下にパッケージごとの手順を示します。
(※) 基本的にデータベースはプログラムファイルとは別の場所に保存されていますので(#167)、新しいバージョンに入れ替えてもデータはそのまま引き継がれますが、念のため作業前にデータをエクスポート(#48)しておくことをお勧めします。

ご意見・ご感想はこちら

Piggydbやこのサイトへのご意見、ご感想、バグ報告、要望、その他なんでも、以下の手段のいずれかで送って頂けると嬉しいです。こんな用途でPiggydbを使っているよ、という報告も大歓迎です。

コメントを書き込めるようにしてみました → ...

このサイト(piggydb.jp)にてコメントを書き込めるようにしてみました。
ログイン画面から guest/guest でログインすると、フラグメント登録できます。
Piggydbやこのサイトに関することなら何でもOKですので、是非是非書き込んでみて下さい。
単にPiggydbを試してみたいという場合は、デモサーバーがありますので、そちらをお試し下さい。

Piggydb.jpに自分専用のアカウントが欲しい方はメールをお送り下さい

ちょっと心配なのは、自分の書いたコメントはWikiみたいに他のguestでも編集可能なんですよね。
そうなんです。なので基本的には匿名での共同作業には向いていないかもですね。参加者全員がユーザーとして登録されていて、フラグメント登録する人、オーガナイズする人と、うまく分担出来れば、Wikiとは異なる面白いコラボレーションができるかもしれないのですが。
もしご自分の登録した情報が他の匿名ユーザーから編集されることについて抵抗感がある、あるいはPiggydb.jp上に自分の城が欲しい(笑)場合は、新たにユーザーをお作りしますので、是非 daisuke.marubinotto (at) gmail.com までメールを(どなたでもOKです)。

Piggydbを使いこなす

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

固有名詞をタグに使う → ...

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

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

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

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

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

→ ...

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

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

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

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

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

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

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

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

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

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

たくさんのユーザーが様々に使いこなしいているEvernoteからPiggydb活用方法のヒントを盗むために、両者を併用して数日。両者の特徴を活かした使い分けのコツが見えてきました。
  • 「記録」と「発見」はPiggydbに
    • 「記録カード」は、私たちの身の回りの事実や現象を記述するのに使います。例えば、日記(生活、仕事、夢)、お金の収支、健康状態(体温・血圧・体重)、食事、天候(天気・気温・湿度)などは、記録カードに属します。
    • このような直感的な発見はすべて「発見カード」となります。例えば、生活・仕事のアイディア、発見、直感、理解、認識、ジョーク、詩、俳句など、私たちの頭・心から湧き出てくるものは、発見カードに属します。
  • 「GTD」と「参照」はEvernoteに
    • GTD(Getting Things Done)とは、David Allen 氏が提唱するタスク処理システムです(Allen, 2002)。GTD カードは、やるべきこと(Things Do)、やったこと(Things Done)を記述するカードです。
    • 本・テレビ・ウェブからのことばの引用、料理のレシピなどは、四番目の「参照カード」に分類されます。これは、「自分以外の他の誰かのアイディア」を記すカードです。

※この考え方は、PoICを参考にしています。PoICはEBtとも親和性の高いメソッドなので、Piggydbとの相性も良いと思います。
  • PoIC とは?
    • (Pile of Index Cards:情報カードの積み重ね) とは、情報カードを使った生産性向上のためのシステムと、それに付随するメソッド(方法論)を指します。
  • 4カード
    • ここでは、私たちの思考や身の回りの情報を追跡するための、4種類のカード(記録、発見、GTD、参照)を導入します。PoIC ではこれを「4カード」と呼びます。私たちをとりまく情報には、実はこの4種類しかありません。
  • 第6回 PoIC++~プラットフォームの拡張
    • PoICは「情報を時系列順にストックする」,「すべての情報を4つのタグで緩やかに分類する」という基本を押さえてしまえば,それ以外のことは比較的自由に考えても構わないシステムだと思います。
    • そして,この2つさえきちんと理解していれば,5×3サイズの5mm方眼罫の情報カードにこだわらずに自由に拡張できます。こうした拡張性の高さが,PoICの魅力のひとつだと思います。そのひとつの例として,ZaurusでのPoICを紹介しました。

閑話休題。私が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で保存する際の利点です。
次に、ノートを準備します。
上記の記事を参考に、私は以下のようにアレンジしています。
  • 「Inbox」
    • Firefoxで保存されたPDFはまずここに収納されます。
  • 「Archive_Lifehack」,「Archive_Football」,「Archive_Golf」,「Archive_Anything」
    • 私がWebクリップするのはほぼ上記の3種類の記事なのでそれに合わせたノートを用意しました。
    • 「Archive_Anything」はそれ以外用のノートです。最初はこれ一つでも充分かも知れません。
  • 「Cache_Anything」
    • 「すぐ見たい」ノートです。私のEvernoteの使い方では、主にGTD用のノートとなります。
ここまで準備できたら、自由にネットサーフィンをして、どんどんPDFを貯めていきます。気になったページは気軽に保存します。「保存して忘れる」ことで、常に脳をリラックスさせるのです。
そして、毎週1回、Inboxを空にします。「保存して忘れる」私の使い方では、ほとんどのPDFが「Inbox」から直接各「Archive」へ移動することになります。ここで、タグの登場です。
Evernoteにおける私のタグ構成は以下の通りです。
  • 「レーティングタグ
    • 「★_保存して忘れる」
    • 「★★_もう一度見たい」
    • 「★★★_殿堂入り」
  • 「トップダウン式インデックスタグ
    • 「岡田監督」
    • 「東京Vユース」
  • 「ボトムアップ式エッセンスタグ
    • 「怒られるからリスク」
    • 「頑張ることに酔って、そこで自己満足するな!」
※「トップダウン式インデックスタグ」と「ボトムアップ式エッセンスタグ」は、サンプル用に抜粋しています。
「Inbox」から「Archive」へ記事を移動させるタイミングでタグ付けしていくワケですが、ざっとタイトルを流し読みして、「★★_もう一度見たい」以上の記事がなければ、何もタグ付けをせずに、範囲選択してジャンルだけ分けて、さっさと「Archive」へ収納してしまいます。
「★★_もう一度見たい」以上の記事だけ、タグ付けをしていきます。その際、「★★_もう一度見たい」以上のレベルの記事は、「トップダウン式インデックスタグ」から一番具体的な固有名詞を一つだけタグ付けすればOKです。「レーティングタグ」と合わせて、タグは最低限2つ付いていれば充分です。もちろん、すぐに思い浮かぶようならば、「ボトムアップ式エッセンスタグ」もつけていきますが、気負う必要はまったくありません。「ボトムアップ式エッセンスタグ」は思いついたときにつけるのが本来の使い方ですから。
※なぜ、Evernoteでも一番具体的な固有名詞を一つだけタグ付けでOKなのか。(Piggydbでは後述のように明確な理由があります)それは、固有名詞ならば簡単に脳内で補完できるからです。「東京Vユース」は「東京V」の「育成年代」であることは、階層タグで定義しなくても自然に理解できます。検索時もEvernoteの機能を活かし、工夫をすれば、一番具体的な固有名詞を一つだけタグ付けでも充分に目的の記事を見つけられるはずです。
「★_保存して忘れる」タグは実際には使用しません。利便性を考えて、他の「レーティングタグ」が付いていない記事が、「★_保存して忘れる」記事ということにしています。そして、更に簡単に使うために、上記の通り、「★_保存して忘れる」には一切タグ付けをしません。Evernoteの検索は優秀なので、それに頼ることにします。
そして、ここがポイントなのですが、一度検索した記事には、必ず「★★_もう一度見たい」タグと、「トップダウン式インデックスタグ」から一番具体的な固有名詞を一つだけタグ付けするようにします。検索したということはそれだけで自分にとって重要な記事であるという証拠ですから、一手間かけるだけの価値はあるはずです。
逆に言えば、WebクリップしてPDF化した時点ですぐにタグ付けしたくなるような記事以外は、検索時にタグ付けするだけで充分なのではないかと思います。つまり、表題への解答は以下の通りです。
  • Evernoteをゆる~く快適に使い続けるためのたった一つのルール。
    • 検索した記事にのみ、最低限のタグを付けていく。
ちなみに、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ならではの魅力はたくさんあります。
  • 完全にオフラインで作動するので、情報漏洩の可能性が無く情報の安全性が高い!
    • ワンボタンで、すべてのファイルが含まれたオールインワンのアーカイブファイルが作成されるので、バックアップの信頼性も高い!!
  • タグクラウドビューのワクワク感!
    • 大きく育ったタグには、たくさんインプットしたなぁという満足感も感じられますね!!
  • スライドバー操作で、様々に変化するフラグメントリストビューの爽快感!
    • 画像フラグメントのサムネイルが表示されるようになると更に楽しくなりますね!!(要望です、ご検討よろしく御願いします)
  • 軽快な検索スピードと、的確な検索結果を併せ持つ、優秀な全文検索!
    • 一回の表示量を制限しているので、大量の検索結果がある場合でも、極端に遅くなったり重くなったりしないのが職人技って感じです!!
  • フィルタ操作を意識させないシームレスな「関連するタグ」機能!
    • +ボタン、-ボタンでポチっポチっと操作していく感じも、分かりやすく面白いです!!
  • フラグメントツリービューからのつながりをたどるネットサーフィンの楽しさ!
    • 双方向つながりだと更にネットワークが広がり、まさに脳内シミュレータと化します!!
  • PiggydbをFirefoxで活用すれば、Stylishで自由にカラーカスタマイズが可能!
    • #546 ブラック&オレンジがテーマのPiggydb用Stylish、自画自賛ですがオススメです!!

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

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

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

強い関係と弱い関係 → ...

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

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

P.S.
 Piggydbを使い始めてから、いろいろとつながりやタグの使い方について考えるようになりました。最近では、以下のような感じで使い分けるようになりました。
  • information 既存の情報。既に分類されている事柄はあまり細かくタグで整理しない(キリが無いので)。主にアウトラインエディタをイメージして、ゆるやかに”つながり”で表現していく。トップダウン。
  • intelligence 自分で発見した情報。私の場合、気付いたこと、感じた事柄をキーワードに纏めて表現できるぐらい把握できた時に、そのキーワードでタグフラグメントを作り、タグ付けで管理します。ボトムアップ。
  • eureka 既存の情報、独自の発想を問わず、自分の中でハッと閃いたり、理解できたフラグメントに"eureka"タグを付けます。
  • question 自分の中で疑問に思った事柄を記したフラグメントに"question"タグを付けます。
  • 脳内時系列での"つながり" あるフラグメントを書いていて、その時ふと一見元のフラグメントとは関係ないアイデアを思いついたら、遠慮せずそこから"つながった"フラグメントにそのアイデアを記入する。
 基本的な方針は、Piggydbに限らず、タグ付けなどの情報の整理は細かくしだすとキリがないので、メリハリを付けていきたい、ということです。そこで、既存の分類の部分は手軽に済ませて、自分独自のカテゴリー、グループ分けが思いついた部分のみ、ピックアップしていこうという感じです。
 Piggydbは使っているとどんどん自分の思考が整理されていく気持ちよさがあるツールだと思います。その気持ちよさを少しでも伝えられたらと思い、私なりのPiggydbの使い方を紹介させて頂きました。何かの参考になれば幸いです。素晴らしいツールの開発、本当にどうもありがとうございました。

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つだと思います。

Piggydb読み物

Piggydb.jpには、Piggydbの紹介やドキュメントに留まらず、日々更新されるいろいろな読み物があります。以下のようにそれぞれタグでまとめてありますので、フィードで更新情報を追いかけるもよし、つながりを辿って情報の海を探索するもよし、何らかの形であなたの知的生産の参考になれば幸いです。

#Piggydb Blog

Piggydb作者によるブログです。

#The Piggydb Way → ...

ここでは、Piggydbというソフトウェア、あるいはその開発を通して考えていること、実験しようとしていることについて書いていこうと思います。基本的には取り留めのない文章になる可能性が大ですが、最終的には、なぜPiggydbが他のアプリケーションとは一線を画するのか、その考え方の枠組み的なものを提示できればいいなと思っています。

#随想のかけら → ...

以下の引用のような経緯から生まれ、使わせて頂くこととなったタグです。
具体的にはとにかく「イメージを文章で表現する事」を目指した知的生産の一手法を実践したフラグメントに付けるタグとなります。過去の経験を基にしたイメージ、ある言葉や文章、イラストなどを見たときにふっと思い浮かんだイメージ、空想や仮想現実のイメージ等が入り乱れる文章となります。ですので、これでタギングされたフラグメントは基本的には全てフィクションの扱いになります。

 まさにその瞬間、彼の脳裏にハッとイメージが浮かんだ。そのイメージこそ、今彼の脳内宇宙を駆けめぐっている疑問への答えそのものである。と、彼は理屈抜きに確信していた。彼はそのイメージを脳内宇宙で何度も反復し、暗唱し、そのイメージを確かな言葉、キーワードとしてから、おもむろに明かりをともした。のっそりと体を起こすと、枕元から愛用のメモ帳を取りだしお気に入りのペンでそのイメージのキーワードを書き記した。
  • #801 『ドアコン(仮称)』(ID801番) より引用。
magicianさん、これ面白いです。このフィクション形式の話を展開させたらどうなるのか読んでみたいと思っちゃいました。
magicianさんの止め処ない思考の軌跡を表現するにはこういった形式が最も適している(読みやすい)ような気がします。このような時系列に展開して行く随想的な話が主系列としてまずあって、その傍流として、そこで発見された様々なアイデアが配置されるみたいな。
もし#801の話を展開して頂けるのでしたら、専用のタグを使って頂いてもOKですよ。「#知的生産物語」みたいな。楽しみにしております (^_^)/

コンセプト指向発想法

Piggydbで提案している知的生産の方法を暫定的に「コンセプト指向発想法」と呼ぶことにします。
コンセプト指向発想法とは、コンセプトを中心に知識を組み立てようという考え方です。ここで言うコンセプトとは、辞書やWikipediaの項目に相当するモノやコトのことです。つまりコンセプト指向では、自分(あるいはチーム)なりの辞書を構築してくような感じで集めた情報を整理していきます。
コンセプト指向のメリットは大きく分けて二つあります。一つは、情報量が増えて知識が複雑になっても、自分にとって重要なコンセプトとその関係が自然に浮き上がってくるため、従来の方法よりも「1) 見通しの良い知識ベースを構築できる」ということ。もう一つは、既存のコンセプトによる情報の整理(カテゴリー)よりも、新しいコンセプトの発想・研究に力点を置くことによって「2) 情報管理がよりクリエイティブなものに」なるということです。
このフラグメントには「コンセプト指向発想法」で重要になってくるコンセプトを随時ぶら下げていきます。この考え方自体もコンセプト指向で発展させようという試みです。

コンセプト → ...

コンセプトに相当する日本語は「概念」ですが、いずれも辞書や辞典の説明で納得するのは難しい抽象的な「概念」です。
ここでは、ヒトが生来的に認識することのできる任意の「類似性」をコンセプトと呼ぶことにします。分かりやすく言うと、名指しできるもの全て、辞書やWikipediaの項目として紹介されるような、モノやコトのことです。
Piggydbは、情報の蓄積と編集を通して、ユーザーが新しいコンセプトを生み出すことを助けるような仕組みを構築することを一つの目標としています。
以下、Wikipediaより:
ある事柄に対して共通事項を包括し、抽象・普遍化してとらえた意味内容で、普通、思考活動の基盤となる基本的な形態として頭の中でとらえたもの。
その概念を言葉で表現されたものを「名辞」と呼び、言語の構成要素として、それを組み合わせ、述べ表し、判断・認識可能なものとして現実世界をとらえて表現する。人間はほぼこのような概念化した名辞によって、この世の中のあらゆることを理解したり、表現したりしている。
また概念は、それを提議・提唱する者の心性、視点、立場、精神的なポジション・在り方を反映する。
コンセプトは、それらを敷衍し同様に扱うことによって、個々の物事・出来事の間の違いを省き、物事・出来事の間に共通する大要、要約、見解、イメージ、つまりは「普遍的概念」となる。このコンセプトは、実在の出来事や事件、物事の関係を種類に分け、分類化し、カテゴライズし、クラス分けをするのに貢献する。
概念は人間の精神内部に存在する何かであり、抽象的、普遍的なものである。精神外部の世界に存在するものや、出来事や、それらの関係について概念が存在する。ひとつの概念は個々の事物というよりも、事物の集合に対して存在する。
概念は、個々の物事の細かな相違点を無視して、それらが同一であるかのように扱うという意味で抽象的である。概念は、(それが表す)個々の事物すべてに当てはまるという点で普遍的である。

みにくいあひるの子定理

人間の認知パタンから独立した客観的な性質をことごとく選んでそれらを等価とみなすと、すべての対象は同じぐらい似ていることが証明できる。あひると白鳥は、2羽の白鳥が似ているのと同じくらい似ているという意味で、これを「みにくいあひるの子定理」という。渡辺慧氏により厳密に証明された。したがって、すべての分類は、本来的に恣意的なものである。あるいは、分類とは、世界観の表明にほかならない。『「超」整理法―情報検索と発想の新システム

KJ法 → ...

KJ法(-ほう)は、文化人類学者川喜田二郎(東京工業大学名誉教授)がデータをまとめるために考案した手法である。データをカードに記述し、カードをグループごとにまとめて、図解し、論文等にまとめてゆく。KJは考案者のイニシャルにちなむ。共同での作業にもよく用いられ、「創造性開発」(または創造的問題解決)に効果があるとされる。(Wikipediaより)
収集した情報をグルーピングしてコンセプトを作る手法。特に「異質のデータを統合する」ときに新しいコンセプトが生み出される、とする。発見したコンセプトを論理的に納得できるよう、空間的に配置し、それを元に文章を作成するのが最終目的である。
Piggydbの手法は基本的な部分でKJ法と同等であると考えられる。KJ法はカードを利用するので情報量に限界があるが、Piggydbはコンピュータソフトウェアで実現されたデータベースなので膨大な情報量を材料にでき、かつ情報の見せ方も柔軟に選択できる。

事後的に発見されるアイデア → ...

アイデアとその実現を別々に考える、というのは、おそらく今でも多くの人にとって自然な考え方でしょうし、特に組織においては支配的な考え方だと思います。まずブレインストーミングなどでアイデアを出すフェーズがあり、そのアイデアに対して評価を行い、その後に、良さそうだとされたアイデアの実現に向けて行動を開始する。
しかし、実際はそのようなやり方が機能することはほとんどなく、組織で生み出されるものは概して流行を追いかけるものばかりだったりします。
現代において新しくて価値のあるものを生み出そうとするなら、ほぼ例外なく、探索的な手法を取らざるを得ないのではないかと思います。トライアル&エラーで常に学習しながら軌道修正していかざるを得ない。その探索の結果を後からまとめたものがアイデアとなる、つまり、そのように事後的にしか発見し得ないのが画期的なアイデアだと思うのです。
探索的、というのは進捗が堂々巡りになったときのクリエーターの言い訳にも聞こえますが、今では探索的な手法を如何に制御可能にするか、予測可能にするかという観点に立ったプロジェクトの管理手法も多く提案されていますし、今後ますます重要な考え方であることは間違いありません。

Piggydb関連リンク集

Piggydb紹介記事

テキスト整形ルールを拡張するスクリプト

自分用に作ったものなので、書式が独自仕様なのですが、マーカーで囲んだ文字列をspanタグで囲み、スタイルシートで修飾可能なスクリプトを作成しました。
次のページからダウンロードすることができます。
スクリプト内の定義テーブルで、たとえば識別子"r"に青色を結びつけると、@r@と@r@で囲まれた部分を青色で表示します。
動作は、Firefox 3.6+Greasemonkeyの環境でしかチェックしていません。
興味ある方は、お使いください。

豚の貯金箱

http://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Sparschwein_Haspa02.jpg/589px-Sparschwein_Haspa02.jpg
イギリスでは、余ったコインを台所などにある赤い陶土(pygg)の陶器の壷に蓄えることがあり、これをピギー銀行(pygg bank)と呼んだが、これが「子豚」を意味するpiggy を連想させたため、陶器製の豚が貯金箱に使われることが多くなった。(Wikipediaより)

Piggydbの今後

Piggydbはまだまだ発展途上のソフトウェアです。今後のプランや方向性の検討については随時ここにまとめて行きたいと思います。フィードバックを頂けると、その方向性に何らかの影響を与えるかもしれません。

あらゆる入力経路と情報構成のしやすさの追求

まさにPiggydbでサポートしたいと考えているボトムアップの知識構築ですね。メタ化はPiggydbではもっと分かりやすい言葉で「意味付け」と呼んだりしていますが、重要なのは、このメタ化を繰り返し繰り返し、試行錯誤できることではないかと思います。入力経路の問題も重要ですね。
ということで、目指すべき方向性としては、
  • 意味付けをより簡単に素早く行えるようにすること
  • 意味付けの対象となる情報をより効率的に俯瞰できるようにすること
  • あらゆる経路でフラグメントの入力をできるようにすること