カテゴリーとタグの実装
2008年7月22日
Twitterでのカテゴリーとタグに関する議論からひぐちさんが導き出された結論が非常に明快で、まさに目から鱗状態。Jeansの仕様を考える上で、NucleusのMultipleCategoryをJeansのコアで実装することばかりに考えが行っており、頭が凝り固まっていたようだ。
そもそも、カテゴリー分けという概念では、multipleの状態は少々おかしいというか、過大解釈の面があるのかもしれない。１アイテム←→１カテゴリーが、基本的な考え方。multipleに指定したいときは、タグを使うと考えたほうが、スッキリする。
今まで自分ではタグの必要性を感じなかったので使っていなかった。考えてみれば、複数のカテゴリーが選択できる仕様のNP_MultipleCategoryが、このタグの考え方を包括している。それが、タグの必要性を感じなかった原因だったのであろう。
もともとNP_MultipleCategoryの機能はJeansに入れる予定であったので、これをmultipleでない、ツリー構造を構築可能なsub categoryのみとし、別途タグもサポートするということで、よさそう。これだと、SQLのカテゴリーテーブルはNucleusのものとほとんど同じで、親カテゴリを指定するためのカラムを一つ追加するだけでよい。アイテムとカテゴリの関係は、OSにおけるファイルとディレクトリの関係と同じ。カテゴリーのツリー構造を保存するためのテーブルを一つ作成しておけば、より下層のカテゴリに属するアイテムをピックアップするのも、一つのSQLクエリーで効率よく出来るはず。
一方で、タグの実装用に、２つテーブルを作成。１つ目のテーブルは、タグ名とタグIDを関連付けるためのもの。２つ目のテーブルは、タグIDとアイテムIDを関連付けるためのもの。２つのテーブルに分けないといけないのは、一つのアイテムに複数のタグを割り当てたり、一つのタグに複数のアイテムを割り当てたりする必要があるため。
そもそも、カテゴリー分けという概念では、multipleの状態は少々おかしいというか、過大解釈の面があるのかもしれない。１アイテム←→１カテゴリーが、基本的な考え方。multipleに指定したいときは、タグを使うと考えたほうが、スッキリする。
今まで自分ではタグの必要性を感じなかったので使っていなかった。考えてみれば、複数のカテゴリーが選択できる仕様のNP_MultipleCategoryが、このタグの考え方を包括している。それが、タグの必要性を感じなかった原因だったのであろう。
もともとNP_MultipleCategoryの機能はJeansに入れる予定であったので、これをmultipleでない、ツリー構造を構築可能なsub categoryのみとし、別途タグもサポートするということで、よさそう。これだと、SQLのカテゴリーテーブルはNucleusのものとほとんど同じで、親カテゴリを指定するためのカラムを一つ追加するだけでよい。アイテムとカテゴリの関係は、OSにおけるファイルとディレクトリの関係と同じ。カテゴリーのツリー構造を保存するためのテーブルを一つ作成しておけば、より下層のカテゴリに属するアイテムをピックアップするのも、一つのSQLクエリーで効率よく出来るはず。
一方で、タグの実装用に、２つテーブルを作成。１つ目のテーブルは、タグ名とタグIDを関連付けるためのもの。２つ目のテーブルは、タグIDとアイテムIDを関連付けるためのもの。２つのテーブルに分けないといけないのは、一つのアイテムに複数のタグを割り当てたり、一つのタグに複数のアイテムを割り当てたりする必要があるため。
コメント
藤咲 (2008年7月22日 17:59:42)
カテゴリにマルチがいらないかというとそれが難しいところで…。
例えば、私の
「本棚ともろもろ」
http://fjsk.tk/Books/
では、「ジャンル別」「レーベル別」「著者別」という3親カテゴリがあって、各本はかならずどのカテゴリにも属するわけです。かつ、アンソロジー本とかだと著者が複数という事もあります。
この中でまだジャンル別は3サブカテゴリでいいんですが、「レーベル別」は54、「著者別」は340という膨大なサブカテゴリ数で、たとえば著者が複数だからといってこれをタグとしてしまうと、標準のタグクラウドではかなり閲覧しにくくなってしまいます。
で、このサイトにタグを使うとするなら、親カテゴリという形でまとめにくい「属性」を振るのがいいのだろうな、と思ってます。
たとえば、「ツンデレ」「ファンタジー」「もう買わない」「最終巻」「正直惰性で買ってる」とか。
（いい考えと、今書いていて思いました。ただ現在1000件近いのでタグを振りなおすのは現実的じゃないですが…）
ということで、ニッチなのかもしれないのですがマルチカテゴリを捨ててしまう、というのも再考して欲しいなぁと思ったりします。すみません、ニッチなくせに余計な事言って…。
例えば、私の
「本棚ともろもろ」
http://fjsk.tk/Books/
では、「ジャンル別」「レーベル別」「著者別」という3親カテゴリがあって、各本はかならずどのカテゴリにも属するわけです。かつ、アンソロジー本とかだと著者が複数という事もあります。
この中でまだジャンル別は3サブカテゴリでいいんですが、「レーベル別」は54、「著者別」は340という膨大なサブカテゴリ数で、たとえば著者が複数だからといってこれをタグとしてしまうと、標準のタグクラウドではかなり閲覧しにくくなってしまいます。
で、このサイトにタグを使うとするなら、親カテゴリという形でまとめにくい「属性」を振るのがいいのだろうな、と思ってます。
たとえば、「ツンデレ」「ファンタジー」「もう買わない」「最終巻」「正直惰性で買ってる」とか。
（いい考えと、今書いていて思いました。ただ現在1000件近いのでタグを振りなおすのは現実的じゃないですが…）
ということで、ニッチなのかもしれないのですがマルチカテゴリを捨ててしまう、というのも再考して欲しいなぁと思ったりします。すみません、ニッチなくせに余計な事言って…。
yu (2008年7月22日 18:54:03)
僕もマルチカテゴリーにはタグとは違った存在意義があると思うほうです。ただカテゴリーは階層化のみにとどめておくほうが構造的にシンプルで美しいのも確かですね・・。
最終的にはJeansの利用シーンをどこまで想定するかによるんじゃないでしょうか。ブログよりひとまわり大きい意味でのCMSを本格的に指向するかどうか。
最終的にはJeansの利用シーンをどこまで想定するかによるんじゃないでしょうか。ブログよりひとまわり大きい意味でのCMSを本格的に指向するかどうか。
Kat (2008年7月22日 19:05:13)
余計な事ってことはないですよ。なるほどと思いました。
これはつまり、タグにもツリー構造が必要なケースがあると捉えて、良いですか？
Nucleusコアのデータ構造としては、ブログの下に複数のカテゴリーがあり、カテゴリーの下に複数のアイテムがあります。逆に考えると、一つのアイテムには一つのカテゴリー、一つのカテゴリーには一つのブログが対応しないといけないんですね。なので、これを拡張するのなら、単にツリー構造を追加するというのが一番分かりやすいんです。
逆に、今のタグの実装にツリー構造を追加すると、藤咲さんおっしゃるケースにも対応できるはずです。運用によって、カテゴリーでツリーを使うか、タグでツリーを使うか分ければ良いのだと思います。場合によっては、タグは使わない、もしくはカテゴリーは使わないという運用の仕方もアリです。
だとすると、ツリー構造を管理する部分を一つのエンジンにしておけば、全体のコードもスッキリしますね。何かのプラグインで別のツリー構造を管理しないといけないようなケースにも対応できます。
これはつまり、タグにもツリー構造が必要なケースがあると捉えて、良いですか？
Nucleusコアのデータ構造としては、ブログの下に複数のカテゴリーがあり、カテゴリーの下に複数のアイテムがあります。逆に考えると、一つのアイテムには一つのカテゴリー、一つのカテゴリーには一つのブログが対応しないといけないんですね。なので、これを拡張するのなら、単にツリー構造を追加するというのが一番分かりやすいんです。
逆に、今のタグの実装にツリー構造を追加すると、藤咲さんおっしゃるケースにも対応できるはずです。運用によって、カテゴリーでツリーを使うか、タグでツリーを使うか分ければ良いのだと思います。場合によっては、タグは使わない、もしくはカテゴリーは使わないという運用の仕方もアリです。
だとすると、ツリー構造を管理する部分を一つのエンジンにしておけば、全体のコードもスッキリしますね。何かのプラグインで別のツリー構造を管理しないといけないようなケースにも対応できます。
Kat (2008年7月22日 19:10:38)
yuさん。
もともとは、藤咲さんおっしゃる形でのMultipleCategoriesを実装する予定だったので、このあたりはしっかり入れたいと思います。
Jeansの場合、コアへの機能追加は比較的簡単に出来る構造になっているので、どんな機能をコアに持たせるかはフレキシブルに出来ると思います。初めはシンプルにしておいて、後で追加も可能です。
もともとは、藤咲さんおっしゃる形でのMultipleCategoriesを実装する予定だったので、このあたりはしっかり入れたいと思います。
Jeansの場合、コアへの機能追加は比較的簡単に出来る構造になっているので、どんな機能をコアに持たせるかはフレキシブルに出来ると思います。初めはシンプルにしておいて、後で追加も可能です。
藤咲 (2008年7月22日 19:32:01)
>これはつまり、タグにもツリー構造が必要なケースがあると捉えて、良いですか？
そう捕らえてもらってもいいと思います。実際に見た目をツリー構造とせず、パンくず的な絞込みGUIもおもしろいと思います。
例：うちの著者別で言うなら、
カテゴリのクラウドとして
「ツンデレ」「ファンタジー」「もう買わない」「最終巻」「正直惰性で買ってる」「著者」「レーベル」と並んでいて、このうち「著者｣と「レーベル」は階層構造としておきます。
で、「著者」をクリックしたときに、その下に「あ行 か行 さ行 … わ行」と表示をさせ、さらに「あ行」をクリックしたら著者名のクラウド(実際にはそれでも多すぎるので「あ」「い」「う」になりそうですが)を表示、とすればタグでも探しやすいナビゲーションが出来ると思います。
難点としてはタグクラウドの並び順をわかりやすくしたいならタグに振り仮名欄がいる(現在はサブカテゴリの説明欄に振り仮名を入れてならべてます）
ということでしょうか。でもタグに振り仮名とか説明欄ってそぐわない気もするんですよね…。
そう捕らえてもらってもいいと思います。実際に見た目をツリー構造とせず、パンくず的な絞込みGUIもおもしろいと思います。
例：うちの著者別で言うなら、
カテゴリのクラウドとして
「ツンデレ」「ファンタジー」「もう買わない」「最終巻」「正直惰性で買ってる」「著者」「レーベル」と並んでいて、このうち「著者｣と「レーベル」は階層構造としておきます。
で、「著者」をクリックしたときに、その下に「あ行 か行 さ行 … わ行」と表示をさせ、さらに「あ行」をクリックしたら著者名のクラウド(実際にはそれでも多すぎるので「あ」「い」「う」になりそうですが)を表示、とすればタグでも探しやすいナビゲーションが出来ると思います。
難点としてはタグクラウドの並び順をわかりやすくしたいならタグに振り仮名欄がいる(現在はサブカテゴリの説明欄に振り仮名を入れてならべてます）
ということでしょうか。でもタグに振り仮名とか説明欄ってそぐわない気もするんですよね…。
Kat (2008年7月22日 19:38:41)
なるほど、パンくずリストの実装も、ツリーの一元管理の中に入れておくと便利かもしれませんね。
並び順については、とりあえずは<!-- 010 -->などの接頭辞を付けることで対応できると思います。もう一つの方法は、twitterでまみおさんがつぶやいていた、orderIDの実装です。この実装自体は難しくないのですが、編集画面の作成が面倒なので、後回しになりそうです。
ツリーの表示にはテンプレートを使うようにしたいと思います。そのほうが、後々、楽だと思うので。
並び順については、とりあえずは<!-- 010 -->などの接頭辞を付けることで対応できると思います。もう一つの方法は、twitterでまみおさんがつぶやいていた、orderIDの実装です。この実装自体は難しくないのですが、編集画面の作成が面倒なので、後回しになりそうです。
ツリーの表示にはテンプレートを使うようにしたいと思います。そのほうが、後々、楽だと思うので。
藤咲 (2008年7月22日 21:36:14)
><!-- 010 -->などの接頭辞を付けることで対応できると思います
コメントって、タグの中に入れると表示されちゃいませんか？(^^;
いや、絞り込んだ結果を少なくなるように絞込みツリー構造を工夫すれば、クラウド的表示ではあまり並び順は関係ないとは思うんで、ないならないでなんとかなるんだとは思うんですけども。
コメントって、タグの中に入れると表示されちゃいませんか？(^^;
いや、絞り込んだ結果を少なくなるように絞込みツリー構造を工夫すれば、クラウド的表示ではあまり並び順は関係ないとは思うんで、ないならないでなんとかなるんだとは思うんですけども。
Kat (2008年7月22日 23:53:21)
タグ使ったことがないので、定かではありません。(^^;
カテゴリーの場合はこの手が使えるので、タグでも大丈夫だと思ってました。htmlspecialchars()通しているのですね。考えてみたら、タグというものは記事を書く人が自由に追加できるようにしないといけないだろうから、HTMLタグ付きのタグ名を許可するのは無理かも（特に、複数ユーザの場合）。
後で気がついたのですが、やはりorderIDを実装して、はじめは手打ちで数字を入れるのでいいのかもしれません。おいおい、JavaScriptを使った編集画面を作るという方向で。
カテゴリーの場合はこの手が使えるので、タグでも大丈夫だと思ってました。htmlspecialchars()通しているのですね。考えてみたら、タグというものは記事を書く人が自由に追加できるようにしないといけないだろうから、HTMLタグ付きのタグ名を許可するのは無理かも（特に、複数ユーザの場合）。
後で気がついたのですが、やはりorderIDを実装して、はじめは手打ちで数字を入れるのでいいのかもしれません。おいおい、JavaScriptを使った編集画面を作るという方向で。
yu (2008年7月23日 00:17:55)
マルチ・サブカテ機能の実装をサブ＋マルチという形で分けて、マルチの部分は内部的にタグとデータ構造を共有しておくというイメージですかね？
タグはカテゴリーと違っていくらでも新しいワードを階層関係を気にせず追加していける気安さがあるので、そのへんの使い勝手を外部的に（UI的に）抑圧しない作りになっていれば内部的にはどういう形になっていてもOKかもしれません。
タグはカテゴリーと違っていくらでも新しいワードを階層関係を気にせず追加していける気安さがあるので、そのへんの使い勝手を外部的に（UI的に）抑圧しない作りになっていれば内部的にはどういう形になっていてもOKかもしれません。
Kat (2008年7月23日 00:41:53)
yuさんの言葉を借りて説明すると、
マルチ・サブカテ機能の実装をサブ＋マルチという形で分けて、マルチの部分はタグの機能として提供する。
という感じです。で、サブカテとタグは全くの別空間で、データを保存するSQLテーブルも別物です。
マルチ・サブカテ機能の実装をサブ＋マルチという形で分けて、マルチの部分はタグの機能として提供する。
という感じです。で、サブカテとタグは全くの別空間で、データを保存するSQLテーブルも別物です。