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

後でいくらでも整理できるので、とにかく最初はどんどんタグ付けしていく、というのは実は私も当初考えていまして、ブログにもそのように書いた記憶があります。ですので、整理することによってタグがうまく機能している限りは全く問題ないと思います。
しかし、私の場合はそれでタグ管理が破綻してしまったという経験がありまして、それ以降は慎重にタグ付けするようになったという経緯があります。
「必ずタグを付ける」理由として、「その情報が取り出せるという安心感」を得るためだということですが、情報へのアクセスを保つためには、タグだけではなくて、つながりを作ってネットワークを維持する方法もあります。例えば、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 でも、主にドキュメントビューでの利用を想定して、タイトルだけのフラグメントを作り、それに対して複数のフラグメントを並べていく場合がありますよね。あれと同じでしょうか。ドキュメントビューで使わないならわざわざそうしなくてもタグをつけた方がスマートなような気がします。

→ ...

まさしくその通りです!フラグメントの構造とは直交するコンセプトタグを利用する、言い換えると、複数の構造(ネットワーク、あるいはツリー)を横断するものですね。横断しているということを示したいがためにタグという要素を別に用意している、と言ってもいいかもしれません。
EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
そのメモ(あるいはフラグメント)を選択すれば、そこからつながる別のメモが見える、という機能に限って言えば、つながりはタグの代用になるわけですが、Piggydbにおいては、その他の機能で以下のような差別化を行っています。
  • つながり
    • ページングなし
    • 順序の保存
つながりにページングが無いのは、それほど大きな数のつながりが作成されることを意図していないということですし、タグページにページングがあるのは、大量のデータを修飾の対象とすることを意図しているからです。 つながりの順序は以前話題になりましたけども(#208)、順序は空間上の配置を意味しますから、これはつながりが基本的には構造的な関係を表すということです。
ちょっと堅い言葉で言いますと、タグの修飾は「概念的包含関係」を表し、つながりは「構造的包含関係」を表しています。この二つの区別には常に混乱が付きまといます。
タイヤは自動車の下位概念ではない。タイヤは自動車の部品である。自動車事故は自動車の下位概念ではない。自動車事故は自動車に関連する概念ではある。

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

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