え〜っと、前回の続きです。タグにはどのような問題があるかという話です。
最近はコンテンツを分類する手法としてタグを使うサービスが増えているのですが、タグにはいくつかの問題があると思います。前回はそのひとつとして、タグの漏れの話をしましたが、それ以上に大きな問題が残っています。それは「局所化」が難しいということです。分類の本質は「見るべき範囲を限定」することで目的のコンテンツにたどり着くまでのコストを抑制することだと前回書きましたが、タグではこれが意外と難しいのです。
タグによってコンテンツを絞り込むには、どのようなタグが実際に使われているのかを知る必要があります。見当違いなタグを指定してしまうと、目的のコンテンツにたどり着けません。タグを付ける側は思いつきでタグを付けられるので気軽なのですが、それを手がかりにコンテンツを探す側から見ると、タグを適切に選択しなければならないというコストがかかるわけです。しかもタグ全体が構造化されていないので、大量のタグの中から目的のタグを探す必要がある。つまり「構造化する必要がない」ということが、タグそのもののファインダビリティを低下させているわけです。
「タグクラウドならよく使われているタグが大きく表示されるよ」という指摘もあるかもしれません。しかし「よく使われているタグ」を見つけだすことは、目的のコンテンツにたどり着くための手法としては十分ではありません。そのタグは多くのコンテンツに付けられているというだけで、他のタグを無視してもいいということにはならないからです。むしろ小さく表示されているタグが、本当に必要なコンテンツに結びつけられているかもしれないのです。
また類似の意味を持つタグをグルーピングできれば、タグを手がかりにした検索の精度も高まるかもしれません。しかしそのためには、タグ同士の関係性を定義する必要があります。これはなかなかコストがかかります。言葉の意味から関係性を定義するには、現在の技術では、どこかで人間の判定が必要になると思われるからです。シソーラス辞書が整備されていれば、ある程度までは自動化できます。しかし上下関係にある言葉は、シソーラスだけでは関係づけることができません。いずれは解決すると思うのですが、現状ではまだ難しいと思います。
もちろんタグやタグクラウドにもメリットはあります。どのタグがよく使われているのかがわかれば、どのテーマに注目している人が多いのかがわかるからです。これはネット上での流行を追いかけている人にとっては、非常に魅力的です。みんながいま何を話題にしているのか、ひとめでわかります。またコンテンツ同士をつなぐキーワードとしてタグを使うことで、類似性の高いコンテンツの間を“サーフィン”することもできます。しかしこのような機能は、目的のコンテンツに低コストでたどり着くためというよりも、たどり着くまでのプロセスを楽しむためのもの、という側面が強いように感じます。いわば「ドンキホーテ」的な面白さです。
このような面白さを否定するつもりはありません。しかしコンテンツのファインダビリティという観点から見れば、あまり効果的なアプローチではないと思います。
私が「コンテンツ群をカテゴリー分けするWebアプリケーション」を作っている最大の目的は、価値のあるコンテンツに低コストでたどり着くにはどうすればいいのか、という課題を解決するためです。カテゴライズはそのための手法として、今なお有効だと考えているのです。
ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
最近更新が滞っておりますが、みなさんお元気でしょうか。前回「コンテンツ群をカテゴリー分けするWebアプリケーションを作っている」という話を書いたのですが、先週の中頃までに、ごくごく原始的なプロトタイプを作ってみました。その後、そのブラッシュアップをするつもりだったのですが、ちょっとした壁にぶつかってしまい、作業がストップしています。
その壁とは何か。コンテンツを分類するのに、本当にカテゴリーを使うのが適切なのか、という疑問です。
我々はなぜ情報を分類するのか。それはファインダビリティ（発見しやすさ）を高めるためです。例えば今ここに、10万エントリーのコンテンツがあったとします。そのままずらっと並んでいる状態では、目的のコンテンツを探し出すことは、たいへん難しいといえます。もちろん不可能ではないのですが、かなりの時間的コストがかかってしまいます。そこで内容や形態といった属性によって、10万エントリーを複数のグループに分けていきます。これによって「見るべき範囲を限定」し、目的のコンテンツにたどり着くまでのコストを抑制する。これが「分類」の本質です。
そのための方法として最も歴史があるのがカテゴリー分けです。階層構造を持つカテゴリーは、人類による知的活動と同じくらい、長い歴史があるのではないでしょうか。しかし最近、他の方法が大きな注目を集めるようになってきました。それがタギング（タグ付け）です。ここ数年、ソーシャルブックマークや動画サイト、写真サイトなどで使われているアレです。ひょっとしたら階層的なカテゴライズよりも、タギングの方が優れているのではないか。そのように考えたのです。
そこで早速、ネット検索でカテゴリーとタグについて書かれたコンテンツを探し回りました。その多くはブログのエントリーとして書かれたものなのですが、PDFの形でアップされている論文や、学術誌の一部と思われるコンテンツもありました。これらを片っ端から読んでいくうちに、気がついたら1週間が過ぎてしまいました。
これらのコンテンツのほとんどは、階層的なカテゴライズの限界と、タギングの可能性について論じています。なるほどと頷いてしまうものも多く、たいへん参考になりました。正直言って、一時はカテゴライズはやめて、タギングでコンテンツを分類する方が良さそうだとも思いました。しかし今では、タギングよりもカテゴライズの方が、「ファインダビリティ」の観点から見れば優れている点が多いのではないかという結論に達しつつあります。
それはなぜか。
ここでカテゴライズの問題と、タギングのメリット/デメリットを整理してみたいと思います。
カテゴライズの問題を指摘するコンテンツはネット上に数多く存在しますが、これらが指摘する問題点をまとめると、大きくふたつに集約できます。
ひとつは「コウモリ問題」です。どちらのカテゴリーに属させるべきか判断しかねる対象が、必ず発生するというものです。例えば商品カテゴリーを考える時、「ガンダムの形をした携帯電話充電器」は、キャラクターグッズに入れるべきなのか、それとも携帯電話周辺機器に入れるべきなのか。このような例は、身の回りにいくらでも見つけることができそうです。好きなキーワードを複数自由に付けられるタギングであれば、このような問題はありません。「ガンダム」「携帯電話」「充電器」といったキーワードを付けておけばいいわけです。
もうひとつの問題は「事前に構造化を行う」ことのコストと柔軟性の欠如です。分類体系を作成するということは、その体系を作成する人の世界観を具現化することに他なりません。世界観が異なれば、分類方法も異なります。これはかなりの心理的コストを伴います。またいったん構造化された世界は、後で大きく変更するのにもコストがかかりそうです。新たなカテゴリーを追加するだけならまだいいのですが、既存のカテゴリーを削除したり、階層構造の中の位置づけを変更する場合には、そのカテゴリーに属するコンテンツのカテゴライズをすべて見直す必要があります。しかしキーワード間の構造化を行わないタギングであれば、この問題も解消できます。
しかしよく考えてみると「コウモリ問題」は、意外と簡単に解決できます。ひとつのコンテンツを複数のカテゴリーに結びつければいいわけです。技術的にも難しくはありません。
「事前に構造化を行う」ことのコストと柔軟性の欠如は、なかなか解決が難しそうです。しかしこのコストは、ある程度のファウンダビリティを担保する上で、重要な意味を持つのかもしれません。
タギングは自由で柔軟性が高いため、実装が簡単です。「実装が簡単」なんていうと誤解を招きそうなのでちょっと言い換えると、「事前に世界観を構築するコストは不要」だということです。しかし「世界観の欠如」は、ファインダビリティを低下させる結果になるのではないかと感じているのです。
例えばこのエントリーにタギングを行う場合、どのようなキーワードが考えられるでしょうか。「カテゴリー」「タグ」「分類」といったものが考えられると思います。ここで問題になるのが、複数の世界を持つ言葉の存在です。例えば「タグ」といった場合、分類のためのタグもあれば、HTMLのタグもある。また洋服などについているブランドタグも考えられます。コンテンツ側から言えば、ひとつのコンテンツに複数のタグがついているので、このコンテンツについている「タグ」の意味は「分類に使われるタグ」のことだとわかります。しかしコンテンツを検索する側から見れば、「タグ」というタグがついているコンテンツをリストアップすると、様々な意味の「タグ」というタグがついているコンテンツが選ばれてしまいます。（ああ、ややっこしい･･･）
もちろんこの問題は、検索時に複数のタグで絞り込む、という方法で解決できます。このアプローチが効果を持つようにするには、ひとつのコンテンツにできるだけ多くのタグを付けておく方がいい。その究極の姿は、コンテンツ内容に登場する言葉と、その言葉に近い言葉をすべてタグとして付与する、というものです。
実はこれに近いことを機械的に行っているのが、Googleだといえます。Googleはクロールしたコンテンツの内容を単語レベルまで分解し、そのすべてを検索キーワードとしてインデックス化しています。つまりコンテンツ内容に登場するすべての言葉がタグになっていると考えられます。タギングの究極の形は全文検索だというわけです。当然の帰結だと言えばそうなのですが、これはなかなかすごいことです。
それでは「タグの情報量が十分であれば、タギングはカテゴライズに取って代わるのか」といえば、必ずしもそうではないと思います。タギングには、他にもいくつかの問題があると考えられるからです。カテゴライズに限界があるように、タギングにも限界がある。もっと言ってしまえば、タギングのメリットは、そのデメリットと表裏一体の関係にある。さらにカテゴライズの限界も、そのメリットと表裏一体の関係にあるのです。
それではタギングには、他にどのような問題があるのか。これについては次回考えてみたいと思います。
ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
またしばらくご無沙汰しておりました。最近は仕事がボチボチ忙しいのもありますが、Webプログラミングで遊んだりもしていて、なかなか他の時間が取れません。で今回は、ちょっとしたプログラミングのネタです。
いま取り組んでいるのは「あるコンテンツ群をカテゴリーで分類してWebブラウザーに表示する」というものです。どうせなら「自由度が高くて、カテゴリー構成を変更してもコンテンツの修正しないですむ仕組み」ということで、ツリー構造のカテゴリーにしたのですが、これがなかなか手強いヤツなのです。
具体的なイメージがないと理解しにくいので、次のようなツリー構造のカテゴリーを考えてみましょう。カテゴリー名はいい加減なので、その部分では突っ込まないでください。階層構造を持つカテゴリーのサンプルです。
データは原則としてすべてMySQL、つまりRDBで管理することを前提とします。この場合、ツリー構造を最もシンプルに表現できるのは、次のようなデータ構造です。自分のID、親のID、自分のカテゴリー名という、3つのカラムを持つテーブルを定義すればいいわけです。
次にこのカテゴリーでコンテンツを分類するには、各コンテンツにカテゴリーID（category_id）を付与してあげればいい。そうしておけば、例えば「野球」に関係するコンテンツなら、
SELECT コンテンツID FROM コンテンツテーブル WHERE カテゴリーID = '野球';
といったSQL文を投げれば、検索できるわけです。（もちろん上のSQL文は考え方を示しただけなので、厳密には正しくありません。'野球'とあるのも、本当は'野球’というカテゴリー名を持つカテゴリーIDを記述すべきです）
ここまで考えて「なかなかいい感じ〜」と思っていたのですが、実はこの方法には大きな問題があります。'野球'で検索すると、'ジャイアンツ'や'タイガース'にカテゴライズされたコンテンツが、検索対象にならないのです。そりゃそうですよね。データベースには、ジャイアンツが野球のサブカテゴリーだということはわかりませんから。
でもこのままでは困ります。例えば'スポーツ'でカテゴリー検索した人は、当然ながらスポーツのサブカテゴリーも含めた検索結果が欲しいわけです。サブカテゴリーも含めた検索を実行するプログラムを作らなければ「この役立たず！」と思われても仕方ありません。
サブカテゴリーまで含んだ検索を実行するには、あるカテゴリーの下にどのようなサブカテゴリーがあるのか、リストアップする仕組みが必要です。実はこれがなかなか厄介な代物なのです。
例えば'スポーツ'に含まれるサブカテゴリーを調べたい場合、すぐに次のSQL文を思いつくわけですが、これでは十分ではありません。
SELECT カテゴリーID FROM カテゴリーテーブル WHERE 親のID = 'スポーツ';
これではジャイアンツとタイガースが検索結果に含まれないのです。実はツリー構造のサブセットに含まれるすべての要素をリストアップするには、再帰的な処理が必要なんですね。
ツリー構造は昔からあるものなので、当然ながらそれを扱うアルゴリズムもできあがっているはずです。そこでググッてみたのですが、なかなかきちんと説明したものが見あたらない。どうも「RDBでツリー構造を扱う」というのが、ひとつの壁みたいです。面白い方法を提唱している論文も見つかりましたが、あまり私の好みの方法ではありません。そこで自力で作ることにしたわけです。
ここでプログラムの前提を示しておきます。
まずカテゴリーテーブルは、MySQLの中に作成しておきます。テーブル作成のSQL文は以下の通りです。
create table category (
category_id int not null auto_increment,
parent_id int,
category_name varchar(255),
primary key(category_id)
);
このテーブルの中に、先ほどと同じ構造のカテゴリー情報を作っておきます。
insert into category ( parent_id, category_name )
values ( 0, "すべて" );
insert into category ( parent_id, category_name )
values ( 1, "スポーツ" );
insert into category ( parent_id, category_name )
values ( 2, "サッカー" );
insert into category ( parent_id, category_name )
values ( 2, "ゴルフ" );
insert into category ( parent_id, category_name )
values ( 1, "グルメ" );
insert into category ( parent_id, category_name )
values ( 5, "レストラン(外食）" );
insert into category ( parent_id, category_name )
values ( 5, "食品(中食）" );
insert into category ( parent_id, category_name )
values ( 2, "野球" );
insert into category ( parent_id, category_name )
values ( 5, "レシピ" );
insert into category ( parent_id, category_name )
values ( 1, "エンターテイメント" );
insert into category ( parent_id, category_name )
values ( 10, "音楽" );
insert into category ( parent_id, category_name )
values ( 10, "映画" );
insert into category ( parent_id, category_name )
values ( 2, "スキー" );
insert into category ( parent_id, category_name )
values ( 10, "演劇" );
insert into category ( parent_id, category_name )
values ( 10, "美術" );
insert into category ( parent_id, category_name )
values ( 8, "ジャイアンツ" );
insert into category ( parent_id, category_name )
values ( 8, "タイガース" );
insert into category ( parent_id, category_name )
values ( 10, "テレビ・ラジオ" );
insert文でcategory_idの指定をしていないのは、自動的にインクリメントした値を挿入するように、テーブル作成の時に定義しているからです。また後からカテゴリーが追加された場合をイメージして、インサートの順序をばらばらにしています。
さてこのような構造のカテゴリーテーブルの中から、特定のカテゴリー以下のサブセットを抜き出すにはどうすればいいのでしょうか。私が今日、ガストで昼食を食べながら考えたのは次のようなものです。
そんなに難しいものではありません。あるカテゴリーのIDを指定して処理を呼び出すと、そのサブカテゴリーのリストが、直感的に理解できる順番で$indexに格納されます。おそらく同じアルゴリズムは、昔からあるはずです。（私が見つけられなかっただけ）
実際のプログラムは以下の通りです。 （HTMLタグの部分を2バイト文字に置き換えてあるので、そのままコピペしても動きません。そうしないとブログの中でうまく表示されなかったので･･･）
＜?php
require ( "config.php" );
$index = category_sub_list( $_GET['cat'] );
$value = array();
foreach ( $index as $value ){
echo $value['name'] . " : " . $value['level'] . " ＜br＞";
}
function category_sub_list( $id ){
$ptr_i = 0;
$ptr_s = 1;
$stack = array();
$index = array();
$stack[$ptr_s]['id'] = $id;
$stack[$ptr_s]['level'] = 0;
$stack[$ptr_s]['name'] = '';
$db = new mysqli ( DB_HOST, DB_USER, DB_PASSWORD, DB_NAME )
or exit( "DB Connect Error..." );
$stmt = $db->prepare( "select category_id, category_name from category
where parent_id = ?
order by category_id desc" )
or exit( "DB Prepare Error..." );
while ( $ptr_s > 0 ){
$index[$ptr_i] = $stack[$ptr_s];
$ptr_s = $ptr_s - 1;
$stmt->bind_param( 'i', $index[$ptr_i]['id'] )
or exit( "DB Parameter Bind Error..." );
$stmt->execute()
or exit( "DB Access Execute Error..." );
$stmt->bind_result( $r_category_id, $r_category_name );
while ( $stmt->fetch() ){
$ptr_s = $ptr_s + 1;
$stack[$ptr_s]['id'] = $r_category_id;
$stack[$ptr_s]['name'] = $r_category_name;
$stack[$ptr_s]['level'] = $index[$ptr_i]['level'] + 1;
}
$ptr_i = $ptr_i + 1;
}
$stmt->close();
return $index;
}
?＞
この内容を「test.php」というファイル名で保存し、WebブラウザのURL入力の場所で「http://localhost/test.php?cat=○」（○にはカテゴリーIDを当てはめます）と記述すれば、サブカテゴリーのリストが、そのカテゴリーからの階層レベルの値と一緒に表示されます。例えば○に1を入れてアクセスすれば、下のように表示されるわけです。
とりあえずはこれで、制約のない階層構造のカテゴリーが扱えるようになりました。最近忘れっぽいので、ブログに残しておくことにします。そうそう、プログラム冒頭で呼び出しているconfig.phpですが、ここにはMySQLアクセスに必要な情報が、定数の形で定義されています。DB_HOST とか DB_USER、 DB_PASSWORD、DB_NAME がそれです。これらの情報はあまり公表したくないので秘密。皆さんの環境に合わせて、適当に決めてくださいね。
ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
ここ数年で、迷惑メールの数がものすごく増えましたね。
私の場合、受信メールのうち7〜8割は迷惑メールです。
以前はメーラーで受信した後、迷惑メールをひとつずつ削除していたのですが
最近ちょっとだけ、いい方法がみつかりました。
それはGmailの迷惑メールフィルタリング機能を使う方法です。
実はiPod touchを買うまで、Gmailを使ったことはなかったんです。
すでにメールアドレスを、公開しているものだけでも3つ持っていましたし
非公開のものもいくつか持っていたので、
これ以上メールアドレスを増やすのもなあ、と思っていたわけです。
でもiPod touchでWebアクセスをするようになると
WebメールでiPodからメールチェックできれば便利だなあ、
と思うようになりました。
そこでGmailのアカウントを取って、
これまで使っていたアドレスのメールを転送するようにしたんです。
はじめは「フリーメールなんだから」とそれほど期待していなかったのですが
使い続けていると、かなり強力なメーラーであることがわかりました。
まず第1に、Webメールとしてだけではなく、
POPサーバーとしても使えるし、
POPクライアントとしても使えます。
さらに最近は、IMAPサーバーとしても使えるようになりました。
第2に、迷惑メールフィルターの機能がすごい。
ごくたまに、おかしな振り分けになることもありますが、
この2ヶ月間使った感じでは、99％以上の確率で、
迷惑メールをフィルタリングできています。
実は私、Outlook 2003をメーラーにしています。
もうずいぶん前からOutlookを使っていて
慣れてしまえばなかなか悪くないメーラーです。
ただ迷惑メールフィルターの機能が、ほとんど使い物になりません。
メール送信元のアドレスで判別しているみたいなのですが
迷惑メールって、どんどんアドレスが変わってしまうので
いくらOutlookに迷惑メールの登録を行っても、
すぐに意味がなくなっちゃうのです。
で、もう半ばあきらめていたのですが、
迷惑メールをひとつずつ削除するのは、やはり鬱陶しい。
それに必要なメールよりも迷惑メールの方が数が多いので
削除作業をしている間に必要なメールまで削除する危険性もあります。
でもGmailを使えば、この問題も簡単に解決できそうです。
そこでさっそく、メール受信の経路に、
Gmailを入れてみることにしました。
携帯電話へのメール転送も行っていたため、
以前は次のような経路でメールを受信していました。
我ながら、けっこう面倒なことをしていると思います。
非公開アドレスにメール転送しているのは、2つの理由から。
ひとつは携帯電話への転送設定を簡単にするため。
携帯電話って、いつ買い換えることになるかわかりませんからね。
（といいつつ、今の携帯電話をもう3年以上使っていますが）
もうひとつの理由は、受信メールのバックアップを用意しておきたいから。
たとえばOutlookで受信した時に、誤操作でメールがなくなっても
非公開アドレスから受信したものがあれば復元できるというわけです。
ここにGmailをかませる方法としては、
非公開アドレスからのメール転送と
GmailをPOP3クライアントにする方法があります。
今回は後者を採用しました。
実は携帯電話にメール転送する時、
サイズの大きい添付ファイルがついていると
メール送信者にエラーが返ってしまうのですが
いったんPOP3でメール転送の経路を切っておけば
このような問題も解決できそうだからです。
その結果、できあがったのが次のような構成です。
Gmailの迷惑フィルターを使うので、
OutlookへのPOP3メール受信はGmailから行います。
POP3で「サーバーにメールを残す」設定にしておけば
Outlookに受信した後もGmailにメールが残るので
バックアップ受信は必要ありません。
ただ、Gmail側で複数のPOP3アカウントを設定するのが面倒なので
非公開アドレスはそのまま使うことにします。
携帯電話へのメール転送は、Gmailから行います。
さらにGmailのIMAPサーバー機能を使い
iPod touchからもアクセスできるようにしてあります。
こうすることで、ネットにアクセスできれば、
いつでもiPodからメールを確認できるようになります。
また迷惑メールフォルダーに必要なメールが紛れ込んでいないか
確認する作業も、iPod touchのメーラーで行えます。
この構成に切り替えてからまだ1週間ほどなのですが
手作業で迷惑メールを削除しなくていいので、とても快適です。
Gmail、なかなか使えるヤツです。
フリーだからといって、侮れませんね。
ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
最近、仕事がメチャ忙しくなってます。
何度かあった3連休も、結局オフィスで過ごすことになりました。
なんてこと言いつつ、PC環境の改善なんかもやってました。
前回、設定変更でレスポンスが速くなった話をしましたが、
メモリーの増設も、ちょっとトライしてみたのです。
ノーブランドのバルクメモリーで、1GBが2枚セットになったものを買ってきて
いま1GB×2になっているメモリー構成を、1GB×4の4GBにしてみました。
結果を先に言ってしまうと･･･撃沈です。
4枚にしてブートしたら、画面がグチャグチャになってしまいました。
HDDの動きを見ると、Windows XPは起動されているようなのですが、画面が･･･
この後メモリーをセットしなおして再度ブートすると、今度は正常に起動。
しかし10分ほどしたら、いきなりリブートがかかってしまいます。
これはメモリーの相性が悪かったのだとあきらめて、また2GBに戻しました。
それからスピーカーを新しくしました。
実は新しい環境にして初めて気がついたんですが
スピーカーの左右が逆になっていたんです。
PC用のアクティブスピーカーを使っていたんですが
PCに近い方のスピーカーが右、もう一方が左、という接続なのです。
しかもケーブルがスピーカーに直づけになっているので、
左右の入れ替えができません。
このオフィスに引っ越す前はPCがデスクの右側にあったので問題なかったのですが
いまの環境はPCがデスクの左側にあるため、
普通に並べると左右が逆になってしまう、というわけです。
まあ、もう古いスピーカーだし、音もそんなによくないので
せっかくPCを新しくしたのでスピーカーも新調しようと。
ヨドバシアキバでEDROL MA-7Aというモニタースピーカーを約1万円で購入。
この製品は音にパンチがあってなかなかいい感じです。
ケーブルもピンジャックで入力するようになっているので
左右を逆にすることも簡単にできます。
で、メインPCを使っているいまのデスク周りはこんな感じ。
次はディスプレイを新しくしたいな〜、なんて考えてます。
ところで･･･
キンモクセイの季節になりましたね〜。
街中を歩いていると、甘いにおいが漂ってきます。
このにおいが好きな人も多いと思うのですが
実は私･･･このにおいが苦手なんです。
キンモクセイのにおいをかぐと、トイレの芳香剤を思い出すんです。
それも、30年くらい前に錦糸町にあった、古い映画館のトイレ･･･
これを反射的に連想しちゃうので、あまり好きではありません。
でもキンモクセイを植えている家って、けっこう多いですよね。
どこにいっても甘いにおいがするので、この季節は苦手です。
ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
